Uploaded image for project: 'MINA'
  1. MINA
  2. DIRMINA-966

NIO Datagram messages can get duplicated when unable to be sent by the underlying DatagramChannel

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.0.7
    • 2.1.4
    • Core
    • None

    Description

      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.

      Attachments

        Activity

          People

            johnnyv Jonathan Valliere
            mcnoche Michael McKnight
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: