I'm pretty new to Scala/Java and have to build a service that will have at least two sub-services running: a socket-based subscriber that listens for messages to kick off workers, and a web server that will serve a status page for those workers.
I can get these things to run, but after both start the whole process immediately exits with code 0.
I did some research to learn about user threads vs daemon threads in Java, as well as threading in general, so now my approach is basically this:
val webServerThread = new Thread(WebServer(config)).start()
val subscriberThread = new Thread(Subscriber(config)).start()
val aliveThread = new Thread(keepAlive(true)).start()
The third thread simply contains a while(true){} block to leave a user thread up.
There has to be a smarter way of doing this, but I don't know what it is and seems impossible to discover. How do http server's stay running, for example? Is there a while(true) loop underneath every framework out there?
Any help would be appreciated.
The run() method of the thread would have to be an endless loop, until some condition occurs and you exit the loop.
To wait for a thread to exit, the way to do that is as follows:
final Runnable runnable = new Runnable() {
public void run() {
// do stuff
}
};
final Thread thread = new Thread(runnable);
thread.start();
try {
thread.join();
} catch (final InterruptedException e) {
// deal with exception
}
Obviously, that will only wait for one thread. It depends on your scenario whether this makes sense. Alternatively, you could use a ThreadPoolExecutor, invoke the shutdown() or shutdownNow() method, and use awaitTermination for it to stop.
So for all services that have to stay running, say a web server or something, is there some code somewhere that just is basically while(shouldRun) {//nothing}?
No. There is never any reason to have a JRE thread that does nothing, and a thread that uses 100% CPU while accomplishing nothing would be even worse.
Pretty much every thread in a program should sit in a loop, waiting for something to do.* E.g., An I/O thread that waits to receive and process input from some external source, a pool thread that waits for tasks to perform, a scheduler thread that waits until it's time to perform the next scheduled task.
A web service must have at least one thread that sits in a loop and waits to handle incoming connections. I don't remember how to write that without doing some research first because there are so many open-source web servers out there: There's no reason to write your own except for practice. There is even one built-in to the Oracle JRE.** In pseudo code, it might look like this:
while (! time_to_shut_down) {
connection = WaitForIncomingConnection();
clientThreadPool.handle(connection);
}
I can get these things to run, but after both start the whole process immediately exits with code 0.
I do not know why your program won't stay running. I am not familiar with Scala or, with the WebServer class or the Subscriber class.
What is config? Maybe somebody would be able to help you if you would ammend your question to show how you create the configuration object.
*One exception to that rule would be a compute-thread in a program that performs a single, massive computation and then exits.
**See https://stackoverflow.com/a/3732328/801894. The server.start(); call in that example is what kicks off the service thread. And, notice that the main() thread terminates right after it starts the server thread.
Related
I am making an online game in Java and I ran into one particular issue where I was trying to find the most efficient way to send clients spawn entity NPC packets. I of course understand how to send them but I wanted to do it off of the main game loop since it requires looping through a map of NPC's (I also made sure its thread safe). To do this I thought a BlockingQueue was my best option so I created a new thread set it to daemon then passed in a runnable object. Then whenever I needed to send one of these packets I would use the insertElement() method to add to the queue. Here is how it looks.
public class NpcAsyncRunnable implements Runnable {
private final BlockingQueue<NpcObject> blockingQueue;
public NpcAsyncRunnable() {
blockingQueue = new LinkedBlockingQueue<>();
}
#Override
public void run() {
while(true) {
try {
final NpcObject obj = blockingQueue.take();
//Run my algorithm here
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public void insertElement(final NpcObject obj) {
blockingQueue.add(obj);
}
}
Now my question is how efficient is this? I am running the thread the whole time in an infinite loop because I always want it to be checking for another inserted element. However, my concern is if I have too many async threads listening would it start to clog up the CPU? I ask this because I know a CPU core can only run 1 thread of execution at a time but with hyperthreading (AMD has the same thing but its called something different) it can jump between executing multiple threads when one needs to search for something in memory. But does this infinite loop without making it sleep mean it will always be checking if the queue has a new entry? My worry is I will make a CPU core waste all its resources infinitely looping over this one thread waiting for another insertion.
Does the CPU instead auto assign small breaks to allow other threads to execute or do I need to include sleep statements so that this thread is not using way more resources than is required? How much CPU time will this use just idling?
...does this infinite loop without making it sleep mean...?
blockingQueue.take() does sleep until there's something in the queue to be taken. The Javadoc for the take method says, "Retrieves and removes the head of this queue, waiting if necessary until an element becomes available."
"Waiting" means it sleeps. Any time you are forced to write catch (InterruptedException...), it's because you called something that sleeps.
how does it know when something is added if its sleeping? It has to be running in order to check if something has been added to the queue right?
No. It doesn't need to run. It doesn't need to "check." A BlockingQueue effectively* uses object.wait() to make a thread "sleep," and it uses object.notify() to wake it up again. When one thread in a Java program calls o.wait() for any Object o, the wait() call will not return** until some other thread calls o.notify() for the same Object o.
wait() and notify() are thin wrappers for operating system-specific calls that do approximately the same thing. All the magic happens in the OS. In a nutshell;
The OS suspends the thread that calls o.wait(), and it adds the thread's saved execution context to a queue associated with the object o.
When some other thread calls o.notify(), the OS takes the saved execution context at the head of the queue (if there is one***), and moves it to the "ready-to-run" queue.
Some time later, the OS scheduler will find the saved thread context at the head of the "ready-to-run" queue, and it will restore the context on one of the system's CPUs.
At that point, the o.wait() call will return, and the thread that waited can then proceed to deal with whatever it was waiting for (e.g., an NpcAsyncRunnable object in your case.)
* I don't know whether any particular class that implements BlockingQueue actually uses object.wait() and object.notify(), but even if they don't use those methods, then they almost certainly use the same operating system calls that underlie wait() and notify().
** Almost true, but there's something called "spurious wakeup." Correctly using o.wait() and o.notify() is tricky. I strongly recommend that you work through the tutorial if you want to try it yourself.
*** o.notify() does absolutely nothing at all if no other thread is already waiting at the moment when it is called. Beginners who don't understand this often ask, "Why did wait() never return?" It didn't return because the thread that wait()ed was too late. Again, I urge you to work through the tutorial if you want to learn how to avoid that particular bug.
In a web app i have a method, this waits for another thread for generate reports if the quantity of customers is less than 10, but if greater than 10 i start my thread but without apply the join method, when the thread finish i notify by e-mail.
I'm a little afraid about the orphan threads with a large execution and the impact on the server.
Is good launch a "heavy" process in background (asynchronically) without use the join method or there is a better way to make it?
try {
thread.start();
if(flagSendEmail > 10){
return "{\"message\":\"success\", \"text\":\"you will be notified by email\"}";
}else{
thread.join(); //the customer waits until finish
}
} catch (InterruptedException e) {
LogError.saveErrorApp(e.getMessage(), e);
return "{\"message\":\"danger\", \"text\":\"can't generate the reports\"}";
}
Orphan threads aren't the problem, simply make sure that the run() method has a finally block that sends out the email.
The problem is that you have no control over the number of threads and that's got nothing to do with calling join(). (Unless you always wait for every single thread in the caller, at which point there's no point launching a background thread in the first place.)
The solution is to use an ExecutorService, which gives you a thread pool, and thus precise control over how many of these background threads are running at any one time. If you submit more tasks than the executor can handle at a given time, the remaining ones are queued up, waiting to be run. This way you can control the load on your server.
An added bonus is that because an executor service will typically recycle the same worker threads, the overhead of submitting a new task is less, meaning that you don't need to bother about whether you've got more than 10 items or not, everything can be run the same way.
In your case you could even consider using two separate executors: one for running the report generation and another one for sending out the emails. The reason for this is that you may want to limit the number of emails sent out in a busy period but without slowing report generation down.
There's no point is starting a thread if the very next thing you do is join() it.
I'm not sure I understand what you're trying to do, but if your example is on the right path, then this would be even better because it avoids creating and destroying a new thread (expensive) in the flagSendEmail <= 10 case:
Runnable r = ...;
if (flagSendEmail > 10) {
Thread thread = new Thread(r);
thread.start();
return "...";
} else {
r.run();
return ???
}
But chances are, you should not be explicitly creating new Threads at all. Any time a program continually creates and destroys threads, that's a sign that it should be using a thread pool instead. (See the javadoc for java.util.concurrent.ThreadPoolExecutor)
By the way: t.join() does not do anything to thread t. It doesn't do anything at all except wait until thread t is dead.
Yes it is safe, I don't recall seeing any Thread#join() actual invocations.
But it will depends on what are you trying to do. I don't know if you mean to use a pool or threads that generate reports or have some resource assigned. In any case you should limit yourself to a maximum number of threads for reports. If they are getting blocked or looped (for some bug or poor synchronization), allowing more and more threads will utterly clog your application.
Thread#join waits for the referred thread to die. Are those threads actually ending? Are you waiting for a thread to die just to launch another thread? Usually synchronization is done with wait() and notify() over the synchronization object.
Launching a process (Runtime#exec()) probably will make things even worse, unless it helps work around some weird limitation.
There are some tools like JConsole which can give you some heads up about threads getting locked and other issues.
So I have this very relevant thread I start when the program starts.
The thread is listening to events coming from a bigger system as the main thread does other stuff.
The thread should never stop working and if it does, it should be recreated and started.
I think I know multiple ways to achieve this, but I'd like to know your opinion on some things :
Am I just striving for nothing? I mean, if I ideally try-catch all the code that can go wrong, will the thread ever betray me for no obvious reason?
What's the best practice to do what I stated? Periodically check the thread health with another thread and a ScheduledExecutor? Implement some kind of observable-observer pattern?
You can create the ExecutorService which is listening to the events via Executors.newSingleThreadExecutor().
In that case You don't have to take a look at the thread if it is healthy, the ExecutorService takes care of that. The SingleThreadExecutor is responsible that only one Task (Runnable or Callable) is running at one time.
If you are checking using normal Java provided methods to view the thread state correctly, you should not have any errors. In the case that a checked exception is thrown or the thread exits for some weird reason, a try-finally block should be sufficient to start a new thread (also ensure it is non-daemon). You could use a while loop with a periodic pause, preferably using a thread scheduling mechanism such as timed wait(...), or timed LockSupport#park(...). You can also sleep the thread as well.
The thread should never stop working and if it does,...
OK, so write it so that it will never stop working.
public void run() {
while (true) {
try {
Message message = receiveNextMessage();
handleMessage(message);
} catch (Exception ex) {
LOGGER.error(ex);
if (somethingTrulyHorribleHasHappened(ex)) {
Runtime.getRuntime().exit(1);
} else {
maybeResetSomethingThatNeedsToBeReset();
}
}
}
}
This is a somewhat pointless and futile exercise. An app-lifetime thread should be debugged and made to not stop. The main thread of your app lasts for the process lifetime and any other threads should be designed, tested and debugged to the same standard.
What would happen if the thread that stopped had corrupted data in other threads when it crashed? If you just restarted it somehow, the data corruption may well make the situation worse.
My program starts in main, and fire off a few threads that do the work of the program (reading sensors, updating a database, displaying information to a screen). I want the program to run indefinitely.
At the moment after my threads have started in main I just have:
public static void main(String []args)
{
//threads start here
while(true) {}
}
Obviously this works but I am wondering if it is wasting resources looping.
Is there an efficient way to keep the program running. Is there a graceful way to exit?
i.e. start an event listener in main that listens for a keyboard or event or something?
I also tried this if it is any better:
while(true) {
TimeUnit.HOURS.sleep(1);
}
EDIT: more info regarding the threads:
I'm not sure what type of thread they are. I am implementing an interface called gnu.io.SerialPortEventListener, that starts and handles the threads, so its abstracted away from me. I'll have to have a look at the API, although I think it isn't well documented, or look at the source I guess. They keep the JVM alive in the IDE (blueJ) but not when I run the program on the command line.
I just use the interface's method to add an event listener to a com port which starts the threads running.
Unless your threads are daemon threads I don't see why you should have a while or for that matter any loops which would just eat your CPU. Your main thread will not be killed unless all non daemon threads are completed. Also if you wish to do cleanup you can register a JVM's shutdown hook.
I do something similar with my RMI servers. Instead of an endless while loop you can use an endless wait().
private final Object forever = new Object();
synchronized (forever) {
try { forever.wait() } catch (InterruptedException ignore) {}
}
The other problem is how do you end this server? When I want to end it I start a new thread that issues a System.exit(0); that kills the JVM. Obviously you would need to program a way to get to this code.
I have a class XYZ which extends Thread and it is also a singleton (Yes. My application needs that).
In the run method, I have something like this:
public void run() {
service.start();
}
The time it takes for service.start() is huge.
Also, my application will not always need the thread to be run but can't decide in advance so while launching the application I am starting this thread.
Now, when application doesn't need the thread, it gets completed very quickly and all I need to do is wait for thread to die.
I tried to use stop() method but came to know that it is deprecated.
See this article for alternatives to calling stop()
http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPrimitiveDeprecation.html
stop has been deprecated a long time ago and should not be used. Thread termination is a cooperative process in Java (i.e. the interrupted code must do something when asked to stop, not the interrupting code) - one way is to call thread.interrupt() on the thread you need to interrupt.
You then need to catch the generated interrupted exception in the running thread or check the interrupted status regularly. Once the running thread detects that is should stop what it's doing, you can then run any cleanup tasks as required and exit whatever you were doing.
Signal your thread to do it's cleanup stuff, which you said is fast anyway, then just do a Thread.join.
Your question is highly dependant on exactly what is going on in service.start(). If it's opening external resources, then naturally you can't just barge in and kill the thread without proper cleanup. The start procedure will need to be coded explicitly for interruptibility with proper cleanup.