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

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

I added this test into our code -- prior to the first port discovery attempt:

            try {
                logger.info("HFCtest -- Opening port via RXTX w/ Datex 
parameters");
                CommPortIdentifier portId = 
CommPortIdentifier.getPortIdentifier(address.getName());
                SerialPort serialPort = (SerialPort) portId.open("Demo 
application", 5000);
                serialPort.setSerialPortParams(19200, SerialPort.DATABITS_8, 
SerialPort.STOPBITS_1, SerialPort.PARITY_EVEN);
                logger.info("   Setting hardware flow control");
                
serialPort.setFlowControlMode(SerialPort.FLOWCONTROL_RTSCTS_IN+SerialPort.FLOWCONTROL_RTSCTS_OUT);
                logger.info("   Port is open.   Holding 5 seconds");
                Thread.sleep(5000);
                logger.info("   Closing port and continuing");
                serialPort.close();
            } catch (NoSuchPortException e) { 
                logger.error("getPortIdentifier failure", e);
            } catch (PortInUseException e) {
                logger.error("open failure", e);
            } catch (UnsupportedCommOperationException e) {
                logger.error("setSerialPortParams() or setFlowControlMode() 
failure", e);
            } catch (InterruptedException e) {
                logger.error("Sleep interrupted", e);
            }



My logs show the port being opened, hardware flow control being set, the 
5-second pause, and the port being closed again.    None of the catch clauses 
above is executed.

Discovery then proceeds normally with Flow control NONE devices and everything 
works fine.

Add in even one Hardware flow control (RTSCTS_IN_OUT) and the port is flagged 
"in use" on all subsequent attempts.

I have switched device drivers around -- took a previously proven non-flow 
controlled device driver and set it to use hardware flow control -- the results 
are exactly the same.   

Once Mina opens a Windows serial port with hardware flow control, the port 
cannot be re-used until the program is exited and restarted.


> 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