You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Guillaume Smet <gu...@gmail.com> on 2014/10/21 12:12:19 UTC
Lock timeout per page class
Hi,
We have a few pages in our application which might take a long time to
generate. This is definitely not the usual case but there are a few of
them.
Thus we were forced to define a high lockTimeout to be sure these
pages can be served.
The fact is that we would really like to have a far lower default
timeout except for these pages.
Is there a way to configure the lockTimeout on a per page basis (I
haven't found one)?
If not, would it be a good idea to provide a way to do so?
Thanks for your feedback.
--
Guillaume
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Guillaume Smet <gu...@gmail.com>.
Thanks Martin!
We will give it a try and post what we got.
--
Guillaume
On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi Guillaume,
>
> You can
> use org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
> to check what is the requested page in your
> own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Oct 21, 2014 at 1:12 PM, Guillaume Smet <gu...@gmail.com>
> wrote:
>
>> Hi,
>>
>> We have a few pages in our application which might take a long time to
>> generate. This is definitely not the usual case but there are a few of
>> them.
>>
>> Thus we were forced to define a high lockTimeout to be sure these
>> pages can be served.
>>
>> The fact is that we would really like to have a far lower default
>> timeout except for these pages.
>>
>> Is there a way to configure the lockTimeout on a per page basis (I
>> haven't found one)?
>>
>> If not, would it be a good idea to provide a way to do so?
>>
>> Thanks for your feedback.
>>
>> --
>> Guillaume
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Guillaume Smet <gu...@gmail.com>.
Hi Martin,
Looks sane to me. I created a JIRA issue:
https://issues.apache.org/jira/browse/WICKET-5740 .
Thanks again for your help!
On Tue, Oct 28, 2014 at 9:45 AM, Martin Grigorov <mg...@apache.org> wrote:
> Here is my version: http://pastie.org/9680245
> Please create a ticket in JIRA if you like it.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Oct 28, 2014 at 9:52 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> Hi,
>>
>> I share Sebastien's concern.
>> I'll see how to workaround this.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Oct 25, 2014 at 2:57 PM, Sebastien <se...@gmail.com> wrote:
>>
>>> Hi Guillaume,
>>>
>>> Generally speaking, you cannot call a non final method from a
>>> constructor...
>>>
>>> Best regards,
>>> Sebastien
>>> On Oct 25, 2014 1:32 PM, "Guillaume Smet" <gu...@gmail.com>
>>> wrote:
>>>
>>> > Hi Martin,
>>> >
>>> > I got something working with the following changes in Wicket:
>>> >
>>> >
>>> https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
>>> >
>>> > Do you consider this commitable? If so, I can create a JIRA issue and
>>> push
>>> > a PR.
>>> >
>>> > Having the pageId in the getTimeout call is quite nice as I don't have
>>> > to get it again from the PageRequestHandlerTracker.
>>> >
>>> > Thanks for your feedback.
>>> >
>>> > On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mg...@apache.org>
>>> > wrote:
>>> > > If you have a base page then BasePage#onInitialize() should be a good
>>> > place.
>>> > > Or you could add the pageIds of the special/slow pages only in the
>>> map.
>>> > >
>>> > > Otherwise you may use PageRequestHandlerTracker#getLastHandler in a
>>> > custom
>>> > > IRequestCycleListener#onDetach().
>>> > >
>>> > > Martin Grigorov
>>> > > Wicket Training and Consulting
>>> > > https://twitter.com/mtgrigorov
>>> > >
>>> > > On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <
>>> > guillaume.smet@gmail.com>
>>> > > wrote:
>>> > >
>>> > >> Hi Martin,
>>> > >>
>>> > >> Yeah, I thought about that too but I'm not sure of the best place to
>>> > >> build the pageId -> pageClassName map. Any advice about this?
>>> > >>
>>> > >> Once I'll get this working, I'll build a PR for the few changes I
>>> made
>>> > >> in Wicket (based on what you proposed earlier). Would be nice to have
>>> > >> them in 6.18.
>>> > >>
>>> > >> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <
>>> mgrigorov@apache.org>
>>> > >> wrote:
>>> > >> > Hi Guillaume,
>>> > >> >
>>> > >> > Sorry for not thinking more carefully about this the first time!
>>> > >> > I'm afraid it is not possible to do it the way I suggested.
>>> > >> > PageAccessSynchronizer is the entry point to start using a page
>>> and it
>>> > >> > works only with pageId!
>>> > >> >
>>> > >> > Here is a new hackish approach:
>>> > >> > Store pageId -> pageClassName map in the Session. Then when
>>> > >> > PageAccessSynchronizer is requested to lock a page by id use that
>>> id
>>> > to
>>> > >> > resolve the class name and to decide what timeout to use.
>>> > >> >
>>> > >> > Martin Grigorov
>>> > >> > Wicket Training and Consulting
>>> > >> > https://twitter.com/mtgrigorov
>>> > >> >
>>> > >> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <
>>> > >> guillaume.smet@gmail.com>
>>> > >> > wrote:
>>> > >> >
>>> > >> >> Hi Martin,
>>> > >> >>
>>> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <
>>> > mgrigorov@apache.org>
>>> > >> >> wrote:
>>> > >> >> > I'd like to avoid moving the logic that gets the timeout from
>>> > >> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
>>> > >> because
>>> > >> >> > this way it will use Application.get() everytime and most apps
>>> > don't
>>> > >> need
>>> > >> >> > to pay for this.
>>> > >> >> >
>>> > >> >> > A way to make it possible for you is to remove the 'final'
>>> > >> >> > from org.apache.wicket.Session#getPageManager and introduce
>>> > >> overridable
>>> > >> >> > PageAccessSynchronizer#getTimeout(). This way you can use your
>>> own
>>> > >> >> > PageAccessSynchronizer.
>>> > >> >> > http://pastie.org/9667070
>>> > >> >>
>>> > >> >> After a few experiments, here I am!
>>> > >> >>
>>> > >> >> So, it mostly works: I thought it would be better to add something
>>> > like:
>>> > >> >> protected IProvider<PageAccessSynchronizer>
>>> > >> >> newPageAccessSynchronizerProvider()
>>> > >> >> {
>>> > >> >> return new PageAccessSynchronizerProvider();
>>> > >> >> }
>>> > >> >> in Session and call it from the constructor instead of removing
>>> the
>>> > >> >> final so I did that in my code.
>>> > >> >>
>>> > >> >> It works pretty well BUT I haven't found a way to get the page
>>> class
>>> > >> >> in getTimeout without having the risk to trigger a
>>> > resolvePageInstance
>>> > >> >> which will try to lock and then call getTimeout leading to a
>>> > wonderful
>>> > >> >> stack overflow exception when dealing with
>>> > >> >> ListenerInterfaceRequestHandler.
>>> > >> >>
>>> > >> >> Obviously (...) what interests me the most is the getTimeout in
>>> > >> >> ListenerInterfaceRequestHandler as it's often actions on buttons
>>> > which
>>> > >> >> are long to run.
>>> > >> >>
>>> > >> >> Here is what I have in mind for my Session class:
>>> > >> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
>>> > >> >>
>>> > >> >> I must admit that an advice would be welcome as I wouldn't like to
>>> > >> >> have stack overflow errors popping out in weird edge cases.
>>> > >> >>
>>> > >> >> Thanks!
>>> > >> >>
>>> > >> >> --
>>> > >> >> Guillaume
>>> > >> >>
>>> > >> >>
>>> ---------------------------------------------------------------------
>>> > >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> > >> >>
>>> > >> >>
>>> > >>
>>> > >> ---------------------------------------------------------------------
>>> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>>> > >>
>>> > >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Martin Grigorov <mg...@apache.org>.
Here is my version: http://pastie.org/9680245
Please create a ticket in JIRA if you like it.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Oct 28, 2014 at 9:52 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi,
>
> I share Sebastien's concern.
> I'll see how to workaround this.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sat, Oct 25, 2014 at 2:57 PM, Sebastien <se...@gmail.com> wrote:
>
>> Hi Guillaume,
>>
>> Generally speaking, you cannot call a non final method from a
>> constructor...
>>
>> Best regards,
>> Sebastien
>> On Oct 25, 2014 1:32 PM, "Guillaume Smet" <gu...@gmail.com>
>> wrote:
>>
>> > Hi Martin,
>> >
>> > I got something working with the following changes in Wicket:
>> >
>> >
>> https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
>> >
>> > Do you consider this commitable? If so, I can create a JIRA issue and
>> push
>> > a PR.
>> >
>> > Having the pageId in the getTimeout call is quite nice as I don't have
>> > to get it again from the PageRequestHandlerTracker.
>> >
>> > Thanks for your feedback.
>> >
>> > On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mg...@apache.org>
>> > wrote:
>> > > If you have a base page then BasePage#onInitialize() should be a good
>> > place.
>> > > Or you could add the pageIds of the special/slow pages only in the
>> map.
>> > >
>> > > Otherwise you may use PageRequestHandlerTracker#getLastHandler in a
>> > custom
>> > > IRequestCycleListener#onDetach().
>> > >
>> > > Martin Grigorov
>> > > Wicket Training and Consulting
>> > > https://twitter.com/mtgrigorov
>> > >
>> > > On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <
>> > guillaume.smet@gmail.com>
>> > > wrote:
>> > >
>> > >> Hi Martin,
>> > >>
>> > >> Yeah, I thought about that too but I'm not sure of the best place to
>> > >> build the pageId -> pageClassName map. Any advice about this?
>> > >>
>> > >> Once I'll get this working, I'll build a PR for the few changes I
>> made
>> > >> in Wicket (based on what you proposed earlier). Would be nice to have
>> > >> them in 6.18.
>> > >>
>> > >> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <
>> mgrigorov@apache.org>
>> > >> wrote:
>> > >> > Hi Guillaume,
>> > >> >
>> > >> > Sorry for not thinking more carefully about this the first time!
>> > >> > I'm afraid it is not possible to do it the way I suggested.
>> > >> > PageAccessSynchronizer is the entry point to start using a page
>> and it
>> > >> > works only with pageId!
>> > >> >
>> > >> > Here is a new hackish approach:
>> > >> > Store pageId -> pageClassName map in the Session. Then when
>> > >> > PageAccessSynchronizer is requested to lock a page by id use that
>> id
>> > to
>> > >> > resolve the class name and to decide what timeout to use.
>> > >> >
>> > >> > Martin Grigorov
>> > >> > Wicket Training and Consulting
>> > >> > https://twitter.com/mtgrigorov
>> > >> >
>> > >> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <
>> > >> guillaume.smet@gmail.com>
>> > >> > wrote:
>> > >> >
>> > >> >> Hi Martin,
>> > >> >>
>> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <
>> > mgrigorov@apache.org>
>> > >> >> wrote:
>> > >> >> > I'd like to avoid moving the logic that gets the timeout from
>> > >> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
>> > >> because
>> > >> >> > this way it will use Application.get() everytime and most apps
>> > don't
>> > >> need
>> > >> >> > to pay for this.
>> > >> >> >
>> > >> >> > A way to make it possible for you is to remove the 'final'
>> > >> >> > from org.apache.wicket.Session#getPageManager and introduce
>> > >> overridable
>> > >> >> > PageAccessSynchronizer#getTimeout(). This way you can use your
>> own
>> > >> >> > PageAccessSynchronizer.
>> > >> >> > http://pastie.org/9667070
>> > >> >>
>> > >> >> After a few experiments, here I am!
>> > >> >>
>> > >> >> So, it mostly works: I thought it would be better to add something
>> > like:
>> > >> >> protected IProvider<PageAccessSynchronizer>
>> > >> >> newPageAccessSynchronizerProvider()
>> > >> >> {
>> > >> >> return new PageAccessSynchronizerProvider();
>> > >> >> }
>> > >> >> in Session and call it from the constructor instead of removing
>> the
>> > >> >> final so I did that in my code.
>> > >> >>
>> > >> >> It works pretty well BUT I haven't found a way to get the page
>> class
>> > >> >> in getTimeout without having the risk to trigger a
>> > resolvePageInstance
>> > >> >> which will try to lock and then call getTimeout leading to a
>> > wonderful
>> > >> >> stack overflow exception when dealing with
>> > >> >> ListenerInterfaceRequestHandler.
>> > >> >>
>> > >> >> Obviously (...) what interests me the most is the getTimeout in
>> > >> >> ListenerInterfaceRequestHandler as it's often actions on buttons
>> > which
>> > >> >> are long to run.
>> > >> >>
>> > >> >> Here is what I have in mind for my Session class:
>> > >> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
>> > >> >>
>> > >> >> I must admit that an advice would be welcome as I wouldn't like to
>> > >> >> have stack overflow errors popping out in weird edge cases.
>> > >> >>
>> > >> >> Thanks!
>> > >> >>
>> > >> >> --
>> > >> >> Guillaume
>> > >> >>
>> > >> >>
>> ---------------------------------------------------------------------
>> > >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >> >>
>> > >> >>
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>> > >>
>> > >>
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>> >
>>
>
>
Re: Lock timeout per page class
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
I share Sebastien's concern.
I'll see how to workaround this.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sat, Oct 25, 2014 at 2:57 PM, Sebastien <se...@gmail.com> wrote:
> Hi Guillaume,
>
> Generally speaking, you cannot call a non final method from a
> constructor...
>
> Best regards,
> Sebastien
> On Oct 25, 2014 1:32 PM, "Guillaume Smet" <gu...@gmail.com>
> wrote:
>
> > Hi Martin,
> >
> > I got something working with the following changes in Wicket:
> >
> >
> https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
> >
> > Do you consider this commitable? If so, I can create a JIRA issue and
> push
> > a PR.
> >
> > Having the pageId in the getTimeout call is quite nice as I don't have
> > to get it again from the PageRequestHandlerTracker.
> >
> > Thanks for your feedback.
> >
> > On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mg...@apache.org>
> > wrote:
> > > If you have a base page then BasePage#onInitialize() should be a good
> > place.
> > > Or you could add the pageIds of the special/slow pages only in the map.
> > >
> > > Otherwise you may use PageRequestHandlerTracker#getLastHandler in a
> > custom
> > > IRequestCycleListener#onDetach().
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> > > On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <
> > guillaume.smet@gmail.com>
> > > wrote:
> > >
> > >> Hi Martin,
> > >>
> > >> Yeah, I thought about that too but I'm not sure of the best place to
> > >> build the pageId -> pageClassName map. Any advice about this?
> > >>
> > >> Once I'll get this working, I'll build a PR for the few changes I made
> > >> in Wicket (based on what you proposed earlier). Would be nice to have
> > >> them in 6.18.
> > >>
> > >> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <
> mgrigorov@apache.org>
> > >> wrote:
> > >> > Hi Guillaume,
> > >> >
> > >> > Sorry for not thinking more carefully about this the first time!
> > >> > I'm afraid it is not possible to do it the way I suggested.
> > >> > PageAccessSynchronizer is the entry point to start using a page and
> it
> > >> > works only with pageId!
> > >> >
> > >> > Here is a new hackish approach:
> > >> > Store pageId -> pageClassName map in the Session. Then when
> > >> > PageAccessSynchronizer is requested to lock a page by id use that id
> > to
> > >> > resolve the class name and to decide what timeout to use.
> > >> >
> > >> > Martin Grigorov
> > >> > Wicket Training and Consulting
> > >> > https://twitter.com/mtgrigorov
> > >> >
> > >> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <
> > >> guillaume.smet@gmail.com>
> > >> > wrote:
> > >> >
> > >> >> Hi Martin,
> > >> >>
> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <
> > mgrigorov@apache.org>
> > >> >> wrote:
> > >> >> > I'd like to avoid moving the logic that gets the timeout from
> > >> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
> > >> because
> > >> >> > this way it will use Application.get() everytime and most apps
> > don't
> > >> need
> > >> >> > to pay for this.
> > >> >> >
> > >> >> > A way to make it possible for you is to remove the 'final'
> > >> >> > from org.apache.wicket.Session#getPageManager and introduce
> > >> overridable
> > >> >> > PageAccessSynchronizer#getTimeout(). This way you can use your
> own
> > >> >> > PageAccessSynchronizer.
> > >> >> > http://pastie.org/9667070
> > >> >>
> > >> >> After a few experiments, here I am!
> > >> >>
> > >> >> So, it mostly works: I thought it would be better to add something
> > like:
> > >> >> protected IProvider<PageAccessSynchronizer>
> > >> >> newPageAccessSynchronizerProvider()
> > >> >> {
> > >> >> return new PageAccessSynchronizerProvider();
> > >> >> }
> > >> >> in Session and call it from the constructor instead of removing the
> > >> >> final so I did that in my code.
> > >> >>
> > >> >> It works pretty well BUT I haven't found a way to get the page
> class
> > >> >> in getTimeout without having the risk to trigger a
> > resolvePageInstance
> > >> >> which will try to lock and then call getTimeout leading to a
> > wonderful
> > >> >> stack overflow exception when dealing with
> > >> >> ListenerInterfaceRequestHandler.
> > >> >>
> > >> >> Obviously (...) what interests me the most is the getTimeout in
> > >> >> ListenerInterfaceRequestHandler as it's often actions on buttons
> > which
> > >> >> are long to run.
> > >> >>
> > >> >> Here is what I have in mind for my Session class:
> > >> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
> > >> >>
> > >> >> I must admit that an advice would be welcome as I wouldn't like to
> > >> >> have stack overflow errors popping out in weird edge cases.
> > >> >>
> > >> >> Thanks!
> > >> >>
> > >> >> --
> > >> >> Guillaume
> > >> >>
> > >> >>
> ---------------------------------------------------------------------
> > >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
> > >> >>
> > >> >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Lock timeout per page class
Posted by Sebastien <se...@gmail.com>.
Hi Guillaume,
Generally speaking, you cannot call a non final method from a constructor...
Best regards,
Sebastien
On Oct 25, 2014 1:32 PM, "Guillaume Smet" <gu...@gmail.com> wrote:
> Hi Martin,
>
> I got something working with the following changes in Wicket:
>
> https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
>
> Do you consider this commitable? If so, I can create a JIRA issue and push
> a PR.
>
> Having the pageId in the getTimeout call is quite nice as I don't have
> to get it again from the PageRequestHandlerTracker.
>
> Thanks for your feedback.
>
> On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mg...@apache.org>
> wrote:
> > If you have a base page then BasePage#onInitialize() should be a good
> place.
> > Or you could add the pageIds of the special/slow pages only in the map.
> >
> > Otherwise you may use PageRequestHandlerTracker#getLastHandler in a
> custom
> > IRequestCycleListener#onDetach().
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <
> guillaume.smet@gmail.com>
> > wrote:
> >
> >> Hi Martin,
> >>
> >> Yeah, I thought about that too but I'm not sure of the best place to
> >> build the pageId -> pageClassName map. Any advice about this?
> >>
> >> Once I'll get this working, I'll build a PR for the few changes I made
> >> in Wicket (based on what you proposed earlier). Would be nice to have
> >> them in 6.18.
> >>
> >> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <mg...@apache.org>
> >> wrote:
> >> > Hi Guillaume,
> >> >
> >> > Sorry for not thinking more carefully about this the first time!
> >> > I'm afraid it is not possible to do it the way I suggested.
> >> > PageAccessSynchronizer is the entry point to start using a page and it
> >> > works only with pageId!
> >> >
> >> > Here is a new hackish approach:
> >> > Store pageId -> pageClassName map in the Session. Then when
> >> > PageAccessSynchronizer is requested to lock a page by id use that id
> to
> >> > resolve the class name and to decide what timeout to use.
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >> >
> >> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <
> >> guillaume.smet@gmail.com>
> >> > wrote:
> >> >
> >> >> Hi Martin,
> >> >>
> >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <
> mgrigorov@apache.org>
> >> >> wrote:
> >> >> > I'd like to avoid moving the logic that gets the timeout from
> >> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
> >> because
> >> >> > this way it will use Application.get() everytime and most apps
> don't
> >> need
> >> >> > to pay for this.
> >> >> >
> >> >> > A way to make it possible for you is to remove the 'final'
> >> >> > from org.apache.wicket.Session#getPageManager and introduce
> >> overridable
> >> >> > PageAccessSynchronizer#getTimeout(). This way you can use your own
> >> >> > PageAccessSynchronizer.
> >> >> > http://pastie.org/9667070
> >> >>
> >> >> After a few experiments, here I am!
> >> >>
> >> >> So, it mostly works: I thought it would be better to add something
> like:
> >> >> protected IProvider<PageAccessSynchronizer>
> >> >> newPageAccessSynchronizerProvider()
> >> >> {
> >> >> return new PageAccessSynchronizerProvider();
> >> >> }
> >> >> in Session and call it from the constructor instead of removing the
> >> >> final so I did that in my code.
> >> >>
> >> >> It works pretty well BUT I haven't found a way to get the page class
> >> >> in getTimeout without having the risk to trigger a
> resolvePageInstance
> >> >> which will try to lock and then call getTimeout leading to a
> wonderful
> >> >> stack overflow exception when dealing with
> >> >> ListenerInterfaceRequestHandler.
> >> >>
> >> >> Obviously (...) what interests me the most is the getTimeout in
> >> >> ListenerInterfaceRequestHandler as it's often actions on buttons
> which
> >> >> are long to run.
> >> >>
> >> >> Here is what I have in mind for my Session class:
> >> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
> >> >>
> >> >> I must admit that an advice would be welcome as I wouldn't like to
> >> >> have stack overflow errors popping out in weird edge cases.
> >> >>
> >> >> Thanks!
> >> >>
> >> >> --
> >> >> Guillaume
> >> >>
> >> >> ---------------------------------------------------------------------
> >> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> >> For additional commands, e-mail: users-help@wicket.apache.org
> >> >>
> >> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Lock timeout per page class
Posted by Guillaume Smet <gu...@gmail.com>.
Hi Martin,
I got something working with the following changes in Wicket:
https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4
Do you consider this commitable? If so, I can create a JIRA issue and push a PR.
Having the pageId in the getTimeout call is quite nice as I don't have
to get it again from the PageRequestHandlerTracker.
Thanks for your feedback.
On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mg...@apache.org> wrote:
> If you have a base page then BasePage#onInitialize() should be a good place.
> Or you could add the pageIds of the special/slow pages only in the map.
>
> Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom
> IRequestCycleListener#onDetach().
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <gu...@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> Yeah, I thought about that too but I'm not sure of the best place to
>> build the pageId -> pageClassName map. Any advice about this?
>>
>> Once I'll get this working, I'll build a PR for the few changes I made
>> in Wicket (based on what you proposed earlier). Would be nice to have
>> them in 6.18.
>>
>> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi Guillaume,
>> >
>> > Sorry for not thinking more carefully about this the first time!
>> > I'm afraid it is not possible to do it the way I suggested.
>> > PageAccessSynchronizer is the entry point to start using a page and it
>> > works only with pageId!
>> >
>> > Here is a new hackish approach:
>> > Store pageId -> pageClassName map in the Session. Then when
>> > PageAccessSynchronizer is requested to lock a page by id use that id to
>> > resolve the class name and to decide what timeout to use.
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >
>> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <
>> guillaume.smet@gmail.com>
>> > wrote:
>> >
>> >> Hi Martin,
>> >>
>> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mg...@apache.org>
>> >> wrote:
>> >> > I'd like to avoid moving the logic that gets the timeout from
>> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
>> because
>> >> > this way it will use Application.get() everytime and most apps don't
>> need
>> >> > to pay for this.
>> >> >
>> >> > A way to make it possible for you is to remove the 'final'
>> >> > from org.apache.wicket.Session#getPageManager and introduce
>> overridable
>> >> > PageAccessSynchronizer#getTimeout(). This way you can use your own
>> >> > PageAccessSynchronizer.
>> >> > http://pastie.org/9667070
>> >>
>> >> After a few experiments, here I am!
>> >>
>> >> So, it mostly works: I thought it would be better to add something like:
>> >> protected IProvider<PageAccessSynchronizer>
>> >> newPageAccessSynchronizerProvider()
>> >> {
>> >> return new PageAccessSynchronizerProvider();
>> >> }
>> >> in Session and call it from the constructor instead of removing the
>> >> final so I did that in my code.
>> >>
>> >> It works pretty well BUT I haven't found a way to get the page class
>> >> in getTimeout without having the risk to trigger a resolvePageInstance
>> >> which will try to lock and then call getTimeout leading to a wonderful
>> >> stack overflow exception when dealing with
>> >> ListenerInterfaceRequestHandler.
>> >>
>> >> Obviously (...) what interests me the most is the getTimeout in
>> >> ListenerInterfaceRequestHandler as it's often actions on buttons which
>> >> are long to run.
>> >>
>> >> Here is what I have in mind for my Session class:
>> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
>> >>
>> >> I must admit that an advice would be welcome as I wouldn't like to
>> >> have stack overflow errors popping out in weird edge cases.
>> >>
>> >> Thanks!
>> >>
>> >> --
>> >> Guillaume
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Martin Grigorov <mg...@apache.org>.
If you have a base page then BasePage#onInitialize() should be a good place.
Or you could add the pageIds of the special/slow pages only in the map.
Otherwise you may use PageRequestHandlerTracker#getLastHandler in a custom
IRequestCycleListener#onDetach().
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet <gu...@gmail.com>
wrote:
> Hi Martin,
>
> Yeah, I thought about that too but I'm not sure of the best place to
> build the pageId -> pageClassName map. Any advice about this?
>
> Once I'll get this working, I'll build a PR for the few changes I made
> in Wicket (based on what you proposed earlier). Would be nice to have
> them in 6.18.
>
> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi Guillaume,
> >
> > Sorry for not thinking more carefully about this the first time!
> > I'm afraid it is not possible to do it the way I suggested.
> > PageAccessSynchronizer is the entry point to start using a page and it
> > works only with pageId!
> >
> > Here is a new hackish approach:
> > Store pageId -> pageClassName map in the Session. Then when
> > PageAccessSynchronizer is requested to lock a page by id use that id to
> > resolve the class name and to decide what timeout to use.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <
> guillaume.smet@gmail.com>
> > wrote:
> >
> >> Hi Martin,
> >>
> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mg...@apache.org>
> >> wrote:
> >> > I'd like to avoid moving the logic that gets the timeout from
> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer
> because
> >> > this way it will use Application.get() everytime and most apps don't
> need
> >> > to pay for this.
> >> >
> >> > A way to make it possible for you is to remove the 'final'
> >> > from org.apache.wicket.Session#getPageManager and introduce
> overridable
> >> > PageAccessSynchronizer#getTimeout(). This way you can use your own
> >> > PageAccessSynchronizer.
> >> > http://pastie.org/9667070
> >>
> >> After a few experiments, here I am!
> >>
> >> So, it mostly works: I thought it would be better to add something like:
> >> protected IProvider<PageAccessSynchronizer>
> >> newPageAccessSynchronizerProvider()
> >> {
> >> return new PageAccessSynchronizerProvider();
> >> }
> >> in Session and call it from the constructor instead of removing the
> >> final so I did that in my code.
> >>
> >> It works pretty well BUT I haven't found a way to get the page class
> >> in getTimeout without having the risk to trigger a resolvePageInstance
> >> which will try to lock and then call getTimeout leading to a wonderful
> >> stack overflow exception when dealing with
> >> ListenerInterfaceRequestHandler.
> >>
> >> Obviously (...) what interests me the most is the getTimeout in
> >> ListenerInterfaceRequestHandler as it's often actions on buttons which
> >> are long to run.
> >>
> >> Here is what I have in mind for my Session class:
> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
> >>
> >> I must admit that an advice would be welcome as I wouldn't like to
> >> have stack overflow errors popping out in weird edge cases.
> >>
> >> Thanks!
> >>
> >> --
> >> Guillaume
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Lock timeout per page class
Posted by Guillaume Smet <gu...@gmail.com>.
Hi Martin,
Yeah, I thought about that too but I'm not sure of the best place to
build the pageId -> pageClassName map. Any advice about this?
Once I'll get this working, I'll build a PR for the few changes I made
in Wicket (based on what you proposed earlier). Would be nice to have
them in 6.18.
On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov <mg...@apache.org> wrote:
> Hi Guillaume,
>
> Sorry for not thinking more carefully about this the first time!
> I'm afraid it is not possible to do it the way I suggested.
> PageAccessSynchronizer is the entry point to start using a page and it
> works only with pageId!
>
> Here is a new hackish approach:
> Store pageId -> pageClassName map in the Session. Then when
> PageAccessSynchronizer is requested to lock a page by id use that id to
> resolve the class name and to decide what timeout to use.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <gu...@gmail.com>
> wrote:
>
>> Hi Martin,
>>
>> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > I'd like to avoid moving the logic that gets the timeout from
>> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
>> > this way it will use Application.get() everytime and most apps don't need
>> > to pay for this.
>> >
>> > A way to make it possible for you is to remove the 'final'
>> > from org.apache.wicket.Session#getPageManager and introduce overridable
>> > PageAccessSynchronizer#getTimeout(). This way you can use your own
>> > PageAccessSynchronizer.
>> > http://pastie.org/9667070
>>
>> After a few experiments, here I am!
>>
>> So, it mostly works: I thought it would be better to add something like:
>> protected IProvider<PageAccessSynchronizer>
>> newPageAccessSynchronizerProvider()
>> {
>> return new PageAccessSynchronizerProvider();
>> }
>> in Session and call it from the constructor instead of removing the
>> final so I did that in my code.
>>
>> It works pretty well BUT I haven't found a way to get the page class
>> in getTimeout without having the risk to trigger a resolvePageInstance
>> which will try to lock and then call getTimeout leading to a wonderful
>> stack overflow exception when dealing with
>> ListenerInterfaceRequestHandler.
>>
>> Obviously (...) what interests me the most is the getTimeout in
>> ListenerInterfaceRequestHandler as it's often actions on buttons which
>> are long to run.
>>
>> Here is what I have in mind for my Session class:
>> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
>>
>> I must admit that an advice would be welcome as I wouldn't like to
>> have stack overflow errors popping out in weird edge cases.
>>
>> Thanks!
>>
>> --
>> Guillaume
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Martin Grigorov <mg...@apache.org>.
Hi Guillaume,
Sorry for not thinking more carefully about this the first time!
I'm afraid it is not possible to do it the way I suggested.
PageAccessSynchronizer is the entry point to start using a page and it
works only with pageId!
Here is a new hackish approach:
Store pageId -> pageClassName map in the Session. Then when
PageAccessSynchronizer is requested to lock a page by id use that id to
resolve the class name and to decide what timeout to use.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <gu...@gmail.com>
wrote:
> Hi Martin,
>
> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mg...@apache.org>
> wrote:
> > I'd like to avoid moving the logic that gets the timeout from
> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
> > this way it will use Application.get() everytime and most apps don't need
> > to pay for this.
> >
> > A way to make it possible for you is to remove the 'final'
> > from org.apache.wicket.Session#getPageManager and introduce overridable
> > PageAccessSynchronizer#getTimeout(). This way you can use your own
> > PageAccessSynchronizer.
> > http://pastie.org/9667070
>
> After a few experiments, here I am!
>
> So, it mostly works: I thought it would be better to add something like:
> protected IProvider<PageAccessSynchronizer>
> newPageAccessSynchronizerProvider()
> {
> return new PageAccessSynchronizerProvider();
> }
> in Session and call it from the constructor instead of removing the
> final so I did that in my code.
>
> It works pretty well BUT I haven't found a way to get the page class
> in getTimeout without having the risk to trigger a resolvePageInstance
> which will try to lock and then call getTimeout leading to a wonderful
> stack overflow exception when dealing with
> ListenerInterfaceRequestHandler.
>
> Obviously (...) what interests me the most is the getTimeout in
> ListenerInterfaceRequestHandler as it's often actions on buttons which
> are long to run.
>
> Here is what I have in mind for my Session class:
> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
>
> I must admit that an advice would be welcome as I wouldn't like to
> have stack overflow errors popping out in weird edge cases.
>
> Thanks!
>
> --
> Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Lock timeout per page class
Posted by Guillaume Smet <gu...@gmail.com>.
Hi Martin,
On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <mg...@apache.org> wrote:
> I'd like to avoid moving the logic that gets the timeout from
> Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
> this way it will use Application.get() everytime and most apps don't need
> to pay for this.
>
> A way to make it possible for you is to remove the 'final'
> from org.apache.wicket.Session#getPageManager and introduce overridable
> PageAccessSynchronizer#getTimeout(). This way you can use your own
> PageAccessSynchronizer.
> http://pastie.org/9667070
After a few experiments, here I am!
So, it mostly works: I thought it would be better to add something like:
protected IProvider<PageAccessSynchronizer> newPageAccessSynchronizerProvider()
{
return new PageAccessSynchronizerProvider();
}
in Session and call it from the constructor instead of removing the
final so I did that in my code.
It works pretty well BUT I haven't found a way to get the page class
in getTimeout without having the risk to trigger a resolvePageInstance
which will try to lock and then call getTimeout leading to a wonderful
stack overflow exception when dealing with
ListenerInterfaceRequestHandler.
Obviously (...) what interests me the most is the getTimeout in
ListenerInterfaceRequestHandler as it's often actions on buttons which
are long to run.
Here is what I have in mind for my Session class:
https://gist.github.com/gsmet/3b9e2775d25fadcef5ef
I must admit that an advice would be welcome as I wouldn't like to
have stack overflow errors popping out in weird edge cases.
Thanks!
--
Guillaume
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
You are right!
On Tue, Oct 21, 2014 at 11:11 PM, Guillaume Smet <gu...@gmail.com>
wrote:
> Hi Martin,
>
> On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > You can
> > use
> org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
> > to check what is the requested page in your
> > own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout
>
> Cute trick but it doesn't work: the timeout is determined once and for
> all when the PageAccessSynchronizer is instantiated (see
> Session$PageAccessSynchronizerProvider).
>
> And AFAICS, the PageAccessSynchronizer is too low level to be a good
> place to manipulate the RequestCycle. Or am I wrong?
>
I'd like to avoid moving the logic that gets the timeout from
Session.PageAccessSynchronizerProvider to PageAccessSynchronizer because
this way it will use Application.get() everytime and most apps don't need
to pay for this.
A way to make it possible for you is to remove the 'final'
from org.apache.wicket.Session#getPageManager and introduce overridable
PageAccessSynchronizer#getTimeout(). This way you can use your own
PageAccessSynchronizer.
http://pastie.org/9667070
Is this good enough ?
>
> --
> Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Lock timeout per page class
Posted by Guillaume Smet <gu...@gmail.com>.
Hi Martin,
On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov <mg...@apache.org> wrote:
> You can
> use org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
> to check what is the requested page in your
> own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout
Cute trick but it doesn't work: the timeout is determined once and for
all when the PageAccessSynchronizer is instantiated (see
Session$PageAccessSynchronizerProvider).
And AFAICS, the PageAccessSynchronizer is too low level to be a good
place to manipulate the RequestCycle. Or am I wrong?
--
Guillaume
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Lock timeout per page class
Posted by Martin Grigorov <mg...@apache.org>.
Hi Guillaume,
You can
use org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
to check what is the requested page in your
own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Oct 21, 2014 at 1:12 PM, Guillaume Smet <gu...@gmail.com>
wrote:
> Hi,
>
> We have a few pages in our application which might take a long time to
> generate. This is definitely not the usual case but there are a few of
> them.
>
> Thus we were forced to define a high lockTimeout to be sure these
> pages can be served.
>
> The fact is that we would really like to have a far lower default
> timeout except for these pages.
>
> Is there a way to configure the lockTimeout on a per page basis (I
> haven't found one)?
>
> If not, would it be a good idea to provide a way to do so?
>
> Thanks for your feedback.
>
> --
> Guillaume
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>