[
https://issues.redhat.com/browse/JGRP-2418?page=com.atlassian.jira.plugin...
]
Bela Ban updated JGRP-2418:
---------------------------
Description:
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.
was:
When sending a message (_of any type_), it is currently marshalled into a byte[] array,
which is handled diffently 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.
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)