How to avoid use of Thread.Sleep - java

I never gave the use of Thread.Sleep much thought, until I downloaded the latest version of Netbeans. Netbeans now warns you not to use Thread.Sleep. So I did some research on the topic and found people stating that you only need to use Thread.Sleep for debugging/testing purposes and that if you use it at any other time you have poorly written code.
So my question is how can I keep from using Thread.Sleep in the following situation.
I have written a server application that interfaces with another application. The server has two threads:
Handles the data coming over the socket and sends back other information or just plain acknoledgements.
This is the main thread. After kicking off the socket thread it going into an indefinite while loop. Within this while loop I check to make sure the socket thread is still active and that the user hasn't asked to exit the application via a TrayIcon interface. Then I sleep and continue this while loop.
With this application, the TrayIcon is the only UI.
Here is the snippet I'm referencing:
// continues running as long as the exitth file is not present and
// the tray icon is not in a safe to exit status.
while(doNotExit())
{
if (getPrimaryThread() == null || !getPrimaryThread().isAlive())
resetsThreadAndSocket();
try
{
// check to see if the socket threads are still active, if not create new ones.
if ((getPrimaryThread() == null || !getPrimaryThread().isAlive()))
createSocketThread();
// check right before sleeping that the user does not want to exit.
if(getTrayIcon().isExiting())
break;
// puts the main Thread to sleep for 3 seconds
Thread.sleep(3000);
}
catch(SQLException ex)
{
_log.error(ex.getMessage(), ex);
restartDatabase();
}
}

The 'preferred' method in most cases would be to use the ScheduledExecutorService built into JavaSE for performing a periodic task, rather than reimplementing it yourself every time using a while loop and Thread.Sleep().
There's nothing wrong per-se with your example. The language just now has a much more robust support for doing that built into it as of Java 5.

Instead of your Thread.sleep(3000) do:
getPrimaryThread().join(3000)
This will wait for the thread to exit for 3 seconds.

You should consider attaching an event listener to your tray icon instead of polling its state. That way you won't need an extra thread just for monitoring.
If you can't do that for some reason, you can still do away with the extra thread as the Timer class can do the waiting for you.

You seem to be paranoid that some condition (maybe a RuntimeException or Error?) is going to cause your socket Thread to just die. Ideally, you would design your Socket Thread such that it protected itself from crashing. The following example creates a loop that can only be broken as a result of a JVM Error or Thread interrupt:
public void run() {
while(!Thread.currentThread.isInterrupted()) {
try {
//you application logic
} catch (RuntimeException e) {
//log uncaught exception
}
}
}
In order to shutdown the application, you would attach a listener to the TrayIcon which contained a reference to the SocketThread and could stop it by simply interrupting it.
socketThread.interrupt();
I'll leave figuring how to add an ActionListener to a TrayIcon up to you.

Related

How to Kill All Threads Created by the Current Class

I'm new to web programming, and I've created a server class that forks off ClientProcess threads to service each client's connection. Currently I have 2 problems:
Keeping track of running threads
Shutting down the threads once execution finishes and closing connections (the topic of this thread)
For problem one, I'm currently using an Arraylist<ClientProcess> to hold a list of threads and call Thread.interrupt() at the appropriate time. I know that the java API contains a class ThreadGroup that is supposed to perform this task but I don't know how I'm supposed to add threads to the group or if that just happens automatically when I call Thread.start(). In other words, I have already solved this problem but if anyone knows a better way to perform this I'm open to implement one.
For problem two, I still have no clue how to begin. I've read the article about Thread.stop by Oracle but I don't understand their recommendation for how to interrupt/stop the thread. For reference, my ClientProcess class looks something like this:
public class ClientProcess extends Thread {
private Socket clientConnection;
/* class constructor, etc. */
#Override
public void run() {
try (BufferedReader in = new BufferedReader(clientConnection.getInputStream());
PrintWriter out = new PrintWriter(clientConnection.getOutputStream())) {
while (in.hasNext()) { /* do stuff */ }
} catch (InterruptedException e) {
/* close connection, clean resources, etc. */
}
}
}
From the article, it looks like I'm supposed to be storing a reference to the thread in the class (why?) and that I'm supposed to set the variable to null when I want to stop the thread from running, then check for null anywhere that the thread may stop. I don't see a reason for my thread to hold a reference to itself or to have to check if it's null with every single branch statement that I need to perform in run(). I'm open to a complete refactor of the code (this project is still in its early stages) but I'm just looking for anyone to point me in the right direction.
Edit: The question already has a few answers, but I realized that my real question is very different than what I asked. I'm trying to learn modern techniques for web programming, and I remembered that a few years ago I read in a C++ web programming book that multithreading is typically used in order to service clients. After poking around a bit on the web I've seen that web programming has evolved to fit demand and now uses completely different paradigms. What I really should have asked was something along the lines of 'How do I Create a Server that can Handle Taskes Asynchronously' or 'What are some Modern Programming Paradigms for Server/Client Architectures?' The real answer to this question is that multithreading is no longer considered tractable and that there are other paradigms that I should be using to solve this problem.
If you make blocking calls that throw an interrupt exception, then interrupting the thread will cause an interrupt exception. Otherwise, you'll have to explicitly check if the thread has been interrupted. You should have an executor service for starting your class.
ExecutorService executor = Executors.newFixedThreadPool(2);
Then submit tasks:
Future<?> f = executor.submit( ()->{
try (BufferedReader in = new BufferedReader(clientConnection.getInputStream());
PrintWriter out = new PrintWriter(clientConnection.getOutputStream())) {
while (in.hasNext()) { /* do stuff */ }
} catch (InterruptedException e) {
//try with resources takes care of the streams.
return;
}
} );
Then when you need to shutdown all you have to do is.
executor.shutdownNow();
Then your currently running tasks will be interrupted. There are execution services with more features to, and you can use the futures to control the task.
1) Keeping track of running threads
I know that the java API contains a class ThreadGroup that is supposed to perform this task but I don't know how I'm supposed to add threads to the group
Yeah, using your own collection of threads, or even better an ExecutorService, to manage your threads is the right thing to do. I've written a large number of Java threaded applications and never had to use a ThreadGroup.
2) Shutting down the threads once execution finishes and closing connections
Unfortunately, you cannot use thread.interrupt() to cause an IO method to throw InterruptedException because none of the IO methods throw that exception unless you are using NIO's InterruptibleChannel or other special classes. If you are interrupting a thread that is processing something, you can test for Thread.currentThread().isInterrupted() but not when you are blocking on IO.
The right thing to do here would be to close the client socket out from under it. I would add a clientProcess.close() method which closes the Socket clientConnection.
public void close() throws IOException {
clientConnection.close();
}
This will then cause the client thread which is reading on that socket to get an IOException when it goes to read from the socket which it can catch and return to stop running.
From the article, it looks like I'm supposed to be storing a reference to the thread in the class (why?) and that I'm supposed to set the variable to null when I want to stop the thread from running
If your thread is looping around, it is common to use a volatile field which could be set by the caller to cause the looping thread to stop. But in your case, the thread is waiting on IO and not in a processing loop so I think closing the socket is the way to go.

Shutting down a ThreadPoolExecutor when a worker thread has an Exception

What is the best way for a worker thread to signal that a graceful shutdown should be initiated?
I have a fixed size thread pool which works through a continuous set of tasks, each lasting no more than a few seconds. During normal operation this works well and chugs along with its workload.
The problem I am having is when an exception is thrown in one of the threads. If this happens I would like to bring the whole thing down and have been unable to get this working correctly.
Current approach
The naive approach that I have been using is to have a static method in the "Supervisor" class which shuts down the thread pool using the standard shutdown() and awaitTermination() approach. This is then called by any of the "Worker" classes if they encounter a problem. This was done rather than propagating the exception because execute() requires a Runnable and the run() method cannot throw exceptions.
Here is some pseudo code:
// Finds work to do and passes them on to workers
class Supervisor {
ThreadPoolExecutor exec;
static main() {
exec = new FixedThreadPool(...);
forever {
exec.execute(new Worker(next available task));
}
}
static stopThreadPool() {
exec.shutdown();
if(!exec.awaitTermination(timeout_value)) {
print "Timed out waiting on terminate"
}
}
}
class Worker {
run() {
try {
// Work goes here
} catch () {
Supervisor.stopThreadPool()
}
}
}
The effect that I am seeing is that the threads do pause for a while but then I see the timeout message and they all resume their processing. This pattern continues until I manually shut it down. If I put a call to stopThreadPool() in the main method after having broken out of the loop, the shutdown happens correctly as expected.
The approach is clearly wrong because it doesn't work, but it also feels like the design is not right.
To reiterate the question: What is the best way for a worker thread to signal that a graceful shutdown should be initiated?
Additional information
The questions I have looked at on SO have been of two types:
"How do I kill a thread in a thread pool?"
"How do I know all my threads are finished?"
That's not what I'm after. They also seem to exclusively talk about a finite set of tasks whereas I am dealing with a continuous feed.
I have read about an alternative approach using exec.submit() and Futures which puts the onus on the supervisor class to check that everything's ok but I don't know enough about it to know if it's a better design. The exception case is, well ... exceptional and so I wouldn't want to add work/complexity to the normal case unnecessarily.
(Minor side note: This is a work project and there are other people involved. I'm saying "I" in the question for simplicity.)
You are not that far from the correct solution, the problem is that you need to handle the interruption caused by the shutdown call properly. So your thread's run method should look like this:
run () {
try {
while (Thread.interrupted() == false) {
doSomeWork();
}
} catch (Exception e) {
myExecutor.shutdown();
}
}
Note that I explicitly used the shutdown() without awaitTermination() because otherwise the waiting thread is the one that keeps the Executor from properly terminating, because one thread is still waiting. Perfect single-thread deadlock. ;)
The check for interruption is by the way the hint on how to kill a thread gracefully: get the run method to end by either setting a running boolean to false or by interrupting, the thread will die a moment later.
To check if all of your threads have terminated (= are just about to end their run method), you can use a CountDownLatch for a simple case or the CyclicBarrier/Phaser class for more complex cases.
There are 2 problems here:
If you intend to just force a shutdown on any exception in a worker, then you do you use shutdown() and await counterparts. Just force it using shutdownNow and you should be good. shutdown does a graceful shutdown.
try to break your for loop when such a thing happens. The best way to do it is have a try catch in your for loop around the execute call. when an exception happens in a worker throw an unchecked exception and catch it in the for loop. Terminate the for loop and call your method to force shutdown on executor. This is a cleaner approach. Alternately you can also consider using consider a handler in your executor for doing this.

What is the exact usage of Interrupts in java?

I am new to Java concurrecny and I am reading this at the moment: Java Tutorial-Interrupts But I can't really understand where and why I should use an Interrupt. Can someone give me an example (code) so I better understand it? thx
Interrupts are used when you want to (cough) interrupt the thread -- typically meaning stop it from operating. Thread.stop() has been deprecated because of various issues so Thread.interrupt() is the way that you tell the thread that it should cease running -- it should cleanup what it is doing and quit. In reality, the programmer can use the interrupt signal on a thread in any way that they want.
Some examples:
Your thread might be sleeping for a minute and then spidering a web-page. You want it to stop this behavior.
Maybe you have a thread which is consuming from a queue of jobs and you want to tell it that no more jobs are coming its way.
Maybe you have a number of background threads that you want to interrupt because the process is shutting down and you want to do so cleanly.
There are certainly many ways to accomplish the above signaling but interrupt can be used.
One of the more powerful ways that Thread.interrupt() affects a running thread is by throwing InterruptedException from a couple different methods including Thread.sleep(), Object.wait(), and others.
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
// i've been interrupted
// catching InterruptedException clears the interrupt status on the thread
// so a good pattern is to re-interrupt the thread
Thread.currentThread().interrupt();
// but maybe we want to just kill the thread
return;
}
Also, often in a thread we are looping doing some task and so we check for interrupt status:
while (!Thread.currentThread().isInterrupted()) {
// keep doing our task until we are interrupted
}
With multi-threading, the idea is that you have some work that you divide up among several threads. The classic example would be to have a thread that does a background calculation or a background action such as a server query that will take a fair amount of time without doing that action in the main thread that handles the user interface.
By offloading those actions that might take a noticeable amount of time, you can prevent the user interface from seeming to get stuck. An example of this would be when you start an action in a displayed dialog, go to another window then return to the displayed dialog and the dialog does not update itself when you click on it.
Sometimes the background activity needs to be stopped. In that case you would use the Thread.interrupt() method to request that the thread stop itself.
An example might be if you have a client that is getting status information from a server once a second. The background thread handles the communication to the server and getting the data. The user interface thread takes the data and updates the display. Then the user presses a Stop or Cancel button on the display. The user interface thread then does an interrupt on the background thread so that it will stop requesting the status information from the server.
In concurrent programming, many programmers arrive at the conclusion that they need to stop a thread. They decide it would be a good idea to have some sort of boolean flag to tell indicate to the thread that it should stop. The interrupt flag is that boolean mechanism provided through the Java standard library.
For example:
class LongIterativeTask implements Runnable {
public void run() {
while (!thread.isInterrupted()) { //while not interrupted
//do an iteration of a long task
}
}
}
class LongSequentialTask implements Runnable {
public void run() {
//do some work
if (!thread.isInterrupted()) { //check flag before starting long process
//do a lot of long work that needs to be done in one pass
}
// do some stuff to setup for next step
if (!thread.isInterrupted()) { //check flag before starting long process
//do the next step of long work that needs to be done in one pass
}
}
}

End execution of Thread without using its stop() method

I have a Swing form with a button, which is when clicked starts SocketServer for listening to incoming requests in a separate thread. Following is structure of classes I have.
MainForm : This is my main class which launches Swing Form. It has two buttons, "start server" and "stop buttons".
MySocketServer : This class is where SocketServer object exists, it has methods startServer() and stopServer().
Following is Start button's Click Event Body.
t = new Thread(new Runnable() //Object t is created globally in this main class.
{
public void run()
{
myss = new MySocketServer(); //Object myss has similar accessibility as t.
myss.startServer();
}
});
t.start();
And Following is Stop Button's Click Event Body
myss.stopServer();
if(t.isAlive());
System.out.println("Thread is still alive!!");
Though I can toggle SockeServer "start" and "stop" as my times I want, but I realize that everytime I start the server, new thread gets created and it remains active even though server is stopped using MySocketServer's method.
I can use stop() of Thread and stop the thread execution but since it is depreciated and I have studied that threads get ended once their run() method has executed completely, but I have startServer() method separated so that it can handle connected clients separately.
Please note that startServer() has While-Listen loop, so essentially run() method of thread is in infinite state of execution, until I explicitly call stopServer() and halt the loop.
what can be done here?
Firstly, you are right to not try to use Thread.stop(). It is potentially dangerous.
So what should you do?
One possibility might to be to write your server thread like this:
....
ServerSocket ss = new ServerSocket(...);
try {
while (keepGoing) {
Socket s = ss.accept(...);
try {
// do stuff
} finally {
// close socket
}
}
} finally {
// close the server socket
}
and have stopServer clear the keepGoing flag. But the problem is that the stop typically will come while the thread is blocked in the accept call, and there's nothing to unblock it.
Another possibility might be to call Thread.interrupt() on the thread. That causes some things to unblock, and throw an exception, but I don't think it will unblock the accept() call though. (However, this is still better than setting a flag if the "do stuff" part needs interrupting.)
The real solution (I think) is to close the ServerSocket. This will cause the ss.accept() call to unblock and throw an exception, which you need to handle in the server thread.
In your MySocketServer class in the while loop you need a flag which will test if it should keep running or not.
In your newly added shutdown method set the flag which the loop in the thread will test. Once the loop breaks and run() returns the thread will end.
You shouldn't use stop(). Take a look at this http://docs.oracle.com/javase/1.4.2/docs/guide/misc/threadPrimitiveDeprecation.html
The solution with infinite loop and start/stop flags is straightforward but leads to ineffective using of CPU time. The better way is to use wait/notify approach. The way you operate with MySocketServer gives me feeling that you have other infinite loop inside the startServer(). That's why you have to stop it. It would be better to wrap this loop into it's own thread internally and make start/stop methods operate with this thread state in wait/notify manner.
Forgot to mention, as your GUI runs in its own thread you can't escape start/stop flag inside the MySocketServer because using wait() in GUI thread will make it hanged.

Make a java program sleep without threading

I have a java program that does some calculations and then uploads the results to a MYSQL database (hosted in another computer in the same network). I sometimes face the problem that the program does calculations faster than it uploads the result. Therefore it is not able to upload all the results. The program currently is not threaded.
Is there a way I can make the program sleep for a few milliseconds after it has done the calculations so that the upload takes place properly. (Like in other languages sleep or wait function)
I can thread the program but that will be too much rewriting. Is there an easier way?
Thanks
Is there a way I can make the program sleep for a few milliseconds after it has done the calculations so that the upload takes place properly. (Like in other languages sleep or wait function)
Thread.sleep(milliseconds) is a public static method that will work with single threaded programs as well. Something like the following is a typical pattern:
try {
// to sleep 10 seconds
Thread.sleep(10000);
} catch (InterruptedException e) {
// recommended because catching InterruptedException clears interrupt flag
Thread.currentThread().interrupt();
// you probably want to quit if the thread is interrupted
return;
}
There is no need to implement Runnable or do anything else with thread calls. You can just call it anytime to put a pause in some code.
You don't have to re-thread or any such thing. All you need to do is call:
Thread.Sleep(5000); // pause the app for 5 seconds
Every application is also a thread, in your case also called a single-threaded app. You can use a threading API like Sleep w/o any other code or refactoring.
Big note of caution though: If you need to use Thread.Sleep to manage your control flow then there's probably something going wrong architecturally. From your OP I am concerned than in what you describe as a single-threaded app you seem to have one operation "outpacing" another. This should not be possible, unless you're receiving asynch events from elsewhere.
Another caveat: Sleep takes a millisecond parameter that's usually arbitrary and just means "wait a little while." The problem is that a "little while" may be OK today but tomorrow your machine will be under greater load and "a little while" will no longer be good enough, your Sleep will lapse and the same error will appear. Sure, you can set the time out to "a long while" but then you'll be waiting "a long while" for each and every transaction... Catch 22.
Use Thread.sleep():
try
{
Thread.sleep(1000); // Sleep for one second
}
catch (InterruptedException e)
{
Thread.currentThread().interrupt();
}
This does not introduce a new Thread into the program or require any other Thread related machinery.
Just use:-
try
{
Thread.sleep(<time in ms>);
}
catch(InterruptedException ex}
{
}
This will make the current thread (e.g. main thread) sleep.
The static method sleep() in the java.lang.Thread class pauses the current thread -- which could just be the main thread -- when called. You don't need to do anything special to use it.
Every Java application executes in a thread in the JVM. Calling the static method Thread.sleep will cause your application's thread (the one that is running) to stop
Your program is not Multi-threaded...but it is using a thread. Thread.Sleep will still work.
You can use Thread.sleep(); after the calculation without the need to rewrite your whole program with threads!

Categories