Thanks for the feedback. Having a meeting today to discuss installing
JavaMonitor on the RHEL6 in place of tomcat for deployment for external
applications. We are still using OSX 10.6.7 server with JavaMonitor for
internal apps
On Wed, May 30, 2012 at 3:16 PM, John Huss johnth...@gmail.com wrote:
I have been doing some more research and I am beginning to think this post
describes the cause of the issue
http://stackoverflow.com/questions/3320400/to-prevent-a-memory-leak-the-jdbc-driver-has-been-forcibly-unregistered
Has anyone deployed and application to production with either Tomcat
Le 2012-05-30 à 10:04, Ron Lift a écrit :
I have been doing some more research and I am beginning to think this post
describes the cause of the issue
http://stackoverflow.com/questions/3320400/to-prevent-a-memory-leak-the-jdbc-driver-has-been-forcibly-unregistered
Has anyone deployed
I would go with wotaskd/monitor. You can more easily run multiple
instances; each instance gives you another database connection.
Alternatively, you can set the property:
er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=3
And this will give you a pool of database connections
On May 30, 2012, at 7:13 AM, John Huss wrote:
I would go with wotaskd/monitor. You can more easily run multiple instances;
each instance gives you another database connection.
Alternatively, you can set the property:
er.extensions.ERXObjectStoreCoordinatorPool.maxCoordinators=3
Does that mean you have a fix coming? :-)
On Wed, May 30, 2012 at 10:16 AM, Ramsey Gurley ramseygur...@gmail.comwrote:
On May 30, 2012, at 7:13 AM, John Huss wrote:
I would go with wotaskd/monitor. You can more easily run multiple
instances; each instance gives you another database
Given the way the pool is implemented, it is not fixable AFAICT. The EC is
only connected to one OSC to run cleanup. So snapshots get inserted into all
OSCs, but only get removed from one. The bigger the pool, the bigger the leak.
Persistent session storage with multiple stateless instances
On Wed, May 30, 2012 at 10:43 AM, Ramsey Gurley ramseygur...@gmail.comwrote:
Given the way the pool is implemented, it is not fixable AFAICT. The EC
is only connected to one OSC to run cleanup. So snapshots get inserted
into all OSCs, but only get removed from one. The bigger the pool, the
On May 30, 2012, at 9:31 AM, John Huss wrote:
On Wed, May 30, 2012 at 10:43 AM, Ramsey Gurley ramseygur...@gmail.com
wrote:
Given the way the pool is implemented, it is not fixable AFAICT. The EC is
only connected to one OSC to run cleanup. So snapshots get inserted into all
OSCs,
On Wed, May 30, 2012 at 10:43 AM, Ramsey Gurley ramseygur...@gmail.comwrote:
Given the way the pool is implemented, it is not fixable AFAICT. The EC
is only connected to one OSC to run cleanup. So snapshots get inserted
into all OSCs, but only get removed from one. The bigger the pool, the
I have noticed these messages too and would like to know if there is anything
that can be done about them
Tim
On 29/05/2012, at 23:31, Ron Lift rpgi...@gmail.com wrote:
At work we are migrating from RHEL 5 to RHEL 6 and also upgrading to Tomcat
6. When I deploy the current application
11 matches
Mail list logo
