We use Message Broker to communicate between different service components. One of the requirement, after one of the clients logs in, firstly, we need to send him a large amount of historical data (trade data for the last day) to init UI, after that client receives subsequent trade data updates in real-time. All data provided by our back-end servers which should push data to our server which is responsible for client data, servers communicate over MQ. Given that it might be not a good idea to send a lot of data when a member logs in over MQ because of MQ message size limitation, we either need to split a historical message into single messages - but this will be lots of data in the MQ which can affect the performance of our MQ. One more approach is to fetch historical data with REST and receive subsequent updates with MQ, but this can cause unsync situation: while we wait for REST results to travel to the server responsible for handling front-end clients, more trades might happen and we will need to run some reconciliation logic to filter out trades from MQ in our REST message response or apply them - doesn't not look quite good to me. how would you approach this problem given you have MQ Broker (RabbitMQ)? 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 mechanical-sympathy+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Great suggestion Mike, can be even simplified by sending snapshot on same channel as incremental updates,. By doing this you will not need any buffering.
On 17-Apr-2017 11:17 PM, "Vero K." <vero....@gmail.com> wrote:
Thanks, Mike. useful input
--
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 mechanical-sympathy+unsubscribe...@googlegroups.com.