[JBoss JIRA] (DROOLS-3396) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-3396?page=com.atlassian.jira.plugi... ]
Toni Rikkola updated DROOLS-3396:
---------------------------------
Sprint: 2018 Week 48-50
> CRLF in ACTION cell of xlsx spreadsheet is not treated as is
> ------------------------------------------------------------
>
> Key: DROOLS-3396
> URL: https://issues.jboss.org/browse/DROOLS-3396
> Project: Drools
> Issue Type: Bug
> Components: core engine, decision tables
> Affects Versions: 7.10.0.Final
> Environment: - RHDM7.1.0
> - Windows
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Major
> Labels: support
> Attachments: CheckTest.zip
>
>
> Customer runs rule on Windows environment.
> They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3396) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-3396?page=com.atlassian.jira.plugi... ]
Toni Rikkola commented on DROOLS-3396:
--------------------------------------
[~hiroko] I took a quick look and I can reproduce. Today I tried to narrow down the cause and I will continue the work tomorrow.
> CRLF in ACTION cell of xlsx spreadsheet is not treated as is
> ------------------------------------------------------------
>
> Key: DROOLS-3396
> URL: https://issues.jboss.org/browse/DROOLS-3396
> Project: Drools
> Issue Type: Bug
> Components: core engine, decision tables
> Affects Versions: 7.10.0.Final
> Environment: - RHDM7.1.0
> - Windows
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Major
> Labels: support
> Attachments: CheckTest.zip
>
>
> Customer runs rule on Windows environment.
> They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3396) CRLF in ACTION cell of xlsx spreadsheet is not treated as is
by Toni Rikkola (Jira)
[ https://issues.jboss.org/browse/DROOLS-3396?page=com.atlassian.jira.plugi... ]
Toni Rikkola reassigned DROOLS-3396:
------------------------------------
Assignee: Toni Rikkola (was: Mario Fusco)
> CRLF in ACTION cell of xlsx spreadsheet is not treated as is
> ------------------------------------------------------------
>
> Key: DROOLS-3396
> URL: https://issues.jboss.org/browse/DROOLS-3396
> Project: Drools
> Issue Type: Bug
> Components: core engine, decision tables
> Affects Versions: 7.10.0.Final
> Environment: - RHDM7.1.0
> - Windows
> Reporter: Hiroko Miura
> Assignee: Toni Rikkola
> Priority: Major
> Labels: support
> Attachments: CheckTest.zip
>
>
> Customer runs rule on Windows environment.
> They then want to include CRLF(\r\n) in ACTION cell of XLSX spreadsheet as a value in order to generate error message. They expect that '\r\n' is treated as is, but when the rule is fired, it converted to ';\n'. Please take a look at attached reproducer.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-10841) XA recovery warnings when server reloaded
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-10841?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-10841:
----------------------------------------
The issue should be fixed in the next Narayana release (most probably 5.9.1.Final) by fix of [~tomjenkinson] - https://github.com/jbosstm/narayana/pull/1378. The issue to be fixed in the WildFly requires the Narayana component upgrade.
> XA recovery warnings when server reloaded
> -----------------------------------------
>
> Key: WFLY-10841
> URL: https://issues.jboss.org/browse/WFLY-10841
> Project: WildFly
> Issue Type: Bug
> Components: JMS, Transactions
> Affects Versions: 13.0.0.Final, 14.0.0.Final
> Reporter: Chao Wang
> Assignee: Ondra Chaloupka
> Priority: Minor
>
> Following warning messages are outputted when server reloaded.
> {code}
> 15:33:52,740 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122015: Can not connect to XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=, factory=org-apache-activemq-artemi
> s-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA] on auto-generated resource recovery: ActiveMQNotConnectedException[errorType=NOT_CONNECTED m
> essage=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:787)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:311)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> 15:33:52,752 WARN [org.apache.activemq.artemis.service.extensions.xa.recovery] (Periodic Recovery) AMQ122008: XA Recovery can not connect to any broker on recovery [XARecoveryConfig [transportConfiguration=[TransportConfiguration(name=
> , factory=org-apache-activemq-artemis-core-remoting-impl-invm-InVMConnectorFactory) ?serverId=0], discoveryConfiguration=null, username=null, password=****, JNDI_NAME=java:/JmsXA]]
> 15:33:52,752 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMFAIL: javax.transaction.xa.XAException: Error trying to connect to any providers for xa reco
> very
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:258)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.recover(ActiveMQXAResourceWrapper.java:69)
> at org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl.recover(ActiveMQXAResourceWrapperImpl.java:106)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoverySecondPass(XARecoveryModule.java:791)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.bottomUpRecovery(XARecoveryModule.java:482)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkSecondPass(XARecoveryModule.java:233)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:150)
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:140)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:765)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:377)
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=null]
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.connect(ActiveMQXAResourceWrapper.java:345)
> at org.apache.activemq.artemis.service.extensions.xa.recovery.ActiveMQXAResourceWrapper.getDelegate(ActiveMQXAResourceWrapper.java:239)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-11450) Cannot get delegate of JMSContext during an beforeCompletion synch
by Ondra Chaloupka (Jira)
[ https://issues.jboss.org/browse/WFLY-11450?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka commented on WFLY-11450:
----------------------------------------
[~jwgmeligmeyling] please, do you have some reproducer that could be run and the behaviour could be checked with?
> Cannot get delegate of JMSContext during an beforeCompletion synch
> ------------------------------------------------------------------
>
> Key: WFLY-11450
> URL: https://issues.jboss.org/browse/WFLY-11450
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 14.0.1.Final, 8.0.0.CR1
> Environment: WildFly 14.0.1.Final, narayana 5.9.0.Final
> WildFly 8.0.0.CR1
> Reporter: Jan-Willem Gmelig Meyling
> Assignee: Matej Novotny
> Priority: Minor
> Attachments: ARJUNA016082.log
>
>
> The {{TransactionContext}} registers a {{TransactionScopeCleanup}} {{Synchronization}} with the active transaction. This prevents a {{TransactionContext}} to be opened from another {{beforeCompletion}} {{Synchronization}}, if the transacted {{JMSContext}} was not interacted with earlier in the transaction. (Because the synchronization cannot be placed)
> *Use case*
> I have a JPA post insert lifecycle listener that needs to publish an event. I'd like this to happen within the same XA transaction. The lifecycle listener is handled in during the pre-commit flush, itself invoked through another {{beforeCompletion}} transaction {{Synchronization}}.
> *Workaround*
> Flush the {{EntityManager}} and don't leave the flushing up to the {{beforeCompletion}} synchronization.
> The issue seems also described in the following Stack Overflow issue: https://stackoverflow.com/questions/21523534/jboss-wildfly-arjuna016082-s...
> (Which refers to WildFly 8.0.0.CR1)
> Back in the day, it seemed [~smarlow] suggested that an *interposed* synchronization should be registered with the {{TransactionSynchronizationRegistry}} instead.
> See the attached log for a full stack trace.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (DROOLS-3031) [DMN Designer] UX for Expand / Collapse all
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3031?page=com.atlassian.jira.plugi... ]
Liz Clayton updated DROOLS-3031:
--------------------------------
Sprint: (was: 2018 Week 48-50)
> [DMN Designer] UX for Expand / Collapse all
> -------------------------------------------
>
> Key: DROOLS-3031
> URL: https://issues.jboss.org/browse/DROOLS-3031
> Project: Drools
> Issue Type: Task
> Components: DMN Editor
> Affects Versions: 7.12.0.Final
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
>
> User should have possibility to easily expand / collapse all data types in the *manage custom data type* dialog.
> h2. Manual acceptance test
> - Expand
> -- All collapsed initially
> -- Something collapsed initially, something expanded already
> -- All expanded already
> - Collapse
> -- All expanded initially
> -- Something expanded initially, something collapsed already
> -- All collapsed already
> - No error warning in browser console log
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-10749) Artemis with JDBC store on slow or high latency database crashed on: Critical IO Error. Failed to process JDBC Record statements: java.sql.BatchUpdateException: IO Error: Socket read timed out
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-10749?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10749:
----------------------------------
Affects Version/s: 15.0.0.Beta1
> Artemis with JDBC store on slow or high latency database crashed on: Critical IO Error. Failed to process JDBC Record statements: java.sql.BatchUpdateException: IO Error: Socket read timed out
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10749
> URL: https://issues.jboss.org/browse/WFLY-10749
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final, 13.0.0.Final, 14.0.0.Final, 15.0.0.Beta1
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Critical
>
> Artemis configured with JDBC store is not robust if database is slow/under high load and when there is higher latency to database. Artemis has tendency to shutdown itself on "Critical IO Error" under really low load. It is visible when EAP QE moved Jenkins to Central CI where is higher latency to used Oracle12cR2 database. In following test scenario:
> * Start 2 WF/EAP server in cluster. There is queue InQueue and OutQueue deployed on both of the servers.
> * Send 10 000 small messages to InQueue to server 1
> * Then deploy MDB on server 2. MDB consumes messages from InQueue and resends to OutQueue
> * Wait until MDB processes all messages and check that 10 000 messages is in OutQueue
> Result:
> Sometimes happens that Artemis in server 1 crashes due to following exception:
> {code}
> 20:13:45,641 WARN [org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] (Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@4de066d8)) IO Error: Socket read
> timed out: java.sql.BatchUpdateException: IO Error: Socket read timed out
> at oracle.jdbc.driver.OraclePreparedStatement.executeLargeBatch(OraclePreparedStatement.java:10032)
> at oracle.jdbc.driver.T4CPreparedStatement.executeLargeBatch(T4CPreparedStatement.java:1364)
> at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:9839)
> at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:234)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1180)
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl.sync(JDBCJournalImpl.java:228) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl$JDBCJournalSync.run(JDBCJournalImpl.java:991) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:284) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> 20:13:45,652 WARN [org.apache.activemq.artemis.core.server] (Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@4de066d8)) AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=Critical IO Error. Failed to process JDBC Record statements: java.sql.BatchUpdateException: IO Error: Socket read timed out
> at oracle.jdbc.driver.OraclePreparedStatement.executeLargeBatch(OraclePreparedStatement.java:10032)
> at oracle.jdbc.driver.T4CPreparedStatement.executeLargeBatch(T4CPreparedStatement.java:1364)
> at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:9839)
> at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:234)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1180)
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl.sync(JDBCJournalImpl.java:228) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl$JDBCJournalSync.run(JDBCJournalImpl.java:991) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:284) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> 20:13:45,655 WARN [org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] (Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@4de066d8)) java.sql.SQLRecoverableException: Closed Connection
> {code}
> This thing can be very frustrating for customers who would rely on JDBC store in production. We should provide more robust solution and guide how to configure JDBC store to avoid this situation.
> This problem will arise also when moving to OpenShift which runs in cloud environment with unreliable and slow network to database like Amazon AWS, MS Azure or OpenStack.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (WFLY-10749) Artemis with JDBC store on slow or high latency database crashed on: Critical IO Error. Failed to process JDBC Record statements: java.sql.BatchUpdateException: IO Error: Socket read timed out
by Miroslav Novak (Jira)
[ https://issues.jboss.org/browse/WFLY-10749?page=com.atlassian.jira.plugin... ]
Miroslav Novak updated WFLY-10749:
----------------------------------
Affects Version/s: 14.0.0.Final
> Artemis with JDBC store on slow or high latency database crashed on: Critical IO Error. Failed to process JDBC Record statements: java.sql.BatchUpdateException: IO Error: Socket read timed out
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10749
> URL: https://issues.jboss.org/browse/WFLY-10749
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 12.0.0.Final, 13.0.0.Final, 14.0.0.Final, 15.0.0.Beta1
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Critical
>
> Artemis configured with JDBC store is not robust if database is slow/under high load and when there is higher latency to database. Artemis has tendency to shutdown itself on "Critical IO Error" under really low load. It is visible when EAP QE moved Jenkins to Central CI where is higher latency to used Oracle12cR2 database. In following test scenario:
> * Start 2 WF/EAP server in cluster. There is queue InQueue and OutQueue deployed on both of the servers.
> * Send 10 000 small messages to InQueue to server 1
> * Then deploy MDB on server 2. MDB consumes messages from InQueue and resends to OutQueue
> * Wait until MDB processes all messages and check that 10 000 messages is in OutQueue
> Result:
> Sometimes happens that Artemis in server 1 crashes due to following exception:
> {code}
> 20:13:45,641 WARN [org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] (Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@4de066d8)) IO Error: Socket read
> timed out: java.sql.BatchUpdateException: IO Error: Socket read timed out
> at oracle.jdbc.driver.OraclePreparedStatement.executeLargeBatch(OraclePreparedStatement.java:10032)
> at oracle.jdbc.driver.T4CPreparedStatement.executeLargeBatch(T4CPreparedStatement.java:1364)
> at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:9839)
> at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:234)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1180)
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl.sync(JDBCJournalImpl.java:228) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl$JDBCJournalSync.run(JDBCJournalImpl.java:991) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:284) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> 20:13:45,652 WARN [org.apache.activemq.artemis.core.server] (Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@4de066d8)) AMQ222010: Critical IO Error, shutting down the server. file=NULL, message=Critical IO Error. Failed to process JDBC Record statements: java.sql.BatchUpdateException: IO Error: Socket read timed out
> at oracle.jdbc.driver.OraclePreparedStatement.executeLargeBatch(OraclePreparedStatement.java:10032)
> at oracle.jdbc.driver.T4CPreparedStatement.executeLargeBatch(T4CPreparedStatement.java:1364)
> at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:9839)
> at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:234)
> at org.jboss.jca.adapters.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:1180)
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl.sync(JDBCJournalImpl.java:228) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl$JDBCJournalSync.run(JDBCJournalImpl.java:991) [artemis-jdbc-store-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.core.server.ActiveMQScheduledComponent$2.run(ActiveMQScheduledComponent.java:284) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122) [artemis-commons-1.5.5.jbossorg-012.jar:1.5.5.jbossorg-012]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_171]
> 20:13:45,655 WARN [org.apache.activemq.artemis.jdbc.store.journal.JDBCJournalImpl] (Thread-17 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@4de066d8)) java.sql.SQLRecoverableException: Closed Connection
> {code}
> This thing can be very frustrating for customers who would rely on JDBC store in production. We should provide more robust solution and guide how to configure JDBC store to avoid this situation.
> This problem will arise also when moving to OpenShift which runs in cloud environment with unreliable and slow network to database like Amazon AWS, MS Azure or OpenStack.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months