Thanks for your answers, Matej and Johan. Matej: we are running with multi-window support on, and store per-window related navigation in the session keyed on page map name. This works fine most of the time.
Johan: I've been stepping through the Wicket code and studying the docs to understand how it deals with new windows, and I think I'm starting to understand what's happening, and your comments about default page maps. Basically what seems to be the case is that the inital window in a session never receives its own page map name, it stays on the default one. This means that this initial window is indistinguishable from a brand new window that hasn't yet had a page map name allocated and been redirected to a page with this set. I've done some tests which seem to confirm this hypothesis: - I open an initial browser window on my application (window 1) - I open a second window in the same session (window 2) If a start a long-running operation in window 1, any new windows created will lock until window 1's operation has been completed. However, if I start the long-running operation in window 2, I can open new windows to my heart's content and they will not block. Does that make sense, is this an accurate description of the problem? It seems odd that the initial window is never allocated a page map name, which leads to this assymtry between windows. Is this something that can be fixed? Or even better, can I do something my side in order to force any window/page map opened against a session to have a unique name allocated? Regards, Jan 2008/8/29 Johan Compagner <[EMAIL PROTECTED]> > And even with that check it will not work. > If you open a new tab then the first page wicket will render when you > type in an url will be the defaul pagemap. Only on the first page > rendered we know that we have to redirect. So that first page will be > blocked. The only thing that could maybe help is never use the defaul > pagemap. So always use from the first page on a differnt one. And if > you then see that a defaul pagemap request is done in your page, > create a new pagemap and redirect again. > > On 8/29/08, Matej Knopp <[EMAIL PROTECTED]> wrote: > > Only if multi window support is on (which is off by default with > > secondlevelcachesessionstore). The multiwindow support is more or less > > a hack, because HTTP doesn't really provide any means to detect > > browser windows/tabs. > > > > -Matej > > > > On Fri, Aug 29, 2008 at 2:28 AM, Jan Stette <[EMAIL PROTECTED]> > wrote: > >> I agree, that's a better long-term fix. Even so, isn't it wrong that > the > >> request from a new window is locked waiting on the other window's page > map > >> - > >> I would have thought the new window should have ended up with its own > page > >> map? > >> > >> Regards, > >> Jan > >> > >> > >> 2008/8/29 Matej Knopp <[EMAIL PROTECTED]> > >> > >>> Hi, > >>> > >>> the long running process should be executed in separate thread. You > >>> can make wicket periodically poll for result (via ajax). It is > >>> generally not a good idea to run action that potentially can take long > >>> time to complete from a request thread. > >>> > >>> -Matej > >>> > >>> On Thu, Aug 28, 2008 at 8:42 PM, Jan Stette <[EMAIL PROTECTED]> > wrote: > >>> > I'm having a problem with the following scenario: > >>> > > >>> > 1. A user logs into our Wicket application and starts using it. > >>> > 2. The user clicks on a link which kicks off a potentially > >>> > long-running > >>> > operation. > >>> > 3. While getting bored with waiting for this to complete, the user > >>> copies > >>> > the URL from her browser into another tab or window. > >>> > > >>> > Unfortunately, at this stage, the second window is locked and times > out > >>> with > >>> > a message "pagemap is still locked after one minute". > >>> > Should this work? Stepping through the second request in the > debugger, > >>> it > >>> > appears that it this request has a page map name = null, as has the > >>> previous > >>> > request ( in the long running thread). So they seem to pick up the > >>> > same > >>> > page map. Presumably this is wrong; multiple windows should each > have > >>> their > >>> > unique page map? Or does the magic that detects new windows hence > new > >>> page > >>> > maps to be created break down in cases like this? > >>> > > >>> > Regards, > >>> > Jan > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
