[
https://issues.jboss.org/browse/WFLY-10531?page=com.atlassian.jira.plugin...
]
Jiri Ondrusek edited comment on WFLY-10531 at 10/4/18 8:41 AM:
---------------------------------------------------------------
[~jwgmeligmeyling] I'm still trying to figure, what exactly is causing this error.
Currently, I've created better test:
https://github.com/JiriOndrusek/wildfly/commit/fd84ff61e074ade65d4b9f5a21...
(which doesn't exhaust server)
My current thoughts about this issue are following:
* I have logs from two executions with small amount (the same numbers) of calls of
injected contexts with leaking connections and without leaking connections -> error
doesn't depend on precise number of calls from reproducer
* if I set count of executions to higher values, there is an error with almost 100%
certainty
* I was able to count registered contexts in transaction synchronization on multiple
executions, and then number of closed ones -> I see difference which I can not explain
for now
I have suspicion, that that problem is caused near registering of synchronization
listener. I think that it is possible, that some contexts are not registered for closing
at the end of transaction.
It answers the questions:
- why it is happening only with more injected contexts
- and the fact that I see that not all contexts, which should be registered, are not
closed by synchronization listener
I'll investigate this scenario, to be sure.
If my suspicion is correct, then proposed fix works only as workaround.
was (Author: jondruse):
[~jwgmeligmeyling] I'm still trying to figure, what exactly is causing this error.
Currently, I've created better test:
https://github.com/JiriOndrusek/wildfly/commit/fd84ff61e074ade65d4b9f5a21...
(which doesn't exhaust server)
My current thoughts about this issue are following:
* I have logs from two executions with small amount (the same numbers) of calls of
injected contexts with leaking connections and without leaking connections -> error
doesn't depend on precise number of calls from reproducer
* if I set count of executions to higher values, there is an error with almost 100%
certainty
* I was able to count registered contexts in transaction synchronization on multiple
executions, and then number of closed ones -> I see difference which I can not explain
for now
I have suspicion, that that problem is caused near registering of synchronization
listener. I think that it is possible, that some contexts are not registered for closing
at the end of transaction.
It answers the questions:
- why it is happening only with more injected contexts
- and the fact that I see that not all contexts, which should be registered, are not
closed by synchronization listener
I'll investigate this scenario, to be sure.
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
Priority: Major
Attachments: WFLY-10531-ear-1.0.ear, WFLY10531.zip
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.12.1#712002)