We Keep Coding

How Java Thread Pool works?

I am working on an IoT project where devices send data to our Java Application called Gateway Adapter (GA).
In java I am using Thread Pool to start a new thread for every message we received from devices.
I have following code for Thread Allocator and Runnable Thread.
public class ThreadAllocator {
/** The thread pool. */
private ExecutorService executorService = Executors.newWorkStealingPool(1000);
public void allocateThread(IoSession session, String message) {
LOGGER.info("Entering allocateThread");
executorService.execute(new HelperThread(null,session, message));
}
}
public class HelperThread implements Runnable {
private String message;
public HelperThread(String message) {
LOGGER.info("Entering HelperThread");
this.message = message;
}
public void run() {
LOGGER.info("Entering run");
// Process Message
}
}
With above code when i did a load testing by sending around 5000 messages, I could see messages "Entering allocateThread" and "Entering HelperThread" 5000 times in log file but my run method executed only 1000 times means message "Entering run" was there in log file only 1000 times. Due to which other 4000 messages could not processed.
Is it the expected behavior "newWorkStealingPool" Thread Pool? Will it only execute tasks equals to number provided in its constructor? E.g. Executors.newWorkStealingPool(1000);
Kindly suggest the solution?
Am i missing some configuration or it is not the correct Thread Pool for my scenario? Then which Thread Pool will work correctly in this case?
Really appreciate your help.
Regards,
Krishan

Returning a value from thread

First of all, yes I looked up this question on google and I did not find any answer to it. There are only answers, where the thread is FINISHED and than the value is returned. What I want, is to return an "infinite" amount of values.
Just to make it more clear for you: My thread is reading messages from a socket and never really finishes. So whenever a new message comes in, I want another class to get this message. How would I do that?
public void run(){
while(ircMessage != null){
ircMessage = in.readLine();
System.out.println(ircMessage);
if (ircMessage.contains("PRIVMSG")){
String[] ViewerNameRawRaw;
ViewerNameRawRaw = ircMessage.split("#");
String ViewerNameRaw = ViewerNameRawRaw[2];
String[] ViewerNameR = ViewerNameRaw.split(".tmi.twitch.tv");
viewerName = ViewerNameR[0];
String[] ViewerMessageRawRawRaw = ircMessage.split("PRIVMSG");
String ViewerMessageRawRaw = ViewerMessageRawRawRaw[1];
String ViewerMessageRaw[] = ViewerMessageRawRaw.split(":", 2);
viewerMessage = ViewerMessageRaw[1];
}
}
}

What you are describing is a typical scenario of asynchronous communication. Usually solution could be implemented with Queue. Your Thread is a producer. Each time your thread reads a message from socket it builds its result and sends it into a queue. Any Entity that is interested to receive the result should be listening to the Queue (i.e. be a consumer). Read more about queues as you can send your message so that only one consumer will get it or (publishing) means that all registered consumers may get it. Queue implementation could be a comercialy available products such as Rabbit MQ for example or as simple as Java provided classes that can work as in memory queues. (See Queue interface and its various implementations). Another way to go about it is communication over web (HTTP). Your thread reads a message from a socket, builds a result and sends it over http using let's say a REST protocol to a consumer that exposes a rest API that your thread can call to.

Why not have a status variable in your thread class? You can then update this during execution and before exiting. Once the thread has completed, you can still query the status.
public static void main(String[] args) throws InterruptedException {
threading th = new threading();
System.out.println("before run Status:" + th.getStatus());
th.start();
Thread.sleep(500);
System.out.println("running Status:" + th.getStatus());
while(th.isAlive()) {}
System.out.println("after run Status:" + th.getStatus());
}
Extend thread to be:
public class threading extends Thread {
private int status = -1; //not started
private void setStatus(int status){
this.status = status;
}
public void run(){
setStatus(1);//running
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
}
setStatus(0); //exit clean
}
public int getStatus(){
return this.status;
}
}
And get an output of:
before run Status:-1
running Status:1
after run Status:0

Block Java application from exiting until ThreadPool is empty

I've got an ExecutorService sitting inside a singleton class which receives tasks from many different classes. On application shutdown, I need to wait for the pool to be empty before I allow the application to exit.
private static NotificationService instance = null;
private ExecutorService executorService = Executors.newFixedThreadPool(25);
public static synchronized NotificationService getInstance() {
if (instance == null) {
instance = new NotificationService(true);
}
return instance;
}
While using this NotificationService, it frequently happens that I restart the application and the executorService hasn't finished processing all the notifications.
For Testing, I can manually shutdown the executorService and wait until all tasks are completed.
public static boolean canExit() throws InterruptedException {
NotificationService service = getInstance();
service.executorService.shutdown();
service.executorService.awaitTermination(30, TimeUnit.SECONDS);
return service.executorService.isTerminated();
}
Is it reliable and safe to override the finalize method and wait there until the pool is empty? From what I've read, finalize is not always called, especially not when using a singleton class.
#Override
protected void finalize() throws Throwable {
while (!canExit()){
Thread.sleep(100);
}
super.finalize();
}
This code is included in a library that will be included in another application, so there's no main method where I can wait until the pool is empty, unless I force the person using it to do so which is not great.
What is the correct way to stall the application (for a reasonable amount of time) from terminating until the pool is empty?

You can use addShutdownHook to catch the process termination event and wait for the pool there.
example:
Runtime.getRuntime().addShutdownHook(new Thread() {
public void run() {
NotificationService service = getInstance();
service.executorService.shutdown();
service.executorService.awaitTermination(30, TimeUnit.SECONDS);
}
});

Answered here: Java Finalize method call when close the application
Finalizers do not run on exit by default and the functionality to do this is deprecated.
One common advice is to use the Runtime.addShutdownHook but be aware of the following line of documentation:
Shutdown hooks should also finish their work quickly. When a program invokes exit the expectation is that the virtual machine will promptly shut down and exit. When the virtual machine is terminated due to user logoff or system shutdown the underlying operating system may only allow a fixed amount of time in which to shut down and exit. It is therefore inadvisable to attempt any user interaction or to perform a long-running computation in a shutdown hook.
In all honesty the best way to ensure everything gets properly cleaned up is to have your own application lifecycle which you can end before you even ask the VM to exit.

Don't use blocking shutdown hooks or anything similar in a library. You never know how the library is meant to be used. So it should always be up to the code that is using your library to take sensible actions on shut down.
Of course, you have to provide the necessary API for that, e.g. by adding lifecycle-methods to your class:
public class NotificationService {
...
public void start() {
...
}
/**
* Stops this notification service and waits until
* all notifications have been processed, or a timeout occurs.
* #return the list of unprocessed notification (in case of a timeout),
or an empty list.
*/
public List<Notification> stop(long timeout, TimeUnit unit) {
service.shutdown();
if (!service.awaitTermination(timeout, unit)) {
List<Runnable> tasks = service.shutdownNow();
return extractNotification(tasks);
}
return Collections.emptyList();
}
private List<Notification> extractNotification(List<Runnable> tasks) {
...
}
}
Then, the application code can take the required actions to handle your service, e.g.:
public static void main(String[] args) {
NotificationService service = new NotificationService(...);
service.start();
try {
// use service here
} finally {
List<Notification> pending = service.stop(30, TimeUnit.SECONDS);
if (!pending.isEmpty()) {
// timeout occured => handle pending notifications
}
}
}
Btw.: Avoid using singletons, if feasible.

Threads and Interrupts: Continue or exit?

The official documentation and forum posts I could find are very vague on this. They say it's up to the programmer to decide whether to continue after being interrupted or exit, but I can't find any documentation of the conditions that would warrant one or the other.
Here is the code in question:
private final LinkedBlockingQueue<Message> messageQueue = new LinkedBlockingQueue<Message>();
// The sender argument is an enum describing who sent the message: the user, the app, or the person on the other end.
public void sendMessage(String address, String message, Sender sender) {
messageQueue.offer(Message.create(address, message, sender));
startSenderThread();
}
private Thread senderThread;
private void startSenderThread(){
if(senderThread == null || !senderThread.isAlive()){
senderThread = new Thread(){
#Override
public void run() {
loopSendMessage();
}
};
senderThread.start();
}
}
private void loopSendMessage(){
Message queuedMessage;
// Should this condition simply be `true` instead?
while(!Thread.interrupted()){
try {
queuedMessage = messageQueue.poll(10, TimeUnit.SECONDS);
} catch (InterruptedException e) {
EasyLog.e(this, "SenderThread interrupted while polling.", e);
continue;
}
if(queuedMessage != null)
sendOrQueueMessage(queuedMessage);
else
break;
}
}
// Queue in this context means storing the message in the database
// so it can be sent later.
private void sendOrQueueMessage(Message message){
//Irrelevant code omitted.
}
The sendMessage() method can be called from any thread and at any time. It posts a new message to send to the message queue and starts the sender thread if it isn't running. The sender thread polls the queue with a timeout, and processes the messages. If there are no more messages in the queue, the thread exits.
It's for an Android app that automates SMS message handling. This is in a class that handles the outbound messages, deciding whether to immediately send them or save them to send later, as Android has an internal 100 message/hour limit that can only be changed by rooting and accessing the settings database.
Messages can be sent from different parts of the app simultaneously, by the user or the app itself. Deciding when to queue for later needs to be handled synchronously to avoid needing atomic message counting.
I want to handle interrupts gracefully, but I don't want to stop sending messages if there are more to send. The Java documentation on threading says most methods simply return after being interrupted, but that will leave unsent messages in the queue.
Could anyone please recommend a course of action?

I guess the answer depends on why you are being interrupted? Often threads are interrupted because some other process/thread is trying to cancel or kill it. In those cases, stopping is appropriate.
Perhaps when interrupted, you send out all remaining messages and don't accept new ones?

Java nio server client asynchonous

I made a server myself using java nio and a selector. I can receive the data and answer directly from the client if needed.
But now I want a thread that will process data, and anytime it will send data to each client.
So how can I do that? Also how to keep in memory all channels to write the data to each client ?
If you need I can post the part of my code with java nio.

Create a new thread with a runnable and make sure it knows your server because your server should know all clients. If a client sends a message parse it through the data processor thread and let it do it's job. When it's done processing your task then let the server know so he can update all clients.
Tip: you should make a waiting queue for the processing thread with something like a LinkedBlockingQueue so you can always put tasks on the queue without waiting for the task to finish. Then the thead will wait for things on the queue that need to be processed. This way the processing thread will only use CPU resources when there are actually tasks on the queue
Here is a code example
public abstract class Queue implements Runnable {
private final LinkedBlockingQueue<Message> queue;
public Queue() {
this.queue = new LinkedBlockingQueue<Message>();
}
/**
* Adds a message to the queue.
* #param message
*/
public void add(final Message message) {
try {
queue.put(message);
} catch (final InterruptedException e) {
e.printStackTrace();
}
}
/**
* Waits for new messages
*/
#Override
public void run() {
while(true) {
try {
final Message message = queue.take();
processMessage(message);
} catch (final InterruptedException e) {
e.printStackTrace();
}
}
}
/**
* Processes the new message
*/
protected abstract void processMessage(Message message);
}