thanks, but losing msgs won't work for us: either wait and disconnect or consume all
On Friday, April 14, 2017 at 4:00:07 PM UTC+3, peter royal wrote: > > 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] <javascript:>> > 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] <javascript:>. > 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.
