Re: Lock timeout per page class
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 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 > 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 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" >>> 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 >>> > 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.s...@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 < >>> mgrigo...@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.s...@gmail.com> >>> > >> > wrote: >>> > >> > >>> > >> >> Hi Martin, >>> > >> >> >>> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov < >>> > mgrigo...@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 >>> > >> >> 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 intere
Re: Lock timeout per page class
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 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 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" >> 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 >> > 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.s...@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 < >> mgrigo...@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.s...@gmail.com> >> > >> > wrote: >> > >> > >> > >> >> Hi Martin, >> > >> >> >> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov < >> > mgrigo...@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 >> > >> >> 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 w
Re: Lock timeout per page class
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 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" > 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 > > 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.s...@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 < > mgrigo...@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.s...@gmail.com> > > >> > wrote: > > >> > > > >> >> Hi Martin, > > >> >> > > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov < > > mgrigo...@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 > > >> >> 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-unsubscr...@wicket.apache.org > > >> >> For additional commands, e-mail: users-h...@wick
Re: Lock timeout per page class
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" 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 > 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.s...@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 > >> 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.s...@gmail.com> > >> > wrote: > >> > > >> >> Hi Martin, > >> >> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov < > mgrigo...@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 > >> >> 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-unsubscr...@wicket.apache.org > >> >> For additional commands, e-mail: users-h...@wicket.apache.org > >> >> > >> >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Lock timeout per page class
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 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 > 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 >> 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.s...@gmail.com> >> > wrote: >> > >> >> Hi Martin, >> >> >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov >> >> 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 >> >> 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-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
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 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 > 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.s...@gmail.com> > > wrote: > > > >> Hi Martin, > >> > >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov > >> 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 > >> 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-unsubscr...@wicket.apache.org > >> For additional commands, e-mail: users-h...@wicket.apache.org > >> > >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Lock timeout per page class
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 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 > wrote: > >> Hi Martin, >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov >> 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 >> 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-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
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 wrote: > Hi Martin, > > On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov > 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 > 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Lock timeout per page class
Hi Martin, On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov 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 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
Hi, You are right! On Tue, Oct 21, 2014 at 11:11 PM, Guillaume Smet wrote: > Hi Martin, > > On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov > 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: Lock timeout per page class
Hi Martin, On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov 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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
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 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 > 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-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Lock timeout per page class
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 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-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
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-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org