7 Replies Latest reply on Jun 25, 2016 7:01 AM by igarashitm

Wildfly 10.0.0.Final datasources - connection leak?

arielcarrera Jun 22, 2016 3:27 PM

Hi, I've been being affected by a problem while I was testing a jboss quickstart from Switchyard project with Wildfly 10.0.0.Final.

When I run the example with Wildfly 8.1.0.Final it works ok but when I run it with

Wildfly 10.0.0.Final it fails. A connection leak take place.

After some time debugging I could resolve the problem using a custom EntityManagerFactory that uses to a jboss datasource or a HikariCP Pool.

The "Switchyard/Camel jpa component" used into the the quickstart project (that i was testing) creates every time an EntityManagerFactory instead to reuse one. It has a reference into the persistence.xml to the jboss datasource by JNDI. Maybe it must not be an implementation with the best performance or yes, but I think that it shouldn't be a problem if reuse a singular jboss datasource.

I don't know if it is exactly the way to reproduce the problem but I understand that if it is working with Wildfly 8, should work fine with Wildfly 10 instead.

I created a jira issue in the Switchyard project ([SWITCHYARD-2925] Connection leak on Wildfly 10 (component-camel/camel-jpa) - JBoss Issue Tracker) but in my opinion, can be a problem with Wildfly / Ironjacamar implementation.

Regards,

1. Re: Wildfly 10.0.0.Final datasources - connection leak?

ctomc Jun 22, 2016 3:55 PM (in response to arielcarrera)

how do you know it is connection leak? any more data to back that claim?
something in the log?
did you try with connection tracing enabled which would helps identify exact point where leak is happening.
Actions
2. Re: Wildfly 10.0.0.Final datasources - connection leak?

arielcarrera Jun 22, 2016 5:53 PM (in response to ctomc)

Hi Tomaz, I have tried with debug logs enabled and datasource statistics enabled. Furthermore I monitored the pool with wildfly's console and by JMX (hawtio) too.
At some point, the connection is supplied from the pool but is never closed and a new connection is supplied again. I'm afraid that it could be a lock into the BaseWrapperManagedConnection(LocalManagedConnection).
If you wants, I have some log traces that I can send by email to get another opinion.

Regards,
Actions
3. Re: Wildfly 10.0.0.Final datasources - connection leak?

ctomc Jun 22, 2016 6:32 PM (in response to arielcarrera)

can you try with connection leak detector? Detecting Connection leaks with WildFly 9
Actions
4. Re: Wildfly 10.0.0.Final datasources - connection leak?

arielcarrera Jun 23, 2016 11:35 AM (in response to ctomc)

Hi Tomaz, I tried but it doesn't generate any file. When there is no connection leak, is this expected? (connections are killed by timeout, maybe this is not considered technically a connection leak)
Actions
5. Re: Wildfly 10.0.0.Final datasources - connection leak?

ctomc Jun 23, 2016 12:02 PM (in response to arielcarrera)

Well that is odd in any case. But it is not connection leak in app server code anywhere.
But somewhere in code that is deployed on it. So maybe switchyard guys can help here.
Actions
6. Re: Wildfly 10.0.0.Final datasources - connection leak?

arielcarrera Jun 23, 2016 12:27 PM (in response to ctomc)

Thanks Tomaz, I found a workaround to this problem. Maybe in future versions, doing upgrade of camel or spring to last version can solve the problem.

The only thing that I could see to improve into the switchyard component is the possibility to set a custom entity manager factory to avoid to create one every time, the rest of process is doing by apache camel and spring framework. This was the key of my workaround.

Thanks for your replyTomaz!

Regards
Actions
7. Re: Wildfly 10.0.0.Final datasources - connection leak?

igarashitm Jun 25, 2016 7:01 AM (in response to arielcarrera)

Hmm I haven't looked into it deeper yet, but I think connection should not leak even if EntityManagerFactory is created everytime. If it only happens on WildFly10, there would be an issue in hibernate bundled in WF10.
Actions

Go to original post