Closed rerpha closed 6 hours ago
Am interested in the answer to this. I think we have it working with around 36000 existing PVs, some of which are 4000 point waveforms (the PVs are not sumulated).
Yes, there may be a few things you need to adjust in your tomcat setup. Details depend on your installation and usage patterns. For me, running on a tomcat instance that's shared with other apps, it was in the conf/server.xml
where the acceptCount
had to be increased. For some reason, I see bursts where many clients connect. The maxThreads
wasn't actually reached, but clients still got blocked. That turned out to be an acceptCount
issue, which I had to increment to
<Connector port=... acceptCount="200"
from its default of 100 to better handle those bursts.
Feel free to add an example with your textBufferSize
to the README.
This may be more of a question than anything, feel free to close if you think it's correct behaviour.
If i try and subscribe to say 1000 PVs at once I get an error
1009 Message too big: The decoded text message was too big for the output buffer and the endpoint does not support partial messages
I think this because it's hitting a default message size limit on a message, according to the tomcat docs here:
Can we up this at all? if we said PV names had a char limit of 80 (think this is right for epics v7?), then 1000*80(plus the number of bytes for the subscription prefix) should be sufficient? I guess this can't be changed per-tomcat-instance?
To reproduce this I wrote a python one-liner to generate a huge subscription message, then used postman to send it to PVWS.
import json; print(f'{{ "type": "subscribe", "pvs": {json.dumps([f"sim://noise(1,{x},1)" for x in range(1,1000)])} }}')