I have an old legacy database interface system that uses message queues to communicate. We have a Java application that we are trying to write to retrieve information from this database using this legacy system. The native calls to this system were crashing, and I finally found out why. The call to the system call msgrcv() was being interrupted by a signal - SIGALRM (14) to be exact. I theorized that this had something to do with the mouse movements/event-type structure of Java and I think I'm right.
O/S is Sun, Solaris 2.3. We're using JDK1.1.1
To prevent the problem, I tried to ignore the signal (or trap it) just before the msgrcv() call and restore it after the call. Every time I do this, the msgrcv() calls works fine, but the Java VM crashes giving me the single message: "Alarm Clock" on stdout. I have written a very small Java application and native routine (which does nothing but trap and restore this signal when it gets called) and each time the VM crashes with this error. So far, the work-around has been to simply retry the system call for some MAX times until it either works or fails MAX times. While this works so far, I don't know what other system calls may fail. And this seems to be a silly work around.
The question then is, how do I make a native call from Java while ignoring any signals so that the VM doesn't crash?