[ 
https://issues.apache.org/jira/browse/DIRMINA-720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744673#action_12744673
 ] 

boB Gage commented on DIRMINA-720:
----------------------------------

Yes, for each discovery attempt I open the session, (usually) send a request, 
(always) wait to see some data, try to parse it.

If either no data appears (timeout) or data appears that I cannot parse, I 
close the port, sleep a couple seconds and repeat the process with the next 
protocol.    

The protocol list is circular.   Eventually (given the nothing's out there 
scenario) each port times out for each protocol and tries them all again and 
again.   One of our "smoke tests" is to stay in this state for awhile and then 
turn on external devices and see them get discovered.

The first time a protocol using hardware flow control is attempted, it operates 
normally (ie displays no errors other than time out).  BUT the next protocol 
attempt (and every one thereafter) fails with the PortInUseException.   

This MIGHT mean that the hardware flow controlled protocol's close() method 
failed; causing the subsequent exceptions.



> 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.

Reply via email to