[
https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1989:
--------------------------------
Actually, buffer pools can be used more widely:
* Sending of message batches and single messages
** Also for {{TCP_NIO2}} once JGRP-1991 is in place
* Reception of message batches
** The message batches are de-serialized from the buffer, so the buffer can be reused
immediately after deserialization (in {{TP.handleMessageBatch}})
* Reception of single messages
** Can we assume that - after the {{receive()}} callback returned - we can reuse the
buffer?
** Asynchronous Invocation API?
** User cannot store the buffer somewhere, but needs to copy if it wants to hang on to the
buffer
** Possibly make this configurable
Bundlers: reuse send buffer when transport == sync.
---------------------------------------------------
Key: JGRP-1989
URL:
https://issues.jboss.org/browse/JGRP-1989
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.7
With the addition of {{TCP_NIO2}}, all bundlers now create new send buffers for every
message (or message list). This generates a lot of memory allocations, perhaps it is
better to revert this change for *synchronous transports* such as {{UDP}} and {{TCP}}, and
still create new buffers for *asynchronous transports* such as {{TCP_NIO2}}.
Synchronous transports guarantee a message has been put on the wire when {{TP.send()}}
returns, whereas asynchronous transports may only have completed a partial write (so we
cannot reuse the buffer).
The code in the bundler should check for this, and copy if async or not copy if sync.
Whether or not a transport is sync is determined by a new abstract method that needs to
be overridden by every transport.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)