James Davison

One more question: If create a singleton around the ServletContext, is that the best way to access the ExecutorService objects in the application?

Thanks Tim!

...Their parent is the engine as a whole. Which exempts them from the restrictions on threading that servlets themselves have.

Tim,

Thanks so much for explanation! I feel like I am really starting to get a handle on this. FYI, I have do invoke shutdownNow() on all executors in the listener's contextDestroyed() method.

FYI, my idea behind the third executor service was simply to limit the maximum number of threads that could run at one time, in my example 14 (1 + 3 + 10). From your response, it is not unlike your (2.) "Multi-thread" example description. My second executor would be the "Master Dispatcher" that spawns child (task) threads in the third executor. My intention was to enable up to 3 batch jobs to executely concurrently with additional batch jobs getting queued. Those 3 jobs, in turn could spawn up to 10 individual worker threads, as required, to perform individual tasks.

Does that clarify my intentions?

Tim,

Okay, I think I am beginning to understand the advantages of using a ServletContext listener implementation. I agree, the overhead is probably minimal so I am not overly concerned about that. I do have one question for you for my clarification. If an ExecutorService object is anchored to the ServletContext listener, do the threads it spawns run inside the Servlet Engine or in a separate process? I am asking to improve my understanding of how this implementation will work.

Now that I have had some time to consider a ServletContext listener implementation, I have tentatively decided there should probably be three (3) ExecutorService objects maintained in the servlet context (in a very generic implementation), i.e.

1) A single-thread executor - when jobs MUST be run in a specified order.
2) A multi-thread job executor - e.g. with a thread pool size of 3, that limits the number of batch jobs that may be run at one time - all batch jobs would be submitted to this executor.
3) A multi-thread job task executor - e.g. with a thread pool size of 10, that limits the number of (batch job) tasks that may be run at one time - this executor would receive tasks from the single or multi-thread job executors, i.e. 1) or 2) above.

Such an environment would seem to me to allow the greatest flexibility for submitting and running batch jobs. Since I am proceeding with a ServletContext listener implementation, what I would like to do is design an implementation that will handle most scenarios.

Would you consider this a good design or should I pursue another approach?

Tim,

The most common way to manage on-demand long-running processes is to construct an engine in the ServletContext listener that runs when the web application launches. This engine can contain as many threads as it likes, depending on how many of these long-running processes you want to run in parallel. In fact, if you're really into such things, it could construct an entire private thread pool.

I have seen examples of creating an ExecutorService in the context listener. However, is that really a best solution for my scenario? Perhaps it will not consume many resources but I do not see the point of keeping an ExecutorService object in memory for an on-demand task. The task is rarely invoked more than once a day. If an ExecutorService can be created in the servlet context, why not just create it as needed? Or am I wrong?

Also, if one were to create an ExecutorService in the servlet context, I would assume one would need to create as many ExecutorService objects as there are potential multi-threaded tasks in the application? If I am successful, there are other long-running processes in this application that we may wish to address also. Or can a single ExecutorService object handle tasks from potentially multiple batch jobs without the jobs interfering with one another? If so, I see why one would create a single ExecutorService object in the servlet context.

And, if so, perhaps it makes sense (in some environments) to maintain two (2) ExecutorService objects in the servlet context - 1 for tasks that must run in a specific order, i.e. a single-thread service, and 1 for task that may run independently, i.e. a multi-threaded service?

Finally, assuming an ExecutorService object is created in the servlet context, would it not make sense to use the Apache Tomcat implementations of ExecutorService, i.e. ThreadPoolExecutor, and ThreadFactory, i.e. TaskThreadFactory?

Thanks for your response!

I must not be only one interested in the java.util.concurrent functionality in Apache Tomcat. For anyone else interested in similar functionality, I found the following classes in Apache Tomcat 7.

ThreadPoolExecutor.java
TaskQueue.java
TaskThread.java
TaskThreadFactory.java
Constants.java

These classes are based on the java.util.concurrent package and are used internally by the Apache Tomcat team, for example, StandardThreadExecutor.java. If it works for the Apache Tomcat team, it should work for me.

I backported ThreadPoolExecutor.java and the associated 4 utility classes to my application, removing only the logging lines from ThreadPoolExecutor.java to remove the logging dependency. The Apache Tomcat ThreadPoolExecutor implementation of ExecutorService interface appears to be exactly what I was looking for.

I was recently asked to modify a web application that initiates a very long running task that generally results in correspondingly long user wait time for a page to be displayed. The task itself consists of smaller, independent, individual tasks that, ideally, would be spawned as separate threads and aggregated in a parent task. However, I know creating threads in the servlet container is not recommended.

I have done quite a lot of research on the web and, frankly, while I have uncovered some possible solutions, there seems to be no consensus on the best way to implement a solution for such a scenario. It seems that I am not the only one who has faced such a problem. JSRs 236 and 237 called for a solution but appear to have gone nowhere. JSR 342 (Java EE 7) may resuscitate JSR 236 but I cannot wait. I need a Java EE 5/6 solution.

The CommonJ Work Manager implementation may be a possible solution but is this the way to go? Has anyone else used the CommonJ Work Manager API? If so, can you recommend it?

The Quartz Scheduler seems to be highly recommended but this is NOT a task that may be scheduled. It is an on-demand task and may be requested perhaps 1 to 3 times per day or perhaps not all for a particular day.

Ideally, I would like to use the java.util.concurrent API introduced in Java SE 5. Has anyone else done used this API in Tomcat? If so, can you recommend it? Assuming Java EE 7 does, in fact, eventually implement JSR 236, it seems like this may be the best approach. When the Java EE 7 API becomes available, the code could simply be modified to use the corresponding managed Java EE API classes.

FYI, I am NOT concerned about exceptionally long running tasks or renegade threads. While, as a developer, I would never say never, those scenarios will NOT occur in this particular application. Although RELATIVELY long running, each individual task would generally never exceed 1 second in elapsed time. What makes the parent task long running is that there may be thousands of the individual tasks. If not for the prohibition against creating threads in the servlet container, I would simply create a class that implements Runnable, execute a limited number of threads, perhaps 10, at any given time and aggregate the results in a parent class as each individual task completes.

Assuming I am able to implement a threading solution of some sort, what I would like to do is return the page immediately after submitting a job thread to improve user response time then use Ajax calls to periodically check the job status on the server and update the page as results become available.

I have actually seen applications that have created their own threads in Tomcat and not experience any problems (as long as the thread execution time is short and the thread does not fail). However, I have always been leery of such implementations because I know it is not recommended. I would like to implement a solution for this scenario using the recommended best practices. The only problems is I am having trouble ascertaining what those best practices are.

I would appreciate any recommendations on how to approach a solution to this problem.

Bear, Thanks for the suggestion but, no, setting a border-width to zero did not solve the problem.

Actually, it did not. The div element is just a placeholder containing a single no break space. The background image is all that displays. It should be:
<div>&nbsp;</div>

Thanks Paul. You beat to the solution.

I have a page that displays the following element as a pseudo button:

<div>&nbsp;</div>

using the following CSS styles (and jQuery image):

#button { position : absolute; top : 0; right : 5px; width : 15px; height : 15px; background : transparent url(../_script/lib/images/ui-icons_222222_256x240.png) no-repeat -33px -17px; float : right; cursor : pointer; }

I have noticed that when the button is clicked rapidly in succession, it appears to be selected to the user, i.e displayed in dark blue. It does not cause any problems but it is an annoyance - at least to me. From the dark blue outline displayed by the browser (it is a cross-browser issue), it appears the browser is attempting to select the background image and not the div element.

My question is this: Is there any way to prevent this? I have a reference to the div element but what can be done to unselect the element?

Thanks for your responses but I have now discovered the WorkManager API which I believe will do what I want to do within a Java EE environment.

But to answer your questions:

What does the first sentence above mean?

Sorry. It should have read: The code that is creating the threads IS on the server.

What code is creating the threads? Or, where do you think you can put code to create threads that will have EJB calls?

A class invoked by the model class (on the server) used to create the view required by a page.

Will you be calling a Session EJB or an Entity EJB?

Stateless Session EJBs.

Why do you need to create an EJB to get data from the database for display on a web page?

I have no choice. These are vendor-supplied EJBs to interact with their product (on a mainframe). I have no direct access to the data.

It violates the spec for a good reason, you're breaking security, risking breaking transactions, and otherwise a program that isn't really an EJB.

Would please clarify? How does this break security? Why is it not an EJB? As far as breaking transactions, the stateless session EJBs in question are used to retrieve data from a mainframe only. No updates are performed.

Have you tried Message Driven Beans? Its one of the J2EE ways to create a thread that is supported by the spec.

This may be a better option but I am reluctant to do this. The EJBs in question are provided by a third-party vendor to access data on a mainframe and the only reason EJBs are used in this particular application. And I (a consultant who contract expires at year-end) am reluctant to introduce more complexity into this application because the level of Java knowledge on my team is really low. The other team members are all former mainframers who are capable of creating syntactically correct code but have yet to grasp fundamental concepts of object-oriented programming. Simply attempting to spin these expensive tasks off into a separate thread is an advanced concept for them.

Please explain this a little. How is a "web page" making numerous calls to an EJB? What on the page is making the calls? What triggers each call to a EJB?

Okay, my explanation is perhaps not as precise as I thought. The web pages themselves do not make the actual calls but a number of EJBs are required to retrieve all the data to display the pages because the vendor API is, shall we say, "clunky" and several calls are required to retrieve all the data the users wish to see on the page. These calls are initiated by a model class on the server that pulls data together into a view used to create the page.

Firstly, you are not executing an EJB. You are calling a method of the EJB's Remote interface. Where is the code that is creating the threads? What creates the threads? the "web page"?

The code that is creating the threads on the server. Because there are several web pages that are displayed in sequence, I can often anticipate at least some of the data that will be required for a subsequent page. And that is the reason I would to spin some of these tasks, e.g. EJB calls, off in a separate thread. While I am creating the view object for one page, I would like to create a thread the proactively retrieves data I will likely need for the next page to minimize response time once the next page is requested.

Is it possible to perform a POST or GET request to another server while in the process of handling the current request?

My scenario is this: I need to POST to second servlet which may or may not be on a different server depending upon the production/test/development environment. The second servlet was originally designed to handle Ajax requests. I could possibly do a Ajax call after I displayed my page but it will make my life much more complicated. I simply want to do a POST (within a POST), consume the response, and continue handling the current POST request.

Is what I want to do possible? If so, would someone please provide a hint as to how?

Thanks!

I created two methods to read/write serialized objects. The basic code for the read is shown below. Initially, both methods worked fine when contained in a class in the same Eclipse project as the class objects I was serializing. However, since it is generic code, I attempted to move the code to a separate utility project. The read code now fails with a ClassNotFoundException when it attempts to load a serialized file. I suspect it is a classloader issue because, within the utility project code, I can load the class to be read from a file using the Thread context class loader but not with the class loader that loaded the class containing the read/write methods. However I am unsure how to make this work. Any suggestions?

// Read from disk using FileInputStream java.io.FileInputStream f_in = new java.io.FileInputStream(this.getName(id)); // Read object using ObjectInputStream java.io.ObjectInputStream obj_in = new java.io.ObjectInputStream (f_in); // Read an object return obj_in.readObject();

I ran across the following code which got me to thinking: Is there any good reason to synchronize a run method for a class that implements Runnable? Because this method implements a while(true) statement in the method body, a second invocation of the run method will never be executed. Perhaps that was the original developer's intention?
/* (non-Javadoc) * @see java.lang.Runnable#run() */ public synchronized void run() {
The same class contains the following method. Ordinarily, I would synchronize a method like this too, if I used an ArrayList. However, purgeQueue is Vector. For that reason, I would not think it necessary to synchronize the method itself (although I know it does not really hurt). Am I correct?
public final synchronized void addDocument(String docPath) { Date curTimeStamp = new Date(); Document aDoc = new Document(docPath,curTimeStamp); this.purgeQueue.add(aDoc); }
[ April 10, 2007: Message edited by: James Davison ]