[ https://issues.jboss.org/browse/ISPN-6799?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-6799: --------------------------------------- Rather than modelling each "need to reply" with a thread, couldn't we have a clever data structure which collects all the responses-to-be-sent. I believe this was shared during past face to face meetings, so to recap the high level concepts: You'd have a limited number of threads periodically scanning this and sending them out in batches. The collection would need to be: - somewhat fairly ordered to make sure that no response waits too long - efficiently drop those responses which already waited too long - organised by target address, so it can be scanned efficiently for multiple answers which need to be batched to the same address: there's high likelihood for many responses to need to in the same "direction" Contention, context switches (and complexity) could be minimised by doing all this in a single thread in a disruptor-style queue, at most sharding by a combination of segment-id and target-address to achieve multiple "shared nothing" structures, maintaining each queue as a fully independent highway lane. This would also remove some pressure from the batching done at JGroups level as many small messages will already be delivered "packed by target" at JGroups - we might even consider disabling the JGroups batch features and that would improve latency. On top of this, I believe that such a design would allow us to (in future) enhance JGroups to not always need to hold on the entire message payload for the retransmission table but rather keep a hook to the Infinispan's "queue of outbound messages", re-marshalling on demand; this might also need an entry "snapshot" mechanism to re-transmit fragments of the original value if it changed, or a protocol improvement to rather undo the other fragments and re-send with the updated value. -- This message was sent by Atlassian JIRA (v6.4.11#64026)