[JBoss JIRA] (WFCORE-4181) Add support for registering a single JVM / Server wide default SSLContext
by Darran Lofthouse (Jira)
Darran Lofthouse created WFCORE-4181:
----------------------------------------
Summary: Add support for registering a single JVM / Server wide default SSLContext
Key: WFCORE-4181
URL: https://issues.jboss.org/browse/WFCORE-4181
Project: WildFly Core
Issue Type: Feature Request
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.0.0.Alpha5
By registering a global SSLContext libraries used within the application server can make use of a managed SSLContext instead of relying on one automatically being created through the standard system properties.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11249) EJB Timer is not properly set when the database is different than the defaults
by Filippe Spolti (Jira)
Filippe Spolti created WFLY-11249:
-------------------------------------
Summary: EJB Timer is not properly set when the database is different than the defaults
Key: WFLY-11249
URL: https://issues.jboss.org/browse/WFLY-11249
Project: WildFly
Issue Type: Task
Components: EJB
Affects Versions: 14.0.0.Final
Reporter: Filippe Spolti
Assignee: Filippe Spolti
When using EJB timers the tables will be created during startup based on the database type.
If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail:
time-store example:
{code:xml}
<timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds">
<data-stores>
<file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
<database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/>
</data-stores>
</timer-service>
{code}
Issue:
{code:java}
2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration
...
2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1)
2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354)
at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127)
at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264)
at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628)
at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver name, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11248) EJB Timer is not properly set when the database is different than the defaults
by Filippe Spolti (Jira)
[ https://issues.jboss.org/browse/WFLY-11248?page=com.atlassian.jira.plugin... ]
Filippe Spolti updated WFLY-11248:
----------------------------------
Issue Type: Bug (was: Task)
> EJB Timer is not properly set when the database is different than the defaults
> ------------------------------------------------------------------------------
>
> Key: WFLY-11248
> URL: https://issues.jboss.org/browse/WFLY-11248
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 14.0.0.Final
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Major
>
> When using EJB timers the tables will be created during startup based on the database type.
> If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail:
> time-store example:
> {code:xml}
> <timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds">
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> <database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/>
> </data-stores>
> </timer-service>
> {code}
> Issue:
> {code:java}
> 2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration
> ...
> 2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1)
> 2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120)
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
> at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
> at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354)
> at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127)
> at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264)
> at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver name, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11248) EJB Timer is not properly set when the database is different than the defaults
by Filippe Spolti (Jira)
[ https://issues.jboss.org/browse/WFLY-11248?page=com.atlassian.jira.plugin... ]
Filippe Spolti updated WFLY-11248:
----------------------------------
Description:
When using EJB timers the tables will be created during startup based on the database type.
If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail:
time-store example:
{code:xml}
<timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds">
<data-stores>
<file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
<database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/>
</data-stores>
</timer-service>
{code}
Issue:
{code:java}
2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration
...
2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1)
2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354)
at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127)
at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264)
at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628)
at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver name, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57.
was:
When using EJB timers the tables will be created during startup based on the database type.
If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail:
time-store example:
{code:xml}
<timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds">
<data-stores>
<file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
<database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/>
</data-stores>
</timer-service>
{code}
Issue:
{code:java}
2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration
...
2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1)
2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354)
at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127)
at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264)
at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628)
at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57.
> EJB Timer is not properly set when the database is different than the defaults
> ------------------------------------------------------------------------------
>
> Key: WFLY-11248
> URL: https://issues.jboss.org/browse/WFLY-11248
> Project: WildFly
> Issue Type: Task
> Components: EJB
> Affects Versions: 14.0.0.Final
> Reporter: Filippe Spolti
> Assignee: Filippe Spolti
> Priority: Major
>
> When using EJB timers the tables will be created during startup based on the database type.
> If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail:
> time-store example:
> {code:xml}
> <timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds">
> <data-stores>
> <file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
> <database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/>
> </data-stores>
> </timer-service>
> {code}
> Issue:
> {code:java}
> 2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration
> ...
> 2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1)
> 2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120)
> at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
> at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
> at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354)
> at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127)
> at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264)
> at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292)
> at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver name, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11248) EJB Timer is not properly set when the database is different than the defaults
by Filippe Spolti (Jira)
Filippe Spolti created WFLY-11248:
-------------------------------------
Summary: EJB Timer is not properly set when the database is different than the defaults
Key: WFLY-11248
URL: https://issues.jboss.org/browse/WFLY-11248
Project: WildFly
Issue Type: Task
Components: EJB
Affects Versions: 14.0.0.Final
Reporter: Filippe Spolti
Assignee: Filippe Spolti
When using EJB timers the tables will be created during startup based on the database type.
If we set the *database* different than the default names, i.e. mariadb, mysql, it will fail:
time-store example:
{code:xml}
<timer-service thread-pool-name="default" default-data-store="ejb_timer-EJB_TIMER_ds">
<data-stores>
<file-data-store name="default-file-store" path="timer-service-data" relative-to="jboss.server.data.dir"/>
<database-data-store name="ejb_timer-EJB_TIMER_ds" datasource-jndi-name="java:jboss/datasources/jbpmDS_EJBTimer" database="mysql57" partition="ejb_timer-EJB_TIMER_part" refresh-interval="30000"/>
</data-stores>
</timer-service>
{code}
Issue:
{code:java}
2018-10-25 13:06:57,541 DEBUG [org.jboss.as.ejb3.timer] (MSC service thread 1-5) Database dialect 'mysql57' read from configuration
...
2018-10-25 13:06:58,056 INFO [org.jboss.ws.common.management] (MSC service thread 1-4) JBWS022052: Starting JBossWS 5.2.3.Final (Apache CXF 3.2.5.jbossorg-1)
2018-10-25 13:06:58,222 ERROR [org.jboss.as.ejb3.timer] (MSC service thread 1-5) WFLYEJB0163: Cannot create table for timer persistence: java.sql.SQLSyntaxErrorException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'PRIMARY KEY NOT NULL, TIMED_OBJECT_ID VARCHAR NOT NULL, INITIAL_DATE TIMESTAMP, ' at line 1
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:120)
at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
at com.mysql.cj.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1354)
at com.mysql.cj.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2127)
at com.mysql.cj.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1264)
at com.mysql.cj.jdbc.StatementWrapper.executeUpdate(StatementWrapper.java:628)
at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:430)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.checkDatabase(DatabaseTimerPersistence.java:292)
at org.jboss.as.ejb3.timerservice.persistence.database.DatabaseTimerPersistence.start(DatabaseTimerPersistence.java:166)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1736)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1698)
at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1556)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
at java.lang.Thread.run(Thread.java:748)
{code}
This issue was spotted on OpenShift environment, the behavior there is to use as the database type on the datastore the same value than the datasource driver, in this specific case, we we're trying a custom mysql jdbc driver version and named it to mysql57.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (DROOLS-3190) fix typo in Test editor intro text.
by Liz Clayton (Jira)
Liz Clayton created DROOLS-3190:
-----------------------------------
Summary: fix typo in Test editor intro text.
Key: DROOLS-3190
URL: https://issues.jboss.org/browse/DROOLS-3190
Project: Drools
Issue Type: Sub-task
Reporter: Liz Clayton
Assignee: Gabriele Cardosi
Current text in UI:
"To create a test template, define the "Given" and "Expect" columns *by using use* the expression editor below."
* should not include both using and use.
Possible rewording: To fix typo and perhaps clarify the task:
"Define the "Given" and "Expect" statements using the expression editor below."
* or whatever [~stetson.robinson] [~g.dey18] recommend. It might be nice to add something about being able to type an expression directly into the cell, wdyt?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11241) CoarseWebFailoverTestCase.test fails intermittently (after Infinispan 9.4.0 upgrade?)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11241?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-11241:
----------------------------------
Affects Version/s: No Release
> CoarseWebFailoverTestCase.test fails intermittently (after Infinispan 9.4.0 upgrade?)
> -------------------------------------------------------------------------------------
>
> Key: WFLY-11241
> URL: https://issues.jboss.org/browse/WFLY-11241
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Started to fail intermittently again after 19 Oct, which seems to correlate with Infinispan 9.4.0.Final upgrade on 17 Oct.
> {code}
> 07:17:11,909 INFO [io.undertow.servlet] (default task-1) /CoarseWebFailoverTestCase/simple, value = 3
> 07:17:12,491 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t2) [Context=CoarseWebFailoverTestCase.war] ISPN100009: Advancing to rebalance phase READ_NEW_WRITE_ALL, topology id 33
> 07:17:12,503 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (remote-thread--p6-t3) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(nUIcjLVQdeTRWxsBIwHRSRarTu75v5FgXeZQ4Lnt) in behalf of transaction GlobalTx:node-3:24. Current owner GlobalTx:node-2:30.
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:252)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:337)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:137)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:153)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:122)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:208)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:191)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
> at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:223)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
> at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
> at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
> at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:95)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> at java.lang.Thread.run(Thread.java:748)
> 07:17:12,511 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (remote-thread--p6-t3) ISPN000071: Caught exception when handling command LockControlCommand{cache=CoarseWebFailoverTestCase.war, keys=[SessionCreationMetaDataKey(nUIcjLVQdeTRWxsBIwHRSRarTu75v5FgXeZQ4Lnt)], flags=[ZERO_LOCK_ACQUISITION_TIMEOUT, FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTx:node-3:24}: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(nUIcjLVQdeTRWxsBIwHRSRarTu75v5FgXeZQ4Lnt) in behalf of transaction GlobalTx:node-3:24. Current owner GlobalTx:node-2:30.
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:252)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:337)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:137)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:153)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:122)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:208)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:191)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
> at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:223)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
> at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
> at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
> at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:95)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> at java.lang.Thread.run(Thread.java:748)
> 07:17:13,090 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t3) [Context=CoarseWebFailoverTestCase.war] ISPN100010: Finished rebalance with members [node-3, node-2], topology id 34
> 07:17:14,298 INFO [io.undertow.servlet] (default task-2) /CoarseWebFailoverTestCase/simple, value = 4
> {code}
> https://gist.github.com/rhusar/496f1c7c5a308db1901a81a4437b570e
> https://ci.wildfly.org/viewLog.html?buildId=125879&tab=buildResultsDiv&bu...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months
[JBoss JIRA] (WFLY-11241) CoarseWebFailoverTestCase.test fails intermittently (after Infinispan 9.4.0 upgrade?)
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-11241?page=com.atlassian.jira.plugin... ]
Radoslav Husar reassigned WFLY-11241:
-------------------------------------
Assignee: Radoslav Husar (was: Paul Ferraro)
> CoarseWebFailoverTestCase.test fails intermittently (after Infinispan 9.4.0 upgrade?)
> -------------------------------------------------------------------------------------
>
> Key: WFLY-11241
> URL: https://issues.jboss.org/browse/WFLY-11241
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: No Release
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Major
>
> Started to fail intermittently again after 19 Oct, which seems to correlate with Infinispan 9.4.0.Final upgrade on 17 Oct.
> {code}
> 07:17:11,909 INFO [io.undertow.servlet] (default task-1) /CoarseWebFailoverTestCase/simple, value = 3
> 07:17:12,491 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t2) [Context=CoarseWebFailoverTestCase.war] ISPN100009: Advancing to rebalance phase READ_NEW_WRITE_ALL, topology id 33
> 07:17:12,503 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (remote-thread--p6-t3) ISPN000136: Error executing command LockControlCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(nUIcjLVQdeTRWxsBIwHRSRarTu75v5FgXeZQ4Lnt) in behalf of transaction GlobalTx:node-3:24. Current owner GlobalTx:node-2:30.
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:252)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:337)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:137)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:153)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:122)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:208)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:191)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
> at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:223)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
> at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
> at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
> at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:95)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> at java.lang.Thread.run(Thread.java:748)
> 07:17:12,511 WARN [org.infinispan.remoting.inboundhandler.NonTotalOrderTxPerCacheInboundInvocationHandler] (remote-thread--p6-t3) ISPN000071: Caught exception when handling command LockControlCommand{cache=CoarseWebFailoverTestCase.war, keys=[SessionCreationMetaDataKey(nUIcjLVQdeTRWxsBIwHRSRarTu75v5FgXeZQ4Lnt)], flags=[ZERO_LOCK_ACQUISITION_TIMEOUT, FORCE_WRITE_LOCK], unlock=false, gtx=GlobalTx:node-3:24}: org.infinispan.util.concurrent.TimeoutException: Could not acquire lock on SessionCreationMetaDataKey(nUIcjLVQdeTRWxsBIwHRSRarTu75v5FgXeZQ4Lnt) in behalf of transaction GlobalTx:node-3:24. Current owner GlobalTx:node-2:30.
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.timeout(DefaultPendingLockManager.java:252)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitOn(DefaultPendingLockManager.java:337)
> at org.infinispan.util.concurrent.locks.impl.DefaultPendingLockManager.awaitPendingTransactionsForAllKeys(DefaultPendingLockManager.java:137)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockAllKeys(AbstractTxLockingInterceptor.java:153)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockAllOrRegisterBackupLock(AbstractTxLockingInterceptor.java:122)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.localLockCommandWork(PessimisticLockingInterceptor.java:208)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.lambda$new$0(PessimisticLockingInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenApply(BaseAsyncInterceptor.java:81)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitLockControlCommand(PessimisticLockingInterceptor.java:191)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:183)
> at org.infinispan.interceptors.impl.TxInterceptor.visitLockControlCommand(TxInterceptor.java:223)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54)
> at org.infinispan.interceptors.BaseAsyncInterceptor.lambda$new$0(BaseAsyncInterceptor.java:22)
> at org.infinispan.interceptors.InvocationSuccessFunction.apply(InvocationSuccessFunction.java:25)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:70)
> at org.infinispan.interceptors.InvocationStage.thenApply(InvocationStage.java:45)
> at org.infinispan.interceptors.BaseAsyncInterceptor.asyncInvokeNext(BaseAsyncInterceptor.java:224)
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:46)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitLockControlCommand(StateTransferInterceptor.java:90)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56)
> at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitLockControlCommand(DDAsyncInterceptor.java:160)
> at org.infinispan.commands.control.LockControlCommand.acceptVisitor(LockControlCommand.java:117)
> at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234)
> at org.infinispan.commands.control.LockControlCommand.invokeAsync(LockControlCommand.java:126)
> at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:95)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.invoke(BaseBlockingRunnable.java:99)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.runAsync(BaseBlockingRunnable.java:71)
> at org.infinispan.remoting.inboundhandler.BaseBlockingRunnable.run(BaseBlockingRunnable.java:40)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at org.wildfly.clustering.service.concurrent.ClassLoaderThreadFactory.lambda$newThread$0(ClassLoaderThreadFactory.java:47)
> at java.lang.Thread.run(Thread.java:748)
> 07:17:13,090 INFO [org.infinispan.CLUSTER] (remote-thread--p6-t3) [Context=CoarseWebFailoverTestCase.war] ISPN100010: Finished rebalance with members [node-3, node-2], topology id 34
> 07:17:14,298 INFO [io.undertow.servlet] (default task-2) /CoarseWebFailoverTestCase/simple, value = 4
> {code}
> https://gist.github.com/rhusar/496f1c7c5a308db1901a81a4437b570e
> https://ci.wildfly.org/viewLog.html?buildId=125879&tab=buildResultsDiv&bu...
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 7 months