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
