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

[Sanne Grinovero (JIRA)]

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

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

{quote}Even the most light-weight impl adds ~16 bytes to every message, and I'm not willing to add that cost.{quote}

Let me clarify why I returned to that idea, and why I think you should take a second look at it too, especially after this interesting reuse opportunities which you have found.

By abstracting the "buffer type" into some more abstract JGroups specific contract, one would be able to replace these reusable buffers with an off-heap pool. (Yea, I know we talked about that, and bear with me about the details of implementing such an efficient pool for now, let's simply agree that while it might be non trivial, it surely can be done. and it's not that hard considering you have a rather "stable" buffer size).

So with the {{byte[]}} solution the memory cost of JVM heap usage would be
* *A* {{(buffer_size + array_headers) * N}}

With a simple wrapper option like I am re-proposing now this would result into (what you say is unacceptable):
* *B* {{(~16 bytes + buffer_size + array_headers) * N}}

My guess is you consider this unacceptable because N is often large? But then we'll agree that the {{buffer_size}} is more concerning than the ~16 bytes.

But the ultimate solution looks like this:
* *C* {{(~16 bytes + cost_of_pointers_to_mmapped_memory) * N}}

Which imo looks much better as the overall cost is better predictable as it's not depending on the size of the objects being transmitted. Predictability is good, and {{N}} is probably not unbounded (I guess?) so that would allow people configuring it to make a clear decision on how much memory mapped space one wants to dedicate for this purpose.

So while we can certainly agree that *B* is less efficient than *A*, the reason I'd change the interface nevertheless is that it can then allow us to move on to solution *C* at due time. And really, those 16bytes, I have a hard time believing they make all the difference: compared to the buffer size itself I suspect that's a negligible overhead.

Not least, I believe the abstraction would make for a better internal API and integration points to either express reusage of buffers explicitly, or be able to perform some (optional?) validation for correct behaviour.

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