On Tue, 22 Jan 2002, Bo Xu wrote:
> Date: Tue, 22 Jan 2002 13:41:10 -0500
> From: Bo Xu <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> Subject: Re: Asynchronous messages from servlets
>
> ----- Original Message -----
> From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" <[EMAIL PROTECTED]>
> Sent: Tuesday, January 22, 2002 1:04 PM
> Subject: Re: Asynchronous messages from servlets
>
>
> > On Tue, 22 Jan 2002, Ronald Wildenberg wrote:
> >
> > > Date: Tue, 22 Jan 2002 09:50:14 +0100
> > > From: Ronald Wildenberg <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> > > To: [EMAIL PROTECTED]
> > > Subject: Asynchronous messages from servlets
> > >
> > > Hi,
> > >
> > > I have the following problem. A simple form submits data
> > > to a servlet. The servlet sends a message via JMS to
> > > another application (in another JVM). Once the message
> > > has been sent, the 'service' method of the servlet ends.
> > > After a while, say five seconds, the other application would
> > > like to send back a response. How do I show this response
> > > to the user?
> > >
> > > Since the 'service' method has finished after sending the
> > > message, I have lost control over the output from the other
> > > application.
> > >
> > > What I need is a way to push the response to the browser. I
> > > would like the server to take the initiative in updating the browser
> > > window, not the user. Is this possible in any way?
> > >
> > > Thanks in advance,
> > > Ronald Wildenberg
> > >
> >
> > There are two pieces to the answer for this kind of thing -- getting the
> > data back from the other JVM (I assume you are using asynchronous JMS
> > calls, right?), and displaying the data back to the user.
> >
> > For the first step, doing an asynchronous JMS call in the other direction
> > (to a JMS receiver in the same JVM as Tomcat) could then receive the
> > results, and make them available as a servlet context or session
> > attribute.
> >
> > For the second, I've seen people set up a page that uses the meta-refresh
> > capability in HTML to automatically keep sending a request every XX
> > seconds. The servlet that receives this request will check to see if the
> > results are back yet - if they are, they are displayed, if they are not it
> > shows a "Request in Progress ... please wait" page with the meta refresh
> > tag.
> >
> > The key thing is that you won't be able to respond on the original HTTP
> > request, since that has already been sent and your service() method has
> > returned.
> >
> > Craig
> >[...]
>
>
> Thanks for your info! if the processing of "asynchronous JMS calls" will be
> responsed in short time by JMS-Thread, is the following(half-synchronous
> way) also possible?
> - use javax.servlet.ServletResponse.flushBuffer() to show a
> info("please wait...") to client
> - make a asynchronous JMS calls
> - block this Servlet-Thread, wait for a "event" sent by JMS
> - when the "event" comes, the blocking ends, then the results
> are responsed to client, and the Servlet-Thread ends.
>
> I am not sure about:
> - can javax.servlet.ServletResponse.flushBuffer() always response
> info to client before the Servlet-Thread ends(so the client can get
> "please wait...
> " info)? in my testing, it works, but some emails say that sometimes it
> can not
> work.
> - is this half-synchronous way a good Servlet-DesignPattern if I can be sure
> that the blocking will not need a long-time? or it is not good?
>
> Thanks in advance!
>
> Bo
> Jan222002
>
Whether the "please wait" message will be visible or not is client
dependent. I would still model this kind of thing as a separate request
with the meta refresh, as I outlined above (you'll need to do the JMS
query in a separate thread for this to work).
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
