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

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0.7
    • Fix Version/s: 2.0.8
    • Component/s: Core
    • Labels:
      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.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            mcnoche Michael McKnight
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development