You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by "boB Gage (JIRA)" <ji...@apache.org> on 2009/10/13 18:15:31 UTC

[jira] Commented: (DIRMINA-720) Hardware Flow Control Disables Serial Port on Windows Platform

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

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

Retested with DIRMINA-740 fixes.     Unfortunately no change was detected.

Once a given COM port has been opened with hardware flow control, all future attempts to open it fail with a PortInUseException.    

This behaviour is ONLY seen on Windows [ XP?] systems -- same tests on Linux systems work as expected.

>From our application log (whitespace added for legibility):

2009-10-13 11:43:37,156 [PM.1_COM5] INFO  MonitorSupport - Opening session to port [COM5] from [WelchAllyn]
                                              ^^^^^  Matches our ConnectFuture cf = ioc.connect(address) call

2009-10-13 11:43:42,421 [PM.1_COM5] INFO  MonitorSupport - Not connected after 5 seconds.  Canceling connect.
                                              ^^^^^  After cf.await() times out,   cf.isConnected() returned false

2009-10-13 11:43:42,421 [PM.1_COM5] ERROR MonitorSupport - Exception [PortInUseException] on open.
                                                     cf.getException().getClass().getSimpleName()  ^^^^^^^^^^^^^^^^^^^^^^

                                                     vvvvvvv  This is cf.getException()'s stack trace
gnu.io.PortInUseException: Apache MINA
        at gnu.io.CommPortIdentifier.open(CommPortIdentifier.java:452)
        at org.apache.mina.transport.serial.SerialConnector.initializePort(SerialConnector.java:155)
        at org.apache.mina.transport.serial.SerialConnector.connect0(SerialConnector.java:94)
        at org.apache.mina.core.service.AbstractIoConnector.connect(AbstractIoConnector.java:262)
        at org.apache.mina.core.service.AbstractIoConnector.connect(AbstractIoConnector.java:172)
        at com.merge.frontiers.physio.monitors.MonitorSupport.open(MonitorSupport.java:330)
        at com.merge.frontiers.physio.monitors.MonitorSupport.open(MonitorSupport.java:453)
        at com.merge.frontiers.physio.framework.PortManager.establishConnection(PortManager.java:416)
        at com.merge.frontiers.physio.framework.PortManager.tryOne(PortManager.java:351)
        at com.merge.frontiers.physio.framework.PortManager.run(PortManager.java:244)



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