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 > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >> > >> > >> > > > > >
