ornl-epics / pvws

PV Web Socket: Channel Access, PV Access, simulated PVs, ... via a ws://
BSD 3-Clause "New" or "Revised" License
21 stars 15 forks source link

subscribe request limit #30

Closed rerpha closed 6 hours ago

rerpha commented 1 day ago

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:

The default buffer size for text messages is 8192 bytes. This may be changed for a web application by setting the servlet context initialization parameter org.apache.tomcat.websocket.textBufferSize to the desired value in bytes.

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)])} }}')

GDH-ISIS commented 1 day 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).

kasemir commented 1 day ago

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.