[
https://issues.apache.org/jira/browse/DIRMINA-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025219#comment-13025219
]
Christian Schwarz commented on DIRMINA-830:
-------------------------------------------
During the last week we tried our own patch, it works well until now ! We
simply put the synchronized block around the while-loop. I think your patch
have still a little race condition issue. It is possible that the loop
condition (isConnected() && !isClosing()) is true and before entering the
synchronized block it can turn false. In other words: The session can be closed
before entering the synchronized block, so flushWrites() can be called on a
closing or closed session.
During the next weeks we try to test your patch. Do you see an advantage for
one or another solution ?
This is our solution (the ReadWorker-Loop is similar):
synchronized (writeMonitor) {
while (isConnected() && !isClosing()) {
flushWrites();
// wait for more data
try {
writeMonitor.wait();
}catch (InterruptedException e) {
log.error("InterruptedException", e);
}
....
> Unconditional wait() in Read- and WriteWorker of SerialSessionImpl
> ------------------------------------------------------------------
>
> Key: DIRMINA-830
> URL: https://issues.apache.org/jira/browse/DIRMINA-830
> Project: MINA
> Issue Type: Bug
> Components: Transport
> Affects Versions: 2.0.2
> Environment: win32 x86
> Reporter: Christian Schwarz
> Labels: rs232, rxtx, serial
> Attachments: patch.diff
>
>
> The inner worker classes of SerialSessionImpl violates the guarded block
> contract for Object#wait(). Under certain conditions it is possible that a
> session write starved.
> The wait loops of Read- and WriteWorker should be inside the synchronized
> block! We have some starvations while writing data to or serial session. We
> found out that in this case the WriteWorker-Thread waits endless for data to
> write. Because we write data asynchron to the serial session, we assume that
> a race condition occures. One thread is inside the unguarded
> WriterWorker#flushWrites() while an other invoke SerialProcessor#flush().
> http://download.oracle.com/javase/tutorial/essential/concurrency/guardmeth.html
> states-> Always invoke wait inside a loop that tests for the condition being
> waited for. Don't assume that the interrupt was for the particular condition
> you were waiting for, or that the condition is still true.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
