[
https://issues.redhat.com/browse/JGRP-2418?page=com.atlassian.jira.plugin...
]
Bela Ban commented on JGRP-2418:
--------------------------------
Hmm, there is a problem: we cannot only send the ByteBuffer passed to us, but we also need
to generate some metadata (version, headers, src and dest address), which prepends the
buffer.
This is memory allocation, so it is not better than the temp buffer which exists today to
write the ByteBuffer to the output stream. In addition, we'd need to change the
signature of {{send(ByteBuffer)}} to {{send(ByteBuffer[])}} in BaseServer, in order to be
able to pass _multiple_ ByteBuffers to BaseServer.
I'll investigate a bit more, but atm, there seems to be no gain to be had. On the
contrary, some bundlers (RingBufferBundler) would have to create temp lists to be able to
pass messages to the same destinations to the transport, rather than writing directly to
the output stream.
Impedence mismatch between message types and transports
-------------------------------------------------------
Key: JGRP-2418
URL:
https://issues.redhat.com/browse/JGRP-2418
Project: JGroups
Issue Type: Enhancement
Reporter: Bela Ban
Assignee: Bela Ban
Priority: Major
Fix For: 5.1
When sending a message (_of any type_), it is currently marshalled into a byte[] array,
which is handled differently by each transport:
* UDP wraps it into a DatagramPacket and calls DatagramSocket.send()
* TCP writes the array to the socket's output stream
* TCP_NIO2 wraps it into a {{ByteBuffer}} and calls SocketChannel.write(ByteBuffer)
In some cases, there is an impedance mismatch between the type of the message and the
type of the transport: for example, when sending an NioMessage (containing a ByteBuffer),
we don't actually need the conversion to byte array and the subsequent wrapping into a
ByteBuffer; this is superfluous. Even worse, when using off-heap, this creates an unneeded
memory allocation. Passing the *same* ByteBuffer all the way down from the application to
the transport would be better.
This requires changes in the way bundlers accumulate messages. Also, perhaps the
transport itself should become an SPI, to which a generic {{Transport}} protocol
delegates. This would also allow us to implement multiple transports (JGRP-1424) in the
same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)