[
https://issues.apache.org/jira/browse/DIRMINA-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16195839#comment-16195839
]
Jonathan Valliere edited comment on DIRMINA-1057 at 10/7/17 10:00 PM:
----------------------------------------------------------------------
-Okay, looks like I found a condition where fireMessageSent can occur more than
once per WriteRequest causing the counter to go negative.
{code:java}
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}
Should be
{code:java}
int localWrittenBytes = send(session, buf, destination);
if(localWrittenBytes > 0 )
writtenBytes += localWrittenBytes;
if ((localWrittenBytes == 0) || buf.hasRemaining() ||
(writtenBytes >= maxWrittenBytes)) {
// Kernel buffer is full or wrote too much
setInterestedInWrite(session, true);
session.getWriteRequestQueue().offer(session, writeRequest);
scheduleFlush(session);
break;
} else {
setInterestedInWrite(session, false);
// Clear and fire event
session.setCurrentWriteRequest(null);
buf.reset();
session.getFilterChain().fireMessageSent(writeRequest);
break;
}
{code}
Basically what I think is happening is that the buffer had written data; it got
caught by the condition then was re-added back to the queue. The for... loop
cycled found no data was remaining and called fireMessageSent not knowing that
it still existed in the Queue. So, later the same message was sent again.
The fix checks for buf.hasRemaining() and breaks out of the loop when a "bad
write" condition is met. It also fixes the maxWrittenBytes condition which
would never fail otherwise because it wasn't being incremented in a functioning
part of the loop.
-
Ignore - was looking in the wrong class - I pulled the examples and am working
it out now.
was (Author: johnnyv):
Okay, looks like I found a condition where fireMessageSent can occur more than
once per WriteRequest causing the counter to go negative.
{code:java}
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}
Should be
{code:java}
int localWrittenBytes = send(session, buf, destination);
if(localWrittenBytes > 0 )
writtenBytes += localWrittenBytes;
if ((localWrittenBytes == 0) || buf.hasRemaining() ||
(writtenBytes >= maxWrittenBytes)) {
// Kernel buffer is full or wrote too much
setInterestedInWrite(session, true);
session.getWriteRequestQueue().offer(session, writeRequest);
scheduleFlush(session);
break;
} else {
setInterestedInWrite(session, false);
// Clear and fire event
session.setCurrentWriteRequest(null);
buf.reset();
session.getFilterChain().fireMessageSent(writeRequest);
break;
}
{code}
Basically what I think is happening is that the buffer had written data; it got
caught by the condition then was re-added back to the queue. The for... loop
cycled found no data was remaining and called fireMessageSent not knowing that
it still existed in the Queue. So, later the same message was sent again.
The fix checks for buf.hasRemaining() and breaks out of the loop when a "bad
write" condition is met. It also fixes the maxWrittenBytes condition which
would never fail otherwise because it wasn't being incremented in a functioning
part of the loop.
> AbstractIoSession getScheduledWriteMessages always -negative?
> -------------------------------------------------------------
>
> Key: DIRMINA-1057
> URL: https://issues.apache.org/jira/browse/DIRMINA-1057
> Project: MINA
> Issue Type: Bug
> Components: Core
> Affects Versions: 2.0.16
> Environment: I'm testing slow consumer backlog detection and while
> getScheduledWriteBytes() correctly grows, getScheduledWriteMessages is always
> negative and does not increase. looking into code to see why but putting bug
> report here as well for tracking
> Reporter: Andre Mermegas
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
