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 <[email protected]> wrote: > From: Werner Punz <[email protected]> > Subject: Re: submit and ajax request will not be queued together > To: [email protected] > 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<[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 > >>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > >> > > > > > > > > > > >
