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 <[EMAIL PROTECTED]>
>>> 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: [EMAIL PROTECTED]
>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>
>>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
