Alex Tkachman schrieb:

hmm... I am not sure this will really fix the problem... the problem was a OOME because the loader could not be garbage collected, because there is still an active thread. Assuming the thread does stop 5s after the last use and another deploy would not have enough memory left, but is done within these 5s, then we still get the OOME. If things are bad and there are multiple deploys in that time the story gets even worse. If multiple aplication are in the server and they use groovy then you have that problem multiple times.

Also I am not too sure about the reference counting you do. If there are still entries, then the loader can not be garbage collected, because oif the Thread. On the other hand if there where entries and no thread, then the loader and all classes could be garbage collected right away. So the garbage collector would have to do multiple passes and then the Thread still waits for 5s and I think in the meantime the OMMe is already there. So at last we need to decrement first and leave the thread right away if it reaches 0. But I still think that would not be enough, because that code would be executed after the garbage collector was not able to free enough space.

We will still get the OOME.

I think neither the reference count nor the timeout will work in general. There is a small chance it will do for the glassfish people if they are not fast enough... but the more groovy applications are running and are redeployed the higher the chance for a OOME, because the 5s are not past yet

bye blackdrag