In our java application, we need to send email in case the application goes out of memory and recovers from it by its own. To do so, we need a callback kind of thing that should be called once the JVM recovered from OOM. Is there such a callback in Java?
Use -XX:OnOutOfMemoryError=<command> JVM option.
If you need more flexible error handling within the Java process itself, look at ResourceExhausted JVMTI callback.
Related
I've written a Java application that is launched as a daemon (I daemonize redirecting stderr and stdout and closing stdin though bash). However, occasionally I would like to be able to message this application and inform it to change certain parts of its behavior. I need to be able to message the application from a terminal, so anything that requires a graphical utility is a no-go.
The change in behaviour is fairly simple. I need a toggle for the state of one thread in my application, and a way to gracefully close the application.
What are my options in achieving this? I know I could have a thread in the process that listens on a socket of some sort for messages, but this seems like overkill for the needs I have.
I'm not too familiar with Signals on Linux/Unix, so I'd like to ask if I could simply set up a custom handler for some signals, and have my code execute when the process receives a signal.
Are there any other options that I simply don't know about or haven't thought about?
Signals may be the easiest. You have SIGUSR1 and SIGUSR2 available for application use and you can write a handler for them to manage your toggle. Generally you don't want to do much in a handler so you can set a switch and your main loop (or whatever) needs to check the switch and act accordingly. Similarly the receipt of the signal could be programmed to read a config file that you changed.
Beyond that you can use any available IPC (fifos, sockets, MQs) but you are going to either have thread blocking on them or somehow incorporate them a select statement (or whatever the java equivalent of that is).
You basically need a small client that communicates with your application (server). So the default solution should be to use some IPC mechanism. Putting an IPC mechanism is a one time effort and is worth the trouble because it scales well with the requirements. Using signals for IPC is not recommended. I think sockets is a good way to go.
Personally, I like to use OS signals for this.
Use java.lang.Runtime.addShutdownHook and send a SIGTERM, SIGINT or SIGHUP.
Be aware that some signals are reserved for internal use, check out the docs for the JVM you are using.
The SignalHandler is not part of the supported, public interface, so your mileage may vary.
If you are instantiating a JVM from C code, simply set signal handlers (in C) before the JVM and you will be fine.
I have coded a Java application that through JNI calls a linear programming solver written in C++. After a number of successful calls I get an EXCEPTION_ACCESS_VIOLATION error and the application terminates.
How can I dismiss the error and keep the Java application operating?
First of all, if a dll crashes then the JVM will terminate.
This is one of the drawbacks of using JNI in the first place. So it is generally not as simple as swallowing some exception from the dll.
In your case the error hints towards unitialized memory. You should look towards out of bound indexing in your code.
You should post your code though in order to get more help
There is no way to keep JVM running if there is access violation happened in native code.
There are several things you can do.
Best - carefully debug your lib without JNI, with small standalone C++ client, and find the reason of this violation, and add excessive checks around that (incorrect pointer usage, incorrect memory cleanup etc)
Run your DLL in a separate JVM process, which is purely responsible for providing this solver functionality, communicate with second JVM using sockets, tcp-ip, soap, rest - whatever you prefer. Than, use some like Java Service Wrapper to run this second JVM and configure it in the way that it restarts the JVM if it crashed.
I call a dll from Java using JNI. The DLL calls another thirdparty library which spawns a bunch of threads and sends callbacks to my dll. I want these callbacks to be attached to the JVM. What is the best way to do this? I think since the threads call the callback method, the callbacks aren't attached to the JVM, so I have to attach it?
Is there no... inheritance, like all threads created by this thread will automatically attached to the JVM?
I've looked at the documentation but I can't find it.
Thanks
You have to manually call AttachCurrentThread() (and DetachCurrentThread()) from each thread that needs to call into the VM. There is no automatic mechanism.
I would like to know if it is possible to automatically invoke a Java method when a hardware interrupt is raised.
There may be an alternative.
I'm doing something similar: In an application I monitor 4 mice for clicks. Those clicks generate interrupts but I'm happy enough not to deal with them directly from Java.
Under Linux, it turns out there are device files (/dev/input/mouse#) that spew a bunch of characters when something happens with the mouse. I have a Thread for each one with a FileReader blocking on a read. Once characters arrive, the appertaining thread unblocks and I can do whatever processing I like.
So the idea is: If possible, find a way to get a device driver to make the data accessible to you in file/device form, then you can access it from Java using just IO calls from the Java library, with no weird bit-twiddling code and C required in between.
In principle yes, but it will require some C code and JNI to tie that to Java. If you are very lucky perhaps already someone has already built a suitable library for the paltform you are interested in.
Bottom line: if it can be done in C you can hook that to Java.
If you would like to directly respond to an interrupt from Java, then the VM would have to run in kernel space (or on some systems with user space drivers, in a driver context). The JamaicaVM runs in this mode on some RTOSes such as Thread-X or VxWorks as a DKM. The next release of the RTSJ will support writing interrupt service routines in Java.
The RTSJ can be used to run second level interrupt handlers even in user space. This requires a small device driver that either sends a POSIX signal to the VM or provides a character device interface where one thread in the VM blocks on a read of the device. In the first case, an AsyncEventHandler can be assoicated with the POSIX signal. In the second, the tread that blocks on a read of the device can fire an AsyncEvent each time a byte is read from the device. Then any AsyncEventHandler attached to the AsyncEvebt would be released.
If you would like to try this under Linux, you can download the JamaicaVM personal edition: "http://www.aicas.com/jamaica-pe.html". JamaicaVM has a realtime garbage collector and code can be compiled statically to ensure realtime performance. This is a different deployment model than a conventional JVM.
Here is a paper that handles the same topic. And you may have a look at SWT, I think they're dealing with hardware interrupts aswell, although they may rely on the operating systems API.
It's standard on embedded realtime java. go to www.ajile.com, or systrmonx.com and buy an eval board.
Embedded java is not standard on pc's. you can get realtime java on PC hardware, but not the embedded bit.
Take a look at Swig. The Java implementation has Directors that will allow you to call into Java from C/C++.
I've used this technology to handle interrupts calling into C#, and it worked great. Shouldn't be much different calling Java.
Is there any possibility that I can directly send signal to a Java virtual machine which is created by calling JVM_CreateJavavm in native C/C++ code?
e.g.:
For a normal Java process, say its pid is 12345, I can send a signal 3 to it like this ...
kill -3 12345, and hopefully I could trigger javacore or heapdump by changing JVM configurations.
However if the JVM is created thru JNI API and wrapped inside a C/C++ application, only the native process's PID is visible, in that case if I send signal to that process, the whole process is just terminated and seems the JVM cannot receive the signal at all.
Thanks in advance ...
No. There is no separate process for the JVM. The JVM is just running in the process that called it. I don't think that Sun documents a way to use those signal handlers via the invocation interface.
http://www.scribd.com/doc/13119378/If-JNI-based-application-is-crashing-check-signal-handling