[JBoss JIRA] (JBJCA-1328) Communications link failure - unable to create valid connections
by Thirukkumaran Natarajan (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1328?page=com.atlassian.jira.plugin... ]
Thirukkumaran Natarajan commented on JBJCA-1328:
------------------------------------------------
I am facing this issue in Keycloak, any workaround available?
> Communications link failure - unable to create valid connections
> ----------------------------------------------------------------
>
> Key: JBJCA-1328
> URL: https://issues.jboss.org/browse/JBJCA-1328
> Project: IronJacamar
> Issue Type: Bug
> Components: JDBC, Standalone, Validator
> Environment: Server: Wildfly 10
> OS: CentOS 7
> Database: MySQL 5.7.14
> Reporter: Oscar Calderon
> Assignee: Stefano Maestri
>
> There's a connection pool configured in Wildfly 10 to connect to MySQL database. A Spring REST app is deployed and uses the connection pool. Problem is, it looks like it maintains the opened connections like they were alive, but when DB timeout passes and application requests a connection from pool, it fails with the next error:
> {{code}}
> 2016-08-20 10:05:05,484 DEBUG [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-17) could not extract ResultSet [n/a]: com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
> The last packet successfully received from the server was 3,999,184 milliseconds ago. The last packet sent successfully to the server was 47 milliseconds ago.
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:404)
> at com.mysql.jdbc.SQLError.createCommunicationsException(SQLError.java:988)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3552)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3452)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3893)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2526)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2673)
> at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2549)
> at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1861)
> at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1962)
> at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeQuery(WrappedPreparedStatement.java:504)
> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.extract(ResultSetReturnImpl.java:70)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:2117)
> at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1905)
> at org.hibernate.loader.Loader.executeQueryStatement(Loader.java:1881)
> at org.hibernate.loader.Loader.doQuery(Loader.java:926)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:343)
> at org.hibernate.loader.Loader.doList(Loader.java:2609)
> at org.hibernate.loader.Loader.doList(Loader.java:2592)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2424)
> at org.hibernate.loader.Loader.list(Loader.java:2419)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:502)
> at org.hibernate.hql.internal.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:371)
> at org.hibernate.engine.query.spi.HQLQueryPlan.performList(HQLQueryPlan.java:216)
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1450)
> at org.hibernate.query.internal.AbstractProducedQuery.doList(AbstractProducedQuery.java:1402)
> at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1374)
> at org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1420)
> at com.hayturno.spring.dao.PacienteDAO.getPatientInfo(PacienteDAO.java:28)
> at com.hayturno.spring.service.AuthorizationService.isValidUser(AuthorizationService.java:29)
> at com.hayturno.spring.controller.BaseController.authorizeUser(BaseController.java:41)
> at com.hayturno.spring.controller.DoctorController.getDoctorsList(DoctorController.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
> at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
> at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
> at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
> at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
> at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> Caused by: java.io.EOFException: Can not read response from server. Expected to read 4 bytes, read 0 bytes before connection was unexpectedly lost.
> at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:3004)
> at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:3462)
> ... 73 more
> 2016-08-20 10:05:05,488 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-17) SQL Error: 0, SQLState: 08S01
> 2016-08-20 10:05:05,488 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (default task-17) Communications link failure
> The last packet successfully received from the server was 3,999,184 milliseconds ago. The last packet sent successfully to the server was 47 milliseconds ago.
> 2016-08-20 10:05:05,493 DEBUG [org.hibernate.resource.jdbc.internal.ResourceRegistryStandardImpl] (default task-17) Exception clearing maxRows/queryTimeout [No operations allowed after statement closed.]
> 2016-08-20 10:05:05,499 DEBUG [org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl] (default task-17) JDBC transaction marked for rollback-only (exception provided for stack trace): java.lang.Exception: exception just for purpose of providing stack trace
> at org.hibernate.resource.transaction.backend.jdbc.internal.JdbcResourceLocalTransactionCoordinatorImpl$TransactionDriverControlImpl.markRollbackOnly(JdbcResourceLocalTransactionCoordinatorImpl.java:254)
> at org.hibernate.engine.transaction.internal.TransactionImpl.setRollbackOnly(TransactionImpl.java:143)
> at org.hibernate.Transaction.markRollbackOnly(Transaction.java:68)
> at org.hibernate.internal.AbstractSharedSessionContract.markForRollbackOnly(AbstractSharedSessionContract.java:340)
> at org.hibernate.internal.ExceptionConverterImpl.handlePersistenceException(ExceptionConverterImpl.java:271)
> at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:148)
> at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:155)
> at org.hibernate.query.internal.AbstractProducedQuery.list(AbstractProducedQuery.java:1383)
> at org.hibernate.query.internal.AbstractProducedQuery.getSingleResult(AbstractProducedQuery.java:1420)
> at com.hayturno.spring.dao.PacienteDAO.getPatientInfo(PacienteDAO.java:28)
> at com.hayturno.spring.service.AuthorizationService.isValidUser(AuthorizationService.java:29)
> at com.hayturno.spring.controller.BaseController.authorizeUser(BaseController.java:41)
> at com.hayturno.spring.controller.DoctorController.getDoctorsList(DoctorController.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
> at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
> at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
> at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
> at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
> at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
> at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
> at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
> at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
> at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> 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)
> {{code}}
> Looking above this, we have the next output from JCA:
> {{code}}
> 2016-08-20 08:59:21,290 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 08:59:31,292 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:00:13,707 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:00:13,707 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:00:13,708 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471704913708) [2/30]
> 2016-08-20 09:01:31,296 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:01:41,298 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:02:43,709 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:02:43,709 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:02:43,711 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705063710) [2/30]
> 2016-08-20 09:03:41,302 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:03:51,304 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:05:13,712 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:05:13,712 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:05:13,716 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705213715) [2/30]
> 2016-08-20 09:05:51,307 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:06:01,308 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:07:43,716 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:07:43,717 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:07:43,717 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705363717) [2/30]
> 2016-08-20 09:08:01,310 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:08:11,312 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:10:11,315 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:10:13,718 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:10:13,718 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:10:13,718 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705513718) [2/30]
> 2016-08-20 09:10:21,318 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:12:21,322 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:12:31,324 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:12:43,719 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:12:43,719 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:12:43,719 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705663719) [2/30]
> 2016-08-20 09:14:31,328 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:14:41,331 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:15:13,720 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:15:13,722 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705813721) [2/30]
> 2016-08-20 09:15:13,720 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:16:41,334 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:16:51,336 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:17:43,723 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:17:43,724 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471705963724) [2/30]
> 2016-08-20 09:17:43,724 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:18:51,340 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:19:01,342 DEBUG [org.jboss.ejb.client.txn] (Periodic Recovery) Send recover request for transaction origin node identifier 1 to EJB receiver with node name centos-2gb-nyc1-01
> 2016-08-20 09:20:13,725 DEBUG [org.jboss.jca.core.connectionmanager.pool.validator.ConnectionValidator] (ConnectionValidator) Notifying pools, interval: 150000
> 2016-08-20 09:20:13,725 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (IdleRemover) Notifying pools, interval: 150000
> 2016-08-20 09:20:13,727 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (IdleRemover) HayTurno3DS: removeIdleConnections(1471706113727) [2/30]
> ...
> {{code}}
> It looks like pool validates idle connections and kills the idle ones and it should create new ones, but it doesn´t work. Why it cannot have valid connections? Also, from where does it get 150000 interval?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9289) Name of domain is not reflected on the Wildfly tag
by Martin Stefanko (JIRA)
Martin Stefanko created WFLY-9289:
-------------------------------------
Summary: Name of domain is not reflected on the Wildfly tag
Key: WFLY-9289
URL: https://issues.jboss.org/browse/WFLY-9289
Project: WildFly
Issue Type: Bug
Components: Web Console
Affects Versions: 10.0.0.Final
Reporter: Martin Stefanko
Assignee: Martin Stefanko
If we define domain name in domain.xml in WildFly 9.0.2 then it is being displayed on the Management console tab but in WF 10 it does not display the domain name on WF Management Console Tab(domain controller)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi,
As suggested, I have created a pull request.
https://github.com/wildfly/wildfly/pull/10465
Before doing so, I have tried to follow the guide line of doing the upstream/master rebase to ensure no merge conflicts take place.
I did not squash all the commits, into a single commit. I think it might make your life easier to have separate commmits in particular in regards to any pom dependency changes, which I am quite sure those java-ee.api and such you will most likely want to fine tune with other depencies already being managed in the parent pom.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ]
Nuno Godinho de Matos commented on WFLY-8954:
---------------------------------------------
Hi Scott,
I have done as recommended.
https://github.com/99sono/wildfly/commit/dd29331a9b0270fcb0e1e3d0f9d6a811...
You are essentially explaining that the java:jboss/TransactionSynchronizationRegistry is "technically" more readily available to use than the objects that are (aliased) into the java:comp namespace. Did I understand it correctly?
I will read the instructions on the document and make the pull request.
// NOTE: I have started trying to investigate that problem with eclipselink trying to return a used connection to the connection manager, and the connection manager reporting it has no clue what connection is being returned. I have increased the logging level on "org.jboss.jca.core.tracer.Tracer" - I have the feeling that the connectionmanager.ccm.CachedConnectionManager is somehow losing the reference to the connection. Unfortunately, in a small sample application where I tried to reproduce the firing of the event, oserving the event on new transaction and so on ... everything went out perfectly. Could not make it happen. But based on the log file, I see that the flow of statements:
{panel}
####2017-09-02 13:18:28,282 ThreadId:321 ALL connectionmanager.ccm.CachedConnectionManager - registering connection from connection manager: org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl@fdf6032, connection : org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@73598cd4, key: org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction@76d9d984 <LogContext:Facade> <ServerService Thread Pool -- 173>
{panel}
And later:
{panel}
####2017-09-02 13:18:30,655 ThreadId:321 ALL connectionmanager.ccm.CachedConnectionManager - unregistering connection from connection manager: org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl@fdf6032, connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7@73598cd4, key: org.jboss.as.connector.deployers.ra.processors.CachedConnectionManagerSetupProcessor$CachedConnectionManagerSetupAction@76d9d984 <LogContext:Facade> <ServerService Thread Pool -- 173>
{panel}
Only appear once each. And it is during this unregister that the blow up happens. So it looks as if in the in between time after the "registering" the connection manager simply lost track of the connection.
I will have to open a JIRA for this, I suppose. I want to investigate it a bit more, but I have very little time avalable to play around this.
I will let you know as soon as the pull request is sent out.
Kindest regards.
> Wildfly 10 with eclipselink Onscucess observer gets stale entity
> ----------------------------------------------------------------
>
> Key: WFLY-8954
> URL: https://issues.jboss.org/browse/WFLY-8954
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Reporter: Nuno Godinho de Matos
> Assignee: Scott Marlow
>
> Hi,
> In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink.
> When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success.
> Then the observer will be working with stale entities that do not reflect the modifications done to the entity.
> A sample application for this issue is available in:
> https://github.com/99sono/wildfly10-observe-on-success-stale-entity
> The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation.
> Many thanks for taking a look.
> Kindest regards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos edited comment on WFCORE-3210 at 9/2/17 6:43 AM:
-----------------------------------------------------------------------
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. when using log4j, someone who uses OFF to log statements is doing something completely wrong. It is making those log statements become impossible to filter out.
This bug leads to the fact that if configure the logging susystem to trace IRON JAC AMAR - which I am trying to debug right now, this is producing on many layers log statements with level OFF. I was wondering why I could not filter them out until I realized this.
so JUL.OFF -> Log4j.OFF it is a definite NOGO.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic isolation of the custom appender during startup - making the appender useless.
Many thanks.
was (Author: nuno.godinhomatos):
Hi just a side note.
The JUL to Log4j router whose source code you have in the artifacts I have provided you still has some bugs.
- 1 - The JUL log level to Log4j level mapping is bugy.
The JUL log Level OFF shuld be mapped to the Log4j log Level ALL.
In Log4j log level OFF is the highest rank possible, above Fatal, and it is only to be used to qualify categories and never to be used to produce log statements. Someone who uses OFF to log statements does not know what he is doing.
This bug leads to the fact that IRON JAC AMAR - which I am trying to debug, is producing on many layers log statements with level OFF.
I was wondering why I could not filter them out until I realized this.
- 2 - In the cove version you have, you will have double logging of a LogRecord, whenever that log record does not come with any MDC context. I was missing a return statement.
So you will see every log event logged twice.
These bugs however should not matter for this Jira, since the theme here is occasional problematic isolation of the custom appender during startup - making the appender useless.
Many thanks.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months