[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