Java Comm WaitCommEvent: Error 31

I've written an application which communicates with my mobile phone (Nokia 7610) using Java Comm API to send/receive SMS.

Now, if the mobile phone gets disconnected/ unplugged or switched off, my application prints the following to the standard error infinitely:

WaitCommEvent: Error 31

This is NOT happening in any of my code. It appears to be happening somewhere in the Java COMM classes.

I need to gracefully detect and handle such events and close the COMM ports. I tried few things to see if there are any serial events are received when this happens, but there doesn't seem to be any.

Any clues/suggestions?

[652 byte] By [Kiran_Dextera] at [2007-11-27 1:53:20]
# 1

Are you sure it doesn't go through a single line of your code between outputs?

Add "System.out.print" to every other line to make sure.

If you can confirm this, then this is unquestionably a bug. Non-user code should not go into an infinite loop unless it is user code that causes(/closes) the loop. Though, to be honest, that it outputs to System.err on its own accord is alarming on its own.

Of course, it would help if you gave a better clue as to what your code actually looks like to really identify the cause of this output.

SlugFillera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 2

Hi,

Thanks for your reply.

JavaComm is event driven and makes us of the comm.jar file with a native library win32com.dll for the windows platform. Now when I disconnect the modem after opening the port, the message keeps coming possibly due to an unhandled event which some function in comm.jar keeps printing. Further investigation on this brought me to the point that the message is present infact in the win32com.dll native library. I figured it out by doing a hexedit on the dll file. To further verify that there is no bug in my code, you can run any sample program given in the comm api package. Once you open a port to the modem, just disconnect it and boom.. you'll see an infinte loop of those prints on your screen!

Hope this helps!

Thanks

Kiran_Dextera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 3
By disconnecting, I mean removing the wire connecting your PC (where the java application is running) and the modem.
Kiran_Dextera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 4

This could still be an issue with the sample programs having poor error management. In fact, it won't be all that rare among sample programs.

I still recommend the "make everything verbose" debugging solution, it has helped me solve countless problems in the past, on any number of coding platforms and languages.

I somehow doubt the loop exists entirely inside that dll. The message, maybe(although that's poor design, unless it's in a part not called by your code, detecting errors that do occur in your code), but the loop is something different altogether. If after "hotspot"ing your entire code this odd printout remains alone, then this is probably a bug in the dll and/or the library using it.

In the more reasonable scenario, you'll get lines in your code that are still being tripped, and that should give you a clue as to where changes and error-detection should occur.

SlugFillera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 5

SlugFiller,

It is not a loop per say. It is just that the native library keeps throwing an error message that it is not able to communicate with the modem. It is event driven (asynchronous) and so calls some callback in some class in comm.jar which prints the message.

Since Sun has not made the source code of the win32com.dll public, there was no way anybody can get around with this problem. Fortunately I was lucky enuf to find a GNU code http://rxtx.org which, you can say is a GNU version of Java Comm API and boy it rocks. I tested it out.. except for a few glitches it rocks. Best part is that since the source code is available, we can cover even the glitches :D

Thanks for your help.

Cheers!!

Kiran

Kiran_Dextera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 6

Hi Kiran,

Thanks for your post about the RXTXcomm lib. I too am trying to get around the errors thrown when the modem is disconnected. I am now using the new Libs but I am still getting an error when the modem is disconnected. Are you getting these errors or any when the modem is disconnected? I am using rxtx-2.1-7-bins-r2 . Maybe this is just a problem on windows, Iam moving to Linux. Can we catch this exception?Except for this problem everything is good. Any help would be awesome.. Thanks

Error 0x1f at /home/bob/foo/rxtx-devel/build/../src/termios.c(482):

A device attached to the system is not functioning.

Message was edited by:

supsoop

supsoopa at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 7

Hi Susoop,

Bingo! Was getting the same too! Was trying hard to solve the same from the last 3 days. Had to dig through the sources and finally was able to gracefully handle all these conditions. It requires tweaking inside the source code of RXTXComm.jar.

Here's how:

When the modem is disconnected, the serial.available() call in serialEvent throws an IOException. This needs to be caught and the eventlisteners needs to be removed. Now, any call to CommPortIdentifier.removeEventListener should *not* be in the context of the serialEvent call back. Else there will be a deadlock which is inherently due to the way RXTX is implemented. Instead, use a thread to close the ports on exception. However this does not solve the problem completely. We need to remove the entry in CommPortIdentifier manually. Hence we need to implement 2 additional APIs in CommPortIdentifier - removePortName and getDriver to delete the commport entry in the linked list when the modem is disconnected. The latter API - getDriver give the reference to the static CommDriver instance which is used to query the driver manually when we fail to obtain an entry in CommPortIdentifier. This is needed since the linked list in CommPortIdentifier is not automatically updated when the modem is connected back. We need to use getDriver().getCommPort() API to see if the modem is connected back. If yes, then we need to manually add an entry in CommPortIdentifier using addPortName.

Hope this clarifies your doubt.

Regards,

Kiran

Kiran_Dextera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 8
Thanks for the reply. Thats great news! Should add the source changes to the project! Would it be possible for you to send me a copy of the changes and possibly the compiled jar? I would like to take a look at your solution. If not that is cool, i see what you have done and it makes
supsoop2a at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...
# 9
Sure, you can contact me at kiran.kn80@gmail.com
Kiran_Dextera at 2007-7-12 1:23:22 > top of Java-index,Core,Core APIs...