And for a particular application, you should be able to only keep the
most recent loader directory and remove all the others (those obsolete
loader directories should've been cleaned up by the server code but not
due to the bug).
On 3/13/2013 5:46 PM, Hong Zhang wrote:
> Yeah this issue was already fixed in GlassFish 4.0, but it seems it's
> not a choice for you to upgrade to GlassFish 4.0 right now. If it's a
> choice to buy support contract, you can also get the fix from 3.1.2.5
> patch which will be out in April.
>
> To workaround the issue, I think you can safely delete all the
> generated/jsp directories that are for applications which are already
> undeployed. And if you don't worry too much about the runtime
> performance, I think you can even remove all the contents under the
> generated/jsp directories, they will just get re-generated the next
> time the application is accessed (will take some time to re-generate
> each time if it's not generated already).
>
> - Hong
>
> On 3/13/2013 5:25 PM, forums_at_java.net wrote:
>> Hello guys. I am currently using GlassFish Server Open Source Edition
>> 3.1.2.2
>> (build 5). My problem is that this is already in Prod environment and
>> we just
>> noticed this. It is happening for domain and clusters across all
>> nodes ie:
>> /usr/local/glassfish3/glassfish/nodes/localhost-domain1//generated/jsp/
>> I
>> know there is a ticket issued for this
>> (http://java.net/jira/browse/GLASSFISH-19162) but I was wondering
>> what can be
>> deleted from here and what not as we are running out of disk space.
>> We have
>> nightly rolling-restart and hence we are accumulating lots of these.
>> What is
>> safe to delete from here? and what not? Kindly appreciate your help
>>
>> --
>>
>> [Message sent by forum member 'luisjotapepe']
>>
>> View Post: http://forums.java.net/node/895653
>>
>>
>