-
Bug
-
Resolution: Done
-
Major
-
None
-
None
The bundler is supposed to send a bundle (batch) of messages when (1) the size of the queued messages exceeds max_bundle_size or (2) when max_bundle_timeout milliseconds have elapsed. We're starting a timer whenever we add a message. Now consider this case (max_bundling_timeout=300ms):
T 0: add M1 --> timer1 is scheduled to be run at T+300
T 50: add M2 --> timer2 is scheduled to be run at T + 350
T 350: add M3 --> timer1 is scheduled to be run at T + 650
When timer1 goes off, it will actually send all queued messages at T+300, including M1 and M2.
However, M3 will be sent by timer2 at T+350, which is not correct, as it was received after T300, so it should be sent at T600 ! (We're assuming of course that max_bundle_size has not been exceeded)
To experiment with different bundler strategies, we should make Bundler an interface and provide different implementations !
One implementation could use a ConcurrentLinkedQueue, which has no lock contention on addition and removal. A bundler thread removes messages and sends them as batches. The marshalling and sending could potentially be delegated to a thread pool.
- is duplicated by
-
JGRP-1083 TP: remove sending from critical path
-
- Closed
-