You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mark Struberg <st...@yahoo.de> on 2010/09/07 13:26:33 UTC
submit and ajax request will not be queued together
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
Re: submit and ajax request will not be queued together
Posted by Mark Struberg <st...@yahoo.de>.
txs Werner, we'll try that!
LieGrue,
strub
PS: sorry for still not posting a sample, really stuck in work atm :(
--- On Fri, 9/10/10, Werner Punz <we...@gmail.com> wrote:
> From: Werner Punz <we...@gmail.com>
> Subject: Re: submit and ajax request will not be queued together
> To: dev@myfaces.apache.org
> Date: Friday, September 10, 2010, 10:25 AM
> Ok after rechecking the code, please
> Mark check your code for following:
> a normal commandButton normally is rendered to input
> type="submit" which
> also means regardless whether you return false or true in
> onclick a form
> submit will be issued automatically.
>
> What I personally think could be following, you simply did
> not set
> <h:commandButton type="button" but only
> <h:commandButton just as Ganesh
> iterated
>
> but that is just a wild guessing here.
>
> Werner
>
>
> Am 07.09.10 14:34, schrieb Mark Struberg:
> > 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<we...@gmail.com>
> wrote:
> >
> >> From: Werner Punz<we...@gmail.com>
> >> Subject: Re: submit and ajax request will not be
> queued together
> >> To: dev@myfaces.apache.org
> >> 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
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
>
Re: submit and ajax request will not be queued together
Posted by Werner Punz <we...@gmail.com>.
Ok after rechecking the code, please Mark check your code for following:
a normal commandButton normally is rendered to input type="submit" which
also means regardless whether you return false or true in onclick a form
submit will be issued automatically.
What I personally think could be following, you simply did not set
<h:commandButton type="button" but only <h:commandButton just as Ganesh
iterated
but that is just a wild guessing here.
Werner
Am 07.09.10 14:34, schrieb Mark Struberg:
> 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<we...@gmail.com> wrote:
>
>> From: Werner Punz<we...@gmail.com>
>> Subject: Re: submit and ajax request will not be queued together
>> To: dev@myfaces.apache.org
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
Re: submit and ajax request will not be queued together
Posted by Werner Punz <we...@gmail.com>.
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<we...@gmail.com> wrote:
>
>> From: Werner Punz<we...@gmail.com>
>> Subject: Re: submit and ajax request will not be queued together
>> To: dev@myfaces.apache.org
>> 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<we...@gmail.com>
>> wrote:
>>>>
>>>>> From: Werner Punz<we...@gmail.com>
>>>>> Subject: Re: submit and ajax request will not
>> be queued together
>>>>> To: dev@myfaces.apache.org
>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
>
>
Re: submit and ajax request will not be queued together
Posted by Mark Struberg <st...@yahoo.de>.
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 <we...@gmail.com> wrote:
> From: Werner Punz <we...@gmail.com>
> Subject: Re: submit and ajax request will not be queued together
> To: dev@myfaces.apache.org
> 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 <we...@gmail.com>
> wrote:
> >>
> >>> From: Werner Punz <we...@gmail.com>
> >>> Subject: Re: submit and ajax request will not
> be queued together
> >>> To: dev@myfaces.apache.org
> >>> 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
>
>
>
Re: submit and ajax request will not be queued together
Posted by Werner Punz <we...@gmail.com>.
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 <we...@gmail.com> wrote:
>>
>>> From: Werner Punz <we...@gmail.com>
>>> Subject: Re: submit and ajax request will not be queued together
>>> To: dev@myfaces.apache.org
>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
Re: submit and ajax request will not be queued together
Posted by Ganesh <ga...@j4fry.org>.
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 <we...@gmail.com> wrote:
>
>> From: Werner Punz <we...@gmail.com>
>> Subject: Re: submit and ajax request will not be queued together
>> To: dev@myfaces.apache.org
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
>
>
--
"There are two kinds of people in the world, those who believe there are two kinds of people and those who don't."
— Robert Benchley
Re: submit and ajax request will not be queued together
Posted by Mark Struberg <st...@yahoo.de>.
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 <we...@gmail.com> wrote:
> From: Werner Punz <we...@gmail.com>
> Subject: Re: submit and ajax request will not be queued together
> To: dev@myfaces.apache.org
> 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
> >>
> >>
> >>
> >
> >
> >
>
>
>
Re: submit and ajax request will not be queued together
Posted by Werner Punz <we...@gmail.com>.
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
>>
>>
>>
>
>
>
Re: submit and ajax request will not be queued together
Posted by Werner Punz <we...@gmail.com>.
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
>
>
>
Re: submit and ajax request will not be queued together
Posted by Werner Punz <we...@gmail.com>.
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