So the title says it all, what happens when during asynchronous invocation of a method performed by Java EE Container, there is a call to another method that is also annotated with #Asynchronous. I would expect that there will be one more asynchronous invocation. However the specification does not say anything about this, so could this also be Application sever vendor specific?
Currently I am analyzing the performance of a Java EE application that runs in Websphere. And I clearly see within the method tree that the second asynchronous method will actually be synchronously called. This actually makes sense for me, because we are already in some kind of asynchronous context, so instead of submitting new task we can just execute it right away..
Any idea about this?
This works. The second call will just post a request to execute that method to some internal queue that the AS maintains.
BUT... be very careful with waiting on the results from any Future that the second method might return. If the second method is a void method it's always safe.
Related
I see a lot of classes that extend javax.annotation.processing.AbstractProcessor,
and override the init member, making it synchronous.
For example: https://github.com/weibocom/motan/blob/master/motan-core/src/main/java/com/weibo/api/motan/transport/async/MotanAsyncProcessor.java#L61
I picture this function being called exclusively by the javac compiler, and if "synchronous" were necessary, I would expect to see something about it in Oracle's documentation of AbstractProcessor (but I do not).
https://docs.oracle.com/javase/7/docs/api/javax/annotation/processing/AbstractProcessor.html for reference.
Also, while I see init synchronous, I don't see process synchronous.
Oracle's documentation about the init member does say, "An IllegalStateException will be thrown if this method is called more than once on the same object." But I don't see how that would figure in. I guess I can imagine a scenario where we want to be careful that exactly one thread calls init successfully (thus synchronize), and then only that successful thread gets to call process. But that's quite a flight of imagination without documentation to back it up.
So, is it necessary to specify "synchronous" for our init members of classes inherited from AbstractProcessor? Why or why not? And if it is necessary, why isn't it necessary to make process synchronous too?
Anyone have any insight?
Thanks! - Jim
I'm making Minecraft Plugin which aside from it's normal behaviour provides API for developers.
In Minecraft it's important to run blocking operations Async - so main thread will not be blocked and thus not causing lags.
In my API I have simple method which loads data from Database. This method doesn't care about what thread its executed on - I want to inform user about blocking behavior of this method and that he should run it Async (preferably via BukkitScheduler). I don't want to return CompletableFuture.
Is there any special JavaDoc item or method annotation for this purpose?
I am exposing some operations in a class in my Spring Boot application through JMX. However, in jConsole, when I invoke the method, "Method invoked successfully" pops up. I know that's because the method returns nothing. But I want to show useful information when method invoked.
I am using #ManagedOperation which is provided by Spring, but it has no such property. I couldn't find anything on the documentation, either.
I can notify the executor by sending a notification, but I wonder if there's any way of directly alerting information.
This is how it normally alerts.
Let me give an example. I have multiple containers that are running and I have provided an operation to stop and start them. When, for example, start is invoked, I want it to alert that "Container X has started" or "Container X is already running". I can do this, by returning these responses as string from the method, but I don't think this should be the way to go. I wonder if a way to do this exists through the API itself.
Hope, I'm clear.
That's not possible and you cannot change the jConsole behavior.
To your example:
If you have multiple outcomes of the invoked method it makes perfectly sense to return this as the message.
But maybe you should consider to expose these as HTTP endpoints where you can return an appropriate HTTP status code instead of a string.
When you use a callback in Java (you can't do that right?), does it block execution until everything is finished? Am I using the wrong terminology. I am familiar on the purpose of a Callback as it relates to Inverion Of Control, Interface, etc., just not the sequence of events.
Converting to an answer from a comment:
All method calls are synchronous, in that they return a result to the caller. However, a callback implies potential asynchronous behavior wherein you define a method to execute when some action is complete. For that matter, the state of the application may determine whether the call is synchronous (i.e. caching of resources). In order to know whether the underlying action is synchronous or asynchronous you need to read the documentation for whatever library you are using. In summary: read the docs
A callback is just a piece of code to execute. It can be invoked synchronously or asynchronously.
Yes.
That's not to say that invoking the callback won't start a new thread internally to do something asynchronously, but the callback method itself is synchronous.
Is there any way to check if an async ServletRequest is completed from an AsyncContext? I saw that spring has some kind of wrapper that supports this but googling around I couldn't find anything in the standard library. That is what I was hoping for.
I am using Tomcat 7.
Sounds like one of the two - you either need a listener that will be called upon a asynchronous request completion or you don't need to use an asynchronous call.
Your question is a bit too general.
Talking generally - asynchronous calls are used when the caller is not interested in immediate result of the call.
If the caller is interested to know the result of the call immediately then synchronous calls should be used.
If the caller is not interested to know the result immediately (for example it has secondary priority, like logging in some business applications), but some action should be performed upon the end of execution of asynchronous calls you should use some sort of a listener.
What you need for asynchronous call is some listener (of class javax.servlet.AsyncListener).
In the listener you will know for sure that the asynchronous call is over (onComplete method) and may perform some action to finalize/complement the asynchronous call.
Again, if you see that the caller of the request needs to know the result upon completion immediately, there probably is a mistake in your architecture. You should use a synchronous call - just wait until the call is done and you will have the result of it. Using an asynchronous call is wrong in this situation.
I saw how people use some sort of a loop to check from time to time the result of a asynchronous call, but it looks like in 99.99% of cases such approach is the result of some architectural mistake.
You can register AsyncListener which can implement onComplete() method.
The AsyncListener needs to be added to the AsyncContext.