[
https://issues.apache.org/jira/browse/DIRMINA-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12765684#action_12765684
]
boB Gage commented on DIRMINA-720:
----------------------------------
Cleaned up my code and the re-discovery now won't happen until the
session.close() has completed.
Now the heart of the problem is very apparent.... and still only happens on
Windows machines with hardware flow control turned on.
After an IoSession (session) has been opened using hardware flow control ( Said
driver sending a one-character command "V" and timing out with no response ),
the
session.close(true)
call never returns, and the thread making the call is never heard from again.
Now no further attempts are made to open the port (just time out & watchdog
threads chugging); but when they were, they were getting PortInUseExceptions --
now quite predictably.
I turn off the hardware flow control on the first driver (does not match the
device on the port) and restart my program -- the first device times out, the
second device opens the port, sees data it recognizes, and everything's golden.
Turn hardware flow control back on for the first device (property file setting)
& restart -- first device times out, then fails to close. The main thread
hangs in session.close(true) and never returns.
I can go back and forth at will and control the problem with my flow control
setting for the non-matching driver (which will always time out).
I've done the beginnings of a track through session.close(). It could block
indefinitely based on synchronized () blocks based on AbstractIoSession.lock [
AbstractIoSession.close() ] or DefaultIoFuture.lock [ DefaultIoFuture.isDone()
] -- neither of these blocks is logged, so there's no easy way to tell which we
might be blocking on.
> Hardware Flow Control Disables Serial Port on Windows Platform
> --------------------------------------------------------------
>
> Key: DIRMINA-720
> URL: https://issues.apache.org/jira/browse/DIRMINA-720
> Project: MINA
> Issue Type: Bug
> Components: Transport
> Affects Versions: 2.0.0-M4
> Environment: Windows, serial connections only
> Specifically does NOT happen on Linux systems (others untested)
> Reporter: boB Gage
> Assignee: Julien Vermillard
>
> Attempting protocol discovery on single port -- Most protocols use no flow
> control, one using RTS/CTS. Each protocol attempts connection, fails
> (because far end device turned off), then tries next protocol.
> Test involves letting discovery fail through multiple cycles (ie test all
> available protocols) then eventually turn on device and see it get discovered
> when it's protocol cycles back around.
> HOWEVER... test failed before first cycle completed, because first protocol
> using CTS/RTS flow control (via FlowControl.RTSCTS_OUT parameter to
> SerialAddress constructor) is the last one to successfully open the serial
> port.
> While the protocol with RTS/CTS works (in that it properly fails), the next,
> and all following, protocols fail immediately as the port throws a
> PortInUseException on open attempt.
> Changing FlowControl.RTSCTS_OUT to FlowControl.NONE makes this test run fine.
> It also, however, breaks that particular protocol because the far end
> device expects flow control that it does not see.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
