Bug 50168 - destory method is called twice while the child is destoryed directly
Summary: destory method is called twice while the child is destoryed directly
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.4
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-27 22:47 UTC by Ivan
Modified: 2010-11-04 19:04 UTC (History)
0 users



Attachments
Simple patch (2.01 KB, patch)
2010-11-01 22:11 UTC, Ivan
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan 2010-10-27 22:47:42 UTC
While calling the method destory() on the StandardContext directly, it seems that the method destoryInternal() is called twice in the LifecycleMBeanBase, the two stacktraces are below :
    a.  LifecycleMBeanBase.unregister(ObjectName) line: 191   
         LifecycleMBeanBase.destroyInternal() line: 73   
         ContainerBase.destroyInternal() line: 1109   
         StandardContext.destroyInternal() line: 5114   
         LifecycleBase.destroy() line: 271   
         ContainerBase.removeChild(Container) line: 963   
         ContainerBase.destroyInternal() line: 1106   
         StandardContext.destroyInternal() line: 5114   
         LifecycleBase.destroy() line: 271   
         ...
     b. LifecycleMBeanBase.unregister(ObjectName) line: 191   
         LifecycleMBeanBase.destroyInternal() line: 73   
         ContainerBase.destroyInternal() line: 1109   
         StandardContext.destroyInternal() line: 5114   
         LifecycleBase.destroy() line: 271
         ...
Comment 1 Tim Funk 2010-11-01 18:08:06 UTC
When StandardContext is destroyed is destroys assets is manages which also have their own lifecycle. So you might be seeing those log messages. (Most likely StandardManager)

Please reopen with more proof if this diagnosis is wrong.
Comment 2 Pid 2010-11-01 20:42:06 UTC
(In reply to comment #1)
> When StandardContext is destroyed is destroys assets is manages which also have
> their own lifecycle. So you might be seeing those log messages. (Most likely
> StandardManager)
> 
> Please reopen with more proof if this diagnosis is wrong.

I'm also seeing this on undeploying any app via the Manager application.
Comment 3 Ivan 2010-11-01 22:08:52 UTC
(In reply to comment #1)
> When StandardContext is destroyed is destroys assets is manages which also have
> their own lifecycle. So you might be seeing those log messages. (Most likely
> StandardManager)
> 
> Please reopen with more proof if this diagnosis is wrong.

Not sure I understand your comments clearly. From the stack trace, while destorying the standcontext directly, it will check check whether its parent is null, if not, it will call the parent.removeChild() method, but removeChild method also try to destory the child. (As it does not known who calls the method).
I will reopen the it, and try to attach a patch file.
thanks.
Comment 4 Ivan 2010-11-01 22:11:16 UTC
Created attachment 26248 [details]
Simple patch

Try to provide a patch for it. Might not be proper, but it should be helpful to find what happens.
Exception for the issue about double destory invocation, also, seems that Mapper.unregister action occurs before its  internal destory (e.g. remove welcome resources).
Comment 5 Tim Funk 2010-11-02 15:17:10 UTC
I don't think the patch works.

What I (think I) notice is StandardWrapperValve being destroyed for each servlet in the webapp.

By default there is the default servlet and jsp servlet. If you enable ssi and cgi, I think you will see the call being done 4 times.

Why? TBD.
Comment 6 Ivan 2010-11-03 22:19:21 UTC
(In reply to comment #5)
> I don't think the patch works.
> 
> What I (think I) notice is StandardWrapperValve being destroyed for each
> servlet in the webapp.
> 
> By default there is the default servlet and jsp servlet. If you enable ssi and
> cgi, I think you will see the call being done 4 times.
> 
> Why? TBD.

Hmmm, the problem is not how many times the call is been done, currently, what I found is that the call is done on the same Context for more than more time. 
thanks.
Comment 7 Mark Thomas 2010-11-04 19:04:31 UTC
Fixed in trunk and will be included in 7.0.5 onwards.