[
https://issues.apache.org/jira/browse/DIRMINA-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny updated DIRMINA-966:
--------------------------------------
Fix Version/s: 2.0.8
> 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
> Fix For: 2.0.8
>
>
> 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:
> {code}
> 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;
> }
> {code}
> 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.3.4#6332)
