[jboss-jira] [JBoss JIRA] (JGRP-2165) TP.receive() should also handle InputStreams
Bela Ban (JIRA)
issues at jboss.org
Wed Mar 29 02:06:00 EDT 2017
[ https://issues.jboss.org/browse/JGRP-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13385545#comment-13385545 ]
Bela Ban commented on JGRP-2165:
--------------------------------
This change had wider implications that simply adding {{receive(InputStream)}} to {{TP}}: any class extending {{org.jgroups.blocks.cs.ReceiverAdapter}} and wanting to handle both TCP_NIO2 and TCP had to implement both {{receive(InputStream)}} (TCP) _and_ {{receive(byte[])}} (TCP_NIO2).
This required a common protocol format (e.g. length first) for both TCP and TCP_NIO2. Affected classes included PubServer, PubClient, GossipRouter and RouterStub (used by TCPGOSSIP and TUNNEL).
> TP.receive() should also handle InputStreams
> --------------------------------------------
>
> Key: JGRP-2165
> URL: https://issues.jboss.org/browse/JGRP-2165
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.2
>
>
> Currently, {{TP.receive()}} is passed a byte[] buffer as parameter. This is OK for UDP and TCP_NIO2, however, in TCP we're dealing with a socket input stream.
> TcpConnection reads the length, then copies {{length}} bytes into a byte[] buffer and finally calls TP.receive() with the byte[] buffer as argument.
> The byte[] buffer and the copying of read data into it is superfluous if TP.receive() could also accept input streams as argument.
> Therefore introduce an additional {{TP.receive(InputStream in, int offset, int length}}, which reads directly from the socket's input stream and gets rid of the intermediate byte buffer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
More information about the jboss-jira
mailing list