I actually call sleep 3000 on the server in a servlet which is a
protocol simulator and then issue subsequent requests.
here is an image of what I am getting:
http://people.apache.org/~werpu/images/delayscreenie.jpeg
as you can see clear 3 second delays between the requests!
Werner
Am 07.09.10 16:15, schrieb Mark Struberg:
Werner do you call the sleep in javascript? I meant to sleep(3s) in the java
code on the server.
LieGrue,
strub
--- On Tue, 9/7/10, Werner Punz<[email protected]> wrote:
From: Werner Punz<[email protected]>
Subject: Re: submit and ajax request will not be queued together
To: [email protected]
Date: Tuesday, September 7, 2010, 1:43 PM
I dont think they have a form submit
issue here, that has been resolved
a while ago, but I cannot see in my code how a concurrent
submit can
happen either because a lock monitor is set once the
request is set to
send, which then blocks and reroutes subsequent requests
until the
issued request is done. After that the queue is notified to
dequeue the
next hanging request for the ajax processing.
Basically a sleep 3 is just what I am simulating on my
testcase
differently here I issue a first request, the request then
hangs on the
server for a period of time and then I issue subsequent
requests.
The way I understand the javascript model is that nothing
should be
triggered from the sleep timer until the issuing request
function has
issued the send and returned, by that time the sleep in
Marks case
triggers but then the lockstate already is set and the
issued ajax
request should go straight into the queue.
So it will be really interestint to see what happens here,
not that I
really can say that we might have a fault in our code, but
without a
real testingcase where I can reproduce the issue I have a
hard time to
find out what happens.
Am 07.09.10 15:29, schrieb Ganesh:
Hi Mark,
A standard form submit will always go through whether
an AJAX request is
running or not. There is no queueing of no AJAX
submits. You may
consider disabling the button until the AJAX request
is successfull.
Best regards,
Ganesh
Mark Struberg schrieb:
txs Werner, I'll tinker together a small
standalone test app until
this evening. The problem seem that we FIRST call
the ajax request
(opening a small javascript yes/no dialog) and
THEN the user hits the
commandButton. You can try this by invoking a ajax
method which calls
a sleep(3) and hit the button in the meantime.
LieGrue,
strub
--- On Tue, 9/7/10, Werner Punz<[email protected]>
wrote:
From: Werner Punz<[email protected]>
Subject: Re: submit and ajax request will not
be queued together
To: [email protected]
Date: Tuesday, September 7, 2010, 12:06 PM
I also checked the queue testcodes on
my side. I have a testcase where a server
servlet delays the response
for three seconds, but
it triggers directly jsf.ajax.request. That is
on the latest codebase.
What happens is following if I press the
button multiple
times, the requests are issued exactly after
the delay which means the
requests are definitely queued in while the
original request is
running.
Are you using the jsf.ajax.request in
conjunction with a
layer which sits on top of it and maybe
bypasses the core code or rolls
its own ajax send scripts?
Werner
Am 07.09.10 13:55, schrieb Werner Punz:
Ok Mark I checked the code there should be
no two
requests being sent
issue there, the code definitely enqueues
while a
request is running,
and dequeues once the request has done its
work.
But I do not want to rule out a bug here
on code
level, but can you send
me a demo app so that I can have a look.
Btw. which version of the codebase are you
on?
lG
Werner
Am 07.09.10 13:42, schrieb Werner Punz:
Am 07.09.10 13:26, schrieb Mark
Struberg:
Hi!
We have a page which renders a
confirmation
dialogue area with f:ajax
and this confirmation dialogue has
a
h:commandButton.
Since our view restoration may
take a bit it
happens that the user
might click fast enough on the
commandbutton
while the ajax request is
still on the server. Thus we might
have 2
parallel requests on the
same @ViewScoped bean. This is
even more
troublesome if we use CDI
@ConversationScoped beans.
We looked at the jsf.js and it
seems that
although concurrent f:ajax
requests get queued the submit via
the
commandButton hits the server
unqueued.
Is this behaviour in sync with the
spec?
There is a workaround to also only
use f:ajax
with commandButtons, but
since I have to use this all the
times it
could be easier to queue
submits also.
LieGrue,
strub
I will investigate it the first
request should get
through unqueued the
second one has to go into the queue
and wait while
the first one is
executing that is the expected
behavior, let me
check if we have a
queuing error there.
There should be no request issued
against the
server while another one
currently is on the server.
Werner
