Consider service, which starts some thread inside it. Will Tapestry 5 manage this thread in part of e.g. closing hibernate sessions inside such thread or not? (For example, we can pass Session object inside such child-thread from service. Will Tapestry safely close this session after thread dies?).
Tapestry can only manage things declared in your AppModule.
As a simple rule, if you use the "new" keyword, it's not managed by tapestry.
If you want tapestry to manage your runnable, take a look at ParallelExecutor
If you want to mimic a tapestry managed thread, you must call Perthreadmanager.cleanup() once your runnable has finished.
Hibernate session is attached to the web container's thread which is handling the current request.
If you decide to spawn your own thread and pass to it that Session, then changes to that Session will be committed only if they 're done before Tapestry commits or before the above mentioned web container's thread ends processing that request.
Tapestry's control over the hibernate session is bound to the current request, after the request has been processed the session is closed, so spawning another thread that outlives the request to use the Session would be a bad idea.
Related
I just want to clarify is JwtConsumer thread safe?
I'm going to use it with spring rest controller. Is it fine to use one consumer in whole application for multiple requests or better place it under request skope?
Yes, JwtConsumer is thread safe as long as you are using a recent version and, if your using any additional validators or customizers, they are also thread safe.
There was previously an issue with thread safety but it was fixed in v0.4.3.
I just started learning about Play framework lately and really like it so far.
There is just one thing that isn't clear to me. I'm a Java developer, with an blocking
and multi-threaded way of thinking so async programming is a little new to me.
So, Play framework uses an asynchronous WS API which doesn't block thread that calls it, nor
it blocks or spawns any other thread. When doing some async programming usually you have
to spawn a new thread and then make a WS call so you don't block your main thread. So my question here is how does Play's WS API manages to do async call to a web service without blocking current thread and without spawning a new one? Does it fire a request and then the main thread every once in a little checks if there is a Response available in the Future object? I'm aware of how to use it but I want to know what's the deal "under the hood". How would it be implemented in Scala? A simple example if possible would be a nice help.
Thanks in advance and best regards!
Under the hood play uses async-http-client which is based on NIO. A request will be dispatched and when the server responds, a callback (in this case the completion of the future) will be executed on a thread from the threadpool. This way no thread has to be blocked.
Play uses an "execution context", which is typically a thread pool, as described in the documentation:
It’s important to understand which thread code runs on with futures.
In the two code blocks above, there is an import on Plays default
execution context. This is an implicit parameter that gets passed to
all methods on the future API that accept callbacks. The execution
context will often be equivalent to a thread pool, though not
necessarily.
So no new threads are spawned, but only because there is already a pool of threads available for such work.
In the old days, when each request to a web application was handled by one thread, it was fairly easy to understand the logs. One could, for example, use a servlet filter to name the thread that was handling a request with some sort of request id. This request id then could be output in the logs. In this world, a simple grep was all it took to collect the log lines for a given request.
In my current position, I'm building web applications with Scala (we're using Scalatra but that isn't specifically relevant to my question). Each request creates a scala.concurrent.Future and is then parked until that future has completed. The important bit here is that the thread that actually handles the business logic is different from the thread that handled the request which is different (I think) from the thread that completes the request and so the context of that request is lost during processing. The business logic can log all it likes but it is hard to associate that logging with the specific request it relates to.
Now from the standpoint of supporting my web services in production, the old approach was great and I'd like to come up with something similar for my asynchronous services. I've been trying to come up with a way to do it but have come up empty. That is, I haven't come up with anything nearly as light weight as the old, name-the-thread model. Does the Stack Overflow crowd have any suggestions?
Thanks
As you have written, assign an id to each request, and pass that to the business logic function. You can also do this with implicit parameter, so your code won't be cluttered.
This should be possible with MDC logging available with SLF4j which uses Thread local storage to store the context of the each request.
Also you will have to create a MDC Context Propagating execution context, to move the context across threads.
This post describes it well:
http://code.hootsuite.com/logging-contextual-info-in-an-asynchronous-scala-application/
I want to put an Abort Label or button below...the processing message is shown in ZK. or is there any way to load my custom components instead of the default Processing. message in ZK.
Want will happen if do abort while processing is it ideal to do that, I want to do that anyways as few times my application sleeps while loading
ZK is built on Servlets. When the busy button is shown on the ui awaiting the ajax response then the servlet thread is doing long running work on the server. Perhaps it would be possible to send another thread to interrupt the first thread but really that is high risk as all the servlet threads can end up doing long running work and no new ones will be available to cancel them.
The best solution is that long running work should not be on the servlet thread but handed off to a background thread or message queue. See zk-asynchronous-ui-updates-and-background-processing. In that example the work is offloaded to a java.util.concurrent.ExecutorService which has an API to cancel the work.
Note that cancelling of a working thread uses interruption and it is not guaranteed that code which doing the work will respond to the interrupt properly such that it is actually cancellable. The answers on the thread cancel with executor service outline some of the issues and you should test whether the work you are doing can be interrupted using the API.
I have a managed bean / service running inside of JBOSS. I then have a quartz job that will occasionally wake up and call a method of the managed bean. This method is sometimes long and drawn out, and since I don't want the quartz job to time out, I have implemented a thread within the managed bean to perform the processing. When the thread is finished I need to update a database table with the results. This is a very serial process and it needs to be based upon some business rules, etc.
My main question is that I can use an EntityManager within the service without a problem however I can not use it from within the thread, I get a NullPointerException. What would be the best way to address this?
Thanks,
Scott
As creating threads in appservers is discouraged, I'd modify the setup a bit.
I'd move the core of processing to a message driven bean, and have the Quartz job just send a message to the queue on which the MDB is listening. The MDB in turn can call your EJB, and like this everything remains within what's allowed by the standard.
As per the documentation and specification the Entity Manager is not thread safe and can not be used across different child threads as I had originally had in mind. I ended up going back to the original design similar to the one provided by fvu, however I found some annotations that would allow me to modify the been timeout period and allow the long running process to work properly. Here's the annotation that I used:
#PoolClass(value=org.jboss.ejb3.StrictMaxPool.class, timeout=360000000L)