As a result of this issue , my company reverted to 0.7.1 and it has been
much more stable.
On Tue, Sep 9, 2014 at 12:08 PM, Steven <email address hidden> wrote:
> This problem has a big impact on my application, no workaround seems have
> effect, should I revert to 0.71 ??
> Seems that there is no interest into fixing this issue.. there is
> something planned about this ?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1243551
>
> Title:
> Spontaneous closing of the connection by BoneCP connection pool
>
> Status in BoneCP - Java Database Connection Pool:
> Triaged
>
> Bug description:
> Application (1 test component) is using BoneCP connection pool. All
> the things are usually working fine (getting connection, releasing,
> ....) but sometimes in the random time happen that some connection is
> spontaneously closed.
>
> This is the output from log4j:
>
>
> -----------------------------------------------------------------------------------------------
> com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No
> operations allowed after connection closed.
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
> at com.mysql.jdbc.Util.getInstance(Util.java:386)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1013)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:987)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:982)
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:927)
> at
> com.mysql.jdbc.ConnectionImpl.throwConnectionClosedException(ConnectionImpl.java:1205)
> at com.mysql.jdbc.ConnectionImpl.checkClosed(ConnectionImpl.java:1197)
> at
> com.mysql.jdbc.ConnectionImpl.createStatement(ConnectionImpl.java:2483)
> at
> com.mysql.jdbc.ConnectionImpl.createStatement(ConnectionImpl.java:2465)
> at com.radar.database.Connection.createStatement(Connection.java:218)
> at
> com.jolbox.bonecp.ConnectionHandle.createStatement(ConnectionHandle.java:718)
> at
> com.arbitrage.live.factor.FactorComponent.calculateOverallFactors(FactorComponent.java:181)
> at
> com.arbitrage.live.factor.FactorComponent.access$1000(FactorComponent.java:28)
> at
> com.arbitrage.live.factor.FactorComponent$ProcessMatches.run(FactorComponent.java:139)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
>
>
> -----------------------------------------------------------------------------------------------
>
> So I don't know if it is bug, or just some configuration issue about
> liveness of the connection.
> Idle timeout is set to 60 seconds, min connections = 2, max connections
> = 5.
>
> When the connection was closed, it was normally used by 1 thread of
> application, so it wasn't in the pool, so I think that it should not
> be closed spontaneously.
>
> Thanks for reply.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/bonecp/+bug/1243551/+subscriptions
>
As a result of this issue , my company reverted to 0.7.1 and it has been
much more stable.
On Tue, Sep 9, 2014 at 12:08 PM, Steven <email address hidden> wrote:
> This problem has a big impact on my application, no workaround seems have /bugs.launchpad .net/bugs/ 1243551 ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ---- jdbc.exceptions .jdbc4. MySQLNonTransie ntConnectionExc eption: No NativeConstruct orAccessorImpl. newInstance0( Native Method) NativeConstruct orAccessorImpl. newInstance( NativeConstruct orAccessorImpl. java:39) DelegatingConst ructorAccessorI mpl.newInstance (DelegatingCons tructorAccessor Impl.java: 27) reflect. Constructor. newInstance( Constructor. java:513) jdbc.Util. handleNewInstan ce(Util. java:411) jdbc.Util. getInstance( Util.java: 386) jdbc.SQLError. createSQLExcept ion(SQLError. java:1013) jdbc.SQLError. createSQLExcept ion(SQLError. java:987) jdbc.SQLError. createSQLExcept ion(SQLError. java:982) jdbc.SQLError. createSQLExcept ion(SQLError. java:927) jdbc.Connection Impl.throwConne ctionClosedExce ption(Connectio nImpl.java: 1205) jdbc.Connection Impl.checkClose d(ConnectionImp l.java: 1197) jdbc.Connection Impl.createStat ement(Connectio nImpl.java: 2483) jdbc.Connection Impl.createStat ement(Connectio nImpl.java: 2465) database. Connection. createStatement (Connection. java:218) bonecp. ConnectionHandl e.createStateme nt(ConnectionHa ndle.java: 718) live.factor. FactorComponent .calculateOvera llFactors( FactorComponent .java:181) live.factor. FactorComponent .access$ 1000(FactorComp onent.java: 28) live.factor. FactorComponent $ProcessMatches .run(FactorComp onent.java: 139) concurrent. Executors$ RunnableAdapter .call(Executors .java:441) concurrent. FutureTask$ Sync.innerRunAn dReset( FutureTask. java:317) concurrent. FutureTask. runAndReset( FutureTask. java:150) concurrent. ScheduledThread PoolExecutor$ ScheduledFuture Task.access$ 101(ScheduledTh readPoolExecuto r.java: 98) concurrent. ScheduledThread PoolExecutor$ ScheduledFuture Task.runPeriodi c(ScheduledThre adPoolExecutor. java:180) concurrent. ScheduledThread PoolExecutor$ ScheduledFuture Task.run( ScheduledThread PoolExecutor. java:204) concurrent. ThreadPoolExecu tor$Worker. runTask( ThreadPoolExecu tor.java: 886) concurrent. ThreadPoolExecu tor$Worker. run(ThreadPoolE xecutor. java:908) Thread. run(Thread. java:662) ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ------- ---- /bugs.launchpad .net/bonecp/ +bug/1243551/ +subscriptions
> effect, should I revert to 0.71 ??
> Seems that there is no interest into fixing this issue.. there is
> something planned about this ?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https:/
>
> Title:
> Spontaneous closing of the connection by BoneCP connection pool
>
> Status in BoneCP - Java Database Connection Pool:
> Triaged
>
> Bug description:
> Application (1 test component) is using BoneCP connection pool. All
> the things are usually working fine (getting connection, releasing,
> ....) but sometimes in the random time happen that some connection is
> spontaneously closed.
>
> This is the output from log4j:
>
>
> -------
> com.mysql.
> operations allowed after connection closed.
> at sun.reflect.
> at
> sun.reflect.
> at
> sun.reflect.
> at java.lang.
> at com.mysql.
> at com.mysql.
> at com.mysql.
> at com.mysql.
> at com.mysql.
> at com.mysql.
> at
> com.mysql.
> at com.mysql.
> at
> com.mysql.
> at
> com.mysql.
> at com.radar.
> at
> com.jolbox.
> at
> com.arbitrage.
> at
> com.arbitrage.
> at
> com.arbitrage.
> at
> java.util.
> at
> java.util.
> at java.util.
> at
> java.util.
> at
> java.util.
> at
> java.util.
> at
> java.util.
> at
> java.util.
> at java.lang.
>
>
> -------
>
> So I don't know if it is bug, or just some configuration issue about
> liveness of the connection.
> Idle timeout is set to 60 seconds, min connections = 2, max connections
> = 5.
>
> When the connection was closed, it was normally used by 1 thread of
> application, so it wasn't in the pool, so I think that it should not
> be closed spontaneously.
>
> Thanks for reply.
>
> To manage notifications about this bug go to:
> https:/
>