Since this is my first post here, let me begin by saying "hi" to everyone. I'm pretty new to JSF (actually, to Java and programming in general), so I'm having a bit of trouble with the following:
I'm trying to use a computational backend (Rserve, in case you're interested) in my Java EE application, which is supposed to handle request by clients (other beans). Information is gathered over the course
of several pages and the computation is started by pressing a commandButton on the final page. Now, it's obviously a bad idea to wait for the computations to finish before redirecting to the "results" page,
so I was thinking of generating a seperate thread for the computations, send the user back to the main page and alert him (email, popup,...) as soon as his results are processed.
I will also need a way to limit the number of concurrent computations to only a handful at a time, which probably means queueing up additional request and processing them successively.
Since all clients should be able to enqueue requests, my first impulse was to put the computation functionality into a application-scoped bean.
I've already looked at the Java Implementations of the Producer-Consumer Pattern, but I'm not sure if those are appropriate for an application scoped bean or JSF in general (while(true)-loops? meh?)...
Is there an established way of implementing this kind of thread-pooled server behaviour for JSF?
I hope that wasn't too confusing... if anyone knows how to approach this problem, I'd really appreciate if you could point me in the right direction.
Servlets and servlet-related stuff (like JSF backing beans) are forbidden by the J2Ee spec from spawning threads. That's because the threads that run the servlets come from a pool and if you start a new child thread and then return the parent to the pool, you have a warty thread in the thread pool.
For long-running processes, especially ones with a lot of contention, it's best to create an engine.
The engine is a component that possesses one or more work queues, processing functions, and maybe a thread pool of its own. servlet-level components (such as JSF action processors) can then post (synchronized) requests to the queue(s), query the engine for status, and obtain results from the engine.
Because the engine actually operates in one or more independent threads, you need a place to instantiate and run it outside the servlet environment. As it happens, these days, one of the best ways to do that is in an application context listener.
Customer surveys are for companies who didn't pay proper attention to begin with.
subject: Thread-pooled server as application-scoped bean. Producer-Consumer Problem? Help!