tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45774] jspDestroy called after deployment, the second jspInit follows
Date Tue, 07 Oct 2008 13:56:33 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=45774


Brian Burch <Brian@PingToo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Brian@PingToo.com
            Version|5.5.26                      |5.5.27




--- Comment #2 from Brian Burch <Brian@PingToo.com>  2008-10-07 06:56:31 PST ---
I made a clean install of the new 5.5.27 release on a different machine. I
added my demo war and started tomcat. The servlet still works as designed and
the jsp still flags the antisocial behaviour.... the jsp was destroyed after
the first service and then was immediately re-initialised.

I then stopped tomcat and restarted it using the already deployed webapp. This
time (to my surprise) the jsp was not destroyed.

I used the tomcat manager to stop and start the webapp. It worked fine.

I undeployed it and re-copied the war to automatically deploy. 2 services and
then an unnecessary destroy/init.

I reloaded the webapp, and it worked fine.

I copied the war to get it redeployed - 2 services and then an unnecessary
destroy/init.

I have no problem with the specification allowing Servlet containers to create
and destroy servlet (and jsp) instances when necessary, but this behaviour is
just perverse and wasteful of resources. The whole point of init/destroy is to
be able to setup a shared pool of "expensive" resources that need to be
conserved over a long period of time.

I can do more work on this if you would like. At the moment, the evidence
points to some kind of timing issue related to deployment of a new war and
subsequent compilation of the jsp.

My earlier tests with 5.5.26 (and older releases) on other machines showed the
perverse behaviour could occur after a simple tomcat stop/start cycle (i.e. no
jsp compilation), but I have no evidence of this happening on a clean install
of the latest version of tomcat.

Regards,

Brian


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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message