You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Rich M <ri...@moremagic.com> on 2011/03/21 16:21:17 UTC
5.1 : Available pages downgrade
Hi,
I've been running a production version of a tapestry application for a
couple months now. Just the other day it was reported to me that the
application was no longer resolving pages normally, but instead
displaying a directory view from the root context.
Restarting the application solved the problem, but I'm at a loss as to
the cause. Looking through the application logs, the only unusual
logging I noticed was that sometime during the timeframe in which the
problem was expected to occur, the TapestryModule.ComponentClassResolver
fired off 3 lines of logging similar to when you execute the start-up of
a Tapestry application.
Namely, it displayed lists of available pages, available components, and
available mixins. The list of available pages was significantly reduced
from the actual pages within the application. It seemed like an
at-random mini-subset of the actual pages in the application. There is
nothing to indicate someone had tried to start/restart the application
again or anything along those lines.
Considering the minimal amount of information I have at hand, I was
curious to know if this ComponentClassResolver issue might look familiar
to anyone? Or perhaps at least an idea of what might cause the
ComponentClassResolver to behave as it had so I can follow up with a
code review of my application? I run the application in a standalone
Jetty 6.1.26 as a WAR deployment.
Thanks,
Rich
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.1 : Available pages downgrade
Posted by Cezary Biernacki <ce...@gmail.com>.
Hi,
on Linux or other Unix-like system, one possibility is that Jetty unpacked
your WAR to /tmp and tmpwatch or something similar removed some not recently
used files.
Cezary
On Mon, Mar 21, 2011 at 4:21 PM, Rich M <ri...@moremagic.com> wrote:
> Hi,
>
> I've been running a production version of a tapestry application for a
> couple months now. Just the other day it was reported to me that the
> application was no longer resolving pages normally, but instead displaying a
> directory view from the root context.
>
> Restarting the application solved the problem, but I'm at a loss as to the
> cause. Looking through the application logs, the only unusual logging I
> noticed was that sometime during the timeframe in which the problem was
> expected to occur, the TapestryModule.ComponentClassResolver fired off 3
> lines of logging similar to when you execute the start-up of a Tapestry
> application.
>
> Namely, it displayed lists of available pages, available components, and
> available mixins. The list of available pages was significantly reduced from
> the actual pages within the application. It seemed like an at-random
> mini-subset of the actual pages in the application. There is nothing to
> indicate someone had tried to start/restart the application again or
> anything along those lines.
>
> Considering the minimal amount of information I have at hand, I was curious
> to know if this ComponentClassResolver issue might look familiar to anyone?
> Or perhaps at least an idea of what might cause the ComponentClassResolver
> to behave as it had so I can follow up with a code review of my application?
> I run the application in a standalone Jetty 6.1.26 as a WAR deployment.
>
> Thanks,
> Rich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: 5.1 : Available pages downgrade
Posted by Rich M <ri...@moremagic.com>.
Thanks for the replies so far, they have been helpful. I will be looking
into both the application server's maintenance of the /tmp folder -
where it does seem Jetty is unpacking the WAR - as well as the memory
usage of the application and optimizations for that.
The production version is frozen at 5.1.0.15 unfortunately, but I
recently begun development on the next release version. That, coinciding
with the release of ChenilleKit for 5.2.4, has allowed me to
successfully upgrade the next version to 5.2.4, which I'm very excited
about.
Thanks,
Rich
On 03/21/2011 02:17 PM, Thiago H. de Paula Figueiredo wrote:
> Using 5.2.4 will help, as the memory consumption is lowered by not
> using a page pool anymore.
>
> On Mon, 21 Mar 2011 14:51:01 -0300, Kalle Korhonen
> <ka...@gmail.com> wrote:
>
>> I can confirm I've seen similar behavior on Jetty. It's linked to heap
>> space running out and in my case it was directly related to sending
>> huge amounts gzipped form data. See related Jetty issue at
>> http://jira.codehaus.org/browse/JETTY-1167 and my comments there.
>> Apparently Jetty in some cases shuts down the application in order to
>> keep the container running, after which you'd see the behavior you
>> described. Adjust jvm settings and allocate more memory to your
>> process. Allocate enough until the whole process dies (if you are on
>> Linux platform - especially virtualized with no swap space, the OOM
>> killer will shut down the JVM way before your process consumes all of
>> the available RAM). Then investigate if any of your forms are
>> reserving a high amount of memory, possibly play with other JVM
>> settings and *if* you are sending a lot of gzipped data, turn gzipping
>> off and see if it makes a difference.
>>
>> Kalle
>>
>>
>> On Mon, Mar 21, 2011 at 8:21 AM, Rich M <ri...@moremagic.com> wrote:
>>> Hi,
>>>
>>> I've been running a production version of a tapestry application for a
>>> couple months now. Just the other day it was reported to me that the
>>> application was no longer resolving pages normally, but instead
>>> displaying a
>>> directory view from the root context.
>>>
>>> Restarting the application solved the problem, but I'm at a loss as
>>> to the
>>> cause. Looking through the application logs, the only unusual logging I
>>> noticed was that sometime during the timeframe in which the problem was
>>> expected to occur, the TapestryModule.ComponentClassResolver fired
>>> off 3
>>> lines of logging similar to when you execute the start-up of a Tapestry
>>> application.
>>>
>>> Namely, it displayed lists of available pages, available components,
>>> and
>>> available mixins. The list of available pages was significantly
>>> reduced from
>>> the actual pages within the application. It seemed like an at-random
>>> mini-subset of the actual pages in the application. There is nothing to
>>> indicate someone had tried to start/restart the application again or
>>> anything along those lines.
>>>
>>> Considering the minimal amount of information I have at hand, I was
>>> curious
>>> to know if this ComponentClassResolver issue might look familiar to
>>> anyone?
>>> Or perhaps at least an idea of what might cause the
>>> ComponentClassResolver
>>> to behave as it had so I can follow up with a code review of my
>>> application?
>>> I run the application in a standalone Jetty 6.1.26 as a WAR deployment.
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: 5.1 : Available pages downgrade
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Using 5.2.4 will help, as the memory consumption is lowered by not using a
page pool anymore.
On Mon, 21 Mar 2011 14:51:01 -0300, Kalle Korhonen
<ka...@gmail.com> wrote:
> I can confirm I've seen similar behavior on Jetty. It's linked to heap
> space running out and in my case it was directly related to sending
> huge amounts gzipped form data. See related Jetty issue at
> http://jira.codehaus.org/browse/JETTY-1167 and my comments there.
> Apparently Jetty in some cases shuts down the application in order to
> keep the container running, after which you'd see the behavior you
> described. Adjust jvm settings and allocate more memory to your
> process. Allocate enough until the whole process dies (if you are on
> Linux platform - especially virtualized with no swap space, the OOM
> killer will shut down the JVM way before your process consumes all of
> the available RAM). Then investigate if any of your forms are
> reserving a high amount of memory, possibly play with other JVM
> settings and *if* you are sending a lot of gzipped data, turn gzipping
> off and see if it makes a difference.
>
> Kalle
>
>
> On Mon, Mar 21, 2011 at 8:21 AM, Rich M <ri...@moremagic.com> wrote:
>> Hi,
>>
>> I've been running a production version of a tapestry application for a
>> couple months now. Just the other day it was reported to me that the
>> application was no longer resolving pages normally, but instead
>> displaying a
>> directory view from the root context.
>>
>> Restarting the application solved the problem, but I'm at a loss as to
>> the
>> cause. Looking through the application logs, the only unusual logging I
>> noticed was that sometime during the timeframe in which the problem was
>> expected to occur, the TapestryModule.ComponentClassResolver fired off 3
>> lines of logging similar to when you execute the start-up of a Tapestry
>> application.
>>
>> Namely, it displayed lists of available pages, available components, and
>> available mixins. The list of available pages was significantly reduced
>> from
>> the actual pages within the application. It seemed like an at-random
>> mini-subset of the actual pages in the application. There is nothing to
>> indicate someone had tried to start/restart the application again or
>> anything along those lines.
>>
>> Considering the minimal amount of information I have at hand, I was
>> curious
>> to know if this ComponentClassResolver issue might look familiar to
>> anyone?
>> Or perhaps at least an idea of what might cause the
>> ComponentClassResolver
>> to behave as it had so I can follow up with a code review of my
>> application?
>> I run the application in a standalone Jetty 6.1.26 as a WAR deployment.
>>
>> Thanks,
>> Rich
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: 5.1 : Available pages downgrade
Posted by Kalle Korhonen <ka...@gmail.com>.
I can confirm I've seen similar behavior on Jetty. It's linked to heap
space running out and in my case it was directly related to sending
huge amounts gzipped form data. See related Jetty issue at
http://jira.codehaus.org/browse/JETTY-1167 and my comments there.
Apparently Jetty in some cases shuts down the application in order to
keep the container running, after which you'd see the behavior you
described. Adjust jvm settings and allocate more memory to your
process. Allocate enough until the whole process dies (if you are on
Linux platform - especially virtualized with no swap space, the OOM
killer will shut down the JVM way before your process consumes all of
the available RAM). Then investigate if any of your forms are
reserving a high amount of memory, possibly play with other JVM
settings and *if* you are sending a lot of gzipped data, turn gzipping
off and see if it makes a difference.
Kalle
On Mon, Mar 21, 2011 at 8:21 AM, Rich M <ri...@moremagic.com> wrote:
> Hi,
>
> I've been running a production version of a tapestry application for a
> couple months now. Just the other day it was reported to me that the
> application was no longer resolving pages normally, but instead displaying a
> directory view from the root context.
>
> Restarting the application solved the problem, but I'm at a loss as to the
> cause. Looking through the application logs, the only unusual logging I
> noticed was that sometime during the timeframe in which the problem was
> expected to occur, the TapestryModule.ComponentClassResolver fired off 3
> lines of logging similar to when you execute the start-up of a Tapestry
> application.
>
> Namely, it displayed lists of available pages, available components, and
> available mixins. The list of available pages was significantly reduced from
> the actual pages within the application. It seemed like an at-random
> mini-subset of the actual pages in the application. There is nothing to
> indicate someone had tried to start/restart the application again or
> anything along those lines.
>
> Considering the minimal amount of information I have at hand, I was curious
> to know if this ComponentClassResolver issue might look familiar to anyone?
> Or perhaps at least an idea of what might cause the ComponentClassResolver
> to behave as it had so I can follow up with a code review of my application?
> I run the application in a standalone Jetty 6.1.26 as a WAR deployment.
>
> Thanks,
> Rich
>
>
> ---------------------------------------------------------------------
> 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: 5.1 : Available pages downgrade
Posted by Howard Lewis Ship <hl...@gmail.com>.
This is a troubling mystery, and doesn't sound familiar at all.
On Mon, Mar 21, 2011 at 8:21 AM, Rich M <ri...@moremagic.com> wrote:
> Hi,
>
> I've been running a production version of a tapestry application for a
> couple months now. Just the other day it was reported to me that the
> application was no longer resolving pages normally, but instead displaying a
> directory view from the root context.
>
> Restarting the application solved the problem, but I'm at a loss as to the
> cause. Looking through the application logs, the only unusual logging I
> noticed was that sometime during the timeframe in which the problem was
> expected to occur, the TapestryModule.ComponentClassResolver fired off 3
> lines of logging similar to when you execute the start-up of a Tapestry
> application.
>
> Namely, it displayed lists of available pages, available components, and
> available mixins. The list of available pages was significantly reduced from
> the actual pages within the application. It seemed like an at-random
> mini-subset of the actual pages in the application. There is nothing to
> indicate someone had tried to start/restart the application again or
> anything along those lines.
>
> Considering the minimal amount of information I have at hand, I was curious
> to know if this ComponentClassResolver issue might look familiar to anyone?
> Or perhaps at least an idea of what might cause the ComponentClassResolver
> to behave as it had so I can follow up with a code review of my application?
> I run the application in a standalone Jetty 6.1.26 as a WAR deployment.
>
> Thanks,
> Rich
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org