[JBoss JIRA] (WFLY-10531) Wildfly leaks ActiveMQ connections
by Marcel Šebek (JIRA)
[ https://issues.jboss.org/browse/WFLY-10531?page=com.atlassian.jira.plugin... ]
Marcel Šebek commented on WFLY-10531:
-------------------------------------
[~gunterze] It looks like you have a better reproduction case for this issue than me. I'm trying to prepare one, but it is quite difficult. Currently, all I have is "deploy this huge app and wait for a few days". I tried your description (inject JMSContext into SLSB, invoke it via application-scoped CDI bean) and it worked fine, no crash. So I also included a persistence unit into that deployment (and transaction), trying to mimic your use-case as close as possible, but no luck (sent thousands of messages). Do I understand it correctly that when you deploy your app into wildfly 12, it works fine, but deploying the same app into willdfly 13 leads to a crash after approximately 100 operations?
I guess that without a concise repro case, this issue will be hard to fix by wildfly developers. I'd like to cooperate with you on preparing a repro.
> Wildfly leaks ActiveMQ connections
> ----------------------------------
>
> Key: WFLY-10531
> URL: https://issues.jboss.org/browse/WFLY-10531
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 13.0.0.Final
> Environment: openjdk 8 / openjdk 9, Linux
> Reporter: Marcel Šebek
> Assignee: Jeff Mesnil
>
> After upgrading our application from wildfly 12 to 13, the app started to crash after a while (hours, days, depending on circumstances). It crashes on
> IJ000453: Unable to get managed connection for java:/JmsXA
> and other errors (it simply cannot perform all the jobs it contains). I found that when shutting down the server which has been running for a while, I can see a bunch of these messages in the log:
> WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (ServerService Thread Pool -- 117) [:::] IJ000615: Destroying active connection in pool: ActiveMQConnectionDefinition (org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection@2f37f69)
> Bascially, the longer the server was running, more of these messages are shown. I cannot find a way how to reproduce the issue. When the server runs for short time but with some load, no connection is leaked (or just one, rarely). On the other side, it leaks connections even without any particularly high load (just a few requests and @Schedule jobs) when running for longer time.
> It may also be a bug in our application, which just happen to have more serious impact with the new wildfly version.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2837) Avoid switching by putting the leftInputAdapterNode in an Hashmap
by Luca Molteni (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2837?page=com.atlassian.jira.plugi... ]
Luca Molteni updated DROOLS-2837:
---------------------------------
Description:
In this test:
testAlphaConstraintsSwitchBigDecimal
Let's go from this
{code:java}
private java.util.Map ToNodeId = new java.util.HashMap();
ToNodeId.put(new java.math.BigDecimal("0"), 4);
ToNodeId.put(new java.math.BigDecimal("2"), 10);
ToNodeId.put(new java.math.BigDecimal("1"), 7);
public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
org.drools.modelcompiler.domain.Person fact = (org.drools.modelcompiler.domain.Person)handle.getObject();
Integer NodeId = (Integer)ToNodeId.get(readAccessor.getValue(fact));
if(NodeId != null) {
switch(NodeId.intValue()) {
case 4 :
leftInputAdapterNode5.assertObject(handle,context,wm);
break;
case 7 :
leftInputAdapterNode8.assertObject(handle,context,wm);
break;
case 10 :
leftInputAdapterNode11.assertObject(handle,context,wm);
break;
}
}
}
{code}
to This
{code:java}
private java.util.Map ToNodeId=new java.util.HashMap();
ToNodeId.put(new java.math.BigDecimal("0"),leftInputAdapterNode5);
ToNodeId.put(new java.math.BigDecimal("2"),leftInputAdapterNode11);
ToNodeId.put(new java.math.BigDecimal("1"),leftInputAdapterNode8);
public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
org.drools.modelcompiler.domain.Person fact=(org.drools.modelcompiler.domain.Person)handle.getObject();
org.drools.core.reteoo.LeftInputAdapterNode lia=(Integer)ToNodeId.get(readAccessor.getValue(fact));
if(lia!=null){
lia.assertOject(handle,context,wm);
}
{code}
Therefore avoiding the switch
was:
In this test:
testAlphaConstraintsSwitchBigDecimal
Let's go from this
private java.util.Map ToNodeId = new java.util.HashMap();
ToNodeId.put(new java.math.BigDecimal("0"), 4);
ToNodeId.put(new java.math.BigDecimal("2"), 10);
ToNodeId.put(new java.math.BigDecimal("1"), 7);
public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
org.drools.modelcompiler.domain.Person fact = (org.drools.modelcompiler.domain.Person)handle.getObject();
Integer NodeId = (Integer)ToNodeId.get(readAccessor.getValue(fact));
if(NodeId != null) {
switch(NodeId.intValue()) {
case 4 :
leftInputAdapterNode5.assertObject(handle,context,wm);
break;
case 7 :
leftInputAdapterNode8.assertObject(handle,context,wm);
break;
case 10 :
leftInputAdapterNode11.assertObject(handle,context,wm);
break;
}
}
}
to This
private java.util.Map ToNodeId=new java.util.HashMap();
ToNodeId.put(new java.math.BigDecimal("0"),leftInputAdapterNode5);
ToNodeId.put(new java.math.BigDecimal("2"),leftInputAdapterNode11);
ToNodeId.put(new java.math.BigDecimal("1"),leftInputAdapterNode8);
public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
org.drools.modelcompiler.domain.Person fact=(org.drools.modelcompiler.domain.Person)handle.getObject();
org.drools.core.reteoo.LeftInputAdapterNode lia=(Integer)ToNodeId.get(readAccessor.getValue(fact));
if(lia!=null){
lia.assertOject(handle,context,wm);
}
Therefore avoiding the switch
> Avoid switching by putting the leftInputAdapterNode in an Hashmap
> -----------------------------------------------------------------
>
> Key: DROOLS-2837
> URL: https://issues.jboss.org/browse/DROOLS-2837
> Project: Drools
> Issue Type: Enhancement
> Reporter: Luca Molteni
> Assignee: Luca Molteni
>
> In this test:
> testAlphaConstraintsSwitchBigDecimal
> Let's go from this
> {code:java}
> private java.util.Map ToNodeId = new java.util.HashMap();
> ToNodeId.put(new java.math.BigDecimal("0"), 4);
> ToNodeId.put(new java.math.BigDecimal("2"), 10);
> ToNodeId.put(new java.math.BigDecimal("1"), 7);
> public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
> org.drools.modelcompiler.domain.Person fact = (org.drools.modelcompiler.domain.Person)handle.getObject();
> Integer NodeId = (Integer)ToNodeId.get(readAccessor.getValue(fact));
> if(NodeId != null) {
> switch(NodeId.intValue()) {
> case 4 :
> leftInputAdapterNode5.assertObject(handle,context,wm);
> break;
> case 7 :
> leftInputAdapterNode8.assertObject(handle,context,wm);
> break;
> case 10 :
> leftInputAdapterNode11.assertObject(handle,context,wm);
> break;
> }
> }
> }
> {code}
> to This
> {code:java}
> private java.util.Map ToNodeId=new java.util.HashMap();
> ToNodeId.put(new java.math.BigDecimal("0"),leftInputAdapterNode5);
> ToNodeId.put(new java.math.BigDecimal("2"),leftInputAdapterNode11);
> ToNodeId.put(new java.math.BigDecimal("1"),leftInputAdapterNode8);
> public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
> org.drools.modelcompiler.domain.Person fact=(org.drools.modelcompiler.domain.Person)handle.getObject();
> org.drools.core.reteoo.LeftInputAdapterNode lia=(Integer)ToNodeId.get(readAccessor.getValue(fact));
> if(lia!=null){
> lia.assertOject(handle,context,wm);
> }
> {code}
> Therefore avoiding the switch
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2837) Avoid switching by putting the leftInputAdapterNode in an Hashmap
by Luca Molteni (JIRA)
Luca Molteni created DROOLS-2837:
------------------------------------
Summary: Avoid switching by putting the leftInputAdapterNode in an Hashmap
Key: DROOLS-2837
URL: https://issues.jboss.org/browse/DROOLS-2837
Project: Drools
Issue Type: Enhancement
Reporter: Luca Molteni
Assignee: Luca Molteni
In this test:
testAlphaConstraintsSwitchBigDecimal
Let's go from this
private java.util.Map ToNodeId = new java.util.HashMap();
ToNodeId.put(new java.math.BigDecimal("0"), 4);
ToNodeId.put(new java.math.BigDecimal("2"), 10);
ToNodeId.put(new java.math.BigDecimal("1"), 7);
public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
org.drools.modelcompiler.domain.Person fact = (org.drools.modelcompiler.domain.Person)handle.getObject();
Integer NodeId = (Integer)ToNodeId.get(readAccessor.getValue(fact));
if(NodeId != null) {
switch(NodeId.intValue()) {
case 4 :
leftInputAdapterNode5.assertObject(handle,context,wm);
break;
case 7 :
leftInputAdapterNode8.assertObject(handle,context,wm);
break;
case 10 :
leftInputAdapterNode11.assertObject(handle,context,wm);
break;
}
}
}
to This
private java.util.Map ToNodeId=new java.util.HashMap();
ToNodeId.put(new java.math.BigDecimal("0"),leftInputAdapterNode5);
ToNodeId.put(new java.math.BigDecimal("2"),leftInputAdapterNode11);
ToNodeId.put(new java.math.BigDecimal("1"),leftInputAdapterNode8);
public final void assertObject(org.drools.core.common.InternalFactHandle handle,org.drools.core.spi.PropagationContext context,org.drools.core.common.InternalWorkingMemory wm){
org.drools.modelcompiler.domain.Person fact=(org.drools.modelcompiler.domain.Person)handle.getObject();
org.drools.core.reteoo.LeftInputAdapterNode lia=(Integer)ToNodeId.get(readAccessor.getValue(fact));
if(lia!=null){
lia.assertOject(handle,context,wm);
}
Therefore avoiding the switch
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Francesco Nigro edited comment on WFWIP-28 at 8/6/18 11:07 AM:
---------------------------------------------------------------
Looking at https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP/...
most of the collected metrics are simply wrong (eg negative CPU utilisation and opened File descriptors) probably due to a missing/killed JVM process: my suspect (to be verified) are toward a OOM killer action.
I suppose that collecting the Sosreport and using a static node to avoid anything related the process to be cleaned up with the VM will help to find where the issue is: ATM just the collected logs aren't enough.
FYI the mentioned job has this log that shows the problem and when it has happened:
{code:java}
05:20:49,073 pool-2-thread-2 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute ProcessCpuLoad returned 0.01946859311864822
05:20:49,085 pool-2-thread-2 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute SystemCpuLoad returned 0.1457247132429614
05:20:49,092 pool-1-thread-4 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute ProcessCpuLoad returned -1
05:20:49,100 pool-1-thread-3 WARN [org.jboss.qa.resourcemonitor.ThreadMeasurement:43] Error reseting peak counter
05:20:49,102 pool-1-thread-4 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute SystemCpuLoad returned -1
05:20:49,145 Thread-4321 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:525] AMQ214026: Failure captured on connectionID=e7fb5df2, performing failover or reconnection now
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1050)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
05:20:49,146 Thread-4327 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:525] AMQ214026: Failure captured on connectionID=ca7b4f32, performing failover or reconnection now
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1050)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
was (Author: fnigro):
Looking at https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP/...
most of the collected metrics are simply wrong (CPU utilisation = -100 File descriptors = -1) probably due to a missing/killed JVM process: my suspect (to be verified) are toward a OOM killer action.
I suppose that collecting the Sosreport and using a static node to avoid anything related the process to be cleaned up with the VM will help to find where the issue is: ATM just the collected logs aren't enough.
FYI the mentioned job has this log that shows the problem and when it has happened:
{code:java}
05:20:49,073 pool-2-thread-2 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute ProcessCpuLoad returned 0.01946859311864822
05:20:49,085 pool-2-thread-2 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute SystemCpuLoad returned 0.1457247132429614
05:20:49,092 pool-1-thread-4 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute ProcessCpuLoad returned -1
05:20:49,100 pool-1-thread-3 WARN [org.jboss.qa.resourcemonitor.ThreadMeasurement:43] Error reseting peak counter
05:20:49,102 pool-1-thread-4 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute SystemCpuLoad returned -1
05:20:49,145 Thread-4321 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:525] AMQ214026: Failure captured on connectionID=e7fb5df2, performing failover or reconnection now
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1050)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
05:20:49,146 Thread-4327 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:525] AMQ214026: Failure captured on connectionID=ca7b4f32, performing failover or reconnection now
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1050)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFWIP-28) [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
by Francesco Nigro (JIRA)
[ https://issues.jboss.org/browse/WFWIP-28?page=com.atlassian.jira.plugin.s... ]
Francesco Nigro commented on WFWIP-28:
--------------------------------------
Looking at https://mw-messaging-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP/...
most of the collected metrics are simply wrong (CPU utilisation = -100 File descriptors = -1) probably due to a missing/killed JVM process: my suspect (to be verified) are toward a OOM killer action.
I suppose that collecting the Sosreport and using a static node to avoid anything related the process to be cleaned up with the VM will help to find where the issue is: ATM just the collected logs aren't enough.
FYI the mentioned job has this log that shows the problem and when it has happened:
{code:java}
05:20:49,073 pool-2-thread-2 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute ProcessCpuLoad returned 0.01946859311864822
05:20:49,085 pool-2-thread-2 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute SystemCpuLoad returned 0.1457247132429614
05:20:49,092 pool-1-thread-4 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute ProcessCpuLoad returned -1
05:20:49,100 pool-1-thread-3 WARN [org.jboss.qa.resourcemonitor.ThreadMeasurement:43] Error reseting peak counter
05:20:49,102 pool-1-thread-4 DEBUG [org.jboss.qa.resourcemonitor.CpuLoadMeasurement:70] getCpu attribute SystemCpuLoad returned -1
05:20:49,145 Thread-4321 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:525] AMQ214026: Failure captured on connectionID=e7fb5df2, performing failover or reconnection now
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1050)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
05:20:49,146 Thread-4327 (ActiveMQ-client-global-threads) TRACE [org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl:525] AMQ214026: Failure captured on connectionID=ca7b4f32, performing failover or reconnection now
ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119006: Channel disconnected]
at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353)
at org.apache.activemq.artemis.core.remoting.impl.netty.NettyConnector$Listener$1.run(NettyConnector.java:1050)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
> [Artemis 2.x upgrade] Unexptected crash of server in SOAK test
> --------------------------------------------------------------
>
> Key: WFWIP-28
> URL: https://issues.jboss.org/browse/WFWIP-28
> Project: WildFly WIP
> Issue Type: Bug
> Components: Artemis
> Reporter: Miroslav Novak
> Assignee: Martyn Taylor
> Priority: Blocker
> Labels: feature-branch-blocker
>
> After ~13 hours there is unexpected crash of one server in SOAK test. There is no error/warning in the logs.
> Test Scenario:
> * Start 2 servers
> * Client sends messages to input queue. Messages then go through:
> * One server to another through MDB reading and sending them from remote container through resource adapter
> * Messages are forwarded from one server to another over JMS bridge and back over Core bridge
> * Messages have JMSReplyTo defined with a temporary queue, that is filled with responses for the client
> * Messages are read from the destination with stateless EJB and sent back to clients
> * Client reads the messages after the pass through all the soak modules.
> Pass Criteria: In the last step receiver consumes all messages sent by producer.
> Actual Result:
> After ~13 hours 1st server suddenly crashes. There is no error/warning in server logs.
> Issue was hit with Artemis 2.5.0 with https://github.com/jmesnil/wildfly/tree/WFLY-9407_upgrade_artemis_2.4.0_w... (commit 51dd8102f103ccb0470a3cfc8713d3f9bdb1b65d)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Scott Marlow updated WFLY-10520:
--------------------------------
Description:
A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
>From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
# Change calls to org.hibernate.BasicQueryContract.getFlushMode(), to instead call BasicQueryContract.getHibernateFlushMode().
# Change calls to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
# Change references to Enum org.hibernate.FlushMode.NEVER (0), to FlushMode.MANUAL (0).
# Change calls to org.hibernate.Query.getMaxResults() returning Integer, to instead call org.hibernate.Query.getHibernateMaxResults() (returning Integer).
# Change calls to org.hibernate.Query.setMaxResults(int), to instead call org.hibernate.Query.setHibernateMaxResults(int).
# Change calls to org.hibernate.Query.getFirstResult(int) returning Integer, to instead call org.hibernate.Query.getHibernateFirstResult() (returning Integer).
# Change calls to org.hibernate.Query.setFirstResult(int), to instead call org.hibernate.Query.setHibernateFirstResult(int).
# Also deal with Hibernate user defined types.
was:
A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
>From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
# Change calls to org.hibernate.BasicQueryContract.getFlushMode(), to instead call BasicQueryContract.getHibernateFlushMode().
# Change calls to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
# Change references to Enum org.hibernate.FlushMode.NEVER (0), to FlushMode.MANUAL (0).
# Change calls to org.hibernate.Query.getMaxResults() returning Integer, to instead call org.hibernate.Query.getHibernateMaxResults() (returning Integer).
# Change calls to org.hibernate.Query.setMaxResults(int), to instead call org.hibernate.Query.setHibernateMaxResults(int).
# Change calls to org.hibernate.Query.getFirstResult(int) returning Integer, to instead call org.hibernate.Query.getHibernateFirstResult() (returning Integer).
# Change calls to org.hibernate.Query.setFirstResult(int), to instead call org.hibernate.Query.setHibernateFirstResult(int).
# Fill in rules here for UserType handling, which we are exploring still ([see list of methods in rejected ORM pr|https://github.com/hibernate/hibernate-orm/pull/2412/files]).
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change calls to org.hibernate.BasicQueryContract.getFlushMode(), to instead call BasicQueryContract.getHibernateFlushMode().
> # Change calls to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Change references to Enum org.hibernate.FlushMode.NEVER (0), to FlushMode.MANUAL (0).
> # Change calls to org.hibernate.Query.getMaxResults() returning Integer, to instead call org.hibernate.Query.getHibernateMaxResults() (returning Integer).
> # Change calls to org.hibernate.Query.setMaxResults(int), to instead call org.hibernate.Query.setHibernateMaxResults(int).
> # Change calls to org.hibernate.Query.getFirstResult(int) returning Integer, to instead call org.hibernate.Query.getHibernateFirstResult() (returning Integer).
> # Change calls to org.hibernate.Query.setFirstResult(int), to instead call org.hibernate.Query.setHibernateFirstResult(int).
> # Also deal with Hibernate user defined types.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months
[JBoss JIRA] (DROOLS-2836) Support compiling of a Big Rule
by Luca Molteni (JIRA)
Luca Molteni created DROOLS-2836:
------------------------------------
Summary: Support compiling of a Big Rule
Key: DROOLS-2836
URL: https://issues.jboss.org/browse/DROOLS-2836
Project: Drools
Issue Type: Bug
Reporter: Luca Molteni
Assignee: Mario Fusco
RemoveRuleTest.testRemoveBigRule
java.lang.RuntimeException: This is a bug. Please contact the development team:
[org/drools/core/reteoo/compiled/Compiledorg_drools_compiler_test_SimpleFactNetwork8aecdf1db7f9b4f4abcbafdd301c63d7c.java (6279:25) : package org.drools.compiler.test does not exist, org/drools/core/reteoo/compiled/Compiledorg_drools_compiler_test_SimpleFactNetwork8aecdf1db7f9b4f4abcbafdd301c63d7c.java (6279:69) : package org.drools.compiler.test does not exist, org/drools/core/reteoo/compiled/Compiledorg_drools_compiler_test_SimpleFactNetwork8aecdf1db7f9b4f4abcbafdd301c63d7c.java (7899:25) : package org.drools.compiler.test does not exist, org/drools/core/reteoo/compiled/Compiledorg_drools_compiler_test_SimpleFactNetwork8aecdf1db7f9b4f4abcbafdd301c63d7c.java (7899:69) : package org.drools.compiler.test does not exist]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 11 months