"clebert.suconic(a)jboss.com" wrote : Say you are sending two large message with 2 chunks each. | | The client will send packets to the server on this order: | | SessionSendMessage A1 (header) | SessionSendContinuationMessage A2 (chunk last=false) | SessionSendcontinuationMessage A3 (chunk last=true) | | SessionSendMessage B1 (header) | SessionSendContinuationMessage B2 (chunk last=false) | SessionSendcontinuationMessage B3 (chunk last=true) | | | The regular process on ServerSesionImpl should be: | | A1 received -> CurrentLargeMessage set on the Session | A2 received -> add bytes on the currentLargeMessage | A3 received -> add bytes on the currentLargeMessage, and route it, and clean currentLargeMessage | | B1 received -> CurrentLargeMessage set on Session | B2 received -> add bytes | B3 received -> add bytes, route and clean currentLargeMessage | | | But when we are playing the replication, the flow is delayed and B1 could be received while A3 still being processed. | | I would get the destination from the currentLargeMessage, but I can't play with it as it could be changed in another thread. | | I could make it work nicely after finding a few NPEs here and there.. but the code would be cleaner if I could just wait the first and the last package return from the backup node in certain places. No, you can't block for replication to complete, that would really slow things up. You would be limiting all message sending to the RTT of replication! That's a pretty core principle and it applies to all commands, we shouldn't block replicating any commands. Instead you should just store the LargeMessage in a ConcurrentQueue and pull it off as the replications come back. The replication will always come back in the correct order. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4202669#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...