If I want to properly exit a documentum java job (if params are invalid for example), should I use a system.exit() or is there another way to do it.
As far as I know system.exit closes the virtual machine, does it have an effect on other jobs running?
Definitely don't use System.exit(). If you're on a method server this may try to shutdown the server. In most cases this will raise a SecurityException (depending on the security policy defined for the server).
Like Michael said your job is running in the execute method so any return statement from that method should end the job.
Assuming you are referring to a subclass of the com.documentum.job.Job abstract class you should be able to exit the execute() method by return false;. If you wish to abort instead you could call the abort() method (you may need to have the canAbort() method return true as well). You could also
Either way, I wouldn't recommend calling System.exit() except in very unusual circumstances.
Related
I'm writing a separate thread to monitor an OS process spawned by Java's ProcessBuilder. The process can sometimes get out of control. After a given timeout period, I want to kill the process if it's still running. I can paste my code in if it's helpful (please ask), but the only detail directly relevant to the question is that I'm using Process::waitFor to specify the timeout after which the process will be killed.
The problem is that this code design is relatively inefficient. As even the documentation for Process::waitFor says,
The default implementation of this methods polls the {#code exitValue}
to check if the process has terminated. Concrete implementations of this
class are strongly encouraged to override this method with a more
efficient implementation.
I'm thinking a much more efficient design would be to specify a callback to be executed after the process completes. I could execute my own timeout method that would kill the process if it were still running. But the callback, if run, would cancel the timeout kill method.
Can I implement a callback pattern for a process spawned by ProcessBuilder?
I'm looking at the ProcessBuilder.start(Redirect[] redirects) and wondering if I could just tack the execution of the callback at the end of this method. Problem is that the class is final, so I can't subclass it. I'd have to copy and modify. But I'd also have to duplicate such dependencies as ProcessEnvironment and ProcessImpl, which are not public, as well as being final. Ugh.
Is maybe there some way to extend the abstract class Process to use a callback? That class seems to have/be the only space left by the authors of Java for fixing up the inefficient code they've left.
Or perhaps there's another way to make Process::waitFor more efficient?
I have a question about how local and remote methods cooperate in Java RMI.
Here's the ideal situation:
localClass.setValue(server.getValue());
Does localClass.setValue(..) awaits for the return value from the server or do I have to make sure of it using some sort of synchronization in local?
What happens if the server needs like 5 seconds to execute getValue()?
Not quite.
Arguments are evaluated left to right before the method is called.
So localClass.setValue() isn't even called until the parameter value returned by server.getValue() is available. So the client waits as long as that takes, and then calls localClass.setValue(). It isn't setValue() that does the waiting, it is the stub's call to server.getValue().
You don't have to do anything about it yourself.
The client wait the 5 sec, if you would like to set a timeout exception you have to do it by yourself like already suggested in this question.
I am relatively new to Stackoverflow and Java, but I have a little experience in C. I liked the very clean way of C exiting the programs after a malfunction with the 'exit()' function.
I found a similar function System.exit() in Java, what differs from the C function and when should I use a 'System.exit()' best instead of a simple 'return' in Java like in a void main function?
System.exit() will terminate the jvm initilized for this program, where return; just returns the control from current method back to caller
Also See
when-should-we-call-system-exit-in-java ?
System.exit() will exit the program no matter who calls it or why. return in the main will exit the main() but not kill anything that called it. For simple programs, there is no difference. If you want to call your main from another function (that may be doing performance measurements or error handling) it matters a lot. Your third option is to throw an uncaught runtime exception. This will allow you to exit the program from deep within the call stack, allow any external code that is calling your main a programmatic way to intercept and handle the exit, and when exiting, give the user context of what went wrong and where (as opposed to an exit status like 2).
System.exit() may be handy when you're ready to terminate the program on condition of the user (i.e. a GUI application). return is used to return to the last point in the program's execution. The two are very different operations.
I am a beginner in java and I used Delphi for a long time.
When I want to leave a method I need to use the exit() method and in Java I use return.
To abort all subsequent methods I call the abort() method in Delphi. How to do this in Java?
There's no direct support in Java for what you're asking, but in a non-elegant way you could simulate abort's behavior by throwing an exception and catching it wherever you see fit in your code.
Using System.exit(0) would not be the same, that method call will exit your program without any chance to recover along the way.
If you use abort like in this link (http://www.delphibasics.co.uk/RTL.asp?Name=Abort),
i think this functionality is similar with throw see this link
http://www.roseindia.net/java/exceptions/how-to-throw-exceptions.shtml
http://en.wikibooks.org/wiki/Java_Programming/Throwing_and_Catching_Exceptions
In my application which runs user submitted code[1] in separate threads, there might be some cases where the code might take very long to run or it might even have an infinite loop! In that case how do I stop that particular thread?
I'm not in control of the user code, so I cannot check for Thread.interrupted() from the inside. Nor can I use Thread.stop() carelessly. I also cannot put those code in separate processes.
So, is there anyway to handle this situation?
[1] I'm using JRuby, and the user code is in ruby.
With the constraints you've provided:
User submitted code you have no control over.
Cannot force checks for Thread.interrupted().
Cannot use Thread.stop().
Cannot put the user code in a process jail.
The answer to your question is "no, there is no way of handling this situation". You've pretty much systematically designed things so that you have zero control over untrusted third-party code. This is ... a suboptimal design.
If you want to be able to handle anything, you're going to have to relax one (or preferably more!) of the above constraints.
Edited to add:
There might be a way around this for you without forcing your clients to change code if that is a(nother) constraint. Launch the Ruby code in another process and use some form of IPC mechanism to do interaction with your main code base. To avoid forcing the Ruby code to suddenly have to be coded to use explicit IPC, drop in a set of proxy objects for your API that do the IPC behind the scenes which themselves call proxy objects in your own server. That way your client code is given the illusion of working inside your server while you jail that code in its own process (which you can ultimately kill -9 as the ultimate sanction should it come to that).
Later you're going to want to wean your clients from the illusion since IPC and native calls are very different and hiding that behind a proxy can be evil, but it's a stopgap you can use while you deprecate APIs and move your clients over to the new APIs.
I'm not sure about the Ruby angle (or of the threading angle) of things here, but if you're running user-submitted code, you had best run it in a separate process rather than in a separate thread of the same process.
Rule number one: Never trust user input. Much less if the input is code!
Cheers
Usually you have a variable to indicate to stop a thread. Some other thread then would set this variable to true. Finally you periodically check, whether the variable is set or not.
But given that you can't change user code , I am afraid there isn't a safe way of doing it.
For Running Thread Thread.Interrupt wont actually stop as sfussenegger mentioned aforth (thanks sfussenegger recollected after reading spec).
using a shared variable to signal that it should stop what it is doing. The thread should check the variable periodically,(ex : use a while loop ) and exit in an orderly manner.
private boolean isExit= false;
public void beforeExit() {
isExit= true;
}
public void run() {
while (!isExit) {
}
}