For a similar problem I will only let one message for a given "key" remain in the queue to be sent.
So if a client is slow, they'll receive the most recent message for a key but loose intermediate ones. -pete -- peter royal - (on the go) > On Apr 14, 2017, at 5:03 AM, Vero K. <[email protected]> wrote: > > hi, we want to stream fx rates over websockets and need to find out how to do > it properly. we open socket for every connection and it has a buffer, now if > the buffer is full it might cause a problem, on the other side if our client > is slow as some point we need to drop connection. how would you implement > rates streaming over websockets to handle this? would you consider to put an > additional buffer of some size (for example disruptor queue) for every > client, pick up data from there and put into socket buffer and in case if it > full, keep a message in disruptor and after socket buffer is free, publish it > to the client? and if disruptor q. is full, disconnect a client? do you think > it is a good solution or how it is usually handled? we use java for our > project. > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
