You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by nillehammer <ta...@winfonet.eu> on 2008/09/19 09:02:54 UTC

Re: Page pool hard limit and page instance usage

Hi list,

I am also facing the problem that 9902468 had. I have -according to
Howard's suggestion- replaced every pageLink with a customPageLink to
prevent targeted pages from being created unecessarily. The problem
persists. Trying to load the index-Page of my application with a browser
I have to wait about two minutes before I get an empty page. In the
app's log the following Exception appears:

java.lang.RuntimeException: The page pool for page 'Index' (in locale
de) has been exausted: there are 20 instances currently being used and
no more can be created. Try increasing the hard limit (symbol
tapestry.page-pool.hard-limit) to allow additional instances to be
created, or increasing the soft wait (symbol
tapestry.page-pool.soft-wait) to trade away some throughput for more
efficient use of page instances.
        at
org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
        at
org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
        at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
        at
org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
        at
$RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
        at
$RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
...

In development and in production environment I use Java 6 and Tomcat 6.
Tapestry is 5.0.14. The strange thing is that I am only seeing this in
production environment.

Has anyone a suggestion how to track this down? I am pretty stuck with this.

Thanks in advance, nillehammer

Howard Lewis Ship wrote
> Tapestry is obtaining page instances to see if there is an activation
> context for the page.
> 
> I expect to optimize this in the future, to check to see if the page
> has an event handler for the passivate event.
> 
> In the meantime, you could build your own PageLink component that
> generates the link by invoking
> ComponentResources.createPageLink("pagename", true) ... that will tell
> Tapestry to generate a link to the page with no activation context,
> and the page will NOT be queried for its context, and therefore, won't
> need to be attached to the current request.
> 
> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi> wrote:
>> Hi,
>>
>> we are experiencing strange hard pool limit reached exceptions. (For the
>> user count that we have.) After debugging a little, it seems that our left
>> menu component, which is full of page links, instantiates not only the page
>> that we are at, but also the ones that are referenced in page link.
>>
>> This can be seen also in that exception page is shown, if one of the pages
>> that are referenced in page links have an error.
>>
>> Is this correct behavior? And should we really use common a href= tags to
>> avoid this? Further more, is it possible to create infinite loop, when page
>> a has page link to page b, which has page link to page a?
>>
>>  - 99
>> --
>> View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by 9902468 <vi...@cerion.fi>.
Good point.

Now I'm going to read some documentation ;)

 -99


Ulrich Stärk wrote:
> 
> Yes it can, but CollectionFactory is internal API (whereas
> CaseInsensitiveMap is not) and I didn't 
> want to rely on it.
> 
> Uli
> 
> 9902468 schrieb:
>> Thanks!
>> 
>> Obviously I should read more than code :)
>> 
>> btw, case insensitive map can be obtained by calling
>> org.apache.tapestry5.ioc.internal.util.CollectionFactory.newCaseInsensitiveMap();
>> 
>>  - 99
>> 
>> 
>> Ulrich Stärk wrote:
>>> You don't have to write your own ServletContextSymbolProvider, it
>>> already
>>> comes shipped with 
>>> Tapestry. See here 
>>> http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
>>> You just have to configure it.
>>>
>>> Uli
>>>
>>> 9902468 schrieb:
>>>> Yep, just read through your discussion:
>>>>
>>>> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
>>>>
>>>> and that would be the intelligent way of doing it :)
>>>>
>>>> I'll code symbol provider when I have time. Hopefully these providers
>>>> can
>>>> be
>>>> included in T5 distribution, as these are highly reusable and add only
>>>> little to none "weight" to the distribution.
>>>>
>>>>  - 99
>>>>
>>>>
>>>> Ulrich Stärk wrote:
>>>>> Why not instantiate a ServletContextSymbolProvider (the ServletContext
>>>>> is
>>>>> available from the 
>>>>> ApplicationGlobals service) and contribute it to the SymbolProvider
>>>>> before
>>>>> ApplicationDefaults and 
>>>>> FactoryDefaults. That way you can directly override
>>>>> tapestry.page-pool.hard-limit and automatically 
>>>>> have all other init parameters as symbols, too.
>>>>>
>>>>> Uli
>>>>>
>>>>> 9902468 schrieb:
>>>>>> I always keep nabble open when I'm at work :)
>>>>>>
>>>>>> These parameters can be transferred to web.xml, so that recompile is
>>>>>> not
>>>>>> needed when changing these parameters:
>>>>>>
>>>>>> public static void
>>>>>> contributeApplicationDefaults(MappedConfiguration<String,
>>>>>> String> configuration, ApplicationGlobals globals) {
>>>>>>
>>>>>>     configuration.add("tapestry.page-pool.hard-limit",
>>>>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>>>>
>>>>>> }
>>>>>>
>>>>>> and in web.xml
>>>>>>
>>>>>> <web-app>
>>>>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>>>>     <context-param>
>>>>>>         <!-- The only significant configuration for Tapestry 5, this
>>>>>> informs
>>>>>> Tapestry of where to look for pages, components and mixins. -->
>>>>>>         <param-name>tapestry.app-package</param-name>
>>>>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>>>>     </context-param>
>>>>>>     <context-param>
>>>>>>         <param-name>page_hard_limit</param-name>
>>>>>>         <param-value>60</param-value>
>>>>>>     </context-param>
>>>>>>
>>>>>> This can be used through out every single service and page and
>>>>>> component.
>>>>>> To
>>>>>> access this in a page or component use:
>>>>>>
>>>>>> @Property @Inject @Value("${page_hard_limit}")
>>>>>> private String pageHardLimit;
>>>>>>
>>>>>> Injection can be used in service constructor also (I think) or by
>>>>>> using
>>>>>> buildSomeService method instead of the usual binder.bind
>>>>>>
>>>>>> Of course T5 makes it easy to read these from a file or database or
>>>>>> from
>>>>>> what not, but I have noticed that many admins accept editing web.xml
>>>>>> and
>>>>>> restarting the app ok.
>>>>>>
>>>>>> Hopefully this helps. (And makes it easier to say to admins that just
>>>>>> configure the app according to the load they are experiencing.)
>>>>>>
>>>>>> -99
>>>>>>
>>>>>>
>>>>>> nille hammer wrote:
>>>>>>> Man that was a quick answer! Thanks for that. I am aware of this
>>>>>>> options
>>>>>>> in the configuration. I had not tuned them before, because load is
>>>>>>> not
>>>>>>> my problem. Anyway I have tuned them now and am currently waiting
>>>>>>> for
>>>>>>> the admistrator to deploy the newest war.
>>>>>>>
>>>>>>> According to acces-logs I was the only user accessing the page. So
>>>>>>> as
>>>>>>> far as I understand the mechanism only one instance of index should
>>>>>>> have
>>>>>>> been created and not 20. I think it is an issue with configuration
>>>>>>> in
>>>>>>> production environment. But I have no idea where to take a closer
>>>>>>> look
>>>>>>> (i.e. where to build in log-messages, which of Tomcat's
>>>>>>> configuration
>>>>>>> options to check etc.).
>>>>>>>
>>>>>>> So suggestions are still more than welcome.
>>>>>>>
>>>>>>> Nillehammer
>>>>>>>
>>>>>>> 9902468 schrieb:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Eventually we had to add these to appmodule:
>>>>>>>>
>>>>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>>>>
>>>>>>>> as instructed here:
>>>>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>>>>
>>>>>>>> This solved our problems, and you can go up as long as your server
>>>>>>>> has
>>>>>>>> memory. Our problems were only in production, as development stress
>>>>>>>> just
>>>>>>>> isn't enough. (This is why one really should do load testing with
>>>>>>>> jmeter
>>>>>>>> or
>>>>>>>> similar tool.)
>>>>>>>>
>>>>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>>>>> developer would hit these walls during development and understands
>>>>>>>> to
>>>>>>>> load
>>>>>>>> test / tune the parameters.
>>>>>>>>
>>>>>>>>  - 99
>>>>>>>>
>>>>>>>>
>>>>>>>> nille hammer wrote:
>>>>>>>>> Hi list,
>>>>>>>>>
>>>>>>>>> I am also facing the problem that 9902468 had. I have -according
>>>>>>>>> to
>>>>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink
>>>>>>>>> to
>>>>>>>>> prevent targeted pages from being created unecessarily. The
>>>>>>>>> problem
>>>>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>>>>> browser
>>>>>>>>> I have to wait about two minutes before I get an empty page. In
>>>>>>>>> the
>>>>>>>>> app's log the following Exception appears:
>>>>>>>>>
>>>>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in
>>>>>>>>> locale
>>>>>>>>> de) has been exausted: there are 20 instances currently being used
>>>>>>>>> and
>>>>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>>>>> created, or increasing the soft wait (symbol
>>>>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for
>>>>>>>>> more
>>>>>>>>> efficient use of page instances.
>>>>>>>>>         at
>>>>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>>>>         at
>>>>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>>>>         at
>>>>>>>>> $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>>>>         at
>>>>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>>>>         at
>>>>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>>>>         at
>>>>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>> In development and in production environment I use Java 6 and
>>>>>>>>> Tomcat
>>>>>>>>> 6.
>>>>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing
>>>>>>>>> this
>>>>>>>>> in
>>>>>>>>> production environment.
>>>>>>>>>
>>>>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck
>>>>>>>>> with
>>>>>>>>> this.
>>>>>>>>>
>>>>>>>>> Thanks in advance, nillehammer
>>>>>>>>>
>>>>>>>>> Howard Lewis Ship wrote
>>>>>>>>>> Tapestry is obtaining page instances to see if there is an
>>>>>>>>>> activation
>>>>>>>>>> context for the page.
>>>>>>>>>>
>>>>>>>>>> I expect to optimize this in the future, to check to see if the
>>>>>>>>>> page
>>>>>>>>>> has an event handler for the passivate event.
>>>>>>>>>>
>>>>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>>>>> generates the link by invoking
>>>>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>>>>> tell
>>>>>>>>>> Tapestry to generate a link to the page with no activation
>>>>>>>>>> context,
>>>>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>>>>> won't
>>>>>>>>>> need to be attached to the current request.
>>>>>>>>>>
>>>>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468
>>>>>>>>>> <vi...@cerion.fi>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> we are experiencing strange hard pool limit reached exceptions.
>>>>>>>>>>> (For
>>>>>>>>>>> the
>>>>>>>>>>> user count that we have.) After debugging a little, it seems
>>>>>>>>>>> that
>>>>>>>>>>> our
>>>>>>>>>>> left
>>>>>>>>>>> menu component, which is full of page links, instantiates not
>>>>>>>>>>> only
>>>>>>>>>>> the
>>>>>>>>>>> page
>>>>>>>>>>> that we are at, but also the ones that are referenced in page
>>>>>>>>>>> link.
>>>>>>>>>>>
>>>>>>>>>>> This can be seen also in that exception page is shown, if one of
>>>>>>>>>>> the
>>>>>>>>>>> pages
>>>>>>>>>>> that are referenced in page links have an error.
>>>>>>>>>>>
>>>>>>>>>>> Is this correct behavior? And should we really use common a
>>>>>>>>>>> href=
>>>>>>>>>>> tags
>>>>>>>>>>> to
>>>>>>>>>>> avoid this? Further more, is it possible to create infinite
>>>>>>>>>>> loop,
>>>>>>>>>>> when
>>>>>>>>>>> page
>>>>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>>>>
>>>>>>>>>>>  - 99
>>>>>>>>>>> --
>>>>>>>>>>> View this message in context:
>>>>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>>>>> Sent from the Tapestry - User mailing list archive at
>>>>>>>>>>> Nabble.com.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19570378.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by Ulrich Stärk <ul...@spielviel.de>.
Yes it can, but CollectionFactory is internal API (whereas CaseInsensitiveMap is not) and I didn't 
want to rely on it.

Uli

9902468 schrieb:
> Thanks!
> 
> Obviously I should read more than code :)
> 
> btw, case insensitive map can be obtained by calling
> org.apache.tapestry5.ioc.internal.util.CollectionFactory.newCaseInsensitiveMap();
> 
>  - 99
> 
> 
> Ulrich Stärk wrote:
>> You don't have to write your own ServletContextSymbolProvider, it already
>> comes shipped with 
>> Tapestry. See here 
>> http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
>> You just have to configure it.
>>
>> Uli
>>
>> 9902468 schrieb:
>>> Yep, just read through your discussion:
>>>
>>> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
>>>
>>> and that would be the intelligent way of doing it :)
>>>
>>> I'll code symbol provider when I have time. Hopefully these providers can
>>> be
>>> included in T5 distribution, as these are highly reusable and add only
>>> little to none "weight" to the distribution.
>>>
>>>  - 99
>>>
>>>
>>> Ulrich Stärk wrote:
>>>> Why not instantiate a ServletContextSymbolProvider (the ServletContext
>>>> is
>>>> available from the 
>>>> ApplicationGlobals service) and contribute it to the SymbolProvider
>>>> before
>>>> ApplicationDefaults and 
>>>> FactoryDefaults. That way you can directly override
>>>> tapestry.page-pool.hard-limit and automatically 
>>>> have all other init parameters as symbols, too.
>>>>
>>>> Uli
>>>>
>>>> 9902468 schrieb:
>>>>> I always keep nabble open when I'm at work :)
>>>>>
>>>>> These parameters can be transferred to web.xml, so that recompile is
>>>>> not
>>>>> needed when changing these parameters:
>>>>>
>>>>> public static void
>>>>> contributeApplicationDefaults(MappedConfiguration<String,
>>>>> String> configuration, ApplicationGlobals globals) {
>>>>>
>>>>>     configuration.add("tapestry.page-pool.hard-limit",
>>>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>>>
>>>>> }
>>>>>
>>>>> and in web.xml
>>>>>
>>>>> <web-app>
>>>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>>>     <context-param>
>>>>>         <!-- The only significant configuration for Tapestry 5, this
>>>>> informs
>>>>> Tapestry of where to look for pages, components and mixins. -->
>>>>>         <param-name>tapestry.app-package</param-name>
>>>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>>>     </context-param>
>>>>>     <context-param>
>>>>>         <param-name>page_hard_limit</param-name>
>>>>>         <param-value>60</param-value>
>>>>>     </context-param>
>>>>>
>>>>> This can be used through out every single service and page and
>>>>> component.
>>>>> To
>>>>> access this in a page or component use:
>>>>>
>>>>> @Property @Inject @Value("${page_hard_limit}")
>>>>> private String pageHardLimit;
>>>>>
>>>>> Injection can be used in service constructor also (I think) or by using
>>>>> buildSomeService method instead of the usual binder.bind
>>>>>
>>>>> Of course T5 makes it easy to read these from a file or database or
>>>>> from
>>>>> what not, but I have noticed that many admins accept editing web.xml
>>>>> and
>>>>> restarting the app ok.
>>>>>
>>>>> Hopefully this helps. (And makes it easier to say to admins that just
>>>>> configure the app according to the load they are experiencing.)
>>>>>
>>>>> -99
>>>>>
>>>>>
>>>>> nille hammer wrote:
>>>>>> Man that was a quick answer! Thanks for that. I am aware of this
>>>>>> options
>>>>>> in the configuration. I had not tuned them before, because load is not
>>>>>> my problem. Anyway I have tuned them now and am currently waiting for
>>>>>> the admistrator to deploy the newest war.
>>>>>>
>>>>>> According to acces-logs I was the only user accessing the page. So as
>>>>>> far as I understand the mechanism only one instance of index should
>>>>>> have
>>>>>> been created and not 20. I think it is an issue with configuration in
>>>>>> production environment. But I have no idea where to take a closer look
>>>>>> (i.e. where to build in log-messages, which of Tomcat's configuration
>>>>>> options to check etc.).
>>>>>>
>>>>>> So suggestions are still more than welcome.
>>>>>>
>>>>>> Nillehammer
>>>>>>
>>>>>> 9902468 schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Eventually we had to add these to appmodule:
>>>>>>>
>>>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>>>
>>>>>>> as instructed here:
>>>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>>>
>>>>>>> This solved our problems, and you can go up as long as your server
>>>>>>> has
>>>>>>> memory. Our problems were only in production, as development stress
>>>>>>> just
>>>>>>> isn't enough. (This is why one really should do load testing with
>>>>>>> jmeter
>>>>>>> or
>>>>>>> similar tool.)
>>>>>>>
>>>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>>>> developer would hit these walls during development and understands to
>>>>>>> load
>>>>>>> test / tune the parameters.
>>>>>>>
>>>>>>>  - 99
>>>>>>>
>>>>>>>
>>>>>>> nille hammer wrote:
>>>>>>>> Hi list,
>>>>>>>>
>>>>>>>> I am also facing the problem that 9902468 had. I have -according to
>>>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink
>>>>>>>> to
>>>>>>>> prevent targeted pages from being created unecessarily. The problem
>>>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>>>> browser
>>>>>>>> I have to wait about two minutes before I get an empty page. In the
>>>>>>>> app's log the following Exception appears:
>>>>>>>>
>>>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in
>>>>>>>> locale
>>>>>>>> de) has been exausted: there are 20 instances currently being used
>>>>>>>> and
>>>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>>>> created, or increasing the soft wait (symbol
>>>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>>>>>>> efficient use of page instances.
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>>>         at
>>>>>>>> $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>>>         at
>>>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>>>         at
>>>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>>>> ...
>>>>>>>>
>>>>>>>> In development and in production environment I use Java 6 and Tomcat
>>>>>>>> 6.
>>>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this
>>>>>>>> in
>>>>>>>> production environment.
>>>>>>>>
>>>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck
>>>>>>>> with
>>>>>>>> this.
>>>>>>>>
>>>>>>>> Thanks in advance, nillehammer
>>>>>>>>
>>>>>>>> Howard Lewis Ship wrote
>>>>>>>>> Tapestry is obtaining page instances to see if there is an
>>>>>>>>> activation
>>>>>>>>> context for the page.
>>>>>>>>>
>>>>>>>>> I expect to optimize this in the future, to check to see if the
>>>>>>>>> page
>>>>>>>>> has an event handler for the passivate event.
>>>>>>>>>
>>>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>>>> generates the link by invoking
>>>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>>>> tell
>>>>>>>>> Tapestry to generate a link to the page with no activation context,
>>>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>>>> won't
>>>>>>>>> need to be attached to the current request.
>>>>>>>>>
>>>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> we are experiencing strange hard pool limit reached exceptions.
>>>>>>>>>> (For
>>>>>>>>>> the
>>>>>>>>>> user count that we have.) After debugging a little, it seems that
>>>>>>>>>> our
>>>>>>>>>> left
>>>>>>>>>> menu component, which is full of page links, instantiates not only
>>>>>>>>>> the
>>>>>>>>>> page
>>>>>>>>>> that we are at, but also the ones that are referenced in page
>>>>>>>>>> link.
>>>>>>>>>>
>>>>>>>>>> This can be seen also in that exception page is shown, if one of
>>>>>>>>>> the
>>>>>>>>>> pages
>>>>>>>>>> that are referenced in page links have an error.
>>>>>>>>>>
>>>>>>>>>> Is this correct behavior? And should we really use common a href=
>>>>>>>>>> tags
>>>>>>>>>> to
>>>>>>>>>> avoid this? Further more, is it possible to create infinite loop,
>>>>>>>>>> when
>>>>>>>>>> page
>>>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>>>
>>>>>>>>>>  - 99
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by 9902468 <vi...@cerion.fi>.
Thanks!

Obviously I should read more than code :)

btw, case insensitive map can be obtained by calling
org.apache.tapestry5.ioc.internal.util.CollectionFactory.newCaseInsensitiveMap();

 - 99


Ulrich Stärk wrote:
> 
> You don't have to write your own ServletContextSymbolProvider, it already
> comes shipped with 
> Tapestry. See here 
> http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
> You just have to configure it.
> 
> Uli
> 
> 9902468 schrieb:
>> Yep, just read through your discussion:
>> 
>> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
>> 
>> and that would be the intelligent way of doing it :)
>> 
>> I'll code symbol provider when I have time. Hopefully these providers can
>> be
>> included in T5 distribution, as these are highly reusable and add only
>> little to none "weight" to the distribution.
>> 
>>  - 99
>> 
>> 
>> Ulrich Stärk wrote:
>>> Why not instantiate a ServletContextSymbolProvider (the ServletContext
>>> is
>>> available from the 
>>> ApplicationGlobals service) and contribute it to the SymbolProvider
>>> before
>>> ApplicationDefaults and 
>>> FactoryDefaults. That way you can directly override
>>> tapestry.page-pool.hard-limit and automatically 
>>> have all other init parameters as symbols, too.
>>>
>>> Uli
>>>
>>> 9902468 schrieb:
>>>> I always keep nabble open when I'm at work :)
>>>>
>>>> These parameters can be transferred to web.xml, so that recompile is
>>>> not
>>>> needed when changing these parameters:
>>>>
>>>> public static void
>>>> contributeApplicationDefaults(MappedConfiguration<String,
>>>> String> configuration, ApplicationGlobals globals) {
>>>>
>>>>     configuration.add("tapestry.page-pool.hard-limit",
>>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>>
>>>> }
>>>>
>>>> and in web.xml
>>>>
>>>> <web-app>
>>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>>     <context-param>
>>>>         <!-- The only significant configuration for Tapestry 5, this
>>>> informs
>>>> Tapestry of where to look for pages, components and mixins. -->
>>>>         <param-name>tapestry.app-package</param-name>
>>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>>     </context-param>
>>>>     <context-param>
>>>>         <param-name>page_hard_limit</param-name>
>>>>         <param-value>60</param-value>
>>>>     </context-param>
>>>>
>>>> This can be used through out every single service and page and
>>>> component.
>>>> To
>>>> access this in a page or component use:
>>>>
>>>> @Property @Inject @Value("${page_hard_limit}")
>>>> private String pageHardLimit;
>>>>
>>>> Injection can be used in service constructor also (I think) or by using
>>>> buildSomeService method instead of the usual binder.bind
>>>>
>>>> Of course T5 makes it easy to read these from a file or database or
>>>> from
>>>> what not, but I have noticed that many admins accept editing web.xml
>>>> and
>>>> restarting the app ok.
>>>>
>>>> Hopefully this helps. (And makes it easier to say to admins that just
>>>> configure the app according to the load they are experiencing.)
>>>>
>>>> -99
>>>>
>>>>
>>>> nille hammer wrote:
>>>>> Man that was a quick answer! Thanks for that. I am aware of this
>>>>> options
>>>>> in the configuration. I had not tuned them before, because load is not
>>>>> my problem. Anyway I have tuned them now and am currently waiting for
>>>>> the admistrator to deploy the newest war.
>>>>>
>>>>> According to acces-logs I was the only user accessing the page. So as
>>>>> far as I understand the mechanism only one instance of index should
>>>>> have
>>>>> been created and not 20. I think it is an issue with configuration in
>>>>> production environment. But I have no idea where to take a closer look
>>>>> (i.e. where to build in log-messages, which of Tomcat's configuration
>>>>> options to check etc.).
>>>>>
>>>>> So suggestions are still more than welcome.
>>>>>
>>>>> Nillehammer
>>>>>
>>>>> 9902468 schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> Eventually we had to add these to appmodule:
>>>>>>
>>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>>
>>>>>> as instructed here:
>>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>>
>>>>>> This solved our problems, and you can go up as long as your server
>>>>>> has
>>>>>> memory. Our problems were only in production, as development stress
>>>>>> just
>>>>>> isn't enough. (This is why one really should do load testing with
>>>>>> jmeter
>>>>>> or
>>>>>> similar tool.)
>>>>>>
>>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>>> developer would hit these walls during development and understands to
>>>>>> load
>>>>>> test / tune the parameters.
>>>>>>
>>>>>>  - 99
>>>>>>
>>>>>>
>>>>>> nille hammer wrote:
>>>>>>> Hi list,
>>>>>>>
>>>>>>> I am also facing the problem that 9902468 had. I have -according to
>>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink
>>>>>>> to
>>>>>>> prevent targeted pages from being created unecessarily. The problem
>>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>>> browser
>>>>>>> I have to wait about two minutes before I get an empty page. In the
>>>>>>> app's log the following Exception appears:
>>>>>>>
>>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in
>>>>>>> locale
>>>>>>> de) has been exausted: there are 20 instances currently being used
>>>>>>> and
>>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>>> created, or increasing the soft wait (symbol
>>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>>>>>> efficient use of page instances.
>>>>>>>         at
>>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>>         at
>>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>>         at
>>>>>>> $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>>         at
>>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>>         at
>>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>>         at
>>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>>> ...
>>>>>>>
>>>>>>> In development and in production environment I use Java 6 and Tomcat
>>>>>>> 6.
>>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this
>>>>>>> in
>>>>>>> production environment.
>>>>>>>
>>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck
>>>>>>> with
>>>>>>> this.
>>>>>>>
>>>>>>> Thanks in advance, nillehammer
>>>>>>>
>>>>>>> Howard Lewis Ship wrote
>>>>>>>> Tapestry is obtaining page instances to see if there is an
>>>>>>>> activation
>>>>>>>> context for the page.
>>>>>>>>
>>>>>>>> I expect to optimize this in the future, to check to see if the
>>>>>>>> page
>>>>>>>> has an event handler for the passivate event.
>>>>>>>>
>>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>>> generates the link by invoking
>>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>>> tell
>>>>>>>> Tapestry to generate a link to the page with no activation context,
>>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>>> won't
>>>>>>>> need to be attached to the current request.
>>>>>>>>
>>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> we are experiencing strange hard pool limit reached exceptions.
>>>>>>>>> (For
>>>>>>>>> the
>>>>>>>>> user count that we have.) After debugging a little, it seems that
>>>>>>>>> our
>>>>>>>>> left
>>>>>>>>> menu component, which is full of page links, instantiates not only
>>>>>>>>> the
>>>>>>>>> page
>>>>>>>>> that we are at, but also the ones that are referenced in page
>>>>>>>>> link.
>>>>>>>>>
>>>>>>>>> This can be seen also in that exception page is shown, if one of
>>>>>>>>> the
>>>>>>>>> pages
>>>>>>>>> that are referenced in page links have an error.
>>>>>>>>>
>>>>>>>>> Is this correct behavior? And should we really use common a href=
>>>>>>>>> tags
>>>>>>>>> to
>>>>>>>>> avoid this? Further more, is it possible to create infinite loop,
>>>>>>>>> when
>>>>>>>>> page
>>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>>
>>>>>>>>>  - 99
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19570234.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: NPE when trying to contribute ServletContextSymbolProvider to SymbolSource (WAS: Re: Page pool hard limit and page instance usage)

Posted by Peter Stavrinides <P....@albourne.com>.
Just a wild guess, but it sounds like an 'order of things' type problem, Tapestry being a filter and not essentially a servlet, the context might not be available at that point. 

----- Original Message -----
From: "Ulrich Stärk" <ul...@spielviel.de>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Monday, 22 September, 2008 4:51:23 PM GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: NPE when trying to contribute ServletContextSymbolProvider to  SymbolSource (WAS: Re: Page pool hard limit and page instance usage)

The problem seems to be, that the ServletContext provided by
ApplicationGlobals is null when Tapestry tries to contribute the
ServletContextSymbolProvider to the SymbolSource service. I don't know why
this is the case. Maybe someone else can shed some light on this.

Uli

Am Mo, 22.09.2008, 08:08, schrieb 9902468:
>
> Hi again,
>
> I'm hitting my head to wall here with ServletContextSymbolProvider. It is
> configured like this:
>
> public static void
> contributeSymbolSource(OrderedConfiguration<SymbolProvider> configuration,
> @InjectService("ServletContextSymbolProvider") SymbolProvider
> servletContextSymbolProvider)
>     {
>         configuration.add("ServletContextSymbolProvider" ,
> servletContextSymbolProvider, "after:SystemProperties",
> "before:ApplicationDefaults");
>     }
>
>     public static ServletContextSymbolProvider
> buildServletContextSymbolProvider(ApplicationGlobals globals){
>         return new
> ServletContextSymbolProvider(globals.getServletContext());
>     }
>
> And it always ends to this error:
> java.lang.RuntimeException: Unable to instantiate class
> org.apache.tapestry5.services.TapestryModule as a module builder:
> Exception
> constructing service 'Alias': Error invoking service builder method
> org.apache.tapestry5.services.TapestryModule.buildAlias(Logger, String,
> AliasManager, Collection) (at TapestryModule.java:217) (for service
> 'Alias'): Exception constructing service 'SymbolSource': Error invoking
> constructor
> org.apache.tapestry5.ioc.internal.services.SymbolSourceImpl(List) (at
> SymbolSourceImpl.java:198) via
> org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder)
> (at
> TapestryIOCModule.java:38) (for service 'SymbolSource'): Error invoking
> service contribution method
> com.example.tapestry5.services.ExampleModule.contributeSymbolSource(OrderedConfiguration,
> SymbolProvider): Error building service proxy for service
> 'ServletContextSymbolProvider' (at
> com.example.tapestry5.services.ExampleModule.buildServletContextSymbolProvider(ApplicationGlobals)
> (at ExampleModule.java:215)): Error invoking service builder method
> com.example.tapestry5.services.ExampleModule.buildServletContextSymbolProvider(ApplicationGlobals)
> (at ExampleModule.java:215) (for service 'ServletContextSymbolProvider'):
> Exception constructing service 'Alias': Construction of service 'Alias'
> has
> failed due to recursion: the service depends on itself in some way. Please
> check org.apache.tapestry5.services.TapestryModule.buildAlias(Logger,
> String, AliasManager, Collection) (at TapestryModule.java:217) for
> references to another service that is itself dependent on service 'Alias'.
>
> I can't determine where the recursion is. Is the ApplicationGlobals
> initiating the construction of Alias service? If this is true then
> ApplicationGlobsals cannot be used while I'm constructing my alias
> overrides?
>
> Is there anyone out there who has this working?
>
>  - 99
>
>
> Ulrich Stärk wrote:
>>
>> You don't have to write your own ServletContextSymbolProvider, it
>> already
>> comes shipped with
>> Tapestry. See here
>> http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
>> You just have to configure it.
>>
>> Uli
>>
>> 9902468 schrieb:
>>> Yep, just read through your discussion:
>>>
>>> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
>>>
>>> and that would be the intelligent way of doing it :)
>>>
>>> I'll code symbol provider when I have time. Hopefully these providers
>>> can
>>> be
>>> included in T5 distribution, as these are highly reusable and add only
>>> little to none "weight" to the distribution.
>>>
>>>  - 99
>>>
>>>
>>> Ulrich Stärk wrote:
>>>> Why not instantiate a ServletContextSymbolProvider (the ServletContext
>>>> is
>>>> available from the
>>>> ApplicationGlobals service) and contribute it to the SymbolProvider
>>>> before
>>>> ApplicationDefaults and
>>>> FactoryDefaults. That way you can directly override
>>>> tapestry.page-pool.hard-limit and automatically
>>>> have all other init parameters as symbols, too.
>>>>
>>>> Uli
>>>>
>>>> 9902468 schrieb:
>>>>> I always keep nabble open when I'm at work :)
>>>>>
>>>>> These parameters can be transferred to web.xml, so that recompile is
>>>>> not
>>>>> needed when changing these parameters:
>>>>>
>>>>> public static void
>>>>> contributeApplicationDefaults(MappedConfiguration<String,
>>>>> String> configuration, ApplicationGlobals globals) {
>>>>>
>>>>>     configuration.add("tapestry.page-pool.hard-limit",
>>>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>>>
>>>>> }
>>>>>
>>>>> and in web.xml
>>>>>
>>>>> <web-app>
>>>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>>>     <context-param>
>>>>>         <!-- The only significant configuration for Tapestry 5, this
>>>>> informs
>>>>> Tapestry of where to look for pages, components and mixins. -->
>>>>>         <param-name>tapestry.app-package</param-name>
>>>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>>>     </context-param>
>>>>>     <context-param>
>>>>>         <param-name>page_hard_limit</param-name>
>>>>>         <param-value>60</param-value>
>>>>>     </context-param>
>>>>>
>>>>> This can be used through out every single service and page and
>>>>> component.
>>>>> To
>>>>> access this in a page or component use:
>>>>>
>>>>> @Property @Inject @Value("${page_hard_limit}")
>>>>> private String pageHardLimit;
>>>>>
>>>>> Injection can be used in service constructor also (I think) or by
>>>>> using
>>>>> buildSomeService method instead of the usual binder.bind
>>>>>
>>>>> Of course T5 makes it easy to read these from a file or database or
>>>>> from
>>>>> what not, but I have noticed that many admins accept editing web.xml
>>>>> and
>>>>> restarting the app ok.
>>>>>
>>>>> Hopefully this helps. (And makes it easier to say to admins that just
>>>>> configure the app according to the load they are experiencing.)
>>>>>
>>>>> -99
>>>>>
>>>>>
>>>>> nille hammer wrote:
>>>>>> Man that was a quick answer! Thanks for that. I am aware of this
>>>>>> options
>>>>>> in the configuration. I had not tuned them before, because load is
>>>>>> not
>>>>>> my problem. Anyway I have tuned them now and am currently waiting
>>>>>> for
>>>>>> the admistrator to deploy the newest war.
>>>>>>
>>>>>> According to acces-logs I was the only user accessing the page. So
>>>>>> as
>>>>>> far as I understand the mechanism only one instance of index should
>>>>>> have
>>>>>> been created and not 20. I think it is an issue with configuration
>>>>>> in
>>>>>> production environment. But I have no idea where to take a closer
>>>>>> look
>>>>>> (i.e. where to build in log-messages, which of Tomcat's
>>>>>> configuration
>>>>>> options to check etc.).
>>>>>>
>>>>>> So suggestions are still more than welcome.
>>>>>>
>>>>>> Nillehammer
>>>>>>
>>>>>> 9902468 schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Eventually we had to add these to appmodule:
>>>>>>>
>>>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>>>
>>>>>>> as instructed here:
>>>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>>>
>>>>>>> This solved our problems, and you can go up as long as your server
>>>>>>> has
>>>>>>> memory. Our problems were only in production, as development stress
>>>>>>> just
>>>>>>> isn't enough. (This is why one really should do load testing with
>>>>>>> jmeter
>>>>>>> or
>>>>>>> similar tool.)
>>>>>>>
>>>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>>>> developer would hit these walls during development and understands
>>>>>>> to
>>>>>>> load
>>>>>>> test / tune the parameters.
>>>>>>>
>>>>>>>  - 99
>>>>>>>
>>>>>>>
>>>>>>> nille hammer wrote:
>>>>>>>> Hi list,
>>>>>>>>
>>>>>>>> I am also facing the problem that 9902468 had. I have -according
>>>>>>>> to
>>>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink
>>>>>>>> to
>>>>>>>> prevent targeted pages from being created unecessarily. The
>>>>>>>> problem
>>>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>>>> browser
>>>>>>>> I have to wait about two minutes before I get an empty page. In
>>>>>>>> the
>>>>>>>> app's log the following Exception appears:
>>>>>>>>
>>>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in
>>>>>>>> locale
>>>>>>>> de) has been exausted: there are 20 instances currently being used
>>>>>>>> and
>>>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>>>> created, or increasing the soft wait (symbol
>>>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for
>>>>>>>> more
>>>>>>>> efficient use of page instances.
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>>>         at
>>>>>>>> $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>>>         at
>>>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>>>         at
>>>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>>>> ...
>>>>>>>>
>>>>>>>> In development and in production environment I use Java 6 and
>>>>>>>> Tomcat
>>>>>>>> 6.
>>>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing
>>>>>>>> this
>>>>>>>> in
>>>>>>>> production environment.
>>>>>>>>
>>>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck
>>>>>>>> with
>>>>>>>> this.
>>>>>>>>
>>>>>>>> Thanks in advance, nillehammer
>>>>>>>>
>>>>>>>> Howard Lewis Ship wrote
>>>>>>>>> Tapestry is obtaining page instances to see if there is an
>>>>>>>>> activation
>>>>>>>>> context for the page.
>>>>>>>>>
>>>>>>>>> I expect to optimize this in the future, to check to see if the
>>>>>>>>> page
>>>>>>>>> has an event handler for the passivate event.
>>>>>>>>>
>>>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>>>> generates the link by invoking
>>>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>>>> tell
>>>>>>>>> Tapestry to generate a link to the page with no activation
>>>>>>>>> context,
>>>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>>>> won't
>>>>>>>>> need to be attached to the current request.
>>>>>>>>>
>>>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468
>>>>>>>>> <vi...@cerion.fi>
>>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> we are experiencing strange hard pool limit reached exceptions.
>>>>>>>>>> (For
>>>>>>>>>> the
>>>>>>>>>> user count that we have.) After debugging a little, it seems
>>>>>>>>>> that
>>>>>>>>>> our
>>>>>>>>>> left
>>>>>>>>>> menu component, which is full of page links, instantiates not
>>>>>>>>>> only
>>>>>>>>>> the
>>>>>>>>>> page
>>>>>>>>>> that we are at, but also the ones that are referenced in page
>>>>>>>>>> link.
>>>>>>>>>>
>>>>>>>>>> This can be seen also in that exception page is shown, if one of
>>>>>>>>>> the
>>>>>>>>>> pages
>>>>>>>>>> that are referenced in page links have an error.
>>>>>>>>>>
>>>>>>>>>> Is this correct behavior? And should we really use common a
>>>>>>>>>> href=
>>>>>>>>>> tags
>>>>>>>>>> to
>>>>>>>>>> avoid this? Further more, is it possible to create infinite
>>>>>>>>>> loop,
>>>>>>>>>> when
>>>>>>>>>> page
>>>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>>>
>>>>>>>>>>  - 99
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>>>> Sent from the Tapestry - User mailing list archive at
>>>>>>>>>> Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19602371.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


NPE when trying to contribute ServletContextSymbolProvider to SymbolSource (WAS: Re: Page pool hard limit and page instance usage)

Posted by Ulrich Stärk <ul...@spielviel.de>.
The problem seems to be, that the ServletContext provided by
ApplicationGlobals is null when Tapestry tries to contribute the
ServletContextSymbolProvider to the SymbolSource service. I don't know why
this is the case. Maybe someone else can shed some light on this.

Uli

Am Mo, 22.09.2008, 08:08, schrieb 9902468:
>
> Hi again,
>
> I'm hitting my head to wall here with ServletContextSymbolProvider. It is
> configured like this:
>
> public static void
> contributeSymbolSource(OrderedConfiguration<SymbolProvider> configuration,
> @InjectService("ServletContextSymbolProvider") SymbolProvider
> servletContextSymbolProvider)
>     {
>         configuration.add("ServletContextSymbolProvider" ,
> servletContextSymbolProvider, "after:SystemProperties",
> "before:ApplicationDefaults");
>     }
>
>     public static ServletContextSymbolProvider
> buildServletContextSymbolProvider(ApplicationGlobals globals){
>         return new
> ServletContextSymbolProvider(globals.getServletContext());
>     }
>
> And it always ends to this error:
> java.lang.RuntimeException: Unable to instantiate class
> org.apache.tapestry5.services.TapestryModule as a module builder:
> Exception
> constructing service 'Alias': Error invoking service builder method
> org.apache.tapestry5.services.TapestryModule.buildAlias(Logger, String,
> AliasManager, Collection) (at TapestryModule.java:217) (for service
> 'Alias'): Exception constructing service 'SymbolSource': Error invoking
> constructor
> org.apache.tapestry5.ioc.internal.services.SymbolSourceImpl(List) (at
> SymbolSourceImpl.java:198) via
> org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder)
> (at
> TapestryIOCModule.java:38) (for service 'SymbolSource'): Error invoking
> service contribution method
> com.example.tapestry5.services.ExampleModule.contributeSymbolSource(OrderedConfiguration,
> SymbolProvider): Error building service proxy for service
> 'ServletContextSymbolProvider' (at
> com.example.tapestry5.services.ExampleModule.buildServletContextSymbolProvider(ApplicationGlobals)
> (at ExampleModule.java:215)): Error invoking service builder method
> com.example.tapestry5.services.ExampleModule.buildServletContextSymbolProvider(ApplicationGlobals)
> (at ExampleModule.java:215) (for service 'ServletContextSymbolProvider'):
> Exception constructing service 'Alias': Construction of service 'Alias'
> has
> failed due to recursion: the service depends on itself in some way. Please
> check org.apache.tapestry5.services.TapestryModule.buildAlias(Logger,
> String, AliasManager, Collection) (at TapestryModule.java:217) for
> references to another service that is itself dependent on service 'Alias'.
>
> I can't determine where the recursion is. Is the ApplicationGlobals
> initiating the construction of Alias service? If this is true then
> ApplicationGlobsals cannot be used while I'm constructing my alias
> overrides?
>
> Is there anyone out there who has this working?
>
>  - 99
>
>
> Ulrich Stärk wrote:
>>
>> You don't have to write your own ServletContextSymbolProvider, it
>> already
>> comes shipped with
>> Tapestry. See here
>> http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
>> You just have to configure it.
>>
>> Uli
>>
>> 9902468 schrieb:
>>> Yep, just read through your discussion:
>>>
>>> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
>>>
>>> and that would be the intelligent way of doing it :)
>>>
>>> I'll code symbol provider when I have time. Hopefully these providers
>>> can
>>> be
>>> included in T5 distribution, as these are highly reusable and add only
>>> little to none "weight" to the distribution.
>>>
>>>  - 99
>>>
>>>
>>> Ulrich Stärk wrote:
>>>> Why not instantiate a ServletContextSymbolProvider (the ServletContext
>>>> is
>>>> available from the
>>>> ApplicationGlobals service) and contribute it to the SymbolProvider
>>>> before
>>>> ApplicationDefaults and
>>>> FactoryDefaults. That way you can directly override
>>>> tapestry.page-pool.hard-limit and automatically
>>>> have all other init parameters as symbols, too.
>>>>
>>>> Uli
>>>>
>>>> 9902468 schrieb:
>>>>> I always keep nabble open when I'm at work :)
>>>>>
>>>>> These parameters can be transferred to web.xml, so that recompile is
>>>>> not
>>>>> needed when changing these parameters:
>>>>>
>>>>> public static void
>>>>> contributeApplicationDefaults(MappedConfiguration<String,
>>>>> String> configuration, ApplicationGlobals globals) {
>>>>>
>>>>>     configuration.add("tapestry.page-pool.hard-limit",
>>>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>>>
>>>>> }
>>>>>
>>>>> and in web.xml
>>>>>
>>>>> <web-app>
>>>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>>>     <context-param>
>>>>>         <!-- The only significant configuration for Tapestry 5, this
>>>>> informs
>>>>> Tapestry of where to look for pages, components and mixins. -->
>>>>>         <param-name>tapestry.app-package</param-name>
>>>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>>>     </context-param>
>>>>>     <context-param>
>>>>>         <param-name>page_hard_limit</param-name>
>>>>>         <param-value>60</param-value>
>>>>>     </context-param>
>>>>>
>>>>> This can be used through out every single service and page and
>>>>> component.
>>>>> To
>>>>> access this in a page or component use:
>>>>>
>>>>> @Property @Inject @Value("${page_hard_limit}")
>>>>> private String pageHardLimit;
>>>>>
>>>>> Injection can be used in service constructor also (I think) or by
>>>>> using
>>>>> buildSomeService method instead of the usual binder.bind
>>>>>
>>>>> Of course T5 makes it easy to read these from a file or database or
>>>>> from
>>>>> what not, but I have noticed that many admins accept editing web.xml
>>>>> and
>>>>> restarting the app ok.
>>>>>
>>>>> Hopefully this helps. (And makes it easier to say to admins that just
>>>>> configure the app according to the load they are experiencing.)
>>>>>
>>>>> -99
>>>>>
>>>>>
>>>>> nille hammer wrote:
>>>>>> Man that was a quick answer! Thanks for that. I am aware of this
>>>>>> options
>>>>>> in the configuration. I had not tuned them before, because load is
>>>>>> not
>>>>>> my problem. Anyway I have tuned them now and am currently waiting
>>>>>> for
>>>>>> the admistrator to deploy the newest war.
>>>>>>
>>>>>> According to acces-logs I was the only user accessing the page. So
>>>>>> as
>>>>>> far as I understand the mechanism only one instance of index should
>>>>>> have
>>>>>> been created and not 20. I think it is an issue with configuration
>>>>>> in
>>>>>> production environment. But I have no idea where to take a closer
>>>>>> look
>>>>>> (i.e. where to build in log-messages, which of Tomcat's
>>>>>> configuration
>>>>>> options to check etc.).
>>>>>>
>>>>>> So suggestions are still more than welcome.
>>>>>>
>>>>>> Nillehammer
>>>>>>
>>>>>> 9902468 schrieb:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Eventually we had to add these to appmodule:
>>>>>>>
>>>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>>>
>>>>>>> as instructed here:
>>>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>>>
>>>>>>> This solved our problems, and you can go up as long as your server
>>>>>>> has
>>>>>>> memory. Our problems were only in production, as development stress
>>>>>>> just
>>>>>>> isn't enough. (This is why one really should do load testing with
>>>>>>> jmeter
>>>>>>> or
>>>>>>> similar tool.)
>>>>>>>
>>>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>>>> developer would hit these walls during development and understands
>>>>>>> to
>>>>>>> load
>>>>>>> test / tune the parameters.
>>>>>>>
>>>>>>>  - 99
>>>>>>>
>>>>>>>
>>>>>>> nille hammer wrote:
>>>>>>>> Hi list,
>>>>>>>>
>>>>>>>> I am also facing the problem that 9902468 had. I have -according
>>>>>>>> to
>>>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink
>>>>>>>> to
>>>>>>>> prevent targeted pages from being created unecessarily. The
>>>>>>>> problem
>>>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>>>> browser
>>>>>>>> I have to wait about two minutes before I get an empty page. In
>>>>>>>> the
>>>>>>>> app's log the following Exception appears:
>>>>>>>>
>>>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in
>>>>>>>> locale
>>>>>>>> de) has been exausted: there are 20 instances currently being used
>>>>>>>> and
>>>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>>>> created, or increasing the soft wait (symbol
>>>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for
>>>>>>>> more
>>>>>>>> efficient use of page instances.
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>>>         at
>>>>>>>> $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>>>         at
>>>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>>>         at
>>>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>>>         at
>>>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>>>> ...
>>>>>>>>
>>>>>>>> In development and in production environment I use Java 6 and
>>>>>>>> Tomcat
>>>>>>>> 6.
>>>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing
>>>>>>>> this
>>>>>>>> in
>>>>>>>> production environment.
>>>>>>>>
>>>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck
>>>>>>>> with
>>>>>>>> this.
>>>>>>>>
>>>>>>>> Thanks in advance, nillehammer
>>>>>>>>
>>>>>>>> Howard Lewis Ship wrote
>>>>>>>>> Tapestry is obtaining page instances to see if there is an
>>>>>>>>> activation
>>>>>>>>> context for the page.
>>>>>>>>>
>>>>>>>>> I expect to optimize this in the future, to check to see if the
>>>>>>>>> page
>>>>>>>>> has an event handler for the passivate event.
>>>>>>>>>
>>>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>>>> generates the link by invoking
>>>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>>>> tell
>>>>>>>>> Tapestry to generate a link to the page with no activation
>>>>>>>>> context,
>>>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>>>> won't
>>>>>>>>> need to be attached to the current request.
>>>>>>>>>
>>>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468
>>>>>>>>> <vi...@cerion.fi>
>>>>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> we are experiencing strange hard pool limit reached exceptions.
>>>>>>>>>> (For
>>>>>>>>>> the
>>>>>>>>>> user count that we have.) After debugging a little, it seems
>>>>>>>>>> that
>>>>>>>>>> our
>>>>>>>>>> left
>>>>>>>>>> menu component, which is full of page links, instantiates not
>>>>>>>>>> only
>>>>>>>>>> the
>>>>>>>>>> page
>>>>>>>>>> that we are at, but also the ones that are referenced in page
>>>>>>>>>> link.
>>>>>>>>>>
>>>>>>>>>> This can be seen also in that exception page is shown, if one of
>>>>>>>>>> the
>>>>>>>>>> pages
>>>>>>>>>> that are referenced in page links have an error.
>>>>>>>>>>
>>>>>>>>>> Is this correct behavior? And should we really use common a
>>>>>>>>>> href=
>>>>>>>>>> tags
>>>>>>>>>> to
>>>>>>>>>> avoid this? Further more, is it possible to create infinite
>>>>>>>>>> loop,
>>>>>>>>>> when
>>>>>>>>>> page
>>>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>>>
>>>>>>>>>>  - 99
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>>>> Sent from the Tapestry - User mailing list archive at
>>>>>>>>>> Nabble.com.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19602371.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by 9902468 <vi...@cerion.fi>.
Hi again,

I'm hitting my head to wall here with ServletContextSymbolProvider. It is
configured like this:

public static void
contributeSymbolSource(OrderedConfiguration<SymbolProvider> configuration,
@InjectService("ServletContextSymbolProvider") SymbolProvider
servletContextSymbolProvider)
    {
        configuration.add("ServletContextSymbolProvider" ,
servletContextSymbolProvider, "after:SystemProperties",
"before:ApplicationDefaults");
    }
    
    public static ServletContextSymbolProvider
buildServletContextSymbolProvider(ApplicationGlobals globals){
        return new
ServletContextSymbolProvider(globals.getServletContext());
    }

And it always ends to this error:
java.lang.RuntimeException: Unable to instantiate class
org.apache.tapestry5.services.TapestryModule as a module builder: Exception
constructing service 'Alias': Error invoking service builder method
org.apache.tapestry5.services.TapestryModule.buildAlias(Logger, String,
AliasManager, Collection) (at TapestryModule.java:217) (for service
'Alias'): Exception constructing service 'SymbolSource': Error invoking
constructor
org.apache.tapestry5.ioc.internal.services.SymbolSourceImpl(List) (at
SymbolSourceImpl.java:198) via
org.apache.tapestry5.ioc.services.TapestryIOCModule.bind(ServiceBinder) (at
TapestryIOCModule.java:38) (for service 'SymbolSource'): Error invoking
service contribution method
com.example.tapestry5.services.ExampleModule.contributeSymbolSource(OrderedConfiguration,
SymbolProvider): Error building service proxy for service
'ServletContextSymbolProvider' (at
com.example.tapestry5.services.ExampleModule.buildServletContextSymbolProvider(ApplicationGlobals)
(at ExampleModule.java:215)): Error invoking service builder method
com.example.tapestry5.services.ExampleModule.buildServletContextSymbolProvider(ApplicationGlobals)
(at ExampleModule.java:215) (for service 'ServletContextSymbolProvider'):
Exception constructing service 'Alias': Construction of service 'Alias' has
failed due to recursion: the service depends on itself in some way. Please
check org.apache.tapestry5.services.TapestryModule.buildAlias(Logger,
String, AliasManager, Collection) (at TapestryModule.java:217) for
references to another service that is itself dependent on service 'Alias'.

I can't determine where the recursion is. Is the ApplicationGlobals
initiating the construction of Alias service? If this is true then
ApplicationGlobsals cannot be used while I'm constructing my alias
overrides?

Is there anyone out there who has this working?

 - 99


Ulrich Stärk wrote:
> 
> You don't have to write your own ServletContextSymbolProvider, it already
> comes shipped with 
> Tapestry. See here 
> http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
> You just have to configure it.
> 
> Uli
> 
> 9902468 schrieb:
>> Yep, just read through your discussion:
>> 
>> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
>> 
>> and that would be the intelligent way of doing it :)
>> 
>> I'll code symbol provider when I have time. Hopefully these providers can
>> be
>> included in T5 distribution, as these are highly reusable and add only
>> little to none "weight" to the distribution.
>> 
>>  - 99
>> 
>> 
>> Ulrich Stärk wrote:
>>> Why not instantiate a ServletContextSymbolProvider (the ServletContext
>>> is
>>> available from the 
>>> ApplicationGlobals service) and contribute it to the SymbolProvider
>>> before
>>> ApplicationDefaults and 
>>> FactoryDefaults. That way you can directly override
>>> tapestry.page-pool.hard-limit and automatically 
>>> have all other init parameters as symbols, too.
>>>
>>> Uli
>>>
>>> 9902468 schrieb:
>>>> I always keep nabble open when I'm at work :)
>>>>
>>>> These parameters can be transferred to web.xml, so that recompile is
>>>> not
>>>> needed when changing these parameters:
>>>>
>>>> public static void
>>>> contributeApplicationDefaults(MappedConfiguration<String,
>>>> String> configuration, ApplicationGlobals globals) {
>>>>
>>>>     configuration.add("tapestry.page-pool.hard-limit",
>>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>>
>>>> }
>>>>
>>>> and in web.xml
>>>>
>>>> <web-app>
>>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>>     <context-param>
>>>>         <!-- The only significant configuration for Tapestry 5, this
>>>> informs
>>>> Tapestry of where to look for pages, components and mixins. -->
>>>>         <param-name>tapestry.app-package</param-name>
>>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>>     </context-param>
>>>>     <context-param>
>>>>         <param-name>page_hard_limit</param-name>
>>>>         <param-value>60</param-value>
>>>>     </context-param>
>>>>
>>>> This can be used through out every single service and page and
>>>> component.
>>>> To
>>>> access this in a page or component use:
>>>>
>>>> @Property @Inject @Value("${page_hard_limit}")
>>>> private String pageHardLimit;
>>>>
>>>> Injection can be used in service constructor also (I think) or by using
>>>> buildSomeService method instead of the usual binder.bind
>>>>
>>>> Of course T5 makes it easy to read these from a file or database or
>>>> from
>>>> what not, but I have noticed that many admins accept editing web.xml
>>>> and
>>>> restarting the app ok.
>>>>
>>>> Hopefully this helps. (And makes it easier to say to admins that just
>>>> configure the app according to the load they are experiencing.)
>>>>
>>>> -99
>>>>
>>>>
>>>> nille hammer wrote:
>>>>> Man that was a quick answer! Thanks for that. I am aware of this
>>>>> options
>>>>> in the configuration. I had not tuned them before, because load is not
>>>>> my problem. Anyway I have tuned them now and am currently waiting for
>>>>> the admistrator to deploy the newest war.
>>>>>
>>>>> According to acces-logs I was the only user accessing the page. So as
>>>>> far as I understand the mechanism only one instance of index should
>>>>> have
>>>>> been created and not 20. I think it is an issue with configuration in
>>>>> production environment. But I have no idea where to take a closer look
>>>>> (i.e. where to build in log-messages, which of Tomcat's configuration
>>>>> options to check etc.).
>>>>>
>>>>> So suggestions are still more than welcome.
>>>>>
>>>>> Nillehammer
>>>>>
>>>>> 9902468 schrieb:
>>>>>> Hi,
>>>>>>
>>>>>> Eventually we had to add these to appmodule:
>>>>>>
>>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>>
>>>>>> as instructed here:
>>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>>
>>>>>> This solved our problems, and you can go up as long as your server
>>>>>> has
>>>>>> memory. Our problems were only in production, as development stress
>>>>>> just
>>>>>> isn't enough. (This is why one really should do load testing with
>>>>>> jmeter
>>>>>> or
>>>>>> similar tool.)
>>>>>>
>>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>>> developer would hit these walls during development and understands to
>>>>>> load
>>>>>> test / tune the parameters.
>>>>>>
>>>>>>  - 99
>>>>>>
>>>>>>
>>>>>> nille hammer wrote:
>>>>>>> Hi list,
>>>>>>>
>>>>>>> I am also facing the problem that 9902468 had. I have -according to
>>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink
>>>>>>> to
>>>>>>> prevent targeted pages from being created unecessarily. The problem
>>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>>> browser
>>>>>>> I have to wait about two minutes before I get an empty page. In the
>>>>>>> app's log the following Exception appears:
>>>>>>>
>>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in
>>>>>>> locale
>>>>>>> de) has been exausted: there are 20 instances currently being used
>>>>>>> and
>>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>>> created, or increasing the soft wait (symbol
>>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>>>>>> efficient use of page instances.
>>>>>>>         at
>>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>>         at
>>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>>         at
>>>>>>> $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>>         at
>>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>>         at
>>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>>         at
>>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>>> ...
>>>>>>>
>>>>>>> In development and in production environment I use Java 6 and Tomcat
>>>>>>> 6.
>>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this
>>>>>>> in
>>>>>>> production environment.
>>>>>>>
>>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck
>>>>>>> with
>>>>>>> this.
>>>>>>>
>>>>>>> Thanks in advance, nillehammer
>>>>>>>
>>>>>>> Howard Lewis Ship wrote
>>>>>>>> Tapestry is obtaining page instances to see if there is an
>>>>>>>> activation
>>>>>>>> context for the page.
>>>>>>>>
>>>>>>>> I expect to optimize this in the future, to check to see if the
>>>>>>>> page
>>>>>>>> has an event handler for the passivate event.
>>>>>>>>
>>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>>> generates the link by invoking
>>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>>> tell
>>>>>>>> Tapestry to generate a link to the page with no activation context,
>>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>>> won't
>>>>>>>> need to be attached to the current request.
>>>>>>>>
>>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>>>>>> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> we are experiencing strange hard pool limit reached exceptions.
>>>>>>>>> (For
>>>>>>>>> the
>>>>>>>>> user count that we have.) After debugging a little, it seems that
>>>>>>>>> our
>>>>>>>>> left
>>>>>>>>> menu component, which is full of page links, instantiates not only
>>>>>>>>> the
>>>>>>>>> page
>>>>>>>>> that we are at, but also the ones that are referenced in page
>>>>>>>>> link.
>>>>>>>>>
>>>>>>>>> This can be seen also in that exception page is shown, if one of
>>>>>>>>> the
>>>>>>>>> pages
>>>>>>>>> that are referenced in page links have an error.
>>>>>>>>>
>>>>>>>>> Is this correct behavior? And should we really use common a href=
>>>>>>>>> tags
>>>>>>>>> to
>>>>>>>>> avoid this? Further more, is it possible to create infinite loop,
>>>>>>>>> when
>>>>>>>>> page
>>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>>
>>>>>>>>>  - 99
>>>>>>>>> --
>>>>>>>>> View this message in context:
>>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19602371.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by Ulrich Stärk <ul...@spielviel.de>.
You don't have to write your own ServletContextSymbolProvider, it already comes shipped with 
Tapestry. See here 
http://tapestry.apache.org/tapestry5/apidocs/index.html?org/apache/tapestry5/ioc/services/SymbolProvider.html
You just have to configure it.

Uli

9902468 schrieb:
> Yep, just read through your discussion:
> 
> http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302
> 
> and that would be the intelligent way of doing it :)
> 
> I'll code symbol provider when I have time. Hopefully these providers can be
> included in T5 distribution, as these are highly reusable and add only
> little to none "weight" to the distribution.
> 
>  - 99
> 
> 
> Ulrich Stärk wrote:
>> Why not instantiate a ServletContextSymbolProvider (the ServletContext is
>> available from the 
>> ApplicationGlobals service) and contribute it to the SymbolProvider before
>> ApplicationDefaults and 
>> FactoryDefaults. That way you can directly override
>> tapestry.page-pool.hard-limit and automatically 
>> have all other init parameters as symbols, too.
>>
>> Uli
>>
>> 9902468 schrieb:
>>> I always keep nabble open when I'm at work :)
>>>
>>> These parameters can be transferred to web.xml, so that recompile is not
>>> needed when changing these parameters:
>>>
>>> public static void
>>> contributeApplicationDefaults(MappedConfiguration<String,
>>> String> configuration, ApplicationGlobals globals) {
>>>
>>>     configuration.add("tapestry.page-pool.hard-limit",
>>> globals.getServletContext().getInitParameter("page_hard_limit"));
>>>
>>> }
>>>
>>> and in web.xml
>>>
>>> <web-app>
>>>     <display-name>Some Tapestry 5 Application</display-name>
>>>     <context-param>
>>>         <!-- The only significant configuration for Tapestry 5, this
>>> informs
>>> Tapestry of where to look for pages, components and mixins. -->
>>>         <param-name>tapestry.app-package</param-name>
>>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>>     </context-param>
>>>     <context-param>
>>>         <param-name>page_hard_limit</param-name>
>>>         <param-value>60</param-value>
>>>     </context-param>
>>>
>>> This can be used through out every single service and page and component.
>>> To
>>> access this in a page or component use:
>>>
>>> @Property @Inject @Value("${page_hard_limit}")
>>> private String pageHardLimit;
>>>
>>> Injection can be used in service constructor also (I think) or by using
>>> buildSomeService method instead of the usual binder.bind
>>>
>>> Of course T5 makes it easy to read these from a file or database or from
>>> what not, but I have noticed that many admins accept editing web.xml and
>>> restarting the app ok.
>>>
>>> Hopefully this helps. (And makes it easier to say to admins that just
>>> configure the app according to the load they are experiencing.)
>>>
>>> -99
>>>
>>>
>>> nille hammer wrote:
>>>> Man that was a quick answer! Thanks for that. I am aware of this options
>>>> in the configuration. I had not tuned them before, because load is not
>>>> my problem. Anyway I have tuned them now and am currently waiting for
>>>> the admistrator to deploy the newest war.
>>>>
>>>> According to acces-logs I was the only user accessing the page. So as
>>>> far as I understand the mechanism only one instance of index should have
>>>> been created and not 20. I think it is an issue with configuration in
>>>> production environment. But I have no idea where to take a closer look
>>>> (i.e. where to build in log-messages, which of Tomcat's configuration
>>>> options to check etc.).
>>>>
>>>> So suggestions are still more than welcome.
>>>>
>>>> Nillehammer
>>>>
>>>> 9902468 schrieb:
>>>>> Hi,
>>>>>
>>>>> Eventually we had to add these to appmodule:
>>>>>
>>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>>
>>>>> as instructed here:
>>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>>
>>>>> This solved our problems, and you can go up as long as your server has
>>>>> memory. Our problems were only in production, as development stress
>>>>> just
>>>>> isn't enough. (This is why one really should do load testing with
>>>>> jmeter
>>>>> or
>>>>> similar tool.)
>>>>>
>>>>> The defaults could be a bit more? Or considerably less, so that the
>>>>> developer would hit these walls during development and understands to
>>>>> load
>>>>> test / tune the parameters.
>>>>>
>>>>>  - 99
>>>>>
>>>>>
>>>>> nille hammer wrote:
>>>>>> Hi list,
>>>>>>
>>>>>> I am also facing the problem that 9902468 had. I have -according to
>>>>>> Howard's suggestion- replaced every pageLink with a customPageLink to
>>>>>> prevent targeted pages from being created unecessarily. The problem
>>>>>> persists. Trying to load the index-Page of my application with a
>>>>>> browser
>>>>>> I have to wait about two minutes before I get an empty page. In the
>>>>>> app's log the following Exception appears:
>>>>>>
>>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in locale
>>>>>> de) has been exausted: there are 20 instances currently being used and
>>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>>> created, or increasing the soft wait (symbol
>>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>>>>> efficient use of page instances.
>>>>>>         at
>>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>>         at
>>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>>         at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>>         at
>>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>>         at
>>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>>         at
>>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>>> ...
>>>>>>
>>>>>> In development and in production environment I use Java 6 and Tomcat
>>>>>> 6.
>>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this in
>>>>>> production environment.
>>>>>>
>>>>>> Has anyone a suggestion how to track this down? I am pretty stuck with
>>>>>> this.
>>>>>>
>>>>>> Thanks in advance, nillehammer
>>>>>>
>>>>>> Howard Lewis Ship wrote
>>>>>>> Tapestry is obtaining page instances to see if there is an activation
>>>>>>> context for the page.
>>>>>>>
>>>>>>> I expect to optimize this in the future, to check to see if the page
>>>>>>> has an event handler for the passivate event.
>>>>>>>
>>>>>>> In the meantime, you could build your own PageLink component that
>>>>>>> generates the link by invoking
>>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>>> tell
>>>>>>> Tapestry to generate a link to the page with no activation context,
>>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>>> won't
>>>>>>> need to be attached to the current request.
>>>>>>>
>>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>>>>> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> we are experiencing strange hard pool limit reached exceptions. (For
>>>>>>>> the
>>>>>>>> user count that we have.) After debugging a little, it seems that
>>>>>>>> our
>>>>>>>> left
>>>>>>>> menu component, which is full of page links, instantiates not only
>>>>>>>> the
>>>>>>>> page
>>>>>>>> that we are at, but also the ones that are referenced in page link.
>>>>>>>>
>>>>>>>> This can be seen also in that exception page is shown, if one of the
>>>>>>>> pages
>>>>>>>> that are referenced in page links have an error.
>>>>>>>>
>>>>>>>> Is this correct behavior? And should we really use common a href=
>>>>>>>> tags
>>>>>>>> to
>>>>>>>> avoid this? Further more, is it possible to create infinite loop,
>>>>>>>> when
>>>>>>>> page
>>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>>
>>>>>>>>  - 99
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>>
>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by 9902468 <vi...@cerion.fi>.
Yep, just read through your discussion:

http://www.nabble.com/forum/ViewPost.jtp?post=19547763&framed=y&skin=302

and that would be the intelligent way of doing it :)

I'll code symbol provider when I have time. Hopefully these providers can be
included in T5 distribution, as these are highly reusable and add only
little to none "weight" to the distribution.

 - 99


Ulrich Stärk wrote:
> 
> Why not instantiate a ServletContextSymbolProvider (the ServletContext is
> available from the 
> ApplicationGlobals service) and contribute it to the SymbolProvider before
> ApplicationDefaults and 
> FactoryDefaults. That way you can directly override
> tapestry.page-pool.hard-limit and automatically 
> have all other init parameters as symbols, too.
> 
> Uli
> 
> 9902468 schrieb:
>> I always keep nabble open when I'm at work :)
>> 
>> These parameters can be transferred to web.xml, so that recompile is not
>> needed when changing these parameters:
>> 
>> public static void
>> contributeApplicationDefaults(MappedConfiguration<String,
>> String> configuration, ApplicationGlobals globals) {
>> 
>>     configuration.add("tapestry.page-pool.hard-limit",
>> globals.getServletContext().getInitParameter("page_hard_limit"));
>> 
>> }
>> 
>> and in web.xml
>> 
>> <web-app>
>>     <display-name>Some Tapestry 5 Application</display-name>
>>     <context-param>
>>         <!-- The only significant configuration for Tapestry 5, this
>> informs
>> Tapestry of where to look for pages, components and mixins. -->
>>         <param-name>tapestry.app-package</param-name>
>>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>>     </context-param>
>>     <context-param>
>>         <param-name>page_hard_limit</param-name>
>>         <param-value>60</param-value>
>>     </context-param>
>> 
>> This can be used through out every single service and page and component.
>> To
>> access this in a page or component use:
>> 
>> @Property @Inject @Value("${page_hard_limit}")
>> private String pageHardLimit;
>> 
>> Injection can be used in service constructor also (I think) or by using
>> buildSomeService method instead of the usual binder.bind
>> 
>> Of course T5 makes it easy to read these from a file or database or from
>> what not, but I have noticed that many admins accept editing web.xml and
>> restarting the app ok.
>> 
>> Hopefully this helps. (And makes it easier to say to admins that just
>> configure the app according to the load they are experiencing.)
>> 
>> -99
>> 
>> 
>> nille hammer wrote:
>>> Man that was a quick answer! Thanks for that. I am aware of this options
>>> in the configuration. I had not tuned them before, because load is not
>>> my problem. Anyway I have tuned them now and am currently waiting for
>>> the admistrator to deploy the newest war.
>>>
>>> According to acces-logs I was the only user accessing the page. So as
>>> far as I understand the mechanism only one instance of index should have
>>> been created and not 20. I think it is an issue with configuration in
>>> production environment. But I have no idea where to take a closer look
>>> (i.e. where to build in log-messages, which of Tomcat's configuration
>>> options to check etc.).
>>>
>>> So suggestions are still more than welcome.
>>>
>>> Nillehammer
>>>
>>> 9902468 schrieb:
>>>> Hi,
>>>>
>>>> Eventually we had to add these to appmodule:
>>>>
>>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>>
>>>> as instructed here:
>>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>>
>>>> This solved our problems, and you can go up as long as your server has
>>>> memory. Our problems were only in production, as development stress
>>>> just
>>>> isn't enough. (This is why one really should do load testing with
>>>> jmeter
>>>> or
>>>> similar tool.)
>>>>
>>>> The defaults could be a bit more? Or considerably less, so that the
>>>> developer would hit these walls during development and understands to
>>>> load
>>>> test / tune the parameters.
>>>>
>>>>  - 99
>>>>
>>>>
>>>> nille hammer wrote:
>>>>> Hi list,
>>>>>
>>>>> I am also facing the problem that 9902468 had. I have -according to
>>>>> Howard's suggestion- replaced every pageLink with a customPageLink to
>>>>> prevent targeted pages from being created unecessarily. The problem
>>>>> persists. Trying to load the index-Page of my application with a
>>>>> browser
>>>>> I have to wait about two minutes before I get an empty page. In the
>>>>> app's log the following Exception appears:
>>>>>
>>>>> java.lang.RuntimeException: The page pool for page 'Index' (in locale
>>>>> de) has been exausted: there are 20 instances currently being used and
>>>>> no more can be created. Try increasing the hard limit (symbol
>>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>>> created, or increasing the soft wait (symbol
>>>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>>>> efficient use of page instances.
>>>>>         at
>>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>>         at
>>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>>         at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>>         at
>>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>>         at
>>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>>         at
>>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>>> ...
>>>>>
>>>>> In development and in production environment I use Java 6 and Tomcat
>>>>> 6.
>>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this in
>>>>> production environment.
>>>>>
>>>>> Has anyone a suggestion how to track this down? I am pretty stuck with
>>>>> this.
>>>>>
>>>>> Thanks in advance, nillehammer
>>>>>
>>>>> Howard Lewis Ship wrote
>>>>>> Tapestry is obtaining page instances to see if there is an activation
>>>>>> context for the page.
>>>>>>
>>>>>> I expect to optimize this in the future, to check to see if the page
>>>>>> has an event handler for the passivate event.
>>>>>>
>>>>>> In the meantime, you could build your own PageLink component that
>>>>>> generates the link by invoking
>>>>>> ComponentResources.createPageLink("pagename", true) ... that will
>>>>>> tell
>>>>>> Tapestry to generate a link to the page with no activation context,
>>>>>> and the page will NOT be queried for its context, and therefore,
>>>>>> won't
>>>>>> need to be attached to the current request.
>>>>>>
>>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>>>> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> we are experiencing strange hard pool limit reached exceptions. (For
>>>>>>> the
>>>>>>> user count that we have.) After debugging a little, it seems that
>>>>>>> our
>>>>>>> left
>>>>>>> menu component, which is full of page links, instantiates not only
>>>>>>> the
>>>>>>> page
>>>>>>> that we are at, but also the ones that are referenced in page link.
>>>>>>>
>>>>>>> This can be seen also in that exception page is shown, if one of the
>>>>>>> pages
>>>>>>> that are referenced in page links have an error.
>>>>>>>
>>>>>>> Is this correct behavior? And should we really use common a href=
>>>>>>> tags
>>>>>>> to
>>>>>>> avoid this? Further more, is it possible to create infinite loop,
>>>>>>> when
>>>>>>> page
>>>>>>> a has page link to page b, which has page link to page a?
>>>>>>>
>>>>>>>  - 99
>>>>>>> --
>>>>>>> View this message in context:
>>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>>
>>>>>>>
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19570022.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by Ulrich Stärk <ul...@spielviel.de>.
Why not instantiate a ServletContextSymbolProvider (the ServletContext is available from the 
ApplicationGlobals service) and contribute it to the SymbolProvider before ApplicationDefaults and 
FactoryDefaults. That way you can directly override tapestry.page-pool.hard-limit and automatically 
have all other init parameters as symbols, too.

Uli

9902468 schrieb:
> I always keep nabble open when I'm at work :)
> 
> These parameters can be transferred to web.xml, so that recompile is not
> needed when changing these parameters:
> 
> public static void contributeApplicationDefaults(MappedConfiguration<String,
> String> configuration, ApplicationGlobals globals) {
> 
>     configuration.add("tapestry.page-pool.hard-limit",
> globals.getServletContext().getInitParameter("page_hard_limit"));
> 
> }
> 
> and in web.xml
> 
> <web-app>
>     <display-name>Some Tapestry 5 Application</display-name>
>     <context-param>
>         <!-- The only significant configuration for Tapestry 5, this informs
> Tapestry of where to look for pages, components and mixins. -->
>         <param-name>tapestry.app-package</param-name>
>         <param-value>fi.hanken.resbuilder.tapestry5</param-value>
>     </context-param>
>     <context-param>
>         <param-name>page_hard_limit</param-name>
>         <param-value>60</param-value>
>     </context-param>
> 
> This can be used through out every single service and page and component. To
> access this in a page or component use:
> 
> @Property @Inject @Value("${page_hard_limit}")
> private String pageHardLimit;
> 
> Injection can be used in service constructor also (I think) or by using
> buildSomeService method instead of the usual binder.bind
> 
> Of course T5 makes it easy to read these from a file or database or from
> what not, but I have noticed that many admins accept editing web.xml and
> restarting the app ok.
> 
> Hopefully this helps. (And makes it easier to say to admins that just
> configure the app according to the load they are experiencing.)
> 
> -99
> 
> 
> nille hammer wrote:
>> Man that was a quick answer! Thanks for that. I am aware of this options
>> in the configuration. I had not tuned them before, because load is not
>> my problem. Anyway I have tuned them now and am currently waiting for
>> the admistrator to deploy the newest war.
>>
>> According to acces-logs I was the only user accessing the page. So as
>> far as I understand the mechanism only one instance of index should have
>> been created and not 20. I think it is an issue with configuration in
>> production environment. But I have no idea where to take a closer look
>> (i.e. where to build in log-messages, which of Tomcat's configuration
>> options to check etc.).
>>
>> So suggestions are still more than welcome.
>>
>> Nillehammer
>>
>> 9902468 schrieb:
>>> Hi,
>>>
>>> Eventually we had to add these to appmodule:
>>>
>>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>>>
>>> as instructed here:
>>> http://tapestry.apache.org/tapestry5/guide/conf.html
>>>
>>> This solved our problems, and you can go up as long as your server has
>>> memory. Our problems were only in production, as development stress just
>>> isn't enough. (This is why one really should do load testing with jmeter
>>> or
>>> similar tool.)
>>>
>>> The defaults could be a bit more? Or considerably less, so that the
>>> developer would hit these walls during development and understands to
>>> load
>>> test / tune the parameters.
>>>
>>>  - 99
>>>
>>>
>>> nille hammer wrote:
>>>> Hi list,
>>>>
>>>> I am also facing the problem that 9902468 had. I have -according to
>>>> Howard's suggestion- replaced every pageLink with a customPageLink to
>>>> prevent targeted pages from being created unecessarily. The problem
>>>> persists. Trying to load the index-Page of my application with a browser
>>>> I have to wait about two minutes before I get an empty page. In the
>>>> app's log the following Exception appears:
>>>>
>>>> java.lang.RuntimeException: The page pool for page 'Index' (in locale
>>>> de) has been exausted: there are 20 instances currently being used and
>>>> no more can be created. Try increasing the hard limit (symbol
>>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>>> created, or increasing the soft wait (symbol
>>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>>> efficient use of page instances.
>>>>         at
>>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>>         at
>>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>>         at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>>         at
>>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>>         at
>>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>>         at
>>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>>> ...
>>>>
>>>> In development and in production environment I use Java 6 and Tomcat 6.
>>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this in
>>>> production environment.
>>>>
>>>> Has anyone a suggestion how to track this down? I am pretty stuck with
>>>> this.
>>>>
>>>> Thanks in advance, nillehammer
>>>>
>>>> Howard Lewis Ship wrote
>>>>> Tapestry is obtaining page instances to see if there is an activation
>>>>> context for the page.
>>>>>
>>>>> I expect to optimize this in the future, to check to see if the page
>>>>> has an event handler for the passivate event.
>>>>>
>>>>> In the meantime, you could build your own PageLink component that
>>>>> generates the link by invoking
>>>>> ComponentResources.createPageLink("pagename", true) ... that will tell
>>>>> Tapestry to generate a link to the page with no activation context,
>>>>> and the page will NOT be queried for its context, and therefore, won't
>>>>> need to be attached to the current request.
>>>>>
>>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>>> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> we are experiencing strange hard pool limit reached exceptions. (For
>>>>>> the
>>>>>> user count that we have.) After debugging a little, it seems that our
>>>>>> left
>>>>>> menu component, which is full of page links, instantiates not only the
>>>>>> page
>>>>>> that we are at, but also the ones that are referenced in page link.
>>>>>>
>>>>>> This can be seen also in that exception page is shown, if one of the
>>>>>> pages
>>>>>> that are referenced in page links have an error.
>>>>>>
>>>>>> Is this correct behavior? And should we really use common a href= tags
>>>>>> to
>>>>>> avoid this? Further more, is it possible to create infinite loop, when
>>>>>> page
>>>>>> a has page link to page b, which has page link to page a?
>>>>>>
>>>>>>  - 99
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by 9902468 <vi...@cerion.fi>.
I always keep nabble open when I'm at work :)

These parameters can be transferred to web.xml, so that recompile is not
needed when changing these parameters:

public static void contributeApplicationDefaults(MappedConfiguration<String,
String> configuration, ApplicationGlobals globals) {

    configuration.add("tapestry.page-pool.hard-limit",
globals.getServletContext().getInitParameter("page_hard_limit"));

}

and in web.xml

<web-app>
    <display-name>Some Tapestry 5 Application</display-name>
    <context-param>
        <!-- The only significant configuration for Tapestry 5, this informs
Tapestry of where to look for pages, components and mixins. -->
        <param-name>tapestry.app-package</param-name>
        <param-value>fi.hanken.resbuilder.tapestry5</param-value>
    </context-param>
    <context-param>
        <param-name>page_hard_limit</param-name>
        <param-value>60</param-value>
    </context-param>

This can be used through out every single service and page and component. To
access this in a page or component use:

@Property @Inject @Value("${page_hard_limit}")
private String pageHardLimit;

Injection can be used in service constructor also (I think) or by using
buildSomeService method instead of the usual binder.bind

Of course T5 makes it easy to read these from a file or database or from
what not, but I have noticed that many admins accept editing web.xml and
restarting the app ok.

Hopefully this helps. (And makes it easier to say to admins that just
configure the app according to the load they are experiencing.)

-99


nille hammer wrote:
> 
> Man that was a quick answer! Thanks for that. I am aware of this options
> in the configuration. I had not tuned them before, because load is not
> my problem. Anyway I have tuned them now and am currently waiting for
> the admistrator to deploy the newest war.
> 
> According to acces-logs I was the only user accessing the page. So as
> far as I understand the mechanism only one instance of index should have
> been created and not 20. I think it is an issue with configuration in
> production environment. But I have no idea where to take a closer look
> (i.e. where to build in log-messages, which of Tomcat's configuration
> options to check etc.).
> 
> So suggestions are still more than welcome.
> 
> Nillehammer
> 
> 9902468 schrieb:
>> Hi,
>> 
>> Eventually we had to add these to appmodule:
>> 
>>         configuration.add("tapestry.page-pool.hard-limit", "60");
>>         configuration.add("tapestry.page-pool.soft-limit", "20");
>>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
>> 
>> as instructed here:
>> http://tapestry.apache.org/tapestry5/guide/conf.html
>> 
>> This solved our problems, and you can go up as long as your server has
>> memory. Our problems were only in production, as development stress just
>> isn't enough. (This is why one really should do load testing with jmeter
>> or
>> similar tool.)
>> 
>> The defaults could be a bit more? Or considerably less, so that the
>> developer would hit these walls during development and understands to
>> load
>> test / tune the parameters.
>> 
>>  - 99
>> 
>> 
>> nille hammer wrote:
>>> Hi list,
>>>
>>> I am also facing the problem that 9902468 had. I have -according to
>>> Howard's suggestion- replaced every pageLink with a customPageLink to
>>> prevent targeted pages from being created unecessarily. The problem
>>> persists. Trying to load the index-Page of my application with a browser
>>> I have to wait about two minutes before I get an empty page. In the
>>> app's log the following Exception appears:
>>>
>>> java.lang.RuntimeException: The page pool for page 'Index' (in locale
>>> de) has been exausted: there are 20 instances currently being used and
>>> no more can be created. Try increasing the hard limit (symbol
>>> tapestry.page-pool.hard-limit) to allow additional instances to be
>>> created, or increasing the soft wait (symbol
>>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>>> efficient use of page instances.
>>>         at
>>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>>         at
>>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>>         at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>>         at
>>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>>         at
>>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>>         at
>>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>>> ...
>>>
>>> In development and in production environment I use Java 6 and Tomcat 6.
>>> Tapestry is 5.0.14. The strange thing is that I am only seeing this in
>>> production environment.
>>>
>>> Has anyone a suggestion how to track this down? I am pretty stuck with
>>> this.
>>>
>>> Thanks in advance, nillehammer
>>>
>>> Howard Lewis Ship wrote
>>>> Tapestry is obtaining page instances to see if there is an activation
>>>> context for the page.
>>>>
>>>> I expect to optimize this in the future, to check to see if the page
>>>> has an event handler for the passivate event.
>>>>
>>>> In the meantime, you could build your own PageLink component that
>>>> generates the link by invoking
>>>> ComponentResources.createPageLink("pagename", true) ... that will tell
>>>> Tapestry to generate a link to the page with no activation context,
>>>> and the page will NOT be queried for its context, and therefore, won't
>>>> need to be attached to the current request.
>>>>
>>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> we are experiencing strange hard pool limit reached exceptions. (For
>>>>> the
>>>>> user count that we have.) After debugging a little, it seems that our
>>>>> left
>>>>> menu component, which is full of page links, instantiates not only the
>>>>> page
>>>>> that we are at, but also the ones that are referenced in page link.
>>>>>
>>>>> This can be seen also in that exception page is shown, if one of the
>>>>> pages
>>>>> that are referenced in page links have an error.
>>>>>
>>>>> Is this correct behavior? And should we really use common a href= tags
>>>>> to
>>>>> avoid this? Further more, is it possible to create infinite loop, when
>>>>> page
>>>>> a has page link to page b, which has page link to page a?
>>>>>
>>>>>  - 99
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>>>
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19569731.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by nillehammer <ta...@winfonet.eu>.
Man that was a quick answer! Thanks for that. I am aware of this options
in the configuration. I had not tuned them before, because load is not
my problem. Anyway I have tuned them now and am currently waiting for
the admistrator to deploy the newest war.

According to acces-logs I was the only user accessing the page. So as
far as I understand the mechanism only one instance of index should have
been created and not 20. I think it is an issue with configuration in
production environment. But I have no idea where to take a closer look
(i.e. where to build in log-messages, which of Tomcat's configuration
options to check etc.).

So suggestions are still more than welcome.

Nillehammer

9902468 schrieb:
> Hi,
> 
> Eventually we had to add these to appmodule:
> 
>         configuration.add("tapestry.page-pool.hard-limit", "60");
>         configuration.add("tapestry.page-pool.soft-limit", "20");
>         configuration.add("tapestry.page-pool.soft-wait", "20 ms");
> 
> as instructed here:
> http://tapestry.apache.org/tapestry5/guide/conf.html
> 
> This solved our problems, and you can go up as long as your server has
> memory. Our problems were only in production, as development stress just
> isn't enough. (This is why one really should do load testing with jmeter or
> similar tool.)
> 
> The defaults could be a bit more? Or considerably less, so that the
> developer would hit these walls during development and understands to load
> test / tune the parameters.
> 
>  - 99
> 
> 
> nille hammer wrote:
>> Hi list,
>>
>> I am also facing the problem that 9902468 had. I have -according to
>> Howard's suggestion- replaced every pageLink with a customPageLink to
>> prevent targeted pages from being created unecessarily. The problem
>> persists. Trying to load the index-Page of my application with a browser
>> I have to wait about two minutes before I get an empty page. In the
>> app's log the following Exception appears:
>>
>> java.lang.RuntimeException: The page pool for page 'Index' (in locale
>> de) has been exausted: there are 20 instances currently being used and
>> no more can be created. Try increasing the hard limit (symbol
>> tapestry.page-pool.hard-limit) to allow additional instances to be
>> created, or increasing the soft wait (symbol
>> tapestry.page-pool.soft-wait) to trade away some throughput for more
>> efficient use of page instances.
>>         at
>> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>>         at
>> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>>         at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>>         at
>> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>>         at
>> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>>         at
>> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
>> ...
>>
>> In development and in production environment I use Java 6 and Tomcat 6.
>> Tapestry is 5.0.14. The strange thing is that I am only seeing this in
>> production environment.
>>
>> Has anyone a suggestion how to track this down? I am pretty stuck with
>> this.
>>
>> Thanks in advance, nillehammer
>>
>> Howard Lewis Ship wrote
>>> Tapestry is obtaining page instances to see if there is an activation
>>> context for the page.
>>>
>>> I expect to optimize this in the future, to check to see if the page
>>> has an event handler for the passivate event.
>>>
>>> In the meantime, you could build your own PageLink component that
>>> generates the link by invoking
>>> ComponentResources.createPageLink("pagename", true) ... that will tell
>>> Tapestry to generate a link to the page with no activation context,
>>> and the page will NOT be queried for its context, and therefore, won't
>>> need to be attached to the current request.
>>>
>>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>>> wrote:
>>>> Hi,
>>>>
>>>> we are experiencing strange hard pool limit reached exceptions. (For the
>>>> user count that we have.) After debugging a little, it seems that our
>>>> left
>>>> menu component, which is full of page links, instantiates not only the
>>>> page
>>>> that we are at, but also the ones that are referenced in page link.
>>>>
>>>> This can be seen also in that exception page is shown, if one of the
>>>> pages
>>>> that are referenced in page links have an error.
>>>>
>>>> Is this correct behavior? And should we really use common a href= tags
>>>> to
>>>> avoid this? Further more, is it possible to create infinite loop, when
>>>> page
>>>> a has page link to page b, which has page link to page a?
>>>>
>>>>  - 99
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: Page pool hard limit and page instance usage

Posted by 9902468 <vi...@cerion.fi>.
Hi,

Eventually we had to add these to appmodule:

        configuration.add("tapestry.page-pool.hard-limit", "60");
        configuration.add("tapestry.page-pool.soft-limit", "20");
        configuration.add("tapestry.page-pool.soft-wait", "20 ms");

as instructed here:
http://tapestry.apache.org/tapestry5/guide/conf.html

This solved our problems, and you can go up as long as your server has
memory. Our problems were only in production, as development stress just
isn't enough. (This is why one really should do load testing with jmeter or
similar tool.)

The defaults could be a bit more? Or considerably less, so that the
developer would hit these walls during development and understands to load
test / tune the parameters.

 - 99


nille hammer wrote:
> 
> Hi list,
> 
> I am also facing the problem that 9902468 had. I have -according to
> Howard's suggestion- replaced every pageLink with a customPageLink to
> prevent targeted pages from being created unecessarily. The problem
> persists. Trying to load the index-Page of my application with a browser
> I have to wait about two minutes before I get an empty page. In the
> app's log the following Exception appears:
> 
> java.lang.RuntimeException: The page pool for page 'Index' (in locale
> de) has been exausted: there are 20 instances currently being used and
> no more can be created. Try increasing the hard limit (symbol
> tapestry.page-pool.hard-limit) to allow additional instances to be
> created, or increasing the soft wait (symbol
> tapestry.page-pool.soft-wait) to trade away some throughput for more
> efficient use of page instances.
>         at
> org.apache.tapestry5.internal.services.PagePoolCache.checkout(PagePoolCache.java:199)
>         at
> org.apache.tapestry5.internal.services.PagePoolImpl.checkout(PagePoolImpl.java:107)
>         at $PagePool_11c76f8cf9a.checkout($PagePool_11c76f8cf9a.java)
>         at
> org.apache.tapestry5.internal.services.RequestPageCacheImpl.get(RequestPageCacheImpl.java:43)
>         at
> $RequestPageCache_11c76f8cf99.get($RequestPageCache_11c76f8cf99.java)
>         at
> $RequestPageCache_11c76f8cf91.get($RequestPageCache_11c76f8cf91.java)
> ...
> 
> In development and in production environment I use Java 6 and Tomcat 6.
> Tapestry is 5.0.14. The strange thing is that I am only seeing this in
> production environment.
> 
> Has anyone a suggestion how to track this down? I am pretty stuck with
> this.
> 
> Thanks in advance, nillehammer
> 
> Howard Lewis Ship wrote
>> Tapestry is obtaining page instances to see if there is an activation
>> context for the page.
>> 
>> I expect to optimize this in the future, to check to see if the page
>> has an event handler for the passivate event.
>> 
>> In the meantime, you could build your own PageLink component that
>> generates the link by invoking
>> ComponentResources.createPageLink("pagename", true) ... that will tell
>> Tapestry to generate a link to the page with no activation context,
>> and the page will NOT be queried for its context, and therefore, won't
>> need to be attached to the current request.
>> 
>> On Fri, Aug 29, 2008 at 3:58 AM, 9902468 <vi...@cerion.fi>
>> wrote:
>>> Hi,
>>>
>>> we are experiencing strange hard pool limit reached exceptions. (For the
>>> user count that we have.) After debugging a little, it seems that our
>>> left
>>> menu component, which is full of page links, instantiates not only the
>>> page
>>> that we are at, but also the ones that are referenced in page link.
>>>
>>> This can be seen also in that exception page is shown, if one of the
>>> pages
>>> that are referenced in page links have an error.
>>>
>>> Is this correct behavior? And should we really use common a href= tags
>>> to
>>> avoid this? Further more, is it possible to create infinite loop, when
>>> page
>>> a has page link to page b, which has page link to page a?
>>>
>>>  - 99
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19217773.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>>
>> 
>> 
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Page-pool-hard-limit-and-page-instance-usage-tp19217773p19567417.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org