Michael McKnight created DIRMINA-966:
----------------------------------------
Summary: NIO Datagram messages can get duplicated when unable to
be sent by the underlying DatagramChannel
Key: DIRMINA-966
URL: https://issues.apache.org/jira/browse/DIRMINA-966
Project: MINA
Issue Type: Bug
Components: Core
Affects Versions: 2.0.7
Reporter: Michael McKnight
AbstractPollingConnectionlessIoAcceptor.write method...
within the "for ( ;; )" loop if the channel write fails to send, indicated by 0
being returned, the message is re-enqueued. However the loop is not exited and
the same message is tried again. For each failure to send the same message
over and over a new WriteRequest is added to the queue and the message will be
sent again for each WriteRequest.
Even though the WriteRequest references the same IoBuffer, after each
successful write the IoBuffer is reset which enables each subsequent
WriteRequest in the queue to send it again.
I have had instances where the kernel buffer is full and delays for up to 500ms
or so which resulted in ~ 300 duplicate messages being sent.
Here is the block of code in question within the for ( ;; ) loop:
int localWrittenBytes = send( session, buf, destination );
if ( ( localWrittenBytes == 0 ) || ( writtenBytes >= maxWrittenBytes ) )
{
// Kernel buffer is full or wrote too much
setInterestedInWrite( session, true );
session.getWriteRequestQueue().offer( session, writeRequest );
scheduleFlush( session );
}
else
{
setInterestedInWrite( session, false );
// Clear and fire event
session.setCurrentWriteRequest( null );
writtenBytes += localWrittenBytes;
buf.reset();
session.getFilterChain().fireMessageSent( writeRequest );
break;
}
Possible fixes:
* adding a "break;" after the message has been re-queued would certainly
resolve this but then messages could be delivered out of order.
* don't re-queue the message and just loop back through trying to send it
again.
Workaround:
* ensure that the SO_SNDBUF size is sufficiently large which could, depending
on the application, alleviate the issue altogether or make it less likely to
occur.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
