Solved

Native routines/SIGALRM on Sun

Posted on 1997-04-14
4
479 Views
Last Modified: 2013-11-21
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?
0
Comment
Question by:dennist041497
  • 2
  • 2
4 Comments
 
LVL 1

Expert Comment

by:JWBito
ID: 1219555
I think you're wrong about the source of the alarm signal.  Are you reverse-engineering the C-interface to the database?  Does the database have a name?

It's common to set an alarm to interupt a call to msgrcv, since UNIX provides no other mechanism to block the request for a duration between instantaneous and infinite (excusive).  I can't say that the Solaris JVM is NOT setting an alarm, but it seems like a less likely scenario, given the symptoms you present.
0
 

Author Comment

by:dennist041497
ID: 1219556
I'm right about the source of the signal.  I can get the signal to happen only if I move the mouse after pressing the button on the Java app that calls the native routine.  If the mouse is still, no alarm happens (or happens *very* seldom).  Besides, I have a very small C routine (no database calls, just signal handling), that traps the SIGALRM signal and that signal fires when I move the mouse around (only that signal, by the way).

The database is Informix, but that's irrelevant.  Many years ago, our company wrote a database interface, in C, so that many processes could concurrently use the database (Ingres at the time) without bringing down the system.  The interface was built to be database independent so that if we did change databases (and we did), the applications would not have to change.  The msgrcv() call never is interrupted with our C programs that send messages to this interface, presumably because we never generate such a signal.  But now, Java is also in the picture.  And, with the evidence of the mouse moves... I'd say that's fairly conclusive.  

I did get a note from a newsgroup that says I should probably use the jacket routines provided in the green threads package to do system calls.  I'll have to research this.

Thanks for responding.  Hope this helps clarify my situation.
0
 
LVL 1

Accepted Solution

by:
JWBito earned 200 total points
ID: 1219557
I suppose that it would be a good idea to use the Solaris JVM from SunSoft rather than JavaSoft's.  I imagine that the newer, optimized JVM from SunSoft wouldn't need to resort to SIGALRM to handle timing of mouse-events...

I believe that most threading packages can be made to limp along if you block the signals that they use during system calls.

I suggest
sigset_t set;
sigemptyset(set);
sigaddset(set, SIGALRM);
sigprocmask(SIG_BLOCK, set, NULL);
msgrcv(...)
sigprocmask(SIG_UNBLOCK, set, NULL);

I hope this helps!
sigprocmask(SIG_BLOCK
0
 

Author Comment

by:dennist041497
ID: 1219558
The answer seemed to work, although the code needs to be modified as stated in the answer.  All the calls need a pointer to the set, rather than the set itself.  Other than that, I believe this work around may help.

The Solaris version of the JVM is only compatible with 1.0.2 of the JDK and won't meet our needs (as we need RMI).
0

Featured Post

Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
DNS @ Naked Domain Record 5 84
couple of eclipse 5 38
arguments to jar 5 26
SHA2 certs for IIS AND Java? 2 94
Most ColdFusion developers get confused between the CFSet, Duplicate, and Structcopy methods of copying a Structure, especially which one to use when. This Article will explain the differences in the approaches with examples; therefore, after readin…
Periodically we have to update or add SSL certificates for customers. Depending upon your hosting plan you may be responsible for the installation and/or key generation. In the wake of Heartbleed many sites were forced to re-key. We will concen…
Viewers will learn about arithmetic and Boolean expressions in Java and the logical operators used to create Boolean expressions. We will cover the symbols used for arithmetic expressions and define each logical operator and how to use them in Boole…
This tutorial explains how to use the VisualVM tool for the Java platform application. This video goes into detail on the Threads, Sampler, and Profiler tabs.

803 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question