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
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 :)
resin-interest mailing list