You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2006/02/02 00:15:13 UTC
[OT] Simultaneous and ordered XHRs
On 2/1/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> Wendy Smoak wrote:
> > On 2/1/06, Michael Jouravlev <jm...@gmail.com> wrote:
> >
> >> Hi, Ajax gurus, I have an OT question: how to ensure the proper order
> >> of several XHRs? I found how to create several XHRs simultaneously,
> >> but I have a requirement: to wait for the first request to return
> >> before firing the second,
> >
> > (Hardly an expert but...) the third parameter of
> > XMLHttpRequest.open(...) is a flag that says whether the request
> > should be asynchronous. It's usually true. Set it to false and I
> > think it will block until the response is received. Frank will now
> > correct me if I'm wrong. :)
> >
> > And lets move to the user list if this gets any further off topic, shall we?
> >
> > --
> > Wendy
> >
> No Wendy, you are correct in your explanation :) I see Ajax in Action
> is serving you well :)
>
> I wouldn't expect it to be the best answer though because that parameter
> blocks *all* Javascript, not just further XMLHttpRequest's.
Exactly. This is the reason why I don't want to use this flag. I also
have heard that if server fails to respond, then browser can simply
hang up so I would have to restart it. This will not work for me :)
> What you will probably want to do Michael is build up a queue on the
> client and write some code to ensure the order the handlers fire. This
> could be pretty tricky to say the least.
>
> Take a look at the RequestSender tag in AjaxTags in Java Web Parts...
> AjaxTags builds up such a queue so that multiple requests can fire
> simultaneously without stepping on each other.
I borrowed code from http://www.xml.com/cs/user/view/cs_msg/2815
to make simultaneous XHRs. Works well. I even understand now *how* it works :)
> I suspect you would be
> able to extend this to ensure firing order.
Yep, this is the problem. I will look at your code for ideas ;-)
> Off the top of my head, I
> would think you would need to set up a timer, and when the responses
> come back, instead of processing them on the spot in the callback,
> instead set a flag in the call structure that says "yes, this request
> completed, but don't process it until the previous one completes"...
> fire the timer every half a second or something like that to examine all
> the call structures in the queue and fire them as appropriate.
Nah, this won't work. I need to fire second XHR only after the first
one returns. The reason is that first request updates server status
and I want second request to pick it up. I will think about firing
requests on timer. Seems like this is the only way. Or maybe I can
stick request number into request parameters, and reorder requests on
server? In this case I will need total number of requests too. TCP/IP
somehow does this kind of thing, right? Should have to read more about
it ;-) In my case I always fire *all* requests, so TCP/IP should be a
good exaple to look at.
> Probably not a trivial exercise, but should be doable.
I hope so. I will keep this discussion in public list in case someone
else decides to chime in.
P.S. I should have seen the "Struts-dev" label that I assign to dev
list emails, but apparently I haven't ;-))
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Simultaneous and ordered XHRs
Posted by Craig McClanahan <cr...@apache.org>.
On 2/2/06, Laurie Harper <la...@holoweb.net> wrote:
>
>
> I still think it'd be easier to use the XmlHttpRequest's callback
> function to launch the next request in the queue rather than polling
> with a timer and requiring the callback to record state for the polling
> to query...
+1
Craig
Re: [OT] Simultaneous and ordered XHRs
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Laurie Harper wrote:
> I still think it'd be easier to use the XmlHttpRequest's callback
> function to launch the next request in the queue rather than polling
> with a timer and requiring the callback to record state for the polling
> to query... Something like (pseudo-code):
>
> var q = [];
> function processQ() {
> function callback(req) {
> if (req failed) throw "XmlHttpRequest failed!";
> processQ();
> }
>
> if (q.length > 0) {
> var req = createReq(q.pop(), callback);
> ...
> req.send();
> }
> }
>
> ...
>
> q.push(req1);
> q.push(req2);
> processQ();
>
> L.
I can't say I'm following this psuedo-code very well, but I do think
your description above makes sense... Some UI event fires a function
that (a) puts the call object in the queue and immediately fires the
AJAX call *if* that's the only item in the queue... callback function
removes the just completed item from the queue and fires the AJAX call
for the next item, if any... rinse and repeat as required. That makes
sense to me.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Simultaneous and ordered XHRs
Posted by Laurie Harper <la...@holoweb.net>.
Frank W. Zammetti wrote:
> Michael Jouravlev wrote:
>>> Off the top of my head, I
>>> would think you would need to set up a timer, and when the responses
>>> come back, instead of processing them on the spot in the callback,
>>> instead set a flag in the call structure that says "yes, this request
>>> completed, but don't process it until the previous one completes"...
>>> fire the timer every half a second or something like that to examine all
>>> the call structures in the queue and fire them as appropriate.
>>
>> Nah, this won't work. I need to fire second XHR only after the first
>> one returns. The reason is that first request updates server status
>> and I want second request to pick it up. I will think about firing
>> requests on timer. Seems like this is the only way. Or maybe I can
>> stick request number into request parameters, and reorder requests on
>> server? In this case I will need total number of requests too. TCP/IP
>> somehow does this kind of thing, right? Should have to read more about
>> it ;-) In my case I always fire *all* requests, so TCP/IP should be a
>> good exaple to look at.
>
> Actually, this makes it *easier*... I thought you needed to fire
> multiple requests simultaneously, but only handle their response in the
> order they were fired.
>
> If you simply want to be sure request #2 does not fire until request #1
> returns, try this... Build up the queue like I mentioned, it's just a
> FILO stack... periodically in response to a timer, look at the top item
> on the stack. If it has not returned yet, keep waiting. If it has
> returned, pop it and fire off the next item in the stack. How will you
> determine if it has returned yet? Simply set some flag in your callback
> to indicate it. That's actually not so hard (unless I'm missing
> something, which is of course entirely possible!)
>
>>> Probably not a trivial exercise, but should be doable.
>>
>> I hope so. I will keep this discussion in public list in case someone
>> else decides to chime in.
>
> Give what I suggest here a try, I *think* it will do the trick :) And
> the code in AjaxTags in JWP should be very relevant, you'll just alter
> what's done in the callback (heck, you could actually DO this with
> AjaxTags just by writing yourself a SerializingResponseHandler).
>
> Frank
I still think it'd be easier to use the XmlHttpRequest's callback
function to launch the next request in the queue rather than polling
with a timer and requiring the callback to record state for the polling
to query... Something like (pseudo-code):
var q = [];
function processQ() {
function callback(req) {
if (req failed) throw "XmlHttpRequest failed!";
processQ();
}
if (q.length > 0) {
var req = createReq(q.pop(), callback);
...
req.send();
}
}
...
q.push(req1);
q.push(req2);
processQ();
L.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] Simultaneous and ordered XHRs
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Michael Jouravlev wrote:
>> Off the top of my head, I
>> would think you would need to set up a timer, and when the responses
>> come back, instead of processing them on the spot in the callback,
>> instead set a flag in the call structure that says "yes, this request
>> completed, but don't process it until the previous one completes"...
>> fire the timer every half a second or something like that to examine all
>> the call structures in the queue and fire them as appropriate.
>
> Nah, this won't work. I need to fire second XHR only after the first
> one returns. The reason is that first request updates server status
> and I want second request to pick it up. I will think about firing
> requests on timer. Seems like this is the only way. Or maybe I can
> stick request number into request parameters, and reorder requests on
> server? In this case I will need total number of requests too. TCP/IP
> somehow does this kind of thing, right? Should have to read more about
> it ;-) In my case I always fire *all* requests, so TCP/IP should be a
> good exaple to look at.
Actually, this makes it *easier*... I thought you needed to fire
multiple requests simultaneously, but only handle their response in the
order they were fired.
If you simply want to be sure request #2 does not fire until request #1
returns, try this... Build up the queue like I mentioned, it's just a
FILO stack... periodically in response to a timer, look at the top item
on the stack. If it has not returned yet, keep waiting. If it has
returned, pop it and fire off the next item in the stack. How will you
determine if it has returned yet? Simply set some flag in your callback
to indicate it. That's actually not so hard (unless I'm missing
something, which is of course entirely possible!)
>> Probably not a trivial exercise, but should be doable.
>
> I hope so. I will keep this discussion in public list in case someone
> else decides to chime in.
Give what I suggest here a try, I *think* it will do the trick :) And
the code in AjaxTags in JWP should be very relevant, you'll just alter
what's done in the callback (heck, you could actually DO this with
AjaxTags just by writing yourself a SerializingResponseHandler).
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org