[
https://issues.jboss.org/browse/JGRP-1991?page=com.atlassian.jira.plugin....
]
Bela Ban commented on JGRP-1991:
--------------------------------
There will be a additional method {{Buffers.copy()}} which copies the data in range
{{last_copied .. limit}} and moves {{last_copied}} to {{limit}}. Next time {{copy()}} is
invoked, unless {{limit}} has moved, there won't be any copy.
{{Buffers.copy()}} would typically be called after a {{Buffers.write()}} returned false
(partial write). It would be called by the user, which knows whether data needs to be
copied in the first place. For example, if the user already passes copies into the
{{write()}} call, then {{Buffers.copy()}} would not have to be called.
TCP_NIO2: copy on demand
------------------------
Key: JGRP-1991
URL:
https://issues.jboss.org/browse/JGRP-1991
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6.7
When TCP_NIO2 writes data, we always pass a copy of data of it, because of JGRP-1961
[1].
However, if we copied the data only on a *partial write* (full writes don't need a
copy), then we could always pass data from reused buffers down to the transport.
Example: we want to write 3 buffers of 100, 200 and 700 bytes in a gathering write (the
buffers are allocated from reusable byte[] arrays).
If the write returns 1000, we know that all 3 buffers have been written and there is no
need to copy any of the buffers. However, if only 500 bytes were written, then we can
trash the first 2 buffers, but need to make a copy of the 3rd buffer in range [201 ..
700].
This allows the sender to reuse previously allocated buffers, as all transports (UDP,
TCP, TCP_NIO2) now guarantee that, on return of the send(), either the data was written
completely, or a copy was made.
[1]
https://issues.jboss.org/browse/JGRP-1961
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)