Re: Problem with multiple browser windows and locked page maps
Then you dont throw the right thing, you should set a page as the
response opage thats in a different pagemap
On 9/8/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> Hi Johan,
>
> as I mentioned earlier, I realise that long operations shouldn't be done in
> the request thread. But there are some cases where it's hard to guarantee
> that operations can't take long, and I want to make sure we cope well with
> exceptional cases too.
>
> I didn't fully understand your last reply, but I tried checking the page map
> name in the constructor of a page and throwing an exception when it's not
> set. But then I just got an infinite redirect loop.
>
> Jan
>
>
> 2008/9/6 Johan Compagner <[EMAIL PROTECTED]>
>
>> You have to redirect onces.
>> Just throw a resartresponseexception in the constructor and let a new
>> page be created. It are all landing pages anyway so thats
>> bookmarkable.
>>
>> But to make this thread even simpeler. Just dont have long running
>> stuff in the request thread
>>
>> On 9/5/08, Jan Stette <[EMAIL PROTECTED]> wrote:
>> > Hi Johan,
>> >
>> > I've seen the code in WebPage.onNewBrowserWindow(). The thing I'm
>> > having
>> a
>> > problem figuring out is where to hook in this code. I can't see that I
>> can
>> > do this in the constructor of a page as you suggest. In the constructor
>> the
>> > page hasn't been fully constructed yet so I can't see that I could clone
>> the
>> > page and redirect to it in the way that onNewBrowserWindow does. I've
>> also
>> > had a look in wicket.Session to see if there's a place that I can hook
>> > in
>> > this extra check but I can't see how. Partly because all the relevant
>> > methods are final so can't be overridden...
>> >
>> > I tried to patch our version of Wicket to get a workaround for this. I
>> > added the following to Session.newPageMap(String name):
>> >
>> > public final IPageMap newPageMap(String name)
>> > {
>> > if (name == PageMap.DEFAULT_NAME) {
>> > name = createAutoPageMapName();
>> > log.debug("Allocated new page map name: " + name);
>> > }
>> ><...the rest as before...>
>> > }
>> >
>> > This seems to solve the problem, but I don't know if this as other side
>> > effects. If this is basically a sensible fix, would it be reasonable to
>> add
>> > a hook for doing this in a cleaner way, e.g. adding a call in
>> newPageMap()
>> > to a new method "getPageMapName(name)", that in the default
>> implementation
>> > just returns the argument, but could be overridden to do the above?
>> >
>> > Regards,
>> > Jan
>> >
>> >
>> > 2008/9/1 Johan Compagner <[EMAIL PROTECTED]>
>> >
>> >> First try to look at the newbrowser window check that we have in
>> webpage.
>> >> Dont know if you can all do those things (clone the page and set
>> >> another pagemap)
>> >>
>> >> What you could do is int the page const check pagemap, if default then
>> >> create the same page as you are on but then with a different pagemap
>> >> and throw a restartresponse exception.
>> >>
>> >> Johan
>> >>
>> >> On 9/1/08, Jan Stette <[EMAIL PROTECTED]> wrote:
>> >> > Johan,
>> >> >
>> >> > I've had a look at doing the workaround you suggest, but I don't know
>> >> > Wicket's internals enough to fully understand where to plug it in.
>> >> > In
>> >> the
>> >> > constructor of a page, I can check the page map name, but how would I
>> do
>> >> the
>> >> > redirect here? Conversely, I can override onBeginRequest() in the
>> >> request
>> >> > cycle, but in this case, how would I check the page map name and
>> access
>> >> > other page details in order to redirect to the same page? Sorry if
>> I'm
>> >> > being dim here, but some more details would be greatly appreciated.
>> >> >
>> >> > And yes, pages shouldn't take a long time to load, it's just that in
>> >> > some
>> >> > applications it's hard to guarantee that it will never happen, and
>> we'd
>> >> like
>> >> > to handle all cases to make our application as robust as possible.
>> >> >
>> >> > Regards,
>> >> > Jan
>> >> >
>> >> >
>> >> > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]>
>> >> >
>> >> >> Yes your observation is exactly what i described.
>> >> >>
>> >> >> What you can do is for example check in the constructor (with
>> >> >> pagemap
>> >> >> param) or in onbegin request (before render) of a page, if the
>> pagemap
>> >> >> is the default, if it is create the same page with a new pagemap
>> >> >> and
>> >> >> redicect to that one.
>> >> >>
>> >> >> Whay you want is that the default pagemap is never used, by defaul
>> all
>> >> >> pages are going into that
>> >> >>
>> >> >> But you should check if you really want long running processes like
>> >> that!
>> >> >>
>> >> >> Jihan
>> >> >>
>> >> >> On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote:
>> >> >> > 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
Re: Problem with multiple browser windows and locked page maps
Hi Johan,
as I mentioned earlier, I realise that long operations shouldn't be done in
the request thread. But there are some cases where it's hard to guarantee
that operations can't take long, and I want to make sure we cope well with
exceptional cases too.
I didn't fully understand your last reply, but I tried checking the page map
name in the constructor of a page and throwing an exception when it's not
set. But then I just got an infinite redirect loop.
Jan
2008/9/6 Johan Compagner <[EMAIL PROTECTED]>
> You have to redirect onces.
> Just throw a resartresponseexception in the constructor and let a new
> page be created. It are all landing pages anyway so thats
> bookmarkable.
>
> But to make this thread even simpeler. Just dont have long running
> stuff in the request thread
>
> On 9/5/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> > Hi Johan,
> >
> > I've seen the code in WebPage.onNewBrowserWindow(). The thing I'm having
> a
> > problem figuring out is where to hook in this code. I can't see that I
> can
> > do this in the constructor of a page as you suggest. In the constructor
> the
> > page hasn't been fully constructed yet so I can't see that I could clone
> the
> > page and redirect to it in the way that onNewBrowserWindow does. I've
> also
> > had a look in wicket.Session to see if there's a place that I can hook in
> > this extra check but I can't see how. Partly because all the relevant
> > methods are final so can't be overridden...
> >
> > I tried to patch our version of Wicket to get a workaround for this. I
> > added the following to Session.newPageMap(String name):
> >
> > public final IPageMap newPageMap(String name)
> > {
> > if (name == PageMap.DEFAULT_NAME) {
> > name = createAutoPageMapName();
> > log.debug("Allocated new page map name: " + name);
> > }
> ><...the rest as before...>
> > }
> >
> > This seems to solve the problem, but I don't know if this as other side
> > effects. If this is basically a sensible fix, would it be reasonable to
> add
> > a hook for doing this in a cleaner way, e.g. adding a call in
> newPageMap()
> > to a new method "getPageMapName(name)", that in the default
> implementation
> > just returns the argument, but could be overridden to do the above?
> >
> > Regards,
> > Jan
> >
> >
> > 2008/9/1 Johan Compagner <[EMAIL PROTECTED]>
> >
> >> First try to look at the newbrowser window check that we have in
> webpage.
> >> Dont know if you can all do those things (clone the page and set
> >> another pagemap)
> >>
> >> What you could do is int the page const check pagemap, if default then
> >> create the same page as you are on but then with a different pagemap
> >> and throw a restartresponse exception.
> >>
> >> Johan
> >>
> >> On 9/1/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> >> > Johan,
> >> >
> >> > I've had a look at doing the workaround you suggest, but I don't know
> >> > Wicket's internals enough to fully understand where to plug it in. In
> >> the
> >> > constructor of a page, I can check the page map name, but how would I
> do
> >> the
> >> > redirect here? Conversely, I can override onBeginRequest() in the
> >> request
> >> > cycle, but in this case, how would I check the page map name and
> access
> >> > other page details in order to redirect to the same page? Sorry if
> I'm
> >> > being dim here, but some more details would be greatly appreciated.
> >> >
> >> > And yes, pages shouldn't take a long time to load, it's just that in
> >> > some
> >> > applications it's hard to guarantee that it will never happen, and
> we'd
> >> like
> >> > to handle all cases to make our application as robust as possible.
> >> >
> >> > Regards,
> >> > Jan
> >> >
> >> >
> >> > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]>
> >> >
> >> >> Yes your observation is exactly what i described.
> >> >>
> >> >> What you can do is for example check in the constructor (with pagemap
> >> >> param) or in onbegin request (before render) of a page, if the
> pagemap
> >> >> is the default, if it is create the same page with a new pagemap and
> >> >> redicect to that one.
> >> >>
> >> >> Whay you want is that the default pagemap is never used, by defaul
> all
> >> >> pages are going into that
> >> >>
> >> >> But you should check if you really want long running processes like
> >> that!
> >> >>
> >> >> Jihan
> >> >>
> >> >> On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> >> >> > 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
Re: Problem with multiple browser windows and locked page maps
You have to redirect onces.
Just throw a resartresponseexception in the constructor and let a new
page be created. It are all landing pages anyway so thats
bookmarkable.
But to make this thread even simpeler. Just dont have long running
stuff in the request thread
On 9/5/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> Hi Johan,
>
> I've seen the code in WebPage.onNewBrowserWindow(). The thing I'm having a
> problem figuring out is where to hook in this code. I can't see that I can
> do this in the constructor of a page as you suggest. In the constructor the
> page hasn't been fully constructed yet so I can't see that I could clone the
> page and redirect to it in the way that onNewBrowserWindow does. I've also
> had a look in wicket.Session to see if there's a place that I can hook in
> this extra check but I can't see how. Partly because all the relevant
> methods are final so can't be overridden...
>
> I tried to patch our version of Wicket to get a workaround for this. I
> added the following to Session.newPageMap(String name):
>
> public final IPageMap newPageMap(String name)
> {
> if (name == PageMap.DEFAULT_NAME) {
> name = createAutoPageMapName();
> log.debug("Allocated new page map name: " + name);
> }
><...the rest as before...>
> }
>
> This seems to solve the problem, but I don't know if this as other side
> effects. If this is basically a sensible fix, would it be reasonable to add
> a hook for doing this in a cleaner way, e.g. adding a call in newPageMap()
> to a new method "getPageMapName(name)", that in the default implementation
> just returns the argument, but could be overridden to do the above?
>
> Regards,
> Jan
>
>
> 2008/9/1 Johan Compagner <[EMAIL PROTECTED]>
>
>> First try to look at the newbrowser window check that we have in webpage.
>> Dont know if you can all do those things (clone the page and set
>> another pagemap)
>>
>> What you could do is int the page const check pagemap, if default then
>> create the same page as you are on but then with a different pagemap
>> and throw a restartresponse exception.
>>
>> Johan
>>
>> On 9/1/08, Jan Stette <[EMAIL PROTECTED]> wrote:
>> > Johan,
>> >
>> > I've had a look at doing the workaround you suggest, but I don't know
>> > Wicket's internals enough to fully understand where to plug it in. In
>> the
>> > constructor of a page, I can check the page map name, but how would I do
>> the
>> > redirect here? Conversely, I can override onBeginRequest() in the
>> request
>> > cycle, but in this case, how would I check the page map name and access
>> > other page details in order to redirect to the same page? Sorry if I'm
>> > being dim here, but some more details would be greatly appreciated.
>> >
>> > And yes, pages shouldn't take a long time to load, it's just that in
>> > some
>> > applications it's hard to guarantee that it will never happen, and we'd
>> like
>> > to handle all cases to make our application as robust as possible.
>> >
>> > Regards,
>> > Jan
>> >
>> >
>> > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]>
>> >
>> >> Yes your observation is exactly what i described.
>> >>
>> >> What you can do is for example check in the constructor (with pagemap
>> >> param) or in onbegin request (before render) of a page, if the pagemap
>> >> is the default, if it is create the same page with a new pagemap and
>> >> redicect to that one.
>> >>
>> >> Whay you want is that the default pagemap is never used, by defaul all
>> >> pages are going into that
>> >>
>> >> But you should check if you really want long running processes like
>> that!
>> >>
>> >> Jihan
>> >>
>> >> On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote:
>> >> > 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.
>> >> >
Re: Problem with multiple browser windows and locked page maps
Hi Johan,
I've seen the code in WebPage.onNewBrowserWindow(). The thing I'm having a
problem figuring out is where to hook in this code. I can't see that I can
do this in the constructor of a page as you suggest. In the constructor the
page hasn't been fully constructed yet so I can't see that I could clone the
page and redirect to it in the way that onNewBrowserWindow does. I've also
had a look in wicket.Session to see if there's a place that I can hook in
this extra check but I can't see how. Partly because all the relevant
methods are final so can't be overridden...
I tried to patch our version of Wicket to get a workaround for this. I
added the following to Session.newPageMap(String name):
public final IPageMap newPageMap(String name)
{
if (name == PageMap.DEFAULT_NAME) {
name = createAutoPageMapName();
log.debug("Allocated new page map name: " + name);
}
<...the rest as before...>
}
This seems to solve the problem, but I don't know if this as other side
effects. If this is basically a sensible fix, would it be reasonable to add
a hook for doing this in a cleaner way, e.g. adding a call in newPageMap()
to a new method "getPageMapName(name)", that in the default implementation
just returns the argument, but could be overridden to do the above?
Regards,
Jan
2008/9/1 Johan Compagner <[EMAIL PROTECTED]>
> First try to look at the newbrowser window check that we have in webpage.
> Dont know if you can all do those things (clone the page and set
> another pagemap)
>
> What you could do is int the page const check pagemap, if default then
> create the same page as you are on but then with a different pagemap
> and throw a restartresponse exception.
>
> Johan
>
> On 9/1/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> > Johan,
> >
> > I've had a look at doing the workaround you suggest, but I don't know
> > Wicket's internals enough to fully understand where to plug it in. In
> the
> > constructor of a page, I can check the page map name, but how would I do
> the
> > redirect here? Conversely, I can override onBeginRequest() in the
> request
> > cycle, but in this case, how would I check the page map name and access
> > other page details in order to redirect to the same page? Sorry if I'm
> > being dim here, but some more details would be greatly appreciated.
> >
> > And yes, pages shouldn't take a long time to load, it's just that in some
> > applications it's hard to guarantee that it will never happen, and we'd
> like
> > to handle all cases to make our application as robust as possible.
> >
> > Regards,
> > Jan
> >
> >
> > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]>
> >
> >> Yes your observation is exactly what i described.
> >>
> >> What you can do is for example check in the constructor (with pagemap
> >> param) or in onbegin request (before render) of a page, if the pagemap
> >> is the default, if it is create the same page with a new pagemap and
> >> redicect to that one.
> >>
> >> Whay you want is that the default pagemap is never used, by defaul all
> >> pages are going into that
> >>
> >> But you should check if you really want long running processes like
> that!
> >>
> >> Jihan
> >>
> >> On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote:
> >> > 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 ord
Re: Problem with multiple browser windows and locked page maps
First try to look at the newbrowser window check that we have in webpage. Dont know if you can all do those things (clone the page and set another pagemap) What you could do is int the page const check pagemap, if default then create the same page as you are on but then with a different pagemap and throw a restartresponse exception. Johan On 9/1/08, Jan Stette <[EMAIL PROTECTED]> wrote: > Johan, > > I've had a look at doing the workaround you suggest, but I don't know > Wicket's internals enough to fully understand where to plug it in. In the > constructor of a page, I can check the page map name, but how would I do the > redirect here? Conversely, I can override onBeginRequest() in the request > cycle, but in this case, how would I check the page map name and access > other page details in order to redirect to the same page? Sorry if I'm > being dim here, but some more details would be greatly appreciated. > > And yes, pages shouldn't take a long time to load, it's just that in some > applications it's hard to guarantee that it will never happen, and we'd like > to handle all cases to make our application as robust as possible. > > Regards, > Jan > > > 2008/8/29 Johan Compagner <[EMAIL PROTECTED]> > >> Yes your observation is exactly what i described. >> >> What you can do is for example check in the constructor (with pagemap >> param) or in onbegin request (before render) of a page, if the pagemap >> is the default, if it is create the same page with a new pagemap and >> redicect to that one. >> >> Whay you want is that the default pagemap is never used, by defaul all >> pages are going into that >> >> But you should check if you really want long running processes like that! >> >> Jihan >> >> On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote: >> > 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 <[EMA
Re: Problem with multiple browser windows and locked page maps
Johan, I've had a look at doing the workaround you suggest, but I don't know Wicket's internals enough to fully understand where to plug it in. In the constructor of a page, I can check the page map name, but how would I do the redirect here? Conversely, I can override onBeginRequest() in the request cycle, but in this case, how would I check the page map name and access other page details in order to redirect to the same page? Sorry if I'm being dim here, but some more details would be greatly appreciated. And yes, pages shouldn't take a long time to load, it's just that in some applications it's hard to guarantee that it will never happen, and we'd like to handle all cases to make our application as robust as possible. Regards, Jan 2008/8/29 Johan Compagner <[EMAIL PROTECTED]> > Yes your observation is exactly what i described. > > What you can do is for example check in the constructor (with pagemap > param) or in onbegin request (before render) of a page, if the pagemap > is the default, if it is create the same page with a new pagemap and > redicect to that one. > > Whay you want is that the default pagemap is never used, by defaul all > pages are going into that > > But you should check if you really want long running processes like that! > > Jihan > > On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote: > > 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 Wicke
Re: Problem with multiple browser windows and locked page maps
Yes your observation is exactly what i described. What you can do is for example check in the constructor (with pagemap param) or in onbegin request (before render) of a page, if the pagemap is the default, if it is create the same page with a new pagemap and redicect to that one. Whay you want is that the default pagemap is never used, by defaul all pages are going into that But you should check if you really want long running processes like that! Jihan On 8/29/08, Jan Stette <[EMAIL PROTECTED]> wrote: > 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? >> >>> > >> >>> > R
Re: Problem with multiple browser windows and locked page maps
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] > >
Re: Problem with multiple browser windows and locked page maps
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]
Re: Problem with multiple browser windows and locked page maps
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]
Re: Problem with multiple browser windows and locked page maps
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] > >
Re: Problem with multiple browser windows and locked page maps
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]
Problem with multiple browser windows and locked page maps
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
