I'm thinking how to write a signal handler that would inform the main thread about the need to exit.
What I'm thinking is:
1) use the following code to intercept the signal
SignalHandler handler = new SignalHandler () {
public void handle(Signal sig) {
System.out.println("Signal " + sig);
System.out.println("Shutting down...");
ServiceLocator.ProgramState().setMustExit();
System.exit(0);
}
};
Signal.handle(new Signal("INT"), handler);
Signal.handle(new Signal("TERM"), handler);
2) Set a ProgramState object to indicate the need to exit: ServiceLocator.ProgramState().setMustExit();
3) put the following code in some parts of the program to check if ProgramState tells me to exit:
if (ServiceLocator.ProgramState().mustExit()) {
throw new MustExitException();
}
the exception would be intecepted by the main thread which would exit cleanly.
I don't like very much throwing an exception like I'm going to do, but this seems a quick way to achieve my goal.
Are there any other ways to exit gracefully?
The main thread usually waits for some event/notification (either directly or indirectly) that prevents it from terminating the program immediately
A clean shutdown would be letting the main thread know it's time to "move-on" either by interrupting it or by notifying it. As part of path to end the program execution beyond that point, it should take care of "terminating" other crucial parts of the program (in most of the cases, there aren't any).
If the application is single threaded... well it probably shouldn't be. The core execution logic should be separated from the main thread.
Spring IOC / Guice (Netflix governator) exist especially to achieve better life cycle-control over your object-graph.
Both can aid you in building an implementation where the bootstrap/shutdown/component wiring is decoupled from the actual logic of the application and provide convenient way of managing the life-cycle of your various objects/classes.
I wholeheartedly recommend that you'll use them instead of rolling your own shutdown mechanism. (Keeping the signal handling functionality, of course, but that should also be decoupled from the main thread). You'll eventually wind up with a poison-pill like mechanism.
For example - if you choose to work with Spring, you'll define the signal handler as a bean, inject/autowire it with the ConfigurableApplicationContext instance, and call its close() method upon receiving the desired signal. That'll cause all spring wired beans to perform their defined (if defined) shutdown/destruction behavior
P.S. signal handling will work, but there are more concrete ways to convey shutdown messages (see ZeroMq/JeroMQ, for a brokerless message example) from external sources.
Related
I am very new to RxJava, although I'm familiar with streams and somewhat with Javascript promises. I'm working with some existing code using RxJava, and some comments that some people have made about that code. I'd like to get more background on this, while I continue to absorb the documentation.
The block in question is this (some names changed):
public ShippingMethodHolder callClientsAsync(ShippingMethodContext shippingContext) {
Single<ShippingMethodResponse> productOneResponseEntity = Single.<ShippingMethodResponse>create(source -> {
source.onSuccess(getProductOneowShippingMethodResponse(shippingContext));
}).subscribeOn(Schedulers.io());
Single<ShippingMethodResponse> productTwoResponseEntity = Single.<ShippingMethodResponse>create(source -> {
source.onSuccess(getProductTwoShippingMethodResponse(shippingContext));
}).subscribeOn(Schedulers.io());
Single<ShippingMethodHolder> singleProductCartResponseHolder = Single.zip(productOneResponseEntity, productTwoResponseEntity,
(dtvResponse, productTwoResponse) -> {
return new ShippingMethodHolder(dtvResponse, productTwoResponse);
});
return singleProductCartResponseHolder.blockingGet();
}
The comment made about this code from people more informed about this essentially says that this is missing RxJava exception handling "and will cause blocking or crashing of the stream". I imagine this refers to the fact that the two async calls have "onSuccess()" calls, but no "onError()" calls.
However, this seems odd to me. The scope that "onSuccess()" is being called isn't for business logic success or failure, but seemingly on RxJava's attempt to make an asynchronous call.
I could use some advice on whether this is really a problem from RxJava's point of view.
create is there mainly to bridge an asynchronous source with the reactive world, but your code seems to call something blockingly just to signal its value. For that, fromCallable is more appropriate and communicates the intent to the reader much better:
Single<ShippingMethodResponse> productOneResponseEntity =
Single.<ShippingMethodResponse>fromCallable(() ->
getProductOneowShippingMethodResponse(shippingContext)
)
.subscribeOn(Schedulers.io());
Depending on your type of application, blockingly wait for the result may not be desirable, especially if the method is called from the UI thread. You could return the zipped Single and keep composing until a final subscribe() can be issued.
The comment made about this code from people more informed about this essentially says that this is missing RxJava exception handling "and will cause blocking or crashing of the stream"
The original create and fromCallable will catch your exception and will try to signal it to the consumer. In this case, blockingGet will rethrow one of the source exceptions on the caller thread and the other (if any) will be routed to the global RxJavaPlugins.onError handler. They probably meant that the caller of your method generally doesn't expect it to throw so they may omit a try-catch around it and fail badly at runtime. Resolving it really depends on what kind or error management you intended in the application.
In our application we want to achieve higher throughput so I just want to know how threading works in Spring MVC controllers.
Thanks in advance for your help.
This helped me
http://community.jaspersoft.com/wiki/how-increase-maximum-thread-count-tomcat-level
A web application is hosted in an application server (like tomcat). Usually the application server manage a thread pool and every request is handled by a thread.
The web application don't have to worry about this thread pool. The size of the thread pool is a parameter of the application server.
To achieve higher throughput you really need to identify the bottleneck.
(According my experience, the size of the thread pool of the application server is rarely the root cause of performance problem.)
Note that the "number of controller instances" is normally one. i.e. a controller is usually a singleton shared/used by all threads, and therefore a controller must be thread-safe.
Let us specify the question a little more: an application of interest, implementing a REST controller, is deployed on a typical mutlithreaded application server (running, possibly, other things as well). Q: Is there concurrence in handling of separate requests to the mapped methods of the controller?
I'm not authoritative in this subject, but it is of high importance (in particular: should single-threaded logic be applied to REST-Controller code?).
Edit: answer below is WRONG. Concurrent calls to different methods of same controller are handled concurrently, and so all shared resources they use (services, repositories etc.) must ensure thread safety. For some reason, however, calls to be handled by the same method of the controller are serialized (or: so it appears to me as of now).
The small test below shows, that even though subsequent (and rapid) calls to the mapped methods of the controller are indeed handled by different threads, single-threaded logic applies (i.e. there is no cuncurrency "out of the box").
Let us take the controller:
AtomicInteger count = new AtomicInteger();
#RequestMapping(value = {"/xx/newproduct"})
#ResponseBody
public Answer newProduct(){
Integer atCount = count.incrementAndGet();
////// Any delay/work would do here
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
e.printStackTrace();
}
Answer ans = new Answer("thread:" + Thread.currentThread().getName() + " controller:" + this, atCount);
count.decrementAndGet();
return ans;
}
and launch 10 rapid (almost concurrent w.r.t. the 1000ms sleep time) REST requests, e.g. by the AngularJS code
$scope.newProd = function (cnt) {
var url = $scope.M.dataSource + 'xx/newproduct';
for(var i=0; i<cnt; ++i) {
$http.get(url).success(function(data){
console.log(data);
});
}
};
(the Answer just carries a String and an Integer; making count static would not change anything). What happens, is that all requests become pending concurrently, but responses come sequentially, exactly 1s apart, and none has atCount>1. They do come from different threads though.
More specifically the console log has:
in other words:
Edit: This shows, that concurrent calls to the same method/route are serialized. However, by adding a second method to the controller we easily verify, that calls to this method would be handled concurrently with the calls to the first method, and hence, multithreaded logic for handling requests is mandatory "out-of-the-box".
In order to profit from multithreading one should therefore, as it seems, employ traditional explicit methods, such as launching any non-trivial work as a Runnable on an Executor.
Basically this has nothing to do with Spring. Usually each request is forked into a separate thread. So the usual thing to do here is finding the bottleneck.
However there is a possibility that badly written beans that share state over thread boundaries and therefore need to be synchronized might have a very bad effect.
I'm writing a JEE7/Glassfish 4 application that reads data from an external queue (RabbitMQ) and processes it. It needs a method (I suppose an EJB method) that contains a loop that never exits that reads the queue. I suppose since this loop never exits, it needs to be on a separate thread. My question is, what is the correct way to do this in a JEE7 application?
This may be obvious, but the ReadQueue() method needs to start automatically when the app starts and must keep running permanently.
Is the ManagedExecutorService appropriate for this?
ManagedExecutorService is exactly what you want to use for this.
The availability of this service in JEE is a great benefit. In the past, we basically just ignored the guidelines and managed all of this stuff ourselves.
The MES allows you to capture the context information of the invoking component, and tie your task in to the life cycle of the container. These are both very important in the JEE environment.
As to where to start the task, you basically have two options.
One, you can use a ServletContextListener, and have that kick off the task during container startup.
Two, you can use an #Singleton EJB, and tie in to its lifecycle methods to start your task.
If you start the task up from the ServletContextListener, then the task will run as if it's in the WAR environment. If you start it up from the #Singleton, it will run within the Session Beans environment (this mostly relates to how the JNDI appears).
Either way, you only need to worry about starting the task via these mechanisms. You should rely on the ManagedTaskListener.taskAborted interface method to shut your task down.
In theory you can work with the Thread.interrupt that is sent to your task during shut down. I've never had good luck with that myself, I rely on an external mechanism to tell the long running tasks to shut off.
I wish I could give first hand experience with this new facility, but I haven't had an opportunity to try it out yet. But from the spec, this is what you want to do.
To start a thread with an infinite loop that polls the queue periodically is usually not a good idea. The nature of queues suggests an async, event-driven processing. For such problems in the JEE world you have MDBs. The only issue here is that MDB requires a JMS queue provider but RabbitMQ is using a different protocol (AMQP). You need a JMS-AMQP bridge to make this work. Could be Qpid JMS but no guarantee that it will work.
Here is one way to create a thread that never exits:
public class HelloRunnable implements Runnable {
public void run() {
while (true) {
// do ReadQueue() here
}
}
public static void main(String args[]) {
(new Thread(new HelloRunnable())).start();
}
}
in a Spring MVC Controller I would like to start a thread that continues work while my controller sends the response. Will this work with spring-mvc ?
Best Reagrds,
Heinrich
Yes, You can start new Thread in Controller. But better way of doing asynchronous job is to use spring-scheduling support. You can leverage Quartz framework. That will manage your job.
This link will give you how to integrate this in your application.
Yes, it'll work. On one web app I worked on, I needed to send a notification email depending on the user's action. I added a post-commit interceptor on the service, and had that fire off the email in a separate thread. (In my case that happened to be cleaner than putting the code in the controller, because I only wanted it to happen if the transaction committed.)
You do need to make sure the thread actually stops running at some point, either by setting daemon to true (if it's ok that stopping the server kills the thread without notice) or making sure the code in its run method will always terminate at some point.
You are better off using a threadpool than creating new threads, so you don't risk resource exhaustion (threads stalling out are usually not independent events, if a thread hangs the next one probably will too, so you need a way to cut your losses). Methods annotated with #Async will be executed using an executor that you can configure as shown in the Spring documentation.
As the others mentioned, it's will work. ExecutorService can do the job. Here you can see I used it for starting a video stream that sits on a separate endpoint.
#PostMapping("/capture")
public ResponseEntity capture() {
// some code omitted
ExecutorService service = Executors.newCachedThreadPool();
service.submit(() -> startStreaming(deviceConfig));
return return ResponseEntity.ok()
.body(stream);
}
I have a client/server question that i am trying to figure out the best solution for.
If a client ever gets disconnected from the server, for any reason, i would like a way for the input output thread to alert the gui thread that something went wrong, and thus have the gui thread print an error and gracefully handle it (probably drop back out to the login gui). After the initial gui thread is created, the client could change to any number of guis, depending on what he is doing, so I am thinking i need a way to dynamically see what gui is currently being run.
The way that i was thinking of doing this so far:
1) Create an object that creates and shows every gui. So instead of calling invokeLater...SomeGui.CreateAndShoGui()... we would have this object be responsible for doing that, ie GuiObject.showSomeGui();
2) Have each gui implement an interface, which will insure there is a method that, when called, will gracefully shutdown this gui when we have lost connection to the server.
3) Have a thread that monitors the IO thread and the gui object. If something goes wrong on the IO thread, the IO thread will close down and notify the monitoring thread that we have lost connection the server. The monitoring thread could then alert any open guis (from the gui object) that we have lost connection and that it needs to shut down.
I have just started thinking about this, and so far this is the best solution i have come up with. Does this seem like a reasonable solution that wont add too much complexity to the code? Or can anyone recommend a solution that would be simpler for people reading the code to understand?
Thanks
EDIT:
The other option i am toying with is having an object on the IO thread, that also gets passed to each new gui as it is opened. This object will give the currently opened guis reference back to the io thread, so that the io thread can alert it if something goes wrong. I am leaning against this solution though, because it seems like it would be easier to read if you had one object that was dedicated to get this working (like the above solution), instead of passing some obscure object to each gui.
Let me just go through each of your ideas:
1) Bad idea - you are tying your whole application together through a single object. This makes maintainability difficult and is the antithesis of modularity.
2) This is the way to go IMHO. Since it seems that each gui has unique logic in a failure scenario then it stands to reason that the object that best understands what to do would be the gui object itself.
Another version of this idea would be to create an adapter for each gui to put this failure logic into. The advantage would be you have one less dependency between your application framework and your gui. The disadvantage is that this is an extra layer of complexity. If your gui is already pretty coupled to your application then I would choose the interface method. If you want to reuse your guis in another application then the adapter way could help facilitate that.
3) This complements #2 nicely. So let me get this straight - you would have 3 threads: the IO thread, the monitor thread, and the UI thread. I don't know if you need the monitor thread. From what you were saying the IO thread would be able to detect a connection problem by itself (probably because some form of IOException was caught). When a connection problem is discovered the IO thread is not busy since it is just going to shut itself down soon so it might as well just have the responsibility of notifying the guis that there was a problem. The guis should have their interface method called on the UI thread anyways so the IO thread is just calling a bunch of invokeLater() calls (or asyncExec() calls for SWT) and then the IO thread can just shut itself down.
4) (Your Edit) You are basically describing the Visitor pattern. I do not think this is a good solution because the call is from the IO thread to the gui and not the other way around. I am not sure how passing a visitor object around will help in this case.
One final thought. If you make your interface generic (not gui specific) then you can apply this pattern to other resources. For instance you may want to flush your user credentials when you lose connection (since you talked about going to the login screen again). That isn't really gui logic and should not be done from a gui class.
Edit: I would use an event model. Let's say you create a interface like this:
public interface ConnectionFailureListener {
void handleConnectionFailure(); // Add an event object if you need it
}
You could then have registration methods in some object (maybe the Runnable for the IO thread or somewhere else that is convenient for you). These methods would be pretty standard:
public void addConnectionFailureListener(ConnectionFailureListener l) {}
public void removeConnectionFailureListener(ConnectionFailureListener l) {}
When you show a gui on the screen you would add it to your registration object and when you close the gui you would remove it from the registration object. You can add other types of objects as needed - for example when you log in you can add a listener for your credential system and remove it again when log out is processed.
This way when you have a failure condition you simply loop through the currently registered listeners and the listener does its thing.