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