| [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1794634] |
Tue, 04 September 2018 05:14  |
Eclipse User |
|
|
|
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 06:01] by Moderator |
|
|
| Re: [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1796799 is a reply to message #1794634] |
Fri, 19 October 2018 01:29  |
| Eclipse User |
|
|
|
The CDO tests seem to run successfully with pool capacities set to zero, and even with pools set to null. You'd likely not profit from CDOs statement caches without CDOs pools. The test suite seems to be ~3% slower then. Just to be curious - what harm are your admins expecting when you use CDOs internal pooling?
I don't recall the reason for separate reader/writer connection pools anymore. They're likely a historical relict.
|
|
|
Powered by
FUDForum. Page generated in 0.03861 seconds
Home