Skip to main content

Possible TCPMessenger bug

4 replies [Last post]
Joined: 2004-07-30


I'm performing some testing with JXTA Sockets and when a high
throughput of messages is generated between 2 peers (in both directions),
some messages seems to be lost, and retransmissions can be observed.

I've made a great logging effort, performing message low level analysis, and
TCPMessenger run() procedure seems to be the source of the problem:
to low level, several JXTA messages are present, but processBuffer procedure
only dispatches the first one, so pending messages are kept into TCPMessenger
message buffer, till a new remote message is read from socketChannel.

I would like to know if it's a bug or it's the expected behaviour.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2003-06-12

It used to be the case where the thread return upon receiving 1 message, which has been addressed since. will return when all messages have been completely been parsed, or not enough data to process a single message. That's not to say there aren't any bugs, and if so, if you could express your opinion in the form of a patch.

Thanks for taking the time in analysis.

Joined: 2004-07-30

Thanks Hamada for your answer.

As it's said on comments, method, "reads whatever is available, processes it and goes back to write selector for more IO". The concept
is correct but it seems a bug can be found in:


The problem could be found in processBuffer():when a complete message is dispatched in this method, in case remaining bytes could be
left in read buffer, instead of continue with main "while(true)" loop, consuming
a possible next message (in fact it can be possible!), the method curiosly returns .

If a single message is loaded in buffer with read() method, the is not problem with
processBuffer. The problem arises when a fast peer writes several messages into the remote peer's read buffer, and read method returns with 0 (no more I/O): processBuffer only dispatches the first one message and the next messages are
"virtually" lost until more messages are received in the next read invokation.

This problem persists for a undefined time, because the next reads() returns old
forgotten messages in each iteration.

I'm testing a possible easy solution which is removing
return; the end of switch BODY branch, so in case more messages are pending
to be processed after the first one, it can be consumed too.

I hope this solution would be useful


Joined: 2003-06-12

the while loop in processBuffer is not supposed to return until all messages have been processed out of the buffer, then the while loop in the run method will return if no more data is read. So I am not I sure I see the condition where data could be left in a buffer unprocessed.

Joined: 2004-07-30

Sorry Hamada
the problem I was talking about is for TCPMessenger from JXTA 2.5 rc1 !

I have just downloaded JXTA 2.5 rc3 and all it's OK: processBuffer continues with buffer processing until it's empty