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.
Related
I'm a bit new to Threads and can't seem to find exactly what I need online. The problem I am trying to solve is having multiple clients connect to a server, and running simultaneously. The number of clients is arbitrary, and a client should be able to connect at any time. To do this, I created the "Server" class which stores all the information about clients and is essentially the hub. I then have a helper class "UserThread," which implements Runnable and each UserThread can connect to a client. The problem I'm having is running multiple UserThreads simultaneously. Here is the code I currently have in the Server class for creating new UserThreads:
int currentPort = 1;
while (true) {
System.out.println(currentPort);
System.out.println("waiting for user to connect");
Thread thread = new Thread(new UserThread(currentPort, this));
thread.start();
// A
System.out.println("Connected");
currentPort++;
}
And here is the run method of UserThread:
public void run() {
try {
ServerSocket serverSocket = new ServerSocket(port);
Socket socket = serverSocket.accept();
// B
} catch (Exception e) {
e.printStackTrace();
}
// down here doesn't effect my question so I excluded it
}
I've labeled A and B in each one as comments. Initially when I was just testing with a single instance of UserThread running, I was able to replace A with "user.join();" This allowed the UserThread to run, but it stopped the while loop in Server. What I need, and may not exist the way I think it does, is some code to put in spot A that pauses the while loop until line B is called in UserThread. Then, both the Server and the new UserThread will both continue working simultaneously. If another user connects to the Server, another UserThread is created and all three continue to work. This should function for an arbitrary number of connected Users.
So far, I've tried replacing A with "user.wait()" and B with "this.notify()" but I don't think either of those do what I think they do. user.wait() ended up throwing "java.lang.IllegalMonitorStateException: current thread is not owner". I tried then surrounding it with synchronized(user){} from a post I saw online but it still threw the same exception. At this point I'm pretty lost, so I'd like any insight possible. Do such lines of code exist to replace A and B, or am I approaching this problem in the completely wrong way? Thanks for any help.
Couple of problems here:
wait and notify
They would work here, but you can't call x.wait/notify/notifyAll unless you are within a synchronized(x) block. While x.wait() is waiting, you won't be holding that lock; you'll regain it once wait() returns.
This isn't how to do servers
You make 1 single ServerSocket object, and one thread that will repeatedly do this:
Call accept() on the serversocket object.
Create a new thread; hand it the Socket that comes out of that call.
Start that thread
Go back to the beginning
Your solution is bizarre, and really requires you to fire up all threads simultaneously, listening to a bevy of ports (for no particular reason), and thus limiting incoming connections rather severely.
Then, if you want any of those threads to wait until something happens, use wait/notify, or better yet, stuff from j.u.c. For example, CountDownLatch lets you safely wait until X things happen, for example, have the user threads countdown the latch, and have some other thread wait until 4 countdowns have occurred: That's how you'd write software that waits until 4 connections have come in.
A full tutorial on how to do multithreading in java is just a tad beyond the scope of a reasonable SO question.
My application relies on eBay Picture Service to upload images to from my desktop to eBay server. Normally, it takes a few seconds for the upload to complete. However, it can sometimes take hours, and occasionally, it may never complete. It is unpredictable when this will happen and no exception is thrown by API. This causes my application to call external API too many times simultaneously and also hogs system resources.
My goal is to set a timeout for upload and cancel underlying process if upload is not successful within time limit. I tried to set a timeout on ExecutorService and then cancel future when an exception is thrown as suggested in this and this post:
ExecutorService executorService = Executors.newFixedThreadPool(10);
ArrayList<Future<?>> futuresList = new ArrayList<Future<?>>();
for (String singleTask : taskList) {
futuresList.add(executorService.submit( new Runnable(){
#Override
public void run(){
try {
myBlockingTask(singleTask);
} catch (IOException | InterruptedException | ExecutionException e) {
e.printStackTrace();
}
}
}));
}
try {
future.get(240, TimeUnit.SECONDS);
} catch (Exception e){
e.printStackTrace();
// Stops parent thread from waiting for child but it does not terminate 'child' thread.
// As a result, call(s) to external API continue to increase (rapidly) since the underlying process never actually ends
future.cancel(true);
}
Unfortunately, this solution only works when the underlying thread keeps running due to an infinite loop and/or the underlying operation is designed to understand Thread.isInterrupted() (like in a while() loop). In this case, however, I have no control over the underlying process so it is not possible for me to call interrupt in the child thread. The API does not provide a timeout method either.
Is there any way to force blocking operation to terminate in this example?
Thanks!
First of all i would recommend you to make a thread dump in order to find an exact place which is hang. In meantime try to look at source code of library you use trying to understand what could cause this hanging. Most likely the library invokes something which is not responsible for interruption. Luckily there are not so many such operations and most of them are related to socket I/O. The most comprehensive list i've ever seen for JDK is present in "Java Concurrency in Practice" book chapter 7.1.6. Socket I/O looks like a reasonable explanation for your case because client library for sure invokes ebay API via HTTP. If it uses standard JDK HTTP client try to set these timeouts. Otherwise the only possible solution is to change source code of the library to make it responsible to interruption or use another one :)
There are two or more threads: main and several children. Children are workers, main controls children liveness. Once main thread detects a child thread is dead it creates new thread.
Currently I can't imagine better solution than checking t.isAlive() on each thread in a loop but it is well known that developers should avoid polling at any cost.
Note. Worker thread can wait several minutes on HTTP response (getInputStream() on URLConnection)
UPDATE
Worker doesn't finish its job but after it received a response or on timeout it creates new connection and awaiting for server response again.
You shouldn't use low level Thread methods if you don't really need them. Instead, use Java Concurrency API. For your case, I would use a thread pool which controls the threads. If a thread finishes its job, it returns to the pool rather than really dying.
According to the purposes in your question and our "dialog" in comments, I suggest you following simple idea.
if you want to recreate thread with same functionallity, why do you allow threads to die?
If you have, as you said, 3-d party threads implementation, you can wrap them into another thread and do not allow them to die.
Consider, 3-d party Thread implementation is called ThirdPartyThread class. So, instead of checking their state with .isAlive(), just wrap it into another thread with try ... catch:
new Thread(new Runnable() {
#Override
public void run() {
do {
try {
new ThirdPartyThread().run();
} catch (Throwable t) {
// you can vary behaviour here with different classes of exceptions.
// But main idea is to catch their death and go on
}
} while (true); // instead of `true` you can use your specific condition
}
}).start();
Andremoniy: if you want to recreate thread with same functionallity, why do you allow threads to die?
gumkins: For example I can't fix uncaught exceptions in third-party code.
If it doesn't make sense to catch the exception, and continue running in the same thread, then it won't make any sense to start a new thread to take the old thread's place. Starting a new thread accomplishes nothing.
All threads share the same heap and the same global state. If the library keeps global state in static variables or singleton objects, then that same state will be visible in every thread. If the global state is broken/invalid after some exception, then it's going to be invalid/broken in every thread. (And that includes any new threads that your program creates after the damage was done.)
Incidentally, the wheel that you are trying to re-invent here has a name: It's called a "thread pool."
The Java standard library provides a number of different kinds of thread pool which all implement the java.util.concurrent.ExecutorService interface. You should check it out.
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.
I've been trying to teach myself concurrency, and I've run into an issue. I understand that two Java threads can communicate to each other via wait() and notify(). However, this requires one thread to be inactive and essentially "just sitting around" until the other one wakes it up.
Is it possible to have both threads running simultaneously and still have them listening for notifications from the other? Would this be accomplished through concurrency techniques or instead something like an ActionListener?
For example, the project I'm testing this on is basically a grid where different entities wander around through different cells. When two of the entities happen to wander into the same cell, I'd like one to notify the other and something different to happen based on this (for instance, a greeting: "Hello there!"). But as it stands, with the wait/notify paradigm, one of the threads/entities has to simply sit in one cell waiting for another to wander in; they can't both move around.
There's a few ways you can communicate between threads. Using the most common approach you can use instance variables to share info between threads but you must take care to only write from one thread or synchronize any updates to the shared variable. Alternatively you can use Piped I/O streams which were designed for inter-thread communication, or passing raw data between threads. One thread writes info to the stream while the other reads it.
Here's an example method that would read output from a slow network connection and dump it to System.out using threads.
public void threads() throws IOException {
final PipedOutputStream outputForMainThread = new PipedOutputStream();
new Thread(new Runnable() {
#Override
public void run() {
while(moreDataOnNetwork()) {
byte[] data = readDataFromNetwork();
try {
outputForMainThread.write(data);
} catch (IOException e) {
e.printStackTrace();
}
}
}
}).start();
BufferedReader reader = new BufferedReader(new InputStreamReader(new PipedInputStream(outputForMainThread)));
for(String eachLine = reader.readLine(); eachLine != null; eachLine = reader.readLine()) {
System.out.println(eachLine);
}
}
However it almost sounds like you want an event callback mechanism where one thread (your user interface thread) is notified when the other thread detects a certain condition. Depending on your platform much of this is baked in. Using Android, for eg., you could have a thread that determines that a grid entity moved. It would send an update to the main user interface thread to repaint the screen. Such an update could resemble:
public void gridEntityDidUpdate(final Point fromLocation, final Point toLocation) {
Activity activity = getMainActivity();
activity.runOnUiThread(
new Runnable() {
#Override
public void run() {
updateScreen(fromLocation, toLocation);
if(pointsAreCoincedent(fromLocation, toLocation)) {
System.out.println("Hello there!");
}
}
}
);
}
private void updateScreen(Point fromLocation, Point toLocation) {
//Update the main activity screen here
}
In this scenario you have a background thread that works out the position of all on-screen elements and notifies the main thread when elements positions change. There is an extracted method that determines if 2 points are coincidental or the same.
You can use Erlang language to communicated safely among the Processes which runs within there own Address space along with Java as a better and safe alternative to thread.
I've been trying to teach myself concurrency, and I've run into an issue. I understand that two Java threads can communicate to each other via wait() and notify().
The "classic" Java threading tutorials teach wait/notify early on. Back around the Java 1.1, 1.2 time frame that's all there was.
However if you can get a copy of the excellent "Java Concurrency in Practice" by Brian Goetz, wait/notify are not discussed until chapter 14 "Building Custom Synchronizers" in section IV advanced topics. I am severely paraphrasing here, but the impression I got was "OK if you've read the 300 previous pages and none of the building blocks discussed so far meet your needs, then you can try building your own using wait/notify".
My point is that wait/notify, although very important, might not be the best place to start learning concurrency. Some of the answers/comments in this question (producer/consumer, ExecutorService) are referring to the higher level concurrency building blocks that were added in Java 5. Even though this stuff was added later, it's the stuff you should be learning first.
Back to your question - here are a couple of thoughts:
If this is a GUI application and you want to have a background thread do some work, check out SwingWorker. I have had success using a SwingWorker (section 9.3.3) where the background thread reads messages from a blocking queue (section 5.3) does some work and notifies the GUI thread by invoking the higher level "publish" method. No "wait/notify" - at least not in my code.
If the application is not Swing-based and you want to have different threads performing tasks in parallel and occasionally send messages to each other, consider ZeroMQ "The socket library that acts as a concurrency framework." With ZeroMQ, each thread is running an event loop which reads and processes messages. A thread can schedule work on it's own thread by sending itself a message. It can schedule work/notify a different thread by sending a message to that thread (socket).
Anyhow, good luck.
Try using ThreadManager class, which has List<Thread> and is kind of like a semaphore object. Your threads should be able to find and reference other threads from there.
Is it possible to have both threads running simultaneously and still have them listening for notifications from the other?
Whenever they are not waiting, they can be doing something at the same time. If they appear to be just waiting for each other it is likely you are better off with one thread. (Using multiple threads is not always better)
Would this be accomplished through concurrency techniques or instead something like an ActionListener?
It is more likely to be a design issue with how you have broken down the problem. Threads work best when there is a minimum of interaction between them. If they are highly dependent on each other you should consider using less threads.
But as it stands, with the wait/notify paradigm, one of the threads/entities has to simply sit in one cell waiting for another to wander in;
I don't see why you need wait/notify here at all. I would just have them move around and send messages to one another when they are in the same cell.