| [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1794634] |
Tue, 04 September 2018 09:14  |
 Linuxhippy Mising name
Messages: 16
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 |
|
|
| Re: [CDO] readerPoolCapacity/writerPoolCapacity = 0 ok? [message #1796799 is a reply to message #1794634] |
Fri, 19 October 2018 05:29  |
|
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.02125 seconds
Search
Help
Register
Login
Home
