Re: Memory leak? (issues.apache.org)

2006-05-10 Thread Jeff Turner 
Hi,

On Thu, May 04, 2006 at 11:10:20AM +0200, Remy Maucherat wrote:
> Jeff Turner wrote:
> > 1 May:  93 Objects (126Mb)
> > 2 May:  107 Objects (263Mb)
> > 3 May:  492 Objects (486MB)
> 
> BodyContentImpls are pooled and reused since it makes JSP processing 
> significantly faster. If the application is evil, and uses body tags 
> with huge bodies (it seems to be the case here), then there could be a 
> problem.

Just wondering - are all JSP bodies pooled, or only tag bodies? Eg.
would this JSP's body be pooled:

<%= for (int i=0; i<100; i++) { out.print("womble"); } %>

Or only if it were wrapped in JSP tag.

> Large buffers may be discarded after usage, by setting the 
> "org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER" system property 
> to "true". Unfortunately, performance will go down and GC activity will 
> go up.

It appears to have fixed the leak on issues.a.o.


Cheers,
Jeff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory leak? (issues.apache.org)

2006-05-10 Thread Rainer Jung 
From my understanding PageContextImpls are pooled, but not the JSP 
output (body). Those are written using JspWriterImpls that buffer only 
8KB of output.


If you are using tags, then their content is kept in a char array inside 
BodyContentImpls. Each (pooled) PageContextImpl has a stack of these and 
the stack and the BodyContentImpl including the char array are not 
resized after usage. The pooled PageContextImpl keeps references to those.


The LIMIT_BUFFER makes the BodyContentImpl resizing to 512 Bytes in case 
it grew larger.


Jeff Turner wrote:

Hi,

On Thu, May 04, 2006 at 11:10:20AM +0200, Remy Maucherat wrote:

Jeff Turner wrote:

1 May:  93 Objects (126Mb)
2 May:  107 Objects (263Mb)
3 May:  492 Objects (486MB)
BodyContentImpls are pooled and reused since it makes JSP processing 
significantly faster. If the application is evil, and uses body tags 
with huge bodies (it seems to be the case here), then there could be a 
problem.


Just wondering - are all JSP bodies pooled, or only tag bodies? Eg.
would this JSP's body be pooled:

<%= for (int i=0; i<100; i++) { out.print("womble"); } %>

Or only if it were wrapped in JSP tag.

Large buffers may be discarded after usage, by setting the 
"org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER" system property 
to "true". Unfortunately, performance will go down and GC activity will 
go up.


It appears to have fixed the leak on issues.a.o.


Cheers,
Jeff

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
53111 Bonn

Tel.: 0228/98549-0
Fax:  0228/98549-50
www.kippdata.de
===
kippdata informationstechnologie GmbH
Bornheimer Str. 33a
D-53111 Bonn

Tel.: +49/0228/98549-0
Fax:  +49/0228/98549-50
www.kippdata.de

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16874] - Same session for two different clients as a result of a lack in synchronization during recycling sessions

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=16874


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16874] - Same session for two different clients as a result of a lack in synchronization during recycling sessions

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=16874


[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.1.18  |4.1.24




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16874] - Same session for two different clients as a result of a lack in synchronization during recycling sessions

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=16874


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED
Version|4.1.24  |4.1.18




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39546] New: - In some cases a filter not invoked on 'include'

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39546

   Summary: In some cases a filter not invoked on 'include'
   Product: Tomcat 5
   Version: 5.5.16
  Platform: Other
OS/Version: other
Status: NEW
  Severity: critical
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


In my application, Webmill jsr-168 portal, if I use JSF/MyFaces filters, 
configured in web.xml not invoked.

Investigate this bug, I found what in 
org.apache.catalina.core.ApplicationDispatcher

after prepare include, we call
invoke(outerRequest, outerResponse);  // line 574
corrert call
invoke(wrequest, outerResponse);  

After this patch all filters correctly invoked.

Filters not invoked due to we set dispatcher type in wreqeust object, not in 
outerRequest:
wrequest.setAttribute(ApplicationFilterFactory.DISPATCHER_TYPE_ATTR,
 new Integer
(ApplicationFilterFactory.INCLUDE)); // line 571,572

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39546] - In some cases a filter not invoked on 'include'

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39546





--- Additional Comments From [EMAIL PROTECTED]  2006-05-10 15:55 ---
To start things with, -1 for your proposed fix; if there is a problem, this is
not a way to fix things.

Can you produce a simple test war ?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39546] - In some cases a filter not invoked on 'include'

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39546





--- Additional Comments From [EMAIL PROTECTED]  2006-05-10 16:00 ---
I will try in next few days

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39546] - In some cases a filter not invoked on 'include'

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39546





--- Additional Comments From [EMAIL PROTECTED]  2006-05-10 16:13 ---
The problem I have with this is that the outerRequest field value will actually
be the wrapper, unless you have wrapped the request. In that case, you need to
use ServletRequestWrapper, and delegate properly.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39546] - In some cases a filter not invoked on 'include'

2006-05-10 Thread bugzilla 
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39546





--- Additional Comments From [EMAIL PROTECTED]  2006-05-10 16:55 ---
Yes, I use ServletRequestWrapper
This is my current implementation of request

http://cvs.sourceforge.net/viewcvs.py/riverock/riverock/riverock-
webmill/src/java/org/riverock/webmill/portal/impl/WebmillPortletRequest.java?
rev=1.12&view=markup


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

re: Deployement of war and context.xml files

2006-05-10 Thread Thomas Whitmore 
Hi Henri,

Apparently  /conf/Catalina/localhost  is meant to represent the 'current 
deployed state' of contexts/ webapps deployed.

So it's reasonable from this understanding, that the Context specifier file is 
deleted when you undeploy the app;  the context is being removed from the 
'current state'.  Since the complete deployer rewrite in TC 5.5,  Tomcat now 
takes significant ownership of both /conf/[engine]/[host]  and /webapps. 

My guess is that with the  Customer-specific app customization, that you wish 
to have the same .war deployed with different varying Context specifiers.  
(Probably different context paths for these, too?  I found huge problems with 
context paths since 5.5).  And that you want each Context specifier to be a 
separate file, for modularity.

The sensible way for Deployment to work, would be to supply a Context specifier 
file and a WAR or DocBase.  These would be placed into a location owned by the 
User (you).  You would then tell Tomcat to deploy (mount) the Context, or allow 
it to auto-deploy...

Unfortunately 5.5 seems to be a balls-up, with Tomcat auto-creating 'current 
mounted state' contexts for WARs and webapp folders it finds, auto-deleting 
webapps/ folders on undeploy or after editing 'current state' context files, 
failing to match explicit Context specifiers and thus producing spurious 
default deployments of the webapps, and with the 'Context Path' attribute 
almost completely broken.

As far as I am aware the locations to specify Contexts are, in order;  
'server.xml' as an XML element;  META-INF/context.xml inside the webapp;  or  
/conf/[engine]/[host]  directory. For deployment-specification customization 
obviously you need a Context file, independent of the webapp;  the only place 
to put this is in  /conf/[engine]/[host];  this location is most subject to the 
auto-magic working against you.

Best answer:-
-  use an Ant 'deploy' script from your Dev system
-  call Manager.Deploy  and also specify a Context xml file
-  may need to create a staging directory on the server under your control;
so Tomcat has somewhere it can see to pick up the files;
but safe from TC's  auto-scrubbing within /webapps
-  lastly;  Context Path specifiers, or possibly other important bits, may just 
not work  :-(


I would like to see very great clarification  in this area. (Hi guys). I think 
there is a semantic misunderstanding in failing to distinguish MOUNTING from 
DEPLOYMENT of webapps. Mounting should be Tomcat's responsibility, deploying - 
copying it to where TC can mount it or replicate it around the cluster - should 
be the User's responsibility.

This semantic error appears to have led to a (broad) range of TC behaviours in 
5.5 which are different from previous deployment concepts;  and just plain 
unlikable to developers.

Now if  MOUNTING and mounted state were kept separate from  DEPLOYMENT,  
/webapps and deployment area would not be subject to being scrubbed &  
trodden-upon like they currently are.  Information flows & effects would be 
well-defined, as opposed to current flows which are poorly-defined and effects 
which are undesirable. 

Keeping  terminology clear, information well structured, and avoiding 
conflation of ideas, are key to design of simple, robust & correct software.  
Basically I'd say deployment in 5.5 is an example of failure in these areas.

Lastly,
  stop tramping on my /webapps directory already!

Hope you can sort out your deployment to work effectively in this version - I 
ended up using a workaround  :-(   Anyway, let me know if this helps.


Regards,
Thomas