mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "boB Gage (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-720) Hardware Flow Control Disables Serial Port on Windows Platform
Date Wed, 14 Oct 2009 20:24:31 GMT

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

boB Gage commented on DIRMINA-720:

Woo hoo!  A work around!!  :-)


private class SerialIoProcessor ... { 

        public void remove(SerialSessionImpl session) {

The port.close() call is where my code dead locks.

            try {  // An experiment...   Turn flow control off regardless right before close
            } catch (UnsupportedCommOperationException e) {
                System.out.println("Failed clearing flow control for close! " + e);

Directly BEFORE the port.close() call stops the deadlock.    Port gets reused by next device
whether hardware flow control is turned on or off.

Any chance of getting something like this into the official code stream ???   

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

View raw message