[ https://issues.jboss.org/browse/JGRP-1405?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1405: --------------------------- Fix Version/s: 3.1 (was: 3.2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1405?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1405: -------------------------------- Looking at this, perhaps I don't even want a producer/consumer pattern in play here, as the consumer always needs a separate thread. OTOH, the DefaultBundler has up to 2 tasks in the timer, and those tasks are created frequently, which is not nice, either. So perhaps a good solution would be to combine the DefaultBundler (which has the thread which exceeds the max_bundle_size write the bundled messages) with using pools of hashmaps and *removing the timer tasks*. The latter could be accomplished using the following algorithm: - In general we need to be able to identify a 'batch' of messages. In the solution above, this is identified by pulling non-null messages from the queue - When we have a thread that acceses the bundler, it doesn't know whether it should bundle the message and return, or send the message immediately, mainly because it doesn't know whether there will be another thread immediately after it, which will send the bundled messages. The thread does know whether or not it has to send the bundled messages by checking count against count + msg.size(). - Example: a thread comes into the bundler and adds its message (2000 bytes) to the count (4000). The total is now 6000 bytes, which is well below the max_bundle_size (60000). The DefaultBundler now starts a timer which will elapse after max_bundle_timeout ms (say 30 ms). However, if we don't have such a timer, the thread reaching a count of 6000 bytes has no way of knowing whether it should simply return (and hope that there is a thread after it which will send the bundled messages), or send the bundled messages right away. The solution to this is an atomic counter: - When a thread enters the bundler (*before* acquiring the lock), it increments a counter - After potentially sending the bundled messages and adding the new message, it decrements the counter (inside the lock) - If the counter is 0, the thread knows that there aren't any new threads waiting, and therefore the thread sends the bundled messages - If the counter is > 0, the thread doesn't do anything and simply returns - The next thread to reach 0 will send the bundled messages ==> The advantage is there every thread will every now and then have to send the bundled messages and that we can remove the BundlingTimer tasks -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1405?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1405: -------------------------------- Added DefaultBundler2 (impl of the above idea) and TransferQueueBundler2; will revisit this JIRA in 3.2 or later -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1405?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1405: --------------------------- Fix Version/s: 3.3 (was: 3.2) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/JGRP-1405?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1405 at 9/4/12 10:58 AM: --------------------------------------------------------- Misc comments: - Should we serialize individual messages as they're being added to the bundler ? So serialization would be done on the sending thread, not by the message bundler - Should the message bundler bundle only *multicast* (and not unicast) messages ? This way, we could use a queue instead of a hashmap, as there is only 1 destination (null = send to all). We could then also optimize various headers away, e.g. TpHeader needs to be present only once ! As a matter of fact, we could bundle only the payloads (byte buffers) and send them in one big message with only *one set of headers* ! was (Author: belaban): Misc comments: - Should we serialize individual messages as they're being added to the bundler ? So serialization would be done on the sending thread, not by the message bundler - Should the message bundler bundle only *multicast* (and not unicast) messages ? This way, we could use a queue instead of a hashmap, as there is only 1 destination (null = send to all). We could then also optimize various headers away, e.g. TpHeader needs to be present only once ! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira