[
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)