Hi All,
I have a question if someone can help. I am doing some testing and I am hitting wsfull but I can’t track down what is causing it. I dont see any tables that are big enough to cause this. I am publishing quite a lot of data to a client using .u.pub, is it possible to accumulate memory by doing this? If the client is slow to process messages could that possible cause wsfull? I know .u.pub is async so I dont think it should be affected by the client at all.
Hi Roni,
If you are publishing a lot of data to a client, it is possible that the client/subscriber isn’t able to process the data quickly enough to keep up with your q process.
You should be able to see this with z.W:
q).z.W
3| 80031 80031 80031 80031 80031 80031 80031 80031 80031 80031 80031 80031 80..
In this case, the client (3) is not processing messages and they are building up on the outbound queue of the process that is publishing the messages.
Clients can affect the upstream processes which are publishing data to clients. Chained tickerplants are used to help protect the main tickerplant from getting affected by slow subscribers.
You might also consider throttling the data that you are publishing to the client as well.
Regards,
Paul
Hi,
Yes if you have a slow subscriber data will end up buffered on the TP and will deliberately exit if the -w limit is reached.
If the TP is receiving data faster than it can process, it could also lead to upstream processes exiting due to memory limits e.g. the FH could exit if the TP can’t write data to the log file as quick as it needs to. This can happen if the log file is being written to over NFS for example.
Check the .z.W dict and examine the byte queues for the various connected processes. Include some logging (.Q.w) at regular intervals to monitor usage on your processes and you should be able to eventually zone in on the issue.
Jason
Got it, Thank you guys very much, very helpful.