11:23 p.m.
I finally have the cause:
Deploy
------
1. Structure scanning creates tempX for the nested war (ZipEntryContext-A)
2. During deployment JEEDeployedObject calls getResource, which opens a
vfs URL
3. The vfs registry cache lookup fails because ZipEntryContext-A is a
nested resource, thus the original deployment is rescanned.
4. ZipEntryContext-B is created in the same file context as A (the
deploy dir), therefore *tempX is reused* (see initEntries:539)
Undeploy
--------
5. tempX is removed
6. ZipEntyContext-A is cleaned, and it's container is reset
Redeploy
--------
7. During structure scanning ZipEntryContext-B is retrieved (which still
refers to tempX)is opened *BOOM*
So the fundamental problem is that we reuse temps for entities which
have different lifecycles. We also always purge temps based on the
source location, so even if we keep them separate, the first tempinfo
cleanup will remove them all.
Ales Justin wrote:
Sure, commit and I'll have a look tomorrow.
Sent from my iPhone
On Apr 21, 2009, at 19:12, "Jason T. Greene" <jason.greene(a)redhat.com>
wrote:
> Ales Justin wrote:
>> So, you're saying that even after you fixed ts issues,
>> the 6715 is still there?
>
> Yes, after fixing just the TS issues with TempInfo usage (wanted to
> limit the scope of this), the DeploymentManager test in the AS fails,
> but the override test in the VFS (and all other tests) pass. I have
> not committed this though, since I wanted to make sure the changes did
> not lead to regression first. I could if you want to take a look.
>
>> I don't see a race issue.
>
> The DeploymentManager test succeeds several times before failing, so I
> was assuming timing related, but it might not be. Ill hopefully have
> more info soon.
>
>> It must be something similar to what we already had,
>> something is not cleaning up properly behind itself.
>> That was the issue before -> due to overridden TempInfo,
>> nobody reset the parent VFSContext.
>> Jason T. Greene wrote:
>>> Unfortunately the tempinfo TS fixes resurrects JBAS-6715, although
>>> in a slightly different manner (the VFS test created for 6715
>>> passes). The root problem still seems to be a race that leads to the
>>> deployers somehow holding on to a stale ZipFileWrapper instance.
>>> This is going to take awhile to track down.
>>>
>>> Ales Justin wrote:
>>>> VFS 2.2.0.M1 has .war cleanup bug
>>>> VFS 2.2.0.M2 has TS issues + Iterator.remove bug
>>>> VFS 2.2.0.M3 has TS issues
>>>>
>>>> Seam-int 5.2.0-SNAPSHOT excludes plugins/*.jar from scan
>>>>
>>>> If you could wait for some VFS 2.2.0-SNAPSHOT from Jason
>>>> (it depends how fast he can provide it)
>>>> that would be the best choice.
>>>>
>>>> Otherwise do your pick. :-)
>>>>
>>>> Shelly McGowan wrote:
>>>>> Ales,
>>>>>
>>>>> So, we want to test with VFS 2.2.0.M1 and seam-int 5.2.0-SNAPSHOT?
>>>>>
>>>>>
>>>>> Shelly
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>> From: "Ales Justin" <ales.justin(a)gmail.com>
>>>>> To: "JBoss.org development list"
<jboss-development(a)lists.jboss.org>
>>>>> Sent: Monday, April 20, 2009 12:13:24 PM GMT -05:00 US/Canada
Eastern
>>>>> Subject: Re: [jboss-dev] Reverted VFS to 2.2.0.M1 (& hudson
madness)
>>>>>
>>>>> Can we also change the Seam-int to 5.2.0-SNAPSHOT?
>>>>> (Or Shelly, you already did this?)
>>>>>
>>>>> This should fix the performance issue EmbJopr is having with
>>>>> VFSScanner going "into" plugins/*.jar files.
>>>>>
>>>>> Jason T. Greene wrote:
>>>>>> Hi Everyone,
>>>>>>
>>>>>> Since this weekends hudson meltdown seems likely related to a
>>>>>> memory leak, I have reverted VFS to M1. Recent updates to the VFS
>>>>>> have been observed to leak (JBAS-6805). This is potentially
>>>>>> caused by a thread safety issue introduced in M2. Shelly has
>>>>>> kicked off another 5.1 testrun with this update, and is checking
>>>>>> to see see if M1 resolved 6805.
>>>>>>
>>>>>> In the meantime I am working on an update to the VFS that does
>>>>>> not have the recent TS issues.
>>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
>
>
> --
> Jason T. Greene
> JBoss, a division of Red Hat
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development
--
Jason T. Greene
JBoss, a division of Red Hat