How to add feature of "SHUTDOWN" in MultiThreaded Http Web Server code - java

I am writing a HTTP THREAD-POOLED WEB SERVER code. I made my code at my best. It works fine also.
But there is one problem, whenever I want to shut down my server, I have to use CTRL + C. But that is a bad way to shut down.
I think a lot, to add shutdown feature in my code. But I am unable to do that.
Please help me to add this feature, give any suggestion to do that, I will definitely code that.
EDIT NO. 1
One method that I think is to make one thread that is only listening STDIN input given by keyboard. Whenever it gets "SHUTDOWN". It calls ThreadPol.shutdown(). This way I can achieve this goal.
Is this a right method ? If yes, please help me to implement this.

You can do
ThreadPoolExecuto.shutdownNow()
Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution.

Related

Understanding tomcat/spring boot multi threading

I've created a simple web application on the base of spring-boot. It gets request, do some block operations (like writing to the console numbers from 1 to 10_000) and returns simple response.
When I start to test it with JVisual VM I've noticed that threads work in a strange way.
In the beginning, with low load, they don't work at the same time, they work in turn:
If I try to high-load application than Tomcat creates new Threads (It's OK as I understand) and after time threads work at the same time:
I've used Netling app to test application. It just simple request on localhost, nothing special.
Could you please explain why it works in this way? Or provide some links with description.
Thanks in advance!
I've understood the root of the issue.
On the JVisualVM I saw, that all Threads was blocked by each other, but I didn't know why. Now it's clear - I've use system.out.println() as a block operation, but Threads can't use it at the same time, the console is locked.
I've change console output to file output (use thread name as a filename to prevent lock) and start the application again. Now it's work as expected.
Stupid mistake, but I hope it will be useful for someone :)

How to handle a shutdown request in Java

I assume Java applications receive some sort of shutdown request when, for instance, an OS is trying to reboot. I would like to have some control over how my applications handle these requests. But, I do not know where to start. Some questions I have are:
Do all shutdown requests come from the JVM?
Are the requests different for containers, VMs, and bare metal OSs? I am especially interested on how this is handled inside a docker container.
And, of course, what libraries can I use to handle these requests?
It would be wonderful if someone could point to a resource where this is covered in depth, besides the raw documentation, such as a book or online course (does not have to be free). Although, a link to the documentation will definitely be appreciated as well. Thanks!
Update:
I know I need to be able handle an event like the power cord being yanked.
However, when I ask my Windows machine to shutdown, sometimes a window pops up saying something like "waiting for these application to close". So, I assume the OS tells the applications to shut themselves down before forcing them to stop. Is this an incorrect assumption?
What I want to accomplish is for the app to log information or update a database before shutdown.
I will take a look at the addShutdownHook. Thanks again!
You can add a shutdown hook via the Runtime class. Mind you, these are not guaranteed to run, such as if someone yanks the power cord.
Refer Oracle Documentation

Asynchronous Listener Synchronization Java HID

I tried to look around for some time, but I was not able to find an answer to my problem.
I am currently writing a Java program that will be used to read and update the firmware of an HID device. I am using the pureHID java libraries to communicate with my device and everything is working fine.
The only problem I am currently experiencing, and I was not able to fix, concerns the synchronization of events.
I will give you an example.
When copying the firmware currently installed on the device, I am using the following method
dev.setOutputReport((byte) 0, packet_to_send, BUFFER_SIZE);
The answer from the unit will come in the form of an event received by the listener attached to the device manager, namely the following listener will be invoked
onInputReport() /* Something will happen */
My problem is that SOMETIMES, probably because of concurrent writing/listening invocation, the program completely freeze, without any exception nor any error signaled.
To fix the problem, I tried to implement a simple Lock mechanism, with the Lock being released only when a reply is received; but unfortunately it may happen that the reply packet sometimes is lost thus blocking me in a deadlock.
One possible solution I though would be to use a timer which will release the lock automatically after x milliseconds if it is not released (the reply will arrive within 10ms or will not arrive), but I do not know how to create an independent thread to manage the timer.
Can you please help me fixing this problem, or suggest me another concurrency mechanism which I can use to synchronize the two blocks OR to re-transmit the message, if a reply is lost?
Thank you very much to anyone helping.
Lorenzo

Are there any circumstances under which ScheduledThreadPoolExecutor would completely stop working?

We are running a Java server app that is using ScheduledThreadPoolExecutor to manage some work. There are multiple instances running, for different types of work, but each instance only uses one thread. It's not important why this is as there's really no way around it. What we noticed on the production server is that one of these instances stopped working at some point, completely and silently. Restarting the server brought it back again, but the problem isn't solved.
I know that using scheduleAtFixedRate will stop if the task throws an exception at some point, but this isn't the case here. We had a recurrent task that simply stopped executing, and new tasks that used the schedule() method and still didn't execute. I presume that the thread it was using died and didn't start again.
My question is, are there any circumstances under which this could happen? Is there anything I should look out for?
It looks like the simplest explanation is the answer: all threads hang.
In my case the cause of this seems to be HTTP requests that never timeout. This can happen in certain situations and I am yet to find a good solution for the problem. I think the best option is to implement a timeout on the scheduled task itself to make sure we avoid any issues.

Standalone Java App dies after a few days

We have a Java App that connects via RMI to another Java app.
There are multiple instances of this app running at the same time, and after a few days an instance just stops processing... the CPU is in 0 and I have an extra thread listening to an specific port that helps to shutdown the App.
I can connect to the specific port but the app doesn't do anything.
We're using Log4j to keep a log and nothing is written, so there aren't any exceptions thrown.
We also use c3p0 for the DB connections.
Anyone have ideas?
Thanks,
I would suggest starting with a thread dump of the affected application.
You need to see what is going on on a thread by thread basis. It could be that you have a long running thread, or other process which is blocking other work from being done.
Since you are running linux, you can get your thread dump with the following command
kill -3 <pid>
If you need help reading the output, please post it in your original question.
If nothing is shown from the thread dump, other alternatives can be looked at.
Hum... I would suggest using JMetter to stress the Application and take note of anything weird that might be happening (such as Memory Leaks, Deadlocks and such). Also review the code for any Exceptions that might interrupt the program (or System.exit() calls). Finally, if other people have access to the computer, makes sense to check if the process wasn't killed manually somehow.

Categories