[jboss-dev] VFS Temp Reuse (JBAS-6715)

[Ales Justin]

> 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)

Why exactly is ZEC-B created?
It should be only one, as that's the point of having a cache.

> 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.

If it was only a single instance, as the cache presumes,
there should be no problem, as the entity is reset no cleanup.

OK, there might still be a problem if someone kept a ref on the nested .war,
but I would consider that his problem and a bad impl practice,
as I don't see how else can we properly cleanup temps.

> 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 at 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 at gmail.com>
>>>>>>> To: "JBoss.org development list" <jboss-development at 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> 
>