#2 rxtx ioexception

rxtx libraries throw IOException on some reads. The device2052 init() method succeeds, and sets the scanner to a known state. But subsequent user initiated actions cause an IOException. There is a note in the rxtx release notes for 2.1.7 that state that read() may throw an IOException if rxtx believes that it could cause a deadlock. Looking into that. Meanwhile, javax.comm works fine.

[Litschi_Vienna]

Logged In: YES
user_id=1727860
Originator: NO

Looks to me as if we might have synchronisation troubles. I have added a TrafficMonitorClass key to JScan2052Strings.properties for selecting the implementation during runtime. Also added a TrafficMonitorDummyImpl which does just nothing. With TrafficMonitor switched off, does it work better? Code is in cvs, Jim please do some tests. (I don't own a scanner device.)
Let's see if TrafficMonitor class and JSerialPort class collide with each other.

[Anonymous]

Logged In: YES
user_id=1701854
Originator: YES

Using net.sf.jscan2052.model.scan2052.TrafficMonitorDummyImpl, the buttons on the front panel work fine. Using net.sf.jscan2052.model.scan2052.TrafficMonitorRxTxImpl, they fail to read. It appears that
there is some contention for the serial port, and the application throws an IOException on read instead of deadlocking. This is a feature of rxtx, and we need to fix the collision in the app.

[Anonymous]

Logged In: YES
user_id=1701854
Originator: YES

This appears to be fixed due to changes in TrafficMonitorRxTxImpl.java
Changed the monitorOff and monitorOn methods to check if the monitor is already in that state before continuing. No need to turn monitoring on if it's already on, and vice versa. There appeared to be a collision with turning monitoring off by removing the event listener, and then looking for data back from the port. Jury is still out, but I think it's fixed.

[Anonymous]

Logged In: YES
user_id=1701854
Originator: YES

This appears to be fixed due to changes in TrafficMonitorRxTxImpl.java
Changed the monitorOff and monitorOn methods to check if the monitor is already in that state before continuing. No need to turn monitoring on if it's already on, and vice versa. There appeared to be a collision with turning monitoring off by removing the event listener, and then looking for data back from the port. Jury is still out, but I think it's fixed.

[Anonymous]

Logged In: YES
user_id=1701854
Originator: YES

There may be a known problem with removeEventListener being called by an eventListener action. I have not been able to turn monitor on and then turn it back off without creating the "tooManyEventListeners" exception. Also, occasionally, with this I see the "underlying stream returned zero bytes" IOException.
The solution appears to be to remove the event listener outside the scope of the serialEvent.
To me, that implies the use of an external thread that responds to a condition. The thread monitors a conditional variable, and depending on its value, either adds or removes the event listener. It could also in theory, handle the changing of the color of the traffic label, etc. Your thoughts Robert?

[Anonymous]

Logged In: YES
user_id=1701854
Originator: YES

Robert,
I followed your example and made the selection of the comm library configurable at run time.
There are a few code changes around this, the addition of an abstract class and the implementation classes, etc. This will allow us to work through other problems while sorting out the rxtx deadlocks, by setting the comm implementation to whatever we like, including a dummy or virtual implementation if you so desire.

[Litschi_Vienna]

Logged In: YES
user_id=1727860
Originator: NO

I have skimmed through the rxtx-sources a little today. There are some Java examples in there. I also found a locking technique in the sources. I'd like to understand more of rxtx locking strategy before coming to a conclusion what the real fix strategy should be. I wouldn't like to see a workaround at the very heart of the application. Being able to swap the implementations somewhat relieves the problem and gives us some time to come to terms with the problem more thoroughly.
(Thought you'd like the trick with swapping implementations. I wanted to complete the abstraction today, but you are just too fast for me.)

[Anonymous]

Logged In: YES
user_id=1701854
Originator: YES

Bumped up the priority on this one a notch. I agree that if we don't have to implement a workaround in the application itself, then we shouldn't. I've been looking at the observableBoolean code, and I'm wondering if that is a decent approach for the serial port event listener. Upon the user clicking monitor off, set a boolean value, have the observer witness the change and remove the event listener. That way there's a disconnect between the button and the monitorOff() call. Perhaps this would lessen the chance of a deadlock. Perhaps I'm just blowing smoke?

[Litschi_Vienna]

Logged In: YES
user_id=1727860
Originator: NO

I have read about proposed serial i/o strategies. (I only found not too many articles.)
I think that your idea with introducing read/write seperated threads is good anyway. If it not directly solves the locking problem, it will keep the user interface from freezing, when the i/o operation takes longer for some reason.
I also would like to see if it is possible (as was mentioned somewhere, I hope i did not misunderstood that) to have a single SerialPortEventListener that is connected to the serial port the whole time, reading just anything that's coming in and dispatching it. If I understood that right, the locking problems we experience may come from two instances trying to read at the same time. I'll write a little test program that does some write operations, while a listener is active on the serial port.
The results should get us a step further, I assume.