| [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1794634] |
Tue, 04 September 2018 09:14 |
 Linuxhippy Mising name
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Hi,
We use CDO with a JDBC store as part of a larger application, which also performs "traditional" JDBC database access.
Currently an application-wide connection pool is used and CDOs internal pooling is actually considered harmful in this scenario by our admins.
I wonder - are there any downsides / issues to expect when setting reader- and writerPoolCapacity to 0 when the DataSource is backed by a connection pool anyway?
The reason I ask is because when setting the internal pool capacities to 0, I see the following Exceptions in the application logs:
java.lang.InterruptedException: null
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302) ~[na:1.8.0_121]
at java.util.concurrent.Semaphore.acquire(Semaphore.java:312) ~[na:1.8.0_121]
at org.eclipse.net4j.util.lifecycle.Lifecycle.lock(Lifecycle.java:306) ~[na:na]
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalDeactivate(Lifecycle.java:119) ~[na:na]
at org.eclipse.net4j.util.lifecycle.Lifecycle.deactivate(Lifecycle.java:167) ~[na:na]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:234) ~[na:na]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:224) ~[na:na]
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.deactivate(LifecycleUtil.java:250) ~[na:na]
at org.eclipse.emf.cdo.spi.server.StoreAccessorPool.disposeStoreAccessor(StoreAccessorPool.java:182) ~[na:na]
at org.eclipse.emf.cdo.spi.server.StoreAccessorPool.addStoreAccessor(StoreAccessorPool.java:111) ~[na:na]
at org.eclipse.emf.cdo.spi.server.Store.releaseAccessor(Store.java:429) ~[na:na]
at org.eclipse.emf.cdo.spi.server.StoreAccessorBase.release(StoreAccessorBase.java:135) ~[na:na]
at org.eclipse.emf.cdo.server.StoreThreadLocal.release(StoreThreadLocal.java:118) ~[na:na]
at org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:332) ~[na:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_121]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[na:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) ~[na:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) ~[na:1.8.0_121]
at java.lang.Thread.run(Thread.java:745) ~[na:1.8.0_121]
followed by the connection pool, complaining connections have leaked:
WARNUNG: Connection leak detection triggered for oracle.jdbc.driver.T4CConnection@63e6ab40, stack trace follows
java.lang.Exception: Apparent connection leak detected
at org.eclipse.net4j.internal.db.DataSourceConnectionProvider.getConnection(DataSourceConnectionProvider.java:50)
at org.eclipse.net4j.internal.db.DBDatabase.getConnection(DBDatabase.java:139)
at org.eclipse.net4j.internal.db.DBDatabase.getConnection(DBDatabase.java:1)
at org.eclipse.emf.cdo.server.internal.db.DBStoreAccessor.doActivate(DBStoreAccessor.java:804)
at org.eclipse.net4j.util.lifecycle.Lifecycle.internalActivate(Lifecycle.java:76)
at org.eclipse.net4j.util.lifecycle.Lifecycle.activate(Lifecycle.java:162)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:127)
at org.eclipse.net4j.util.lifecycle.LifecycleUtil.activate(LifecycleUtil.java:117)
at org.eclipse.emf.cdo.spi.server.Store.getReader(Store.java:367)
at org.eclipse.emf.cdo.server.internal.db.DBStore.getReader(DBStore.java:456)
at org.eclipse.emf.cdo.server.internal.db.DBStore.getReader(DBStore.java:1)
at org.eclipse.emf.cdo.server.StoreThreadLocal.getAccessor(StoreThreadLocal.java:89)
at org.eclipse.emf.cdo.internal.server.Repository.getQueryHandler(Repository.java:1243)
at org.eclipse.emf.cdo.internal.server.QueryManager$QueryContext.run(QueryManager.java:309)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Thank you in advance, Clemens
Just to be curious - is there any technical reason behind using separate reader/writer connection pools?
[Updated on: Tue, 04 September 2018 10:01] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.01821 seconds
Search
Help
Register
Login
Home
