That's basically what we do, restart the apps with a cron job 
periodically, as sooner or later when we upgrade things they tend to end 
up having OOMEs. So instead of waiting for them to happen, we just do a 
clean restart.

Even if you have developed the application yourself, some of those 
errors are quite difficult to pinpoint, as they might be caused by 
libraries that use other libraries... that have side effects... ouch. 
The thing is, we profiled our own application under heavy load and 
nothing came up, memory going back to normal each time after a pause, so 
due to lack of time to chase the underlying cause, we ended up using the 
easy route. We don't need to have high availability and restarting each 
resin instance just takes some seconds so...

But it is an itch I want to scratch when we have more time.

On a related note, I've seen similar things with other containers in the 
past, so I think it is related to the messy classloaders universe where 
web applications live. Not sure if latest Resin versions improve on that 
or help detecting things, so we keep restarting them :).


Olli Aro escribió:

> Hi Daniel,
> Thank you so much for your response. The error does not occur too often for
> me either, so I suppose I could schedule Resin restart e.g. every night and
> that would keep it away for me.
> We have not developed the application (an open source CMS system), but are
> just maintaining it, so not that keen to start profiling it if I can get
> away without :)
> Regards,
> Olli 

resin-interest mailing list

Reply via email to