[jboss-jira] [JBoss JIRA] (JGRP-1989) Bundlers: reuse send buffer when transport == sync.

Sanne Grinovero (JIRA) issues at jboss.org
Wed Nov 25 04:23:00 EST 2015


    [ https://issues.jboss.org/browse/JGRP-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133609#comment-13133609 ] 

Sanne Grinovero commented on JGRP-1989:
---------------------------------------

In the use cases I have in mind (i.e. in-memory data grids) holding onto a 60K buffer is really not a concern, so I'd rather keep it simple rather than attempt to scale it down safely.

But I understand 60K is an example, and also there might be applications in the embedded world for which this matters? I'd suggest to have a configurable upper bound, so that when a buffer is needed larger than that you allocate it normally without using the pool. 

> 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)


More information about the jboss-jira mailing list