[
https://issues.apache.org/jira/browse/DIRMINA-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025393#comment-13025393
]
Emmanuel Lecharny commented on DIRMINA-830:
-------------------------------------------
I can apply your patch. Note that as the connection status won't be updated
does not mean the connection still exists when you flush data, you will then
get some exception at some point (ir the synchronized is put outside of the
loop).
Here, you are the one using this piece of code, so if it works well for you, I
see no reason to not applying it to the current code. I must admit I have
little time to do a complete analysis of the possible race conditions we can
meet here (shame on me :/), but this is ost certainly the kind of analysis that
should be done...
> 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
