[
https://issues.redhat.com/browse/JGRP-2418?page=com.atlassian.jira.plugin...
]
Bela Ban commented on JGRP-2418:
--------------------------------
When sending a message, marshalling is done in the bundler. When receiving a message,
unmarshalling is done in the transport.
We should do marshalling/unmarshalling at the same level, in the *transport*. This means
that marshalling would be moved to the transport (further down from the bundler in the
stack). This way, UDP / TCP could marshal messages into a byte array, and then pass it to
the DatagramSocket / Socket. TCP_NIO2, however, would do the same, but pass NIO messages
(direct or heap-based) directly to the SocketChannel, thereby avoiding the unnecessary
conversion from ByteBuffer to byte array to ByteBuffer.
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 unneeded
memory allocation. Passing the *same* ByteBuffer all the way down from the application to
the transport would be beneficial.
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 up to implement multiple transports (JGRP-1424) in the
same stack.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)