How to send "processing" message to user while working...
Jason Rosenberg
We are having a problem where a browser requests requires
some db processing time, and we need to handle the case where
the browser (or the intermediate weblogic-apache bridge plugin) get
impatient and cause a resubmit of the request.
I am thinking that we could have a jsp send an html meta refresh
tag if the processing is not complete, and possibly display
status info, etc., at regular intervals, say every 2 seconds.
Once the processing is done, it would stop sending the meta refresh,
and just send the completed request page.
What I don't understand is how to concurrently have the server working
on the requested operation while the jsp-servlet is keeping the browser
http session alive and happy.
Is there a good way in weblogic to get a new thread from a "thread pool"?
I've seen reference to such in other discussions, but I haven't yet found
any doc on how to do this.
Also, could I have the jsp launch a servlet, which the jsp could monitor
each time it is refreshed, etc.? If so, as long as the servlet provided a
thread-safe
status reporting method, etc., the jsp should be able quite easily to know
when the operation is complete, and then display the completed results,
and then finally signal the servlet to terminate.
Does such a protocol exist?
Can a jsp launch a servlet, retain a reference to that servlet, and call
methods concurrently on the servlet object?
Thanks for any info...
Jason
Dimitri Rakitine
On the initial request you create task descriptor object (java object,
database records, ...), associate it with the session(for example) and
kick-off asynchronous execution.
Options for doing this are:
JMS and ServerSessionPool - see JMS spec at
http://java.sun.com/products/jms/jms-101-spec.pdf paragraph 8.2
Use your own thread pool.
You can create and start your own threads in Weblogic just fine, the only
caveat that I know of is that you should not create threads uncontrollably,
because ThreadLocal implementation keeps thread-specific data in a Map keyed by
thread, so if you create new thread per request you will run out of memory.
So, use your own thread pool - it's better for performance reasons anyway.
I use my own thread pool(s) to execute various asynchronous tasks quite often
and I never had any problems. It was posted on ejb newsgroup that ejb invocations
from non-weblogic threads fail when enable-call-by-reference is set to false,
but that's not a big deal.
At this point your servlet/JSP returns self-refreshing page, or page saying
'click here to see the results'.
On the next request you retrieve this task descriptor from the session
(or request parameter) and check the task status - if it's not ready you
reply with self-refreshing page, if it's done you display results.
> Thanks for any info...
> Jason
Dimitri
Jason Rosenberg
etc., you simply have a delegated message listener client which then
responds to the message in its own thread, etc. MessageDrivenBeans
in the EJB 2.0 release will be even better for this.
But, for now, I was trying to avoid having to use JMS in the short
term. I do agree that in the long run it is the way to go.
Doesn't weblogic provide a way for requesting new threads from
the weblogic thread pool? I'd rather not go against their recommendations
there. If we have a lot of requests, we could grind the server to a
halt....
Can you elaborate what you mean by a ServerSessionPool?
Finally, what about my idea of launching non-HTTP servlets to
do the work? Is there not a way to do this, and be able to
communicate with it to determine it's completion status?
Jason
"Dimitri Rakitine" <dim...@firstworld.net> wrote in message
news:39dee902$1...@newsgroups.bea.com...
Dimitri Rakitine
Here is an idea how to execute task asynchronously using WLS time services:
import weblogic.time.common.*;
import weblogic.common.*;
import weblogic.jndi.*;
import javax.naming.*;
class MyTask implements Schedulable, Triggerable {
boolean done = false;
public void trigger(Schedulable sched) {
// this method is being executed by server execute thread
// do whatever is that we are doing asynchronously here
...
// next schedule() call will return 0 to cancel this trigger
done = true;
}
// schedule this trigger only once
public long schedule(long time) {
return done ? 0 : time;
}
}
And in the servlet's service(...) method:
..
MyTask task = new MyTask();
T3ServicesDef t3 = ctx.lookup("weblogic.common.T3Services");
ScheduledTriggerDef std = t3.time().getScheduledTrigger(trigger, trigger);
std.schedule();
MyTask.trigger() method will be executed asynchronously by one of the
server execute threads.
Dimitri
Jason Rosenberg
But how can we detect whether it has completed successfully,
or not?
It seems like once you call getScheduledTrigger, you are sending
the objects to be executed to the server, and once you do that,
how can you call any methods on it to check its status, etc.?
I'm looking at the weblogic examples, and if I were content
to have a "client-side" implementation, then I could retain local
control over the Triggerable object. Not so for the server-side
example.
So, I have a question. If I am launching this thing from a JavaBean
which is instantiated by a servlet (a jsp page), and I implement
the "client-trigger" model, am I not running in the server (and therefore
utilizing the server thread pool)????
Jason
"Dimitri Rakitine" <dim...@firstworld.net> wrote in message
news:39e0...@newsgroups.bea.com...
Jason Rosenberg
Thanks for the ideas here. I've gotten it all working using
the Time Services approach. Looks good!
What's the best way of pinging back data to the client
browser while the asynchronous task executes. Currently,
I am using the html meta refresh tag to keep the client
side updated and non-stale, but I was wondering if there
were a better way....
Jason
"Jason Rosenberg" <ja...@nospam.squaretrade.com> wrote in message
news:39e18552$1...@newsgroups.bea.com...
Dimitri Rakitine
> What's the best way of pinging back data to the client
> browser while the asynchronous task executes. Currently,
> I am using the html meta refresh tag to keep the client
> side updated and non-stale, but I was wondering if there
> were a better way....
I dont think so. Refresh or providing a link to click to check
the status of the pending request.
> Jason
Dimitri