You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by sgjava <sg...@gmail.com> on 2016/06/30 18:09:04 UTC
TomEE 7.01 heap leak in logging
OK, I left TomEE's logging configured as default and I'm still getting a heap
leak using logback+slf4j. Looks like it's int the loggerCache.
The class "org.apache.openejb.util.Logger", loaded by
"java.net.URLClassLoader @ 0x805b90c0", occupies 316,141,928 (79.36%) bytes.
The memory is accumulated in one instance of
"java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
loader>".
Class Name
| Shallow Heap | Retained Heap
--------------------------------------------------------------------------------------------
loggerCache class org.apache.openejb.util.Logger @ 0x80960510| 48
| 316,141,928
--------------------------------------------------------------------------------------------
Versions:
<tomee.version>7.0.1</tomee.version>
<slf4j.version>1.7.7</slf4j.version>
<logback.version>1.1.2</logback.version>
Web app:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${logback.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>${logback.version}</version>
</dependency>
Class has:
private static final Logger log = LoggerFactory.getLogger(MasService.class);
I have same config running under TomEE 2.0.0 for 1.5 years without heap
leak. It logs a lot more too.
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
It was worth it. I don't like going into production with these kinds of
issues. Thank you for tracking down and fixing the code.
On Wed, Jul 6, 2016 at 1:36 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 2016-07-06 0:03 GMT+02:00 sgjava <sg...@gmail.com>:
>
> > Logback/slf4j config working fine after a few hours, no leaks. Tomcat hot
> > deploys don't always work, so we usually do a rolling deploy behind a
> load
> > balancer.
> >
> >
> Awesome, thanks A LOT for all your hard work!
>
> (and yes a LB is the way to do it in "real life" ;))
>
>
> > On Tue, Jul 5, 2016 at 1:06 AM, Romain Manni-Bucau [via TomEE & OpenEJB]
> <
> > ml-node+s979440n4679221h62@n4.nabble.com> wrote:
> >
> > > Logback should be fine if you dont deploy/undeploy apps without
> > restarting
> > > the server.
> > > Le 5 juil. 2016 04:13, "Steve Goldsmith" <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679221&i=0>> a écrit :
> > >
> > > > This is what I was thinking. In a production scenario I am using REST
> > > and
> > > > SOAP clients in services which can timeout. Some of the code uses
> MDBs
> > > to
> > > > make the call asynchronous, but since they too use REST clients
> > timeouts
> > > > and other exceptions can occur. This would also explain why there
> > wasn't
> > > a
> > > > one to one (call to leak) ratio.
> > > >
> > > > One thing I was thinking is that my logback/slf4j configuration
> > probably
> > > > wasn't causing this issue. Once I'm confident the leak is gone I'll
> try
> > > > switching back one app to that and see what happens. For now I'm
> using
> > > the
> > > > JDK logger...
> > > >
> > > >
> > > > On Mon, Jul 4, 2016 at 7:07 PM, Romain Manni-Bucau <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679221&i=1>>
> > > > wrote:
> > > >
> > > > > Yes the case is pretty hard to reproduce. Needs to go on a path
> were
> > > we
> > > > > re-get a Logger which can happen in error cases for instance.
> > > > > Le 4 juil. 2016 22:57, "sgjava" <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679221&i=2>> a écrit :
> > > > >
> > > > > > I have 2 VMs behind a load balancer that basically get the same
> > > amount
> > > > of
> > > > > > traffic. The node running 7.0.2-SNAPSHOT is not leaking any
> more. I
> > > > > > restarted the 7.0.1 node around the same time and it's leaking
> > > already:
> > > > > >
> > > > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > > > "java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072
> > (28.94%)
> > > > > bytes.
> > > > > > The memory is accumulated in one instance of
> > > > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by
> "<system
> > > > class
> > > > > > loader>".
> > > > > >
> > > > > > Let me check at work tomorrow (US EDT) since we get increased
> > > traffic
> > > > > after
> > > > > > 5 PM local time. If MAT doesn't detect the leak (except it thinks
> > > > > > com.hazelcast.cache.impl.CachePartitionSegment is a leak :) )
> then
> > > I'd
> > > > > say
> > > > > > this is resolved. Crossing fingers on both hands. We are getting
> > > ready
> > > > to
> > > > > > increase traffic on these nodes and the leak would chew through
> 2G
> > > in
> > > > > about
> > > > > > 10-14 days in the past. Thanks so much for your help and not
> giving
> > > up.
> > > > > For
> > > > > > whatever weird reason I cannot duplicate this with a test project
> > > > under a
> > > > > > load test.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
> > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Steven P. Goldsmith
> > > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679221.html
> > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > <
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > >
> > > .
> > > NAML
> > > <
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679235.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-07-06 0:03 GMT+02:00 sgjava <sg...@gmail.com>:
> Logback/slf4j config working fine after a few hours, no leaks. Tomcat hot
> deploys don't always work, so we usually do a rolling deploy behind a load
> balancer.
>
>
Awesome, thanks A LOT for all your hard work!
(and yes a LB is the way to do it in "real life" ;))
> On Tue, Jul 5, 2016 at 1:06 AM, Romain Manni-Bucau [via TomEE & OpenEJB] <
> ml-node+s979440n4679221h62@n4.nabble.com> wrote:
>
> > Logback should be fine if you dont deploy/undeploy apps without
> restarting
> > the server.
> > Le 5 juil. 2016 04:13, "Steve Goldsmith" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679221&i=0>> a écrit :
> >
> > > This is what I was thinking. In a production scenario I am using REST
> > and
> > > SOAP clients in services which can timeout. Some of the code uses MDBs
> > to
> > > make the call asynchronous, but since they too use REST clients
> timeouts
> > > and other exceptions can occur. This would also explain why there
> wasn't
> > a
> > > one to one (call to leak) ratio.
> > >
> > > One thing I was thinking is that my logback/slf4j configuration
> probably
> > > wasn't causing this issue. Once I'm confident the leak is gone I'll try
> > > switching back one app to that and see what happens. For now I'm using
> > the
> > > JDK logger...
> > >
> > >
> > > On Mon, Jul 4, 2016 at 7:07 PM, Romain Manni-Bucau <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679221&i=1>>
> > > wrote:
> > >
> > > > Yes the case is pretty hard to reproduce. Needs to go on a path were
> > we
> > > > re-get a Logger which can happen in error cases for instance.
> > > > Le 4 juil. 2016 22:57, "sgjava" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679221&i=2>> a écrit :
> > > >
> > > > > I have 2 VMs behind a load balancer that basically get the same
> > amount
> > > of
> > > > > traffic. The node running 7.0.2-SNAPSHOT is not leaking any more. I
> > > > > restarted the 7.0.1 node around the same time and it's leaking
> > already:
> > > > >
> > > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > > "java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072
> (28.94%)
> > > > bytes.
> > > > > The memory is accumulated in one instance of
> > > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> > > class
> > > > > loader>".
> > > > >
> > > > > Let me check at work tomorrow (US EDT) since we get increased
> > traffic
> > > > after
> > > > > 5 PM local time. If MAT doesn't detect the leak (except it thinks
> > > > > com.hazelcast.cache.impl.CachePartitionSegment is a leak :) ) then
> > I'd
> > > > say
> > > > > this is resolved. Crossing fingers on both hands. We are getting
> > ready
> > > to
> > > > > increase traffic on these nodes and the leak would chew through 2G
> > in
> > > > about
> > > > > 10-14 days in the past. Thanks so much for your help and not giving
> > up.
> > > > For
> > > > > whatever weird reason I cannot duplicate this with a test project
> > > under a
> > > > > load test.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
> > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679221.html
> > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> >
> > .
> > NAML
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
> --
> Steven P. Goldsmith
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679235.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
Logback/slf4j config working fine after a few hours, no leaks. Tomcat hot
deploys don't always work, so we usually do a rolling deploy behind a load
balancer.
On Tue, Jul 5, 2016 at 1:06 AM, Romain Manni-Bucau [via TomEE & OpenEJB] <
ml-node+s979440n4679221h62@n4.nabble.com> wrote:
> Logback should be fine if you dont deploy/undeploy apps without restarting
> the server.
> Le 5 juil. 2016 04:13, "Steve Goldsmith" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679221&i=0>> a écrit :
>
> > This is what I was thinking. In a production scenario I am using REST
> and
> > SOAP clients in services which can timeout. Some of the code uses MDBs
> to
> > make the call asynchronous, but since they too use REST clients timeouts
> > and other exceptions can occur. This would also explain why there wasn't
> a
> > one to one (call to leak) ratio.
> >
> > One thing I was thinking is that my logback/slf4j configuration probably
> > wasn't causing this issue. Once I'm confident the leak is gone I'll try
> > switching back one app to that and see what happens. For now I'm using
> the
> > JDK logger...
> >
> >
> > On Mon, Jul 4, 2016 at 7:07 PM, Romain Manni-Bucau <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679221&i=1>>
> > wrote:
> >
> > > Yes the case is pretty hard to reproduce. Needs to go on a path were
> we
> > > re-get a Logger which can happen in error cases for instance.
> > > Le 4 juil. 2016 22:57, "sgjava" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679221&i=2>> a écrit :
> > >
> > > > I have 2 VMs behind a load balancer that basically get the same
> amount
> > of
> > > > traffic. The node running 7.0.2-SNAPSHOT is not leaking any more. I
> > > > restarted the 7.0.1 node around the same time and it's leaking
> already:
> > > >
> > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > "java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072 (28.94%)
> > > bytes.
> > > > The memory is accumulated in one instance of
> > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> > class
> > > > loader>".
> > > >
> > > > Let me check at work tomorrow (US EDT) since we get increased
> traffic
> > > after
> > > > 5 PM local time. If MAT doesn't detect the leak (except it thinks
> > > > com.hazelcast.cache.impl.CachePartitionSegment is a leak :) ) then
> I'd
> > > say
> > > > this is resolved. Crossing fingers on both hands. We are getting
> ready
> > to
> > > > increase traffic on these nodes and the leak would chew through 2G
> in
> > > about
> > > > 10-14 days in the past. Thanks so much for your help and not giving
> up.
> > > For
> > > > whatever weird reason I cannot duplicate this with a test project
> > under a
> > > > load test.
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679221.html
> To unsubscribe from TomEE 7.01 heap leak in logging, click here
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5>
> .
> NAML
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Steven P. Goldsmith
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679235.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Logback should be fine if you dont deploy/undeploy apps without restarting
the server.
Le 5 juil. 2016 04:13, "Steve Goldsmith" <sg...@gmail.com> a écrit :
> This is what I was thinking. In a production scenario I am using REST and
> SOAP clients in services which can timeout. Some of the code uses MDBs to
> make the call asynchronous, but since they too use REST clients timeouts
> and other exceptions can occur. This would also explain why there wasn't a
> one to one (call to leak) ratio.
>
> One thing I was thinking is that my logback/slf4j configuration probably
> wasn't causing this issue. Once I'm confident the leak is gone I'll try
> switching back one app to that and see what happens. For now I'm using the
> JDK logger...
>
>
> On Mon, Jul 4, 2016 at 7:07 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Yes the case is pretty hard to reproduce. Needs to go on a path were we
> > re-get a Logger which can happen in error cases for instance.
> > Le 4 juil. 2016 22:57, "sgjava" <sg...@gmail.com> a écrit :
> >
> > > I have 2 VMs behind a load balancer that basically get the same amount
> of
> > > traffic. The node running 7.0.2-SNAPSHOT is not leaking any more. I
> > > restarted the 7.0.1 node around the same time and it's leaking already:
> > >
> > > The class "org.apache.openejb.util.Logger", loaded by
> > > "java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072 (28.94%)
> > bytes.
> > > The memory is accumulated in one instance of
> > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> class
> > > loader>".
> > >
> > > Let me check at work tomorrow (US EDT) since we get increased traffic
> > after
> > > 5 PM local time. If MAT doesn't detect the leak (except it thinks
> > > com.hazelcast.cache.impl.CachePartitionSegment is a leak :) ) then I'd
> > say
> > > this is resolved. Crossing fingers on both hands. We are getting ready
> to
> > > increase traffic on these nodes and the leak would chew through 2G in
> > about
> > > 10-14 days in the past. Thanks so much for your help and not giving up.
> > For
> > > whatever weird reason I cannot duplicate this with a test project
> under a
> > > load test.
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
This is what I was thinking. In a production scenario I am using REST and
SOAP clients in services which can timeout. Some of the code uses MDBs to
make the call asynchronous, but since they too use REST clients timeouts
and other exceptions can occur. This would also explain why there wasn't a
one to one (call to leak) ratio.
One thing I was thinking is that my logback/slf4j configuration probably
wasn't causing this issue. Once I'm confident the leak is gone I'll try
switching back one app to that and see what happens. For now I'm using the
JDK logger...
On Mon, Jul 4, 2016 at 7:07 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Yes the case is pretty hard to reproduce. Needs to go on a path were we
> re-get a Logger which can happen in error cases for instance.
> Le 4 juil. 2016 22:57, "sgjava" <sg...@gmail.com> a écrit :
>
> > I have 2 VMs behind a load balancer that basically get the same amount of
> > traffic. The node running 7.0.2-SNAPSHOT is not leaking any more. I
> > restarted the 7.0.1 node around the same time and it's leaking already:
> >
> > The class "org.apache.openejb.util.Logger", loaded by
> > "java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072 (28.94%)
> bytes.
> > The memory is accumulated in one instance of
> > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> > loader>".
> >
> > Let me check at work tomorrow (US EDT) since we get increased traffic
> after
> > 5 PM local time. If MAT doesn't detect the leak (except it thinks
> > com.hazelcast.cache.impl.CachePartitionSegment is a leak :) ) then I'd
> say
> > this is resolved. Crossing fingers on both hands. We are getting ready to
> > increase traffic on these nodes and the leak would chew through 2G in
> about
> > 10-14 days in the past. Thanks so much for your help and not giving up.
> For
> > whatever weird reason I cannot duplicate this with a test project under a
> > load test.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yes the case is pretty hard to reproduce. Needs to go on a path were we
re-get a Logger which can happen in error cases for instance.
Le 4 juil. 2016 22:57, "sgjava" <sg...@gmail.com> a écrit :
> I have 2 VMs behind a load balancer that basically get the same amount of
> traffic. The node running 7.0.2-SNAPSHOT is not leaking any more. I
> restarted the 7.0.1 node around the same time and it's leaking already:
>
> The class "org.apache.openejb.util.Logger", loaded by
> "java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072 (28.94%) bytes.
> The memory is accumulated in one instance of
> "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> loader>".
>
> Let me check at work tomorrow (US EDT) since we get increased traffic after
> 5 PM local time. If MAT doesn't detect the leak (except it thinks
> com.hazelcast.cache.impl.CachePartitionSegment is a leak :) ) then I'd say
> this is resolved. Crossing fingers on both hands. We are getting ready to
> increase traffic on these nodes and the leak would chew through 2G in about
> 10-14 days in the past. Thanks so much for your help and not giving up. For
> whatever weird reason I cannot duplicate this with a test project under a
> load test.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
I have 2 VMs behind a load balancer that basically get the same amount of
traffic. The node running 7.0.2-SNAPSHOT is not leaking any more. I
restarted the 7.0.1 node around the same time and it's leaking already:
The class "org.apache.openejb.util.Logger", loaded by
"java.net.URLClassLoader @ 0x80599a88", occupies 27,435,072 (28.94%) bytes.
The memory is accumulated in one instance of
"java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
loader>".
Let me check at work tomorrow (US EDT) since we get increased traffic after
5 PM local time. If MAT doesn't detect the leak (except it thinks
com.hazelcast.cache.impl.CachePartitionSegment is a leak :) ) then I'd say
this is resolved. Crossing fingers on both hands. We are getting ready to
increase traffic on these nodes and the leak would chew through 2G in about
10-14 days in the past. Thanks so much for your help and not giving up. For
whatever weird reason I cannot duplicate this with a test project under a
load test.
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679218.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Note: https://issues.apache.org/jira/browse/TOMEE-1857
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-04 8:32 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> Think I found something, if I updated the 7.0.2-SNAPSHOT code today, would
> it be possible to test it on your side - either building it from sources or
> waiting for tomorrow snapshot?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-03 23:56 GMT+02:00 sgjava <sg...@gmail.com>:
>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
>> Sent from the TomEE Users mailing list archive at Nabble.com.
>>
>
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
OK, building now. I will have to configure and deploy to the system with
the issue. After running for several hours I'll check with Zabbix
monitoring and MAT.
On Mon, Jul 4, 2016 at 8:02 AM, Romain Manni-Bucau [via TomEE & OpenEJB] <
ml-node+s979440n4679215h76@n4.nabble.com> wrote:
> yes
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-04 14:43 GMT+02:00 Steve Goldsmith <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679215&i=0>>:
>
> > Did you already make the change?
> >
> > On Mon, Jul 4, 2016 at 2:32 AM, Romain Manni-Bucau <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679215&i=1>>
> > wrote:
> >
> > > Think I found something, if I updated the 7.0.2-SNAPSHOT code today,
> > would
> > > it be possible to test it on your side - either building it from
> sources
> > or
> > > waiting for tomorrow snapshot?
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-07-03 23:56 GMT+02:00 sgjava <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679215&i=2>>:
> > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679215.html
> To unsubscribe from TomEE 7.01 heap leak in logging, click here
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5>
> .
> NAML
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Steven P. Goldsmith
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679216.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
yes
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-04 14:43 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> Did you already make the change?
>
> On Mon, Jul 4, 2016 at 2:32 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Think I found something, if I updated the 7.0.2-SNAPSHOT code today,
> would
> > it be possible to test it on your side - either building it from sources
> or
> > waiting for tomorrow snapshot?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-03 23:56 GMT+02:00 sgjava <sg...@gmail.com>:
> >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
Did you already make the change?
On Mon, Jul 4, 2016 at 2:32 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Think I found something, if I updated the 7.0.2-SNAPSHOT code today, would
> it be possible to test it on your side - either building it from sources or
> waiting for tomorrow snapshot?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-03 23:56 GMT+02:00 sgjava <sg...@gmail.com>:
>
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
Deployed 7.0.2-SNAPSHOT to one of the servers with the leak issue. I'll do
a heap dump and MAT analysis later today. Keeping fingers crossed.
On Mon, Jul 4, 2016 at 2:32 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Think I found something, if I updated the 7.0.2-SNAPSHOT code today, would
> it be possible to test it on your side - either building it from sources or
> waiting for tomorrow snapshot?
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-03 23:56 GMT+02:00 sgjava <sg...@gmail.com>:
>
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Think I found something, if I updated the 7.0.2-SNAPSHOT code today, would
it be possible to test it on your side - either building it from sources or
waiting for tomorrow snapshot?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-03 23:56 GMT+02:00 sgjava <sg...@gmail.com>:
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679205.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Do you have the memory tree associated? Validated on few apps - not jms
true - Logger count was constant one initialized.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-03 15:26 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> It grows over time until out of memory condition (may take a couple of
> weeks to burn through 2G). Based on the number of items on the heap it
> definitely is a leak and not normal logging overhead. I just grabbed
> another heap dump (about 24 hours apart):
>
> The class "org.apache.openejb.util.Logger", loaded by
> "java.net.URLClassLoader @ 0x80243738", occupies 228,810,728 (74.48%)
> bytes. The memory is accumulated in one instance of
> "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> loader>".
>
> Note how much it has grown. Since this is occurring over time with 1M+
> items logged daily you may not be seeing the leak in your tests. I'm
> modifying my JCache example app and wil deploy to TomEE and hit it with a
> remote client. I'll do the bombs away on it and keep an eye on it with JMX.
> It could be the MDB's, so I'll add that next and make the same changes I
> made to the TomEE config.
>
>
> On Sat, Jul 2, 2016 at 6:01 PM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > Hmm, checked several more cases (with scheduled beans typically) and it
> > still doesn't leak.
> >
> > So two things:
> >
> > 1. leaking would imply this value increases, until now we just find this
> > retained memory suspicious, right?
> > 2. Agree this value for loggers is quite high, checked debugging in my
> > sample app and I get ~140 loggers in
> > org.apache.openejb.util.Logger.loggerCache - a quick grep on the code
> tend
> > to show it can grow to ~220 to give you an idea == it will not be 1000
> ;) -
> > can you check it as well in your case with a debugger?
> >
> > Also checked the value with jmap and Eclipse Memory Analyzer and there is
> > nothing suspicious there about logger:
> >
> > Class Name | Objects | Shallow Heap | Retained Heap
> > -----------------------------------------------------------------------
> > org.apache.openejb.util.Logger| 141 | 3 384 | >= 40 784
> > -----------------------------------------------------------------------
> >
> > So here my current thoughts - happy to get yours as well:
> > - logger behavior looks ok
> > - memory is 100% linked to the underlying system (a logger is tomee
> facade
> > which delegates to a LogStream which is an integration with a logging
> > framework like JUL, SLF4J, Log4j2 etc...) and this LogStream has
> generally
> > a reference to the actual logger impl which has handlers/appenders
> etc...).
> > => maybe the underlying system is configured in a way making the memory
> > quite consuming? Saw that very rarely but if you bufferize a lot logs for
> > speed you can consumer such an amount of memory
> >
> > Last thing we didn't speak about yet: I used java 8 (u77) to do my tests.
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-02 21:49 GMT+02:00 sgjava <sg...@gmail.com>:
> >
> > > TomEE Plus 7.0.1 configured as such:
> > >
> > > •Edit NEW_TOMEE/conf/system.properties
> > > ◦Comment out (it’s probably a better idea to use the whitelist which I
> > need
> > > to work on)
> > >
> > > # tomee.serialization.class.blacklist = *
> > >
> > > ◦Add
> > >
> > > # Avoid EJB naming conflicts
> > > openejb.deploymentId.format = {ejbJarId}/{ejbName}
> > >
> > > # Increase JMS/MDB pools
> > > Default\ JMS\ Resource\ Adapter.threadPoolSize=100
> > > Default\ MDB\ Container.InstanceLimit=100
> > >
> > > # Increase stateless bean pool
> > > Default\ Stateless\ Container.MaxSize=100
> > >
> > > # ActiveMQ security
> > >
> > >
> >
> org.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.thoughtworks.xstream.mapper,com.bhn.services.masblaster
> > >
> > >
> > > •Edit NEW_TOMEE/conf/server.xml
> > > ◦Replace 8080 with 8180
> > > ◦Replace 8443 with 8143
> > > ◦Replace 8009 with 8109
> > > ◦Replace 8005 with 8105
> > > ◦Add in listener section
> > >
> > >
> > > <Listener
> > className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> > > rmiRegistryPortPlatform="8104" rmiServerPortPlatform="8104"/>
> > >
> > > ◦Add executor
> > >
> > >
> > > <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
> > > maxIdleTime="60000" maxThreads="300" minSpareThreads="4"/>
> > >
> > > ◦Add SSL connector with proper ciphers
> > >
> > > <Connector executor="tomcatThreadPool" port="8143"
> > > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > > connectionTimeout="40000" SSLEnabled="true" scheme="https"
> > > secure="true"
> > > clientAuth="false" sslProtocol="TLS" xpoweredBy="false"
> > server="Apache
> > > TomEE"
> > > keystoreFile="/opt/tomcat/conf/keystore.jks"
> keystorePass="password"
> > >
> > >
> > >
> >
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> > >
> > >
> >
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
> > >
> > >
> > >
> >
> TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
> > > TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"/>
> > >
> > >
> > > Web app logging:
> > >
> > > private static final Logger log =
> > > Logger.getLogger(SomeClass.class.getName());
> > >
> > > No additional logging libraries added.
> > >
> > >
> > > On Sat, Jul 2, 2016 at 11:04 AM, Romain Manni-Bucau [via TomEE &
> > OpenEJB] <
> > > ml-node+s979440n4679193h94@n4.nabble.com> wrote:
> > >
> > > > Can you share how your tomee is set up?
> > > >
> > > > Dont observe it locally.
> > > > Le 2 juil. 2016 16:15, "Steve Goldsmith" <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=0>> a écrit :
> > > >
> > > > > OK, using the JDK logger I'm seeing the same issue in 7.0.1!
> > > > >
> > > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > > "java.net.URLClassLoader @ 0x80244158", occupies 127,485,416
> (64.82%)
> > > > > bytes. The memory is accumulated in one instance of
> > > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> > > class
> > > > > loader>".
> > > > >
> > > > > java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
> > > > > 4,194,320 127,477,056
> > > > > \table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
> > > > > 64 127,477,120
> > > > > .\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
> > > > > 24 127,477,144
> > > > > ..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
> > > > > 48 127,485,416
> > > > > ...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
> > > > > 24 104
> > > > > ...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader
> @
> > > > > 0x80650ff0
> > > > > 24 136
> > > > > ...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @
> > > > 0x80a1f9a8
> > > > > 168 233,776
> > > > > ...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
> > > > > PoolIdleReleaseTimer Thread
> > > > > 128 752
> > > > > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8
> > pool-2-thread-2
> > > > > Thread
> > > > > 120 288
> > > > > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a540
> > pool-2-thread-1
> > > > > Thread
> > > > > 120 288
> > > > > ...|..+contextClassLoader
> > > > >
> > > >
> > >
> >
> com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread @
> > > > > 0x81dda2c8 hz._hzInstance_1_dev.migration Thread
> > > > > 136 416
> > > > > ...|..+contextClassLoader
> > > > >
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > > > > 0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
> > > > > 168 1,312
> > > > > ...|..+contextClassLoader
> > > > >
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > > > > 0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
> > > > > 168 1,384
> > > > > ...|..+contextClassLoader
> > > > >
> > com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> > > > @
> > > > > 0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
> > > > > 168 704
> > > > > ...|..+contextClassLoader
> > > > >
> > com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> > > > @
> > > > > 0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
> > > > > 168 736
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
> > > > > hz._hzInstance_1_dev.event-5 Thread
> > > > > 128 664
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
> > > > > hz._hzInstance_1_dev.event-4 Thread
> > > > > 128 872
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
> > > > > hz._hzInstance_1_dev.event-3 Thread
> > > > > 128 696
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
> > > > > hz._hzInstance_1_dev.event-2 Thread
> > > > > 128 664
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
> > > > > hz._hzInstance_1_dev.event-1 Thread
> > > > > 128 664
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
> > > > > hz._hzInstance_1_dev.IO.thread-in-2 Thread
> > > > > 168 5,544
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
> > > > > hz._hzInstance_1_dev.IO.thread-in-1 Thread
> > > > > 168 5,544
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
> > > > > hz._hzInstance_1_dev.IO.thread-in-0 Thread
> > > > > 168 5,000
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
> > > > > hz._hzInstance_1_dev.IO.thread-out-2 Thread
> > > > > 168 5,544
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
> > > > > hz._hzInstance_1_dev.IO.thread-out-1 Thread
> > > > > 168 5,544
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
> > > > > hz._hzInstance_1_dev.IO.thread-out-0 Thread
> > > > > 168 4,968
> > > > > ...|..+contextClassLoader
> > > > > com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @
> > > > 0x81e1c9b0
> > > > > hz._hzInstance_1_dev.IOBalancerThread Thread
> > > > > 136 608
> > > > > ...|..+contextClassLoader
> com.hazelcast.nio.tcp.SocketAcceptorThread
> > @
> > > > > 0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
> > > > > 152 448
> > > > > ...|..+contextClassLoader
> > > > >
> > > > >
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
> > > >
> > > > > @ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
> > > > > 128 328
> > > > > ...|..+contextClassLoader
> > > > >
> > > > >
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
> > > >
> > > > > @ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread
> Thread
> > > > > 128 440
> > > > > ...|..+contextClassLoader
> > > > >
> > com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > > > > 0x81e3da48 scheduled Thread
> > > > > 128 464
> > > > > ...|..+contextClassLoader
> > > > >
> > com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > > > > 0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
> > > > > 128 408
> > > > > ...|..\Total: 25 of 29 entries; 4 more
> > > > >
> > > > > ...+[317] java.lang.Object[10240] @ 0x81c405c8 »
> > > > > 40,976 1,771,416
> > > > > ...\Total: 2 entries
> > > > >
> > > > > I'm also using hazelcast as my JCache provider and am seeing
> (hoping
> > > > this
> > > > > is just because of the cache structures):
> > > > >
> > > > > "com.hazelcast.cache.impl.CacheService" loaded by
> > > > "java.net.URLClassLoader
> > > > > @ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is
> > > > accumulated
> > > > > in one instance of
> "com.hazelcast.cache.impl.CachePartitionSegment[]"
> > > > > loaded by "java.net.URLClassLoader @ 0x80244158".
> > > > >
> > > > >
> > > > >
> > > > > On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=1>>
> > > > > wrote:
> > > > >
> > > > > > (Avoiding comments on the quality of logging frameworks ;))
> > > > > >
> > > > > >
> > > > > > Just validated on 7.0.1 and if you provide it by webapp the cache
> > is
> > > > > > correctly setup by webapp.
> > > > > >
> > > > > > In the container it will leak cause logback doesn't provide a by
> > > > > > classloader ContextSelector.
> > > > > >
> > > > > >
> > > > > > Side note: log4j2 provides one and is integrated with tomee as
> well
> > > if
> > > > > you
> > > > > > miss some features for logging guess log4j2 filled the gap
> logback
> > > > > created
> > > > > > with log4j1.
> > > > > >
> > > > > >
> > > > > > Le 1 juil. 2016 22:28, "Steve Goldsmith" <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=2>> a écrit :
> > > > > >
> > > > > > > For now I switched to JDK logger to see if the leak goes away.
> > I'm
> > > > OK
> > > > > > using
> > > > > > > that, but logback+slf4j is a better solution.
> > > > > > >
> > > > > > > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
> > > > > > [hidden email] <http://
> > > /user/SendEmail.jtp?type=node&node=4679193&i=3>>
> > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > basically the idea is to use slf4-api as a reference to where
> > to
> > > > load
> > > > > > > from
> > > > > > > > slf4j api+impl
> > > > > > > >
> > > > > > > > == ie in the webapp we'll take the impl of the container from
> > the
> > > > > > webapp,
> > > > > > > > if in the container we'll use the container impl
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> > Tomitriber
> > > > > > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > > > >
> > > > > > > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=4>>:
> > > > > > > >
> > > > > > > > > Since I'm using provided scope I'm only referencing it at
> > > > compile
> > > > > > time,
> > > > > > > > but
> > > > > > > > > I noticed my logback config is not picked up now. Do I need
> > to
> > > > put
> > > > > > > those
> > > > > > > > > jars in TOMEE/lib as well?
> > > > > > > > >
> > > > > > > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > > > > > > > [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=5>
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Yes but you reuse container slf4j here instead of webapp
> > one
> > > > so
> > > > > > > leaking
> > > > > > > > > can
> > > > > > > > > > be "normal" depending slf4j impl config. Jul one -
> default
> > -
> > > > > > shouldnt
> > > > > > > > > leak.
> > > > > > > > > > Le 1 juil. 2016 02:05, "sgjava" <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=6>> a écrit :
> > > > > > > > > >
> > > > > > > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and
> > ran
> > > > on
> > > > > > > server:
> > > > > > > > > > >
> > > > > > > > > > > <dependency>
> > > > > > > > > > > <groupId>org.slf4j</groupId>
> > > > > > > > > > > <artifactId>slf4j-api</artifactId>
> > > > > > > > > > > <version>${slf4j.version}</version>
> > > > > > > > > > > <scope>provided</scope>
> > > > > > > > > > > </dependency>
> > > > > > > > > > >
> > > > > > > > > > >
> System.out.println(LoggerFactory.class.getClassLoader());
> > > > > > > > > > > System.out.println(log.getClass().getClassLoader());
> > > > > > > > > > >
> > > > > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > > > >
> > > > > > > > > > > Does this look correct?
> > > > > > > > > > >
> > > > > > > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau
> [via
> > > > TomEE
> > > > > &
> > > > > > > > > > OpenEJB] <
> > > > > > > > > > > [hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=7>> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Im not sure what you mean but all good logging
> > framework
> > > > > > provide
> > > > > > > a
> > > > > > > > > > > > classloader friendly impl - juli, log4j2 etc... -
> which
> > > > > doesnt
> > > > > > > > leak.
> > > > > > > > > > Know
> > > > > > > > > > > > logback has something like that but never tested it.
> > > > > > > > > > > >
> > > > > > > > > > > > The fact you load slf4j with app loader can mean you
> > put
> > > > it
> > > > > in
> > > > > > > the
> > > > > > > > > > > > classpath which sounds wrong, should only be in
> common
> > > > loader
> > > > > > and
> > > > > > > > > > > > optionally webapp one.
> > > > > > > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > > > > > > > <http://
> > /user/SendEmail.jtp?type=node&node=4679161&i=0>>
> > > > a
> > > > > > > écrit :
> > > > > > > > > > > >
> > > > > > > > > > > > > Also found
> > > > > > http://java.jiderhamn.se/category/classloader-leaks
> > > > > > > > > > > > >
> > > > > > > > > > > > > As for java.util.logging (JUL), it will always be
> > > > outside
> > > > > the
> > > > > > > web
> > > > > > > > > > > > > application, since it is part of the JDK. With it
> you
> > > > can
> > > > > > cause
> > > > > > > > > > > > classloader
> > > > > > > > > > > > > leaks by creating custom log Levels inside your web
> > > app.
> > > > > This
> > > > > > > is
> > > > > > > > > what
> > > > > > > > > > > > Frank
> > > > > > > > > > > > > Kieviet uses as example in his blog post on
> > classloader
> > > > > > leaks.
> > > > > > > It
> > > > > > > > > > seems
> > > > > > > > > > > > > also
> > > > > > > > > > > > > that JBoss Logging does exactly that if backed by
> > JUL,
> > > > and
> > > > > > > > thereby
> > > > > > > > > > > > triggers
> > > > > > > > > > > > > such a leak if loaded within your web app. See
> report
> > > > here.
> > > > > > > > > > > > >
> > > > > > > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too!
> > So
> > > > do I
> > > > > > > just
> > > > > > > > > > switch
> > > > > > > > > > > > to
> > > > > > > > > > > > > JUL? This really sucks since logback is more
> refined.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > View this message in context:
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > > > > > > > Sent from the TomEE Users mailing list archive at
> > > > > Nabble.com.
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > ------------------------------
> > > > > > > > > > > > If you reply to this email, your message will be
> added
> > to
> > > > the
> > > > > > > > > > discussion
> > > > > > > > > > > > below:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging,
> > > click
> > > > > here
> > > > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > > > > > > > >
> > > > > > > > > > > > .
> > > > > > > > > > > > NAML
> > > > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Steven P. Goldsmith
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > View this message in context:
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > > > > > > > Sent from the TomEE Users mailing list archive at
> > > > Nabble.com.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Steven P. Goldsmith
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Steven P. Goldsmith
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Steven P. Goldsmith
> > > > >
> > > >
> > > >
> > > > ------------------------------
> > > > If you reply to this email, your message will be added to the
> > discussion
> > > > below:
> > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679193.html
> > > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > > <
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > > >
> > > > .
> > > > NAML
> > > > <
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679197.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
It grows over time until out of memory condition (may take a couple of
weeks to burn through 2G). Based on the number of items on the heap it
definitely is a leak and not normal logging overhead. I just grabbed
another heap dump (about 24 hours apart):
The class "org.apache.openejb.util.Logger", loaded by
"java.net.URLClassLoader @ 0x80243738", occupies 228,810,728 (74.48%)
bytes. The memory is accumulated in one instance of
"java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
loader>".
Note how much it has grown. Since this is occurring over time with 1M+
items logged daily you may not be seeing the leak in your tests. I'm
modifying my JCache example app and wil deploy to TomEE and hit it with a
remote client. I'll do the bombs away on it and keep an eye on it with JMX.
It could be the MDB's, so I'll add that next and make the same changes I
made to the TomEE config.
On Sat, Jul 2, 2016 at 6:01 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hmm, checked several more cases (with scheduled beans typically) and it
> still doesn't leak.
>
> So two things:
>
> 1. leaking would imply this value increases, until now we just find this
> retained memory suspicious, right?
> 2. Agree this value for loggers is quite high, checked debugging in my
> sample app and I get ~140 loggers in
> org.apache.openejb.util.Logger.loggerCache - a quick grep on the code tend
> to show it can grow to ~220 to give you an idea == it will not be 1000 ;) -
> can you check it as well in your case with a debugger?
>
> Also checked the value with jmap and Eclipse Memory Analyzer and there is
> nothing suspicious there about logger:
>
> Class Name | Objects | Shallow Heap | Retained Heap
> -----------------------------------------------------------------------
> org.apache.openejb.util.Logger| 141 | 3 384 | >= 40 784
> -----------------------------------------------------------------------
>
> So here my current thoughts - happy to get yours as well:
> - logger behavior looks ok
> - memory is 100% linked to the underlying system (a logger is tomee facade
> which delegates to a LogStream which is an integration with a logging
> framework like JUL, SLF4J, Log4j2 etc...) and this LogStream has generally
> a reference to the actual logger impl which has handlers/appenders etc...).
> => maybe the underlying system is configured in a way making the memory
> quite consuming? Saw that very rarely but if you bufferize a lot logs for
> speed you can consumer such an amount of memory
>
> Last thing we didn't speak about yet: I used java 8 (u77) to do my tests.
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-02 21:49 GMT+02:00 sgjava <sg...@gmail.com>:
>
> > TomEE Plus 7.0.1 configured as such:
> >
> > •Edit NEW_TOMEE/conf/system.properties
> > ◦Comment out (it’s probably a better idea to use the whitelist which I
> need
> > to work on)
> >
> > # tomee.serialization.class.blacklist = *
> >
> > ◦Add
> >
> > # Avoid EJB naming conflicts
> > openejb.deploymentId.format = {ejbJarId}/{ejbName}
> >
> > # Increase JMS/MDB pools
> > Default\ JMS\ Resource\ Adapter.threadPoolSize=100
> > Default\ MDB\ Container.InstanceLimit=100
> >
> > # Increase stateless bean pool
> > Default\ Stateless\ Container.MaxSize=100
> >
> > # ActiveMQ security
> >
> >
> org.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.thoughtworks.xstream.mapper,com.bhn.services.masblaster
> >
> >
> > •Edit NEW_TOMEE/conf/server.xml
> > ◦Replace 8080 with 8180
> > ◦Replace 8443 with 8143
> > ◦Replace 8009 with 8109
> > ◦Replace 8005 with 8105
> > ◦Add in listener section
> >
> >
> > <Listener
> className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> > rmiRegistryPortPlatform="8104" rmiServerPortPlatform="8104"/>
> >
> > ◦Add executor
> >
> >
> > <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
> > maxIdleTime="60000" maxThreads="300" minSpareThreads="4"/>
> >
> > ◦Add SSL connector with proper ciphers
> >
> > <Connector executor="tomcatThreadPool" port="8143"
> > protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> > connectionTimeout="40000" SSLEnabled="true" scheme="https"
> > secure="true"
> > clientAuth="false" sslProtocol="TLS" xpoweredBy="false"
> server="Apache
> > TomEE"
> > keystoreFile="/opt/tomcat/conf/keystore.jks" keystorePass="password"
> >
> >
> >
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
> >
> >
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
> >
> >
> >
> TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
> > TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"/>
> >
> >
> > Web app logging:
> >
> > private static final Logger log =
> > Logger.getLogger(SomeClass.class.getName());
> >
> > No additional logging libraries added.
> >
> >
> > On Sat, Jul 2, 2016 at 11:04 AM, Romain Manni-Bucau [via TomEE &
> OpenEJB] <
> > ml-node+s979440n4679193h94@n4.nabble.com> wrote:
> >
> > > Can you share how your tomee is set up?
> > >
> > > Dont observe it locally.
> > > Le 2 juil. 2016 16:15, "Steve Goldsmith" <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=0>> a écrit :
> > >
> > > > OK, using the JDK logger I'm seeing the same issue in 7.0.1!
> > > >
> > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > "java.net.URLClassLoader @ 0x80244158", occupies 127,485,416 (64.82%)
> > > > bytes. The memory is accumulated in one instance of
> > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> > class
> > > > loader>".
> > > >
> > > > java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
> > > > 4,194,320 127,477,056
> > > > \table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
> > > > 64 127,477,120
> > > > .\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
> > > > 24 127,477,144
> > > > ..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
> > > > 48 127,485,416
> > > > ...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
> > > > 24 104
> > > > ...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader @
> > > > 0x80650ff0
> > > > 24 136
> > > > ...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @
> > > 0x80a1f9a8
> > > > 168 233,776
> > > > ...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
> > > > PoolIdleReleaseTimer Thread
> > > > 128 752
> > > > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8
> pool-2-thread-2
> > > > Thread
> > > > 120 288
> > > > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a540
> pool-2-thread-1
> > > > Thread
> > > > 120 288
> > > > ...|..+contextClassLoader
> > > >
> > >
> >
> com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread @
> > > > 0x81dda2c8 hz._hzInstance_1_dev.migration Thread
> > > > 136 416
> > > > ...|..+contextClassLoader
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > > > 0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
> > > > 168 1,312
> > > > ...|..+contextClassLoader
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > > > 0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
> > > > 168 1,384
> > > > ...|..+contextClassLoader
> > > >
> com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> > > @
> > > > 0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
> > > > 168 704
> > > > ...|..+contextClassLoader
> > > >
> com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> > > @
> > > > 0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
> > > > 168 736
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
> > > > hz._hzInstance_1_dev.event-5 Thread
> > > > 128 664
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
> > > > hz._hzInstance_1_dev.event-4 Thread
> > > > 128 872
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
> > > > hz._hzInstance_1_dev.event-3 Thread
> > > > 128 696
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
> > > > hz._hzInstance_1_dev.event-2 Thread
> > > > 128 664
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
> > > > hz._hzInstance_1_dev.event-1 Thread
> > > > 128 664
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
> > > > hz._hzInstance_1_dev.IO.thread-in-2 Thread
> > > > 168 5,544
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
> > > > hz._hzInstance_1_dev.IO.thread-in-1 Thread
> > > > 168 5,544
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
> > > > hz._hzInstance_1_dev.IO.thread-in-0 Thread
> > > > 168 5,000
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
> > > > hz._hzInstance_1_dev.IO.thread-out-2 Thread
> > > > 168 5,544
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
> > > > hz._hzInstance_1_dev.IO.thread-out-1 Thread
> > > > 168 5,544
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
> > > > hz._hzInstance_1_dev.IO.thread-out-0 Thread
> > > > 168 4,968
> > > > ...|..+contextClassLoader
> > > > com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @
> > > 0x81e1c9b0
> > > > hz._hzInstance_1_dev.IOBalancerThread Thread
> > > > 136 608
> > > > ...|..+contextClassLoader com.hazelcast.nio.tcp.SocketAcceptorThread
> @
> > > > 0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
> > > > 152 448
> > > > ...|..+contextClassLoader
> > > >
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
> > >
> > > > @ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
> > > > 128 328
> > > > ...|..+contextClassLoader
> > > >
> > > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
> > >
> > > > @ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread Thread
> > > > 128 440
> > > > ...|..+contextClassLoader
> > > >
> com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > > > 0x81e3da48 scheduled Thread
> > > > 128 464
> > > > ...|..+contextClassLoader
> > > >
> com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > > > 0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
> > > > 128 408
> > > > ...|..\Total: 25 of 29 entries; 4 more
> > > >
> > > > ...+[317] java.lang.Object[10240] @ 0x81c405c8 »
> > > > 40,976 1,771,416
> > > > ...\Total: 2 entries
> > > >
> > > > I'm also using hazelcast as my JCache provider and am seeing (hoping
> > > this
> > > > is just because of the cache structures):
> > > >
> > > > "com.hazelcast.cache.impl.CacheService" loaded by
> > > "java.net.URLClassLoader
> > > > @ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is
> > > accumulated
> > > > in one instance of "com.hazelcast.cache.impl.CachePartitionSegment[]"
> > > > loaded by "java.net.URLClassLoader @ 0x80244158".
> > > >
> > > >
> > > >
> > > > On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=1>>
> > > > wrote:
> > > >
> > > > > (Avoiding comments on the quality of logging frameworks ;))
> > > > >
> > > > >
> > > > > Just validated on 7.0.1 and if you provide it by webapp the cache
> is
> > > > > correctly setup by webapp.
> > > > >
> > > > > In the container it will leak cause logback doesn't provide a by
> > > > > classloader ContextSelector.
> > > > >
> > > > >
> > > > > Side note: log4j2 provides one and is integrated with tomee as well
> > if
> > > > you
> > > > > miss some features for logging guess log4j2 filled the gap logback
> > > > created
> > > > > with log4j1.
> > > > >
> > > > >
> > > > > Le 1 juil. 2016 22:28, "Steve Goldsmith" <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=2>> a écrit :
> > > > >
> > > > > > For now I switched to JDK logger to see if the leak goes away.
> I'm
> > > OK
> > > > > using
> > > > > > that, but logback+slf4j is a better solution.
> > > > > >
> > > > > > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
> > > > > [hidden email] <http://
> > /user/SendEmail.jtp?type=node&node=4679193&i=3>>
> > >
> > > > > > wrote:
> > > > > >
> > > > > > > basically the idea is to use slf4-api as a reference to where
> to
> > > load
> > > > > > from
> > > > > > > slf4j api+impl
> > > > > > >
> > > > > > > == ie in the webapp we'll take the impl of the container from
> the
> > > > > webapp,
> > > > > > > if in the container we'll use the container impl
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> |
> Tomitriber
> > > > > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > > >
> > > > > > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=4>>:
> > > > > > >
> > > > > > > > Since I'm using provided scope I'm only referencing it at
> > > compile
> > > > > time,
> > > > > > > but
> > > > > > > > I noticed my logback config is not picked up now. Do I need
> to
> > > put
> > > > > > those
> > > > > > > > jars in TOMEE/lib as well?
> > > > > > > >
> > > > > > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > > > > > > [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=5>
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Yes but you reuse container slf4j here instead of webapp
> one
> > > so
> > > > > > leaking
> > > > > > > > can
> > > > > > > > > be "normal" depending slf4j impl config. Jul one - default
> -
> > > > > shouldnt
> > > > > > > > leak.
> > > > > > > > > Le 1 juil. 2016 02:05, "sgjava" <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=6>> a écrit :
> > > > > > > > >
> > > > > > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and
> ran
> > > on
> > > > > > server:
> > > > > > > > > >
> > > > > > > > > > <dependency>
> > > > > > > > > > <groupId>org.slf4j</groupId>
> > > > > > > > > > <artifactId>slf4j-api</artifactId>
> > > > > > > > > > <version>${slf4j.version}</version>
> > > > > > > > > > <scope>provided</scope>
> > > > > > > > > > </dependency>
> > > > > > > > > >
> > > > > > > > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > > > > > > > System.out.println(log.getClass().getClassLoader());
> > > > > > > > > >
> > > > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > > >
> > > > > > > > > > Does this look correct?
> > > > > > > > > >
> > > > > > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via
> > > TomEE
> > > > &
> > > > > > > > > OpenEJB] <
> > > > > > > > > > [hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679193&i=7>> wrote:
> > > > > > > > > >
> > > > > > > > > > > Im not sure what you mean but all good logging
> framework
> > > > > provide
> > > > > > a
> > > > > > > > > > > classloader friendly impl - juli, log4j2 etc... - which
> > > > doesnt
> > > > > > > leak.
> > > > > > > > > Know
> > > > > > > > > > > logback has something like that but never tested it.
> > > > > > > > > > >
> > > > > > > > > > > The fact you load slf4j with app loader can mean you
> put
> > > it
> > > > in
> > > > > > the
> > > > > > > > > > > classpath which sounds wrong, should only be in common
> > > loader
> > > > > and
> > > > > > > > > > > optionally webapp one.
> > > > > > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > > > > > > <http://
> /user/SendEmail.jtp?type=node&node=4679161&i=0>>
> > > a
> > > > > > écrit :
> > > > > > > > > > >
> > > > > > > > > > > > Also found
> > > > > http://java.jiderhamn.se/category/classloader-leaks
> > > > > > > > > > > >
> > > > > > > > > > > > As for java.util.logging (JUL), it will always be
> > > outside
> > > > the
> > > > > > web
> > > > > > > > > > > > application, since it is part of the JDK. With it you
> > > can
> > > > > cause
> > > > > > > > > > > classloader
> > > > > > > > > > > > leaks by creating custom log Levels inside your web
> > app.
> > > > This
> > > > > > is
> > > > > > > > what
> > > > > > > > > > > Frank
> > > > > > > > > > > > Kieviet uses as example in his blog post on
> classloader
> > > > > leaks.
> > > > > > It
> > > > > > > > > seems
> > > > > > > > > > > > also
> > > > > > > > > > > > that JBoss Logging does exactly that if backed by
> JUL,
> > > and
> > > > > > > thereby
> > > > > > > > > > > triggers
> > > > > > > > > > > > such a leak if loaded within your web app. See report
> > > here.
> > > > > > > > > > > >
> > > > > > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too!
> So
> > > do I
> > > > > > just
> > > > > > > > > switch
> > > > > > > > > > > to
> > > > > > > > > > > > JUL? This really sucks since logback is more refined.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > View this message in context:
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > > > > > > Sent from the TomEE Users mailing list archive at
> > > > Nabble.com.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > ------------------------------
> > > > > > > > > > > If you reply to this email, your message will be added
> to
> > > the
> > > > > > > > > discussion
> > > > > > > > > > > below:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging,
> > click
> > > > here
> > > > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > > > > > > > >
> > > > > > > > > > > .
> > > > > > > > > > > NAML
> > > > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Steven P. Goldsmith
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > View this message in context:
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > > > > > > Sent from the TomEE Users mailing list archive at
> > > Nabble.com.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Steven P. Goldsmith
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Steven P. Goldsmith
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Steven P. Goldsmith
> > > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679193.html
> > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > <
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > >
> > > .
> > > NAML
> > > <
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679197.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hmm, checked several more cases (with scheduled beans typically) and it
still doesn't leak.
So two things:
1. leaking would imply this value increases, until now we just find this
retained memory suspicious, right?
2. Agree this value for loggers is quite high, checked debugging in my
sample app and I get ~140 loggers in
org.apache.openejb.util.Logger.loggerCache - a quick grep on the code tend
to show it can grow to ~220 to give you an idea == it will not be 1000 ;) -
can you check it as well in your case with a debugger?
Also checked the value with jmap and Eclipse Memory Analyzer and there is
nothing suspicious there about logger:
Class Name | Objects | Shallow Heap | Retained Heap
-----------------------------------------------------------------------
org.apache.openejb.util.Logger| 141 | 3 384 | >= 40 784
-----------------------------------------------------------------------
So here my current thoughts - happy to get yours as well:
- logger behavior looks ok
- memory is 100% linked to the underlying system (a logger is tomee facade
which delegates to a LogStream which is an integration with a logging
framework like JUL, SLF4J, Log4j2 etc...) and this LogStream has generally
a reference to the actual logger impl which has handlers/appenders etc...).
=> maybe the underlying system is configured in a way making the memory
quite consuming? Saw that very rarely but if you bufferize a lot logs for
speed you can consumer such an amount of memory
Last thing we didn't speak about yet: I used java 8 (u77) to do my tests.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-02 21:49 GMT+02:00 sgjava <sg...@gmail.com>:
> TomEE Plus 7.0.1 configured as such:
>
> •Edit NEW_TOMEE/conf/system.properties
> ◦Comment out (it’s probably a better idea to use the whitelist which I need
> to work on)
>
> # tomee.serialization.class.blacklist = *
>
> ◦Add
>
> # Avoid EJB naming conflicts
> openejb.deploymentId.format = {ejbJarId}/{ejbName}
>
> # Increase JMS/MDB pools
> Default\ JMS\ Resource\ Adapter.threadPoolSize=100
> Default\ MDB\ Container.InstanceLimit=100
>
> # Increase stateless bean pool
> Default\ Stateless\ Container.MaxSize=100
>
> # ActiveMQ security
>
> org.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.thoughtworks.xstream.mapper,com.bhn.services.masblaster
>
>
> •Edit NEW_TOMEE/conf/server.xml
> ◦Replace 8080 with 8180
> ◦Replace 8443 with 8143
> ◦Replace 8009 with 8109
> ◦Replace 8005 with 8105
> ◦Add in listener section
>
>
> <Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
> rmiRegistryPortPlatform="8104" rmiServerPortPlatform="8104"/>
>
> ◦Add executor
>
>
> <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
> maxIdleTime="60000" maxThreads="300" minSpareThreads="4"/>
>
> ◦Add SSL connector with proper ciphers
>
> <Connector executor="tomcatThreadPool" port="8143"
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"
> connectionTimeout="40000" SSLEnabled="true" scheme="https"
> secure="true"
> clientAuth="false" sslProtocol="TLS" xpoweredBy="false" server="Apache
> TomEE"
> keystoreFile="/opt/tomcat/conf/keystore.jks" keystorePass="password"
>
>
> ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
>
>
> TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
> TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"/>
>
>
> Web app logging:
>
> private static final Logger log =
> Logger.getLogger(SomeClass.class.getName());
>
> No additional logging libraries added.
>
>
> On Sat, Jul 2, 2016 at 11:04 AM, Romain Manni-Bucau [via TomEE & OpenEJB] <
> ml-node+s979440n4679193h94@n4.nabble.com> wrote:
>
> > Can you share how your tomee is set up?
> >
> > Dont observe it locally.
> > Le 2 juil. 2016 16:15, "Steve Goldsmith" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=0>> a écrit :
> >
> > > OK, using the JDK logger I'm seeing the same issue in 7.0.1!
> > >
> > > The class "org.apache.openejb.util.Logger", loaded by
> > > "java.net.URLClassLoader @ 0x80244158", occupies 127,485,416 (64.82%)
> > > bytes. The memory is accumulated in one instance of
> > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> class
> > > loader>".
> > >
> > > java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
> > > 4,194,320 127,477,056
> > > \table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
> > > 64 127,477,120
> > > .\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
> > > 24 127,477,144
> > > ..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
> > > 48 127,485,416
> > > ...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
> > > 24 104
> > > ...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader @
> > > 0x80650ff0
> > > 24 136
> > > ...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @
> > 0x80a1f9a8
> > > 168 233,776
> > > ...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
> > > PoolIdleReleaseTimer Thread
> > > 128 752
> > > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8 pool-2-thread-2
> > > Thread
> > > 120 288
> > > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a540 pool-2-thread-1
> > > Thread
> > > 120 288
> > > ...|..+contextClassLoader
> > >
> >
> com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread @
> > > 0x81dda2c8 hz._hzInstance_1_dev.migration Thread
> > > 136 416
> > > ...|..+contextClassLoader
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > > 0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
> > > 168 1,312
> > > ...|..+contextClassLoader
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > > 0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
> > > 168 1,384
> > > ...|..+contextClassLoader
> > > com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> > @
> > > 0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
> > > 168 704
> > > ...|..+contextClassLoader
> > > com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> > @
> > > 0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
> > > 168 736
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
> > > hz._hzInstance_1_dev.event-5 Thread
> > > 128 664
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
> > > hz._hzInstance_1_dev.event-4 Thread
> > > 128 872
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
> > > hz._hzInstance_1_dev.event-3 Thread
> > > 128 696
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
> > > hz._hzInstance_1_dev.event-2 Thread
> > > 128 664
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
> > > hz._hzInstance_1_dev.event-1 Thread
> > > 128 664
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
> > > hz._hzInstance_1_dev.IO.thread-in-2 Thread
> > > 168 5,544
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
> > > hz._hzInstance_1_dev.IO.thread-in-1 Thread
> > > 168 5,544
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
> > > hz._hzInstance_1_dev.IO.thread-in-0 Thread
> > > 168 5,000
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
> > > hz._hzInstance_1_dev.IO.thread-out-2 Thread
> > > 168 5,544
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
> > > hz._hzInstance_1_dev.IO.thread-out-1 Thread
> > > 168 5,544
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
> > > hz._hzInstance_1_dev.IO.thread-out-0 Thread
> > > 168 4,968
> > > ...|..+contextClassLoader
> > > com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @
> > 0x81e1c9b0
> > > hz._hzInstance_1_dev.IOBalancerThread Thread
> > > 136 608
> > > ...|..+contextClassLoader com.hazelcast.nio.tcp.SocketAcceptorThread @
> > > 0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
> > > 152 448
> > > ...|..+contextClassLoader
> > >
> > >
> >
> com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
> >
> > > @ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
> > > 128 328
> > > ...|..+contextClassLoader
> > >
> > >
> >
> com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
> >
> > > @ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread Thread
> > > 128 440
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > > 0x81e3da48 scheduled Thread
> > > 128 464
> > > ...|..+contextClassLoader
> > > com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > > 0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
> > > 128 408
> > > ...|..\Total: 25 of 29 entries; 4 more
> > >
> > > ...+[317] java.lang.Object[10240] @ 0x81c405c8 »
> > > 40,976 1,771,416
> > > ...\Total: 2 entries
> > >
> > > I'm also using hazelcast as my JCache provider and am seeing (hoping
> > this
> > > is just because of the cache structures):
> > >
> > > "com.hazelcast.cache.impl.CacheService" loaded by
> > "java.net.URLClassLoader
> > > @ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is
> > accumulated
> > > in one instance of "com.hazelcast.cache.impl.CachePartitionSegment[]"
> > > loaded by "java.net.URLClassLoader @ 0x80244158".
> > >
> > >
> > >
> > > On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=1>>
> > > wrote:
> > >
> > > > (Avoiding comments on the quality of logging frameworks ;))
> > > >
> > > >
> > > > Just validated on 7.0.1 and if you provide it by webapp the cache is
> > > > correctly setup by webapp.
> > > >
> > > > In the container it will leak cause logback doesn't provide a by
> > > > classloader ContextSelector.
> > > >
> > > >
> > > > Side note: log4j2 provides one and is integrated with tomee as well
> if
> > > you
> > > > miss some features for logging guess log4j2 filled the gap logback
> > > created
> > > > with log4j1.
> > > >
> > > >
> > > > Le 1 juil. 2016 22:28, "Steve Goldsmith" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=2>> a écrit :
> > > >
> > > > > For now I switched to JDK logger to see if the leak goes away. I'm
> > OK
> > > > using
> > > > > that, but logback+slf4j is a better solution.
> > > > >
> > > > > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
> > > > [hidden email] <http://
> /user/SendEmail.jtp?type=node&node=4679193&i=3>>
> >
> > > > > wrote:
> > > > >
> > > > > > basically the idea is to use slf4-api as a reference to where to
> > load
> > > > > from
> > > > > > slf4j api+impl
> > > > > >
> > > > > > == ie in the webapp we'll take the impl of the container from the
> > > > webapp,
> > > > > > if in the container we'll use the container impl
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > > >
> > > > > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=4>>:
> > > > > >
> > > > > > > Since I'm using provided scope I'm only referencing it at
> > compile
> > > > time,
> > > > > > but
> > > > > > > I noticed my logback config is not picked up now. Do I need to
> > put
> > > > > those
> > > > > > > jars in TOMEE/lib as well?
> > > > > > >
> > > > > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > > > > > [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=5>
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Yes but you reuse container slf4j here instead of webapp one
> > so
> > > > > leaking
> > > > > > > can
> > > > > > > > be "normal" depending slf4j impl config. Jul one - default -
> > > > shouldnt
> > > > > > > leak.
> > > > > > > > Le 1 juil. 2016 02:05, "sgjava" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=6>> a écrit :
> > > > > > > >
> > > > > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran
> > on
> > > > > server:
> > > > > > > > >
> > > > > > > > > <dependency>
> > > > > > > > > <groupId>org.slf4j</groupId>
> > > > > > > > > <artifactId>slf4j-api</artifactId>
> > > > > > > > > <version>${slf4j.version}</version>
> > > > > > > > > <scope>provided</scope>
> > > > > > > > > </dependency>
> > > > > > > > >
> > > > > > > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > > > > > > System.out.println(log.getClass().getClassLoader());
> > > > > > > > >
> > > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > >
> > > > > > > > > Does this look correct?
> > > > > > > > >
> > > > > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via
> > TomEE
> > > &
> > > > > > > > OpenEJB] <
> > > > > > > > > [hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679193&i=7>> wrote:
> > > > > > > > >
> > > > > > > > > > Im not sure what you mean but all good logging framework
> > > > provide
> > > > > a
> > > > > > > > > > classloader friendly impl - juli, log4j2 etc... - which
> > > doesnt
> > > > > > leak.
> > > > > > > > Know
> > > > > > > > > > logback has something like that but never tested it.
> > > > > > > > > >
> > > > > > > > > > The fact you load slf4j with app loader can mean you put
> > it
> > > in
> > > > > the
> > > > > > > > > > classpath which sounds wrong, should only be in common
> > loader
> > > > and
> > > > > > > > > > optionally webapp one.
> > > > > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>>
> > a
> > > > > écrit :
> > > > > > > > > >
> > > > > > > > > > > Also found
> > > > http://java.jiderhamn.se/category/classloader-leaks
> > > > > > > > > > >
> > > > > > > > > > > As for java.util.logging (JUL), it will always be
> > outside
> > > the
> > > > > web
> > > > > > > > > > > application, since it is part of the JDK. With it you
> > can
> > > > cause
> > > > > > > > > > classloader
> > > > > > > > > > > leaks by creating custom log Levels inside your web
> app.
> > > This
> > > > > is
> > > > > > > what
> > > > > > > > > > Frank
> > > > > > > > > > > Kieviet uses as example in his blog post on classloader
> > > > leaks.
> > > > > It
> > > > > > > > seems
> > > > > > > > > > > also
> > > > > > > > > > > that JBoss Logging does exactly that if backed by JUL,
> > and
> > > > > > thereby
> > > > > > > > > > triggers
> > > > > > > > > > > such a leak if loaded within your web app. See report
> > here.
> > > > > > > > > > >
> > > > > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So
> > do I
> > > > > just
> > > > > > > > switch
> > > > > > > > > > to
> > > > > > > > > > > JUL? This really sucks since logback is more refined.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > View this message in context:
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > > > > > Sent from the TomEE Users mailing list archive at
> > > Nabble.com.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > ------------------------------
> > > > > > > > > > If you reply to this email, your message will be added to
> > the
> > > > > > > > discussion
> > > > > > > > > > below:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging,
> click
> > > here
> > > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > > > > > > > >
> > > > > > > > > > .
> > > > > > > > > > NAML
> > > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Steven P. Goldsmith
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > View this message in context:
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > > > > > Sent from the TomEE Users mailing list archive at
> > Nabble.com.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Steven P. Goldsmith
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Steven P. Goldsmith
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679193.html
> > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> >
> > .
> > NAML
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
> --
> Steven P. Goldsmith
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679197.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
TomEE Plus 7.0.1 configured as such:
•Edit NEW_TOMEE/conf/system.properties
◦Comment out (it’s probably a better idea to use the whitelist which I need
to work on)
# tomee.serialization.class.blacklist = *
◦Add
# Avoid EJB naming conflicts
openejb.deploymentId.format = {ejbJarId}/{ejbName}
# Increase JMS/MDB pools
Default\ JMS\ Resource\ Adapter.threadPoolSize=100
Default\ MDB\ Container.InstanceLimit=100
# Increase stateless bean pool
Default\ Stateless\ Container.MaxSize=100
# ActiveMQ security
org.apache.activemq.SERIALIZABLE_PACKAGES=java.lang,java.util,org.apache.activemq,org.fusesource.hawtbuf,com.thoughtworks.xstream.mapper,com.bhn.services.masblaster
•Edit NEW_TOMEE/conf/server.xml
◦Replace 8080 with 8180
◦Replace 8443 with 8143
◦Replace 8009 with 8109
◦Replace 8005 with 8105
◦Add in listener section
<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener"
rmiRegistryPortPlatform="8104" rmiServerPortPlatform="8104"/>
◦Add executor
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
maxIdleTime="60000" maxThreads="300" minSpareThreads="4"/>
◦Add SSL connector with proper ciphers
<Connector executor="tomcatThreadPool" port="8143"
protocol="org.apache.coyote.http11.Http11Nio2Protocol"
connectionTimeout="40000" SSLEnabled="true" scheme="https" secure="true"
clientAuth="false" sslProtocol="TLS" xpoweredBy="false" server="Apache
TomEE"
keystoreFile="/opt/tomcat/conf/keystore.jks" keystorePass="password"
ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"/>
Web app logging:
private static final Logger log =
Logger.getLogger(SomeClass.class.getName());
No additional logging libraries added.
On Sat, Jul 2, 2016 at 11:04 AM, Romain Manni-Bucau [via TomEE & OpenEJB] <
ml-node+s979440n4679193h94@n4.nabble.com> wrote:
> Can you share how your tomee is set up?
>
> Dont observe it locally.
> Le 2 juil. 2016 16:15, "Steve Goldsmith" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=0>> a écrit :
>
> > OK, using the JDK logger I'm seeing the same issue in 7.0.1!
> >
> > The class "org.apache.openejb.util.Logger", loaded by
> > "java.net.URLClassLoader @ 0x80244158", occupies 127,485,416 (64.82%)
> > bytes. The memory is accumulated in one instance of
> > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> > loader>".
> >
> > java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
> > 4,194,320 127,477,056
> > \table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
> > 64 127,477,120
> > .\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
> > 24 127,477,144
> > ..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
> > 48 127,485,416
> > ...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
> > 24 104
> > ...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader @
> > 0x80650ff0
> > 24 136
> > ...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @
> 0x80a1f9a8
> > 168 233,776
> > ...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
> > PoolIdleReleaseTimer Thread
> > 128 752
> > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8 pool-2-thread-2
> > Thread
> > 120 288
> > ...|..+contextClassLoader java.lang.Thread @ 0x81d0a540 pool-2-thread-1
> > Thread
> > 120 288
> > ...|..+contextClassLoader
> >
> com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread @
> > 0x81dda2c8 hz._hzInstance_1_dev.migration Thread
> > 136 416
> > ...|..+contextClassLoader
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > 0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
> > 168 1,312
> > ...|..+contextClassLoader
> >
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> > 0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
> > 168 1,384
> > ...|..+contextClassLoader
> > com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> @
> > 0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
> > 168 704
> > ...|..+contextClassLoader
> > com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread
> @
> > 0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
> > 168 736
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
> > hz._hzInstance_1_dev.event-5 Thread
> > 128 664
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
> > hz._hzInstance_1_dev.event-4 Thread
> > 128 872
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
> > hz._hzInstance_1_dev.event-3 Thread
> > 128 696
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
> > hz._hzInstance_1_dev.event-2 Thread
> > 128 664
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
> > hz._hzInstance_1_dev.event-1 Thread
> > 128 664
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
> > hz._hzInstance_1_dev.IO.thread-in-2 Thread
> > 168 5,544
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
> > hz._hzInstance_1_dev.IO.thread-in-1 Thread
> > 168 5,544
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
> > hz._hzInstance_1_dev.IO.thread-in-0 Thread
> > 168 5,000
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
> > hz._hzInstance_1_dev.IO.thread-out-2 Thread
> > 168 5,544
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
> > hz._hzInstance_1_dev.IO.thread-out-1 Thread
> > 168 5,544
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
> > hz._hzInstance_1_dev.IO.thread-out-0 Thread
> > 168 4,968
> > ...|..+contextClassLoader
> > com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @
> 0x81e1c9b0
> > hz._hzInstance_1_dev.IOBalancerThread Thread
> > 136 608
> > ...|..+contextClassLoader com.hazelcast.nio.tcp.SocketAcceptorThread @
> > 0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
> > 152 448
> > ...|..+contextClassLoader
> >
> >
> com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
>
> > @ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
> > 128 328
> > ...|..+contextClassLoader
> >
> >
> com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
>
> > @ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread Thread
> > 128 440
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > 0x81e3da48 scheduled Thread
> > 128 464
> > ...|..+contextClassLoader
> > com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> > 0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
> > 128 408
> > ...|..\Total: 25 of 29 entries; 4 more
> >
> > ...+[317] java.lang.Object[10240] @ 0x81c405c8 »
> > 40,976 1,771,416
> > ...\Total: 2 entries
> >
> > I'm also using hazelcast as my JCache provider and am seeing (hoping
> this
> > is just because of the cache structures):
> >
> > "com.hazelcast.cache.impl.CacheService" loaded by
> "java.net.URLClassLoader
> > @ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is
> accumulated
> > in one instance of "com.hazelcast.cache.impl.CachePartitionSegment[]"
> > loaded by "java.net.URLClassLoader @ 0x80244158".
> >
> >
> >
> > On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=1>>
> > wrote:
> >
> > > (Avoiding comments on the quality of logging frameworks ;))
> > >
> > >
> > > Just validated on 7.0.1 and if you provide it by webapp the cache is
> > > correctly setup by webapp.
> > >
> > > In the container it will leak cause logback doesn't provide a by
> > > classloader ContextSelector.
> > >
> > >
> > > Side note: log4j2 provides one and is integrated with tomee as well if
> > you
> > > miss some features for logging guess log4j2 filled the gap logback
> > created
> > > with log4j1.
> > >
> > >
> > > Le 1 juil. 2016 22:28, "Steve Goldsmith" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=2>> a écrit :
> > >
> > > > For now I switched to JDK logger to see if the leak goes away. I'm
> OK
> > > using
> > > > that, but logback+slf4j is a better solution.
> > > >
> > > > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
> > > [hidden email] <http:///user/SendEmail.jtp?type=node&node=4679193&i=3>>
>
> > > > wrote:
> > > >
> > > > > basically the idea is to use slf4-api as a reference to where to
> load
> > > > from
> > > > > slf4j api+impl
> > > > >
> > > > > == ie in the webapp we'll take the impl of the container from the
> > > webapp,
> > > > > if in the container we'll use the container impl
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > > <http://rmannibucau.wordpress.com> | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > > >
> > > > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=4>>:
> > > > >
> > > > > > Since I'm using provided scope I'm only referencing it at
> compile
> > > time,
> > > > > but
> > > > > > I noticed my logback config is not picked up now. Do I need to
> put
> > > > those
> > > > > > jars in TOMEE/lib as well?
> > > > > >
> > > > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > > > > [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=5>
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Yes but you reuse container slf4j here instead of webapp one
> so
> > > > leaking
> > > > > > can
> > > > > > > be "normal" depending slf4j impl config. Jul one - default -
> > > shouldnt
> > > > > > leak.
> > > > > > > Le 1 juil. 2016 02:05, "sgjava" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=6>> a écrit :
> > > > > > >
> > > > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran
> on
> > > > server:
> > > > > > > >
> > > > > > > > <dependency>
> > > > > > > > <groupId>org.slf4j</groupId>
> > > > > > > > <artifactId>slf4j-api</artifactId>
> > > > > > > > <version>${slf4j.version}</version>
> > > > > > > > <scope>provided</scope>
> > > > > > > > </dependency>
> > > > > > > >
> > > > > > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > > > > > System.out.println(log.getClass().getClassLoader());
> > > > > > > >
> > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > >
> > > > > > > > Does this look correct?
> > > > > > > >
> > > > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via
> TomEE
> > &
> > > > > > > OpenEJB] <
> > > > > > > > [hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679193&i=7>> wrote:
> > > > > > > >
> > > > > > > > > Im not sure what you mean but all good logging framework
> > > provide
> > > > a
> > > > > > > > > classloader friendly impl - juli, log4j2 etc... - which
> > doesnt
> > > > > leak.
> > > > > > > Know
> > > > > > > > > logback has something like that but never tested it.
> > > > > > > > >
> > > > > > > > > The fact you load slf4j with app loader can mean you put
> it
> > in
> > > > the
> > > > > > > > > classpath which sounds wrong, should only be in common
> loader
> > > and
> > > > > > > > > optionally webapp one.
> > > > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>>
> a
> > > > écrit :
> > > > > > > > >
> > > > > > > > > > Also found
> > > http://java.jiderhamn.se/category/classloader-leaks
> > > > > > > > > >
> > > > > > > > > > As for java.util.logging (JUL), it will always be
> outside
> > the
> > > > web
> > > > > > > > > > application, since it is part of the JDK. With it you
> can
> > > cause
> > > > > > > > > classloader
> > > > > > > > > > leaks by creating custom log Levels inside your web app.
> > This
> > > > is
> > > > > > what
> > > > > > > > > Frank
> > > > > > > > > > Kieviet uses as example in his blog post on classloader
> > > leaks.
> > > > It
> > > > > > > seems
> > > > > > > > > > also
> > > > > > > > > > that JBoss Logging does exactly that if backed by JUL,
> and
> > > > > thereby
> > > > > > > > > triggers
> > > > > > > > > > such a leak if loaded within your web app. See report
> here.
> > > > > > > > > >
> > > > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So
> do I
> > > > just
> > > > > > > switch
> > > > > > > > > to
> > > > > > > > > > JUL? This really sucks since logback is more refined.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > View this message in context:
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > > > > Sent from the TomEE Users mailing list archive at
> > Nabble.com.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ------------------------------
> > > > > > > > > If you reply to this email, your message will be added to
> the
> > > > > > > discussion
> > > > > > > > > below:
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging, click
> > here
> > > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> > > > > > > >
> > > > > > > > > .
> > > > > > > > > NAML
> > > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Steven P. Goldsmith
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > > > > Sent from the TomEE Users mailing list archive at
> Nabble.com.
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Steven P. Goldsmith
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Steven P. Goldsmith
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679193.html
> To unsubscribe from TomEE 7.01 heap leak in logging, click here
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5>
> .
> NAML
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Steven P. Goldsmith
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679197.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Checked and - even if my app was a hello world - I get this
https://gist.github.com/rmannibucau/d1eda7d04dc4ef989e6f2f31e8b828dc
which looks pretty fine
really wonder what can cause your leaking
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-02 17:45 GMT+02:00 Romain Manni-Bucau <rm...@gmail.com>:
> Can you share how your tomee is set up?
>
> Dont observe it locally.
> Le 2 juil. 2016 16:15, "Steve Goldsmith" <sg...@gmail.com> a écrit :
>
>> OK, using the JDK logger I'm seeing the same issue in 7.0.1!
>>
>> The class "org.apache.openejb.util.Logger", loaded by
>> "java.net.URLClassLoader @ 0x80244158", occupies 127,485,416 (64.82%)
>> bytes. The memory is accumulated in one instance of
>> "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
>> loader>".
>>
>> java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
>> 4,194,320 127,477,056
>> \table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
>> 64 127,477,120
>> .\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
>> 24 127,477,144
>> ..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
>> 48 127,485,416
>> ...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
>> 24 104
>> ...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader @
>> 0x80650ff0
>> 24 136
>> ...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @
>> 0x80a1f9a8
>> 168 233,776
>> ...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
>> PoolIdleReleaseTimer Thread
>> 128 752
>> ...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8 pool-2-thread-2
>> Thread
>> 120 288
>> ...|..+contextClassLoader java.lang.Thread @ 0x81d0a540 pool-2-thread-1
>> Thread
>> 120 288
>> ...|..+contextClassLoader
>> com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread
>> @
>> 0x81dda2c8 hz._hzInstance_1_dev.migration Thread
>> 136 416
>> ...|..+contextClassLoader
>> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread
>> @
>> 0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
>> 168 1,312
>> ...|..+contextClassLoader
>> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread
>> @
>> 0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
>> 168 1,384
>> ...|..+contextClassLoader
>> com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread @
>> 0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
>> 168 704
>> ...|..+contextClassLoader
>> com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread @
>> 0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
>> 168 736
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
>> hz._hzInstance_1_dev.event-5 Thread
>> 128 664
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
>> hz._hzInstance_1_dev.event-4 Thread
>> 128 872
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
>> hz._hzInstance_1_dev.event-3 Thread
>> 128 696
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
>> hz._hzInstance_1_dev.event-2 Thread
>> 128 664
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
>> hz._hzInstance_1_dev.event-1 Thread
>> 128 664
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
>> hz._hzInstance_1_dev.IO.thread-in-2 Thread
>> 168 5,544
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
>> hz._hzInstance_1_dev.IO.thread-in-1 Thread
>> 168 5,544
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
>> hz._hzInstance_1_dev.IO.thread-in-0 Thread
>> 168 5,000
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
>> hz._hzInstance_1_dev.IO.thread-out-2 Thread
>> 168 5,544
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
>> hz._hzInstance_1_dev.IO.thread-out-1 Thread
>> 168 5,544
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
>> hz._hzInstance_1_dev.IO.thread-out-0 Thread
>> 168 4,968
>> ...|..+contextClassLoader
>> com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @ 0x81e1c9b0
>> hz._hzInstance_1_dev.IOBalancerThread Thread
>> 136 608
>> ...|..+contextClassLoader com.hazelcast.nio.tcp.SocketAcceptorThread @
>> 0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
>> 152 448
>> ...|..+contextClassLoader
>>
>> com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
>> @ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
>> 128 328
>> ...|..+contextClassLoader
>>
>> com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
>> @ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread Thread
>> 128 440
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
>> 0x81e3da48 scheduled Thread
>> 128 464
>> ...|..+contextClassLoader
>> com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
>> 0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
>> 128 408
>> ...|..\Total: 25 of 29 entries; 4 more
>>
>> ...+[317] java.lang.Object[10240] @ 0x81c405c8 »
>> 40,976 1,771,416
>> ...\Total: 2 entries
>>
>> I'm also using hazelcast as my JCache provider and am seeing (hoping this
>> is just because of the cache structures):
>>
>> "com.hazelcast.cache.impl.CacheService" loaded by "java.net.URLClassLoader
>> @ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is
>> accumulated
>> in one instance of "com.hazelcast.cache.impl.CachePartitionSegment[]"
>> loaded by "java.net.URLClassLoader @ 0x80244158".
>>
>>
>>
>> On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <rmannibucau@gmail.com
>> >
>> wrote:
>>
>> > (Avoiding comments on the quality of logging frameworks ;))
>> >
>> >
>> > Just validated on 7.0.1 and if you provide it by webapp the cache is
>> > correctly setup by webapp.
>> >
>> > In the container it will leak cause logback doesn't provide a by
>> > classloader ContextSelector.
>> >
>> >
>> > Side note: log4j2 provides one and is integrated with tomee as well if
>> you
>> > miss some features for logging guess log4j2 filled the gap logback
>> created
>> > with log4j1.
>> >
>> >
>> > Le 1 juil. 2016 22:28, "Steve Goldsmith" <sg...@gmail.com> a écrit :
>> >
>> > > For now I switched to JDK logger to see if the leak goes away. I'm OK
>> > using
>> > > that, but logback+slf4j is a better solution.
>> > >
>> > > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
>> > rmannibucau@gmail.com>
>> > > wrote:
>> > >
>> > > > basically the idea is to use slf4-api as a reference to where to
>> load
>> > > from
>> > > > slf4j api+impl
>> > > >
>> > > > == ie in the webapp we'll take the impl of the container from the
>> > webapp,
>> > > > if in the container we'll use the container impl
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Romain Manni-Bucau
>> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
>> > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
>> > > > <http://rmannibucau.wordpress.com> | Github <
>> > > > https://github.com/rmannibucau> |
>> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
>> > > > <http://www.tomitribe.com> | JavaEE Factory
>> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
>> > > >
>> > > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
>> > > >
>> > > > > Since I'm using provided scope I'm only referencing it at compile
>> > time,
>> > > > but
>> > > > > I noticed my logback config is not picked up now. Do I need to put
>> > > those
>> > > > > jars in TOMEE/lib as well?
>> > > > >
>> > > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
>> > > > rmannibucau@gmail.com
>> > > > > >
>> > > > > wrote:
>> > > > >
>> > > > > > Yes but you reuse container slf4j here instead of webapp one so
>> > > leaking
>> > > > > can
>> > > > > > be "normal" depending slf4j impl config. Jul one - default -
>> > shouldnt
>> > > > > leak.
>> > > > > > Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
>> > > > > >
>> > > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran on
>> > > server:
>> > > > > > >
>> > > > > > > <dependency>
>> > > > > > > <groupId>org.slf4j</groupId>
>> > > > > > > <artifactId>slf4j-api</artifactId>
>> > > > > > > <version>${slf4j.version}</version>
>> > > > > > > <scope>provided</scope>
>> > > > > > > </dependency>
>> > > > > > >
>> > > > > > > System.out.println(LoggerFactory.class.getClassLoader());
>> > > > > > > System.out.println(log.getClass().getClassLoader());
>> > > > > > >
>> > > > > > > java.net.URLClassLoader@6438a396
>> > > > > > > java.net.URLClassLoader@6438a396
>> > > > > > >
>> > > > > > > Does this look correct?
>> > > > > > >
>> > > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via
>> TomEE &
>> > > > > > OpenEJB] <
>> > > > > > > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
>> > > > > > >
>> > > > > > > > Im not sure what you mean but all good logging framework
>> > provide
>> > > a
>> > > > > > > > classloader friendly impl - juli, log4j2 etc... - which
>> doesnt
>> > > > leak.
>> > > > > > Know
>> > > > > > > > logback has something like that but never tested it.
>> > > > > > > >
>> > > > > > > > The fact you load slf4j with app loader can mean you put it
>> in
>> > > the
>> > > > > > > > classpath which sounds wrong, should only be in common
>> loader
>> > and
>> > > > > > > > optionally webapp one.
>> > > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
>> > > > > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a
>> > > écrit :
>> > > > > > > >
>> > > > > > > > > Also found
>> > http://java.jiderhamn.se/category/classloader-leaks
>> > > > > > > > >
>> > > > > > > > > As for java.util.logging (JUL), it will always be outside
>> the
>> > > web
>> > > > > > > > > application, since it is part of the JDK. With it you can
>> > cause
>> > > > > > > > classloader
>> > > > > > > > > leaks by creating custom log Levels inside your web app.
>> This
>> > > is
>> > > > > what
>> > > > > > > > Frank
>> > > > > > > > > Kieviet uses as example in his blog post on classloader
>> > leaks.
>> > > It
>> > > > > > seems
>> > > > > > > > > also
>> > > > > > > > > that JBoss Logging does exactly that if backed by JUL, and
>> > > > thereby
>> > > > > > > > triggers
>> > > > > > > > > such a leak if loaded within your web app. See report
>> here.
>> > > > > > > > >
>> > > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So do
>> I
>> > > just
>> > > > > > switch
>> > > > > > > > to
>> > > > > > > > > JUL? This really sucks since logback is more refined.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > View this message in context:
>> > > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
>> > > > > > > > > Sent from the TomEE Users mailing list archive at
>> Nabble.com.
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > ------------------------------
>> > > > > > > > If you reply to this email, your message will be added to
>> the
>> > > > > > discussion
>> > > > > > > > below:
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
>> > > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging, click
>> here
>> > > > > > > > <
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
>> > > > > > > >
>> > > > > > > > .
>> > > > > > > > NAML
>> > > > > > > > <
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Steven P. Goldsmith
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > View this message in context:
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
>> > > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Steven P. Goldsmith
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Steven P. Goldsmith
>> > >
>> >
>>
>>
>>
>> --
>> Steven P. Goldsmith
>>
>
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Can you share how your tomee is set up?
Dont observe it locally.
Le 2 juil. 2016 16:15, "Steve Goldsmith" <sg...@gmail.com> a écrit :
> OK, using the JDK logger I'm seeing the same issue in 7.0.1!
>
> The class "org.apache.openejb.util.Logger", loaded by
> "java.net.URLClassLoader @ 0x80244158", occupies 127,485,416 (64.82%)
> bytes. The memory is accumulated in one instance of
> "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> loader>".
>
> java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
> 4,194,320 127,477,056
> \table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
> 64 127,477,120
> .\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
> 24 127,477,144
> ..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
> 48 127,485,416
> ...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
> 24 104
> ...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader @
> 0x80650ff0
> 24 136
> ...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @ 0x80a1f9a8
> 168 233,776
> ...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
> PoolIdleReleaseTimer Thread
> 128 752
> ...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8 pool-2-thread-2
> Thread
> 120 288
> ...|..+contextClassLoader java.lang.Thread @ 0x81d0a540 pool-2-thread-1
> Thread
> 120 288
> ...|..+contextClassLoader
> com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread @
> 0x81dda2c8 hz._hzInstance_1_dev.migration Thread
> 136 416
> ...|..+contextClassLoader
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> 0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
> 168 1,312
> ...|..+contextClassLoader
> com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
> 0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
> 168 1,384
> ...|..+contextClassLoader
> com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread @
> 0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
> 168 704
> ...|..+contextClassLoader
> com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread @
> 0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
> 168 736
> ...|..+contextClassLoader
> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
> hz._hzInstance_1_dev.event-5 Thread
> 128 664
> ...|..+contextClassLoader
> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
> hz._hzInstance_1_dev.event-4 Thread
> 128 872
> ...|..+contextClassLoader
> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
> hz._hzInstance_1_dev.event-3 Thread
> 128 696
> ...|..+contextClassLoader
> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
> hz._hzInstance_1_dev.event-2 Thread
> 128 664
> ...|..+contextClassLoader
> com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
> hz._hzInstance_1_dev.event-1 Thread
> 128 664
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
> hz._hzInstance_1_dev.IO.thread-in-2 Thread
> 168 5,544
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
> hz._hzInstance_1_dev.IO.thread-in-1 Thread
> 168 5,544
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
> hz._hzInstance_1_dev.IO.thread-in-0 Thread
> 168 5,000
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
> hz._hzInstance_1_dev.IO.thread-out-2 Thread
> 168 5,544
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
> hz._hzInstance_1_dev.IO.thread-out-1 Thread
> 168 5,544
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
> hz._hzInstance_1_dev.IO.thread-out-0 Thread
> 168 4,968
> ...|..+contextClassLoader
> com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @ 0x81e1c9b0
> hz._hzInstance_1_dev.IOBalancerThread Thread
> 136 608
> ...|..+contextClassLoader com.hazelcast.nio.tcp.SocketAcceptorThread @
> 0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
> 152 448
> ...|..+contextClassLoader
>
> com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
> @ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
> 128 328
> ...|..+contextClassLoader
>
> com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
> @ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread Thread
> 128 440
> ...|..+contextClassLoader
> com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> 0x81e3da48 scheduled Thread
> 128 464
> ...|..+contextClassLoader
> com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
> 0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
> 128 408
> ...|..\Total: 25 of 29 entries; 4 more
>
> ...+[317] java.lang.Object[10240] @ 0x81c405c8 »
> 40,976 1,771,416
> ...\Total: 2 entries
>
> I'm also using hazelcast as my JCache provider and am seeing (hoping this
> is just because of the cache structures):
>
> "com.hazelcast.cache.impl.CacheService" loaded by "java.net.URLClassLoader
> @ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is accumulated
> in one instance of "com.hazelcast.cache.impl.CachePartitionSegment[]"
> loaded by "java.net.URLClassLoader @ 0x80244158".
>
>
>
> On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > (Avoiding comments on the quality of logging frameworks ;))
> >
> >
> > Just validated on 7.0.1 and if you provide it by webapp the cache is
> > correctly setup by webapp.
> >
> > In the container it will leak cause logback doesn't provide a by
> > classloader ContextSelector.
> >
> >
> > Side note: log4j2 provides one and is integrated with tomee as well if
> you
> > miss some features for logging guess log4j2 filled the gap logback
> created
> > with log4j1.
> >
> >
> > Le 1 juil. 2016 22:28, "Steve Goldsmith" <sg...@gmail.com> a écrit :
> >
> > > For now I switched to JDK logger to see if the leak goes away. I'm OK
> > using
> > > that, but logback+slf4j is a better solution.
> > >
> > > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com>
> > > wrote:
> > >
> > > > basically the idea is to use slf4-api as a reference to where to load
> > > from
> > > > slf4j api+impl
> > > >
> > > > == ie in the webapp we'll take the impl of the container from the
> > webapp,
> > > > if in the container we'll use the container impl
> > > >
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > > <http://rmannibucau.wordpress.com> | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > > <http://www.tomitribe.com> | JavaEE Factory
> > > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > > >
> > > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> > > >
> > > > > Since I'm using provided scope I'm only referencing it at compile
> > time,
> > > > but
> > > > > I noticed my logback config is not picked up now. Do I need to put
> > > those
> > > > > jars in TOMEE/lib as well?
> > > > >
> > > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Yes but you reuse container slf4j here instead of webapp one so
> > > leaking
> > > > > can
> > > > > > be "normal" depending slf4j impl config. Jul one - default -
> > shouldnt
> > > > > leak.
> > > > > > Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
> > > > > >
> > > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran on
> > > server:
> > > > > > >
> > > > > > > <dependency>
> > > > > > > <groupId>org.slf4j</groupId>
> > > > > > > <artifactId>slf4j-api</artifactId>
> > > > > > > <version>${slf4j.version}</version>
> > > > > > > <scope>provided</scope>
> > > > > > > </dependency>
> > > > > > >
> > > > > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > > > > System.out.println(log.getClass().getClassLoader());
> > > > > > >
> > > > > > > java.net.URLClassLoader@6438a396
> > > > > > > java.net.URLClassLoader@6438a396
> > > > > > >
> > > > > > > Does this look correct?
> > > > > > >
> > > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE
> &
> > > > > > OpenEJB] <
> > > > > > > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> > > > > > >
> > > > > > > > Im not sure what you mean but all good logging framework
> > provide
> > > a
> > > > > > > > classloader friendly impl - juli, log4j2 etc... - which
> doesnt
> > > > leak.
> > > > > > Know
> > > > > > > > logback has something like that but never tested it.
> > > > > > > >
> > > > > > > > The fact you load slf4j with app loader can mean you put it
> in
> > > the
> > > > > > > > classpath which sounds wrong, should only be in common loader
> > and
> > > > > > > > optionally webapp one.
> > > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a
> > > écrit :
> > > > > > > >
> > > > > > > > > Also found
> > http://java.jiderhamn.se/category/classloader-leaks
> > > > > > > > >
> > > > > > > > > As for java.util.logging (JUL), it will always be outside
> the
> > > web
> > > > > > > > > application, since it is part of the JDK. With it you can
> > cause
> > > > > > > > classloader
> > > > > > > > > leaks by creating custom log Levels inside your web app.
> This
> > > is
> > > > > what
> > > > > > > > Frank
> > > > > > > > > Kieviet uses as example in his blog post on classloader
> > leaks.
> > > It
> > > > > > seems
> > > > > > > > > also
> > > > > > > > > that JBoss Logging does exactly that if backed by JUL, and
> > > > thereby
> > > > > > > > triggers
> > > > > > > > > such a leak if loaded within your web app. See report here.
> > > > > > > > >
> > > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So do I
> > > just
> > > > > > switch
> > > > > > > > to
> > > > > > > > > JUL? This really sucks since logback is more refined.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > View this message in context:
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > > > Sent from the TomEE Users mailing list archive at
> Nabble.com.
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > ------------------------------
> > > > > > > > If you reply to this email, your message will be added to the
> > > > > > discussion
> > > > > > > > below:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging, click
> here
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > > > > > > >
> > > > > > > > .
> > > > > > > > NAML
> > > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Steven P. Goldsmith
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Steven P. Goldsmith
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
OK, using the JDK logger I'm seeing the same issue in 7.0.1!
The class "org.apache.openejb.util.Logger", loaded by
"java.net.URLClassLoader @ 0x80244158", occupies 127,485,416 (64.82%)
bytes. The memory is accumulated in one instance of
"java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
loader>".
java.util.concurrent.ConcurrentHashMap$Node[1048576] @ 0x8a3bfeb8
4,194,320 127,477,056
\table java.util.concurrent.ConcurrentHashMap @ 0x8094efb8
64 127,477,120
.\cache org.apache.openejb.util.Memoizer @ 0x8094efa0
24 127,477,144
..\loggerCache class org.apache.openejb.util.Logger @ 0x806cdcb0
48 127,485,416
...+<class> org.apache.openejb.util.Logger @ 0x80d0b448
24 104
...|\LOGGER class org.apache.tomee.catalina.TomEEWebappClassLoader @
0x80650ff0
24 136
...|.\<class> org.apache.tomee.catalina.TomEEWebappClassLoader @ 0x80a1f9a8
168 233,776
...|..+contextClassLoader java.util.TimerThread @ 0x816447d8
PoolIdleReleaseTimer Thread
128 752
...|..+contextClassLoader java.lang.Thread @ 0x81d0a1c8 pool-2-thread-2
Thread
120 288
...|..+contextClassLoader java.lang.Thread @ 0x81d0a540 pool-2-thread-1
Thread
120 288
...|..+contextClassLoader
com.hazelcast.partition.impl.InternalPartitionServiceImpl$MigrationThread @
0x81dda2c8 hz._hzInstance_1_dev.migration Thread
136 416
...|..+contextClassLoader
com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
0x81de23e8 hz._hzInstance_1_dev.partition-operation.thread-1 Thread
168 1,312
...|..+contextClassLoader
com.hazelcast.spi.impl.operationexecutor.classic.PartitionOperationThread @
0x81de2d70 hz._hzInstance_1_dev.partition-operation.thread-0 Thread
168 1,384
...|..+contextClassLoader
com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread @
0x81dea090 hz._hzInstance_1_dev.generic-operation.thread-0 Thread
168 704
...|..+contextClassLoader
com.hazelcast.spi.impl.operationexecutor.classic.GenericOperationThread @
0x81dea458 hz._hzInstance_1_dev.generic-operation.thread-1 Thread
168 736
...|..+contextClassLoader
com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2068
hz._hzInstance_1_dev.event-5 Thread
128 664
...|..+contextClassLoader
com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2400
hz._hzInstance_1_dev.event-4 Thread
128 872
...|..+contextClassLoader
com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2780
hz._hzInstance_1_dev.event-3 Thread
128 696
...|..+contextClassLoader
com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2b00
hz._hzInstance_1_dev.event-2 Thread
128 664
...|..+contextClassLoader
com.hazelcast.util.executor.StripedExecutor$Worker @ 0x81df2e98
hz._hzInstance_1_dev.event-1 Thread
128 664
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df3820
hz._hzInstance_1_dev.IO.thread-in-2 Thread
168 5,544
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81df4ed8
hz._hzInstance_1_dev.IO.thread-in-1 Thread
168 5,544
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e16590
hz._hzInstance_1_dev.IO.thread-in-0 Thread
168 5,000
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e17cf0
hz._hzInstance_1_dev.IO.thread-out-2 Thread
168 5,544
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e19398
hz._hzInstance_1_dev.IO.thread-out-1 Thread
168 5,544
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread @ 0x81e1aa40
hz._hzInstance_1_dev.IO.thread-out-0 Thread
168 4,968
...|..+contextClassLoader
com.hazelcast.nio.tcp.nonblocking.iobalancer.IOBalancerThread @ 0x81e1c9b0
hz._hzInstance_1_dev.IOBalancerThread Thread
136 608
...|..+contextClassLoader com.hazelcast.nio.tcp.SocketAcceptorThread @
0x81e1e3a0 hz._hzInstance_1_dev.IO.thread-Acceptor Thread
152 448
...|..+contextClassLoader
com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor$MonitorThread
@ 0x81e1f070 hz._hzInstance_1_dev.InvocationMonitorThread Thread
128 328
...|..+contextClassLoader
com.hazelcast.spi.impl.operationexecutor.slowoperationdetector.SlowOperationDetector$DetectorThread
@ 0x81e2bfc8 hz._hzInstance_1_dev.SlowOperationDetectorThread Thread
128 440
...|..+contextClassLoader
com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
0x81e3da48 scheduled Thread
128 464
...|..+contextClassLoader
com.hazelcast.util.executor.SingleExecutorThreadFactory$ManagedThread @
0x81e3eb70 hz._hzInstance_1_dev.wait-notify Thread
128 408
...|..\Total: 25 of 29 entries; 4 more
...+[317] java.lang.Object[10240] @ 0x81c405c8 »
40,976 1,771,416
...\Total: 2 entries
I'm also using hazelcast as my JCache provider and am seeing (hoping this
is just because of the cache structures):
"com.hazelcast.cache.impl.CacheService" loaded by "java.net.URLClassLoader
@ 0x80244158" occupies 23,953,840 (12.18%) bytes. The memory is accumulated
in one instance of "com.hazelcast.cache.impl.CachePartitionSegment[]"
loaded by "java.net.URLClassLoader @ 0x80244158".
On Sat, Jul 2, 2016 at 5:56 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> (Avoiding comments on the quality of logging frameworks ;))
>
>
> Just validated on 7.0.1 and if you provide it by webapp the cache is
> correctly setup by webapp.
>
> In the container it will leak cause logback doesn't provide a by
> classloader ContextSelector.
>
>
> Side note: log4j2 provides one and is integrated with tomee as well if you
> miss some features for logging guess log4j2 filled the gap logback created
> with log4j1.
>
>
> Le 1 juil. 2016 22:28, "Steve Goldsmith" <sg...@gmail.com> a écrit :
>
> > For now I switched to JDK logger to see if the leak goes away. I'm OK
> using
> > that, but logback+slf4j is a better solution.
> >
> > On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> > wrote:
> >
> > > basically the idea is to use slf4-api as a reference to where to load
> > from
> > > slf4j api+impl
> > >
> > > == ie in the webapp we'll take the impl of the container from the
> webapp,
> > > if in the container we'll use the container impl
> > >
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> > >
> > > > Since I'm using provided scope I'm only referencing it at compile
> time,
> > > but
> > > > I noticed my logback config is not picked up now. Do I need to put
> > those
> > > > jars in TOMEE/lib as well?
> > > >
> > > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > Yes but you reuse container slf4j here instead of webapp one so
> > leaking
> > > > can
> > > > > be "normal" depending slf4j impl config. Jul one - default -
> shouldnt
> > > > leak.
> > > > > Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
> > > > >
> > > > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran on
> > server:
> > > > > >
> > > > > > <dependency>
> > > > > > <groupId>org.slf4j</groupId>
> > > > > > <artifactId>slf4j-api</artifactId>
> > > > > > <version>${slf4j.version}</version>
> > > > > > <scope>provided</scope>
> > > > > > </dependency>
> > > > > >
> > > > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > > > System.out.println(log.getClass().getClassLoader());
> > > > > >
> > > > > > java.net.URLClassLoader@6438a396
> > > > > > java.net.URLClassLoader@6438a396
> > > > > >
> > > > > > Does this look correct?
> > > > > >
> > > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE &
> > > > > OpenEJB] <
> > > > > > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> > > > > >
> > > > > > > Im not sure what you mean but all good logging framework
> provide
> > a
> > > > > > > classloader friendly impl - juli, log4j2 etc... - which doesnt
> > > leak.
> > > > > Know
> > > > > > > logback has something like that but never tested it.
> > > > > > >
> > > > > > > The fact you load slf4j with app loader can mean you put it in
> > the
> > > > > > > classpath which sounds wrong, should only be in common loader
> and
> > > > > > > optionally webapp one.
> > > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a
> > écrit :
> > > > > > >
> > > > > > > > Also found
> http://java.jiderhamn.se/category/classloader-leaks
> > > > > > > >
> > > > > > > > As for java.util.logging (JUL), it will always be outside the
> > web
> > > > > > > > application, since it is part of the JDK. With it you can
> cause
> > > > > > > classloader
> > > > > > > > leaks by creating custom log Levels inside your web app. This
> > is
> > > > what
> > > > > > > Frank
> > > > > > > > Kieviet uses as example in his blog post on classloader
> leaks.
> > It
> > > > > seems
> > > > > > > > also
> > > > > > > > that JBoss Logging does exactly that if backed by JUL, and
> > > thereby
> > > > > > > triggers
> > > > > > > > such a leak if loaded within your web app. See report here.
> > > > > > > >
> > > > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So do I
> > just
> > > > > switch
> > > > > > > to
> > > > > > > > JUL? This really sucks since logback is more refined.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > View this message in context:
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > ------------------------------
> > > > > > > If you reply to this email, your message will be added to the
> > > > > discussion
> > > > > > > below:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > > > > > >
> > > > > > > .
> > > > > > > NAML
> > > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Steven P. Goldsmith
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Steven P. Goldsmith
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
(Avoiding comments on the quality of logging frameworks ;))
Just validated on 7.0.1 and if you provide it by webapp the cache is
correctly setup by webapp.
In the container it will leak cause logback doesn't provide a by
classloader ContextSelector.
Side note: log4j2 provides one and is integrated with tomee as well if you
miss some features for logging guess log4j2 filled the gap logback created
with log4j1.
Le 1 juil. 2016 22:28, "Steve Goldsmith" <sg...@gmail.com> a écrit :
> For now I switched to JDK logger to see if the leak goes away. I'm OK using
> that, but logback+slf4j is a better solution.
>
> On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <rm...@gmail.com>
> wrote:
>
> > basically the idea is to use slf4-api as a reference to where to load
> from
> > slf4j api+impl
> >
> > == ie in the webapp we'll take the impl of the container from the webapp,
> > if in the container we'll use the container impl
> >
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> >
> > > Since I'm using provided scope I'm only referencing it at compile time,
> > but
> > > I noticed my logback config is not picked up now. Do I need to put
> those
> > > jars in TOMEE/lib as well?
> > >
> > > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > wrote:
> > >
> > > > Yes but you reuse container slf4j here instead of webapp one so
> leaking
> > > can
> > > > be "normal" depending slf4j impl config. Jul one - default - shouldnt
> > > leak.
> > > > Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
> > > >
> > > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran on
> server:
> > > > >
> > > > > <dependency>
> > > > > <groupId>org.slf4j</groupId>
> > > > > <artifactId>slf4j-api</artifactId>
> > > > > <version>${slf4j.version}</version>
> > > > > <scope>provided</scope>
> > > > > </dependency>
> > > > >
> > > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > > System.out.println(log.getClass().getClassLoader());
> > > > >
> > > > > java.net.URLClassLoader@6438a396
> > > > > java.net.URLClassLoader@6438a396
> > > > >
> > > > > Does this look correct?
> > > > >
> > > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE &
> > > > OpenEJB] <
> > > > > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> > > > >
> > > > > > Im not sure what you mean but all good logging framework provide
> a
> > > > > > classloader friendly impl - juli, log4j2 etc... - which doesnt
> > leak.
> > > > Know
> > > > > > logback has something like that but never tested it.
> > > > > >
> > > > > > The fact you load slf4j with app loader can mean you put it in
> the
> > > > > > classpath which sounds wrong, should only be in common loader and
> > > > > > optionally webapp one.
> > > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a
> écrit :
> > > > > >
> > > > > > > Also found http://java.jiderhamn.se/category/classloader-leaks
> > > > > > >
> > > > > > > As for java.util.logging (JUL), it will always be outside the
> web
> > > > > > > application, since it is part of the JDK. With it you can cause
> > > > > > classloader
> > > > > > > leaks by creating custom log Levels inside your web app. This
> is
> > > what
> > > > > > Frank
> > > > > > > Kieviet uses as example in his blog post on classloader leaks.
> It
> > > > seems
> > > > > > > also
> > > > > > > that JBoss Logging does exactly that if backed by JUL, and
> > thereby
> > > > > > triggers
> > > > > > > such a leak if loaded within your web app. See report here.
> > > > > > >
> > > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So do I
> just
> > > > switch
> > > > > > to
> > > > > > > JUL? This really sucks since logback is more refined.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > View this message in context:
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > > >
> > > > > >
> > > > > >
> > > > > > ------------------------------
> > > > > > If you reply to this email, your message will be added to the
> > > > discussion
> > > > > > below:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > > > > <
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > > > > >
> > > > > > .
> > > > > > NAML
> > > > > > <
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Steven P. Goldsmith
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
For now I switched to JDK logger to see if the leak goes away. I'm OK using
that, but logback+slf4j is a better solution.
On Fri, Jul 1, 2016 at 2:43 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> basically the idea is to use slf4-api as a reference to where to load from
> slf4j api+impl
>
> == ie in the webapp we'll take the impl of the container from the webapp,
> if in the container we'll use the container impl
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-07-01 2:56 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
>
> > Since I'm using provided scope I'm only referencing it at compile time,
> but
> > I noticed my logback config is not picked up now. Do I need to put those
> > jars in TOMEE/lib as well?
> >
> > On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > Yes but you reuse container slf4j here instead of webapp one so leaking
> > can
> > > be "normal" depending slf4j impl config. Jul one - default - shouldnt
> > leak.
> > > Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
> > >
> > > > Here's what I did (removed slf4j from WEB-INF/lib) and ran on server:
> > > >
> > > > <dependency>
> > > > <groupId>org.slf4j</groupId>
> > > > <artifactId>slf4j-api</artifactId>
> > > > <version>${slf4j.version}</version>
> > > > <scope>provided</scope>
> > > > </dependency>
> > > >
> > > > System.out.println(LoggerFactory.class.getClassLoader());
> > > > System.out.println(log.getClass().getClassLoader());
> > > >
> > > > java.net.URLClassLoader@6438a396
> > > > java.net.URLClassLoader@6438a396
> > > >
> > > > Does this look correct?
> > > >
> > > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE &
> > > OpenEJB] <
> > > > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> > > >
> > > > > Im not sure what you mean but all good logging framework provide a
> > > > > classloader friendly impl - juli, log4j2 etc... - which doesnt
> leak.
> > > Know
> > > > > logback has something like that but never tested it.
> > > > >
> > > > > The fact you load slf4j with app loader can mean you put it in the
> > > > > classpath which sounds wrong, should only be in common loader and
> > > > > optionally webapp one.
> > > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a écrit :
> > > > >
> > > > > > Also found http://java.jiderhamn.se/category/classloader-leaks
> > > > > >
> > > > > > As for java.util.logging (JUL), it will always be outside the web
> > > > > > application, since it is part of the JDK. With it you can cause
> > > > > classloader
> > > > > > leaks by creating custom log Levels inside your web app. This is
> > what
> > > > > Frank
> > > > > > Kieviet uses as example in his blog post on classloader leaks. It
> > > seems
> > > > > > also
> > > > > > that JBoss Logging does exactly that if backed by JUL, and
> thereby
> > > > > triggers
> > > > > > such a leak if loaded within your web app. See report here.
> > > > > >
> > > > > > I just checked my TomEE 2.0.0 app and it leaks too! So do I just
> > > switch
> > > > > to
> > > > > > JUL? This really sucks since logback is more refined.
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > View this message in context:
> > > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > > >
> > > > >
> > > > >
> > > > > ------------------------------
> > > > > If you reply to this email, your message will be added to the
> > > discussion
> > > > > below:
> > > > >
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > > > <
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > > > >
> > > > > .
> > > > > NAML
> > > > > <
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Steven P. Goldsmith
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
basically the idea is to use slf4-api as a reference to where to load from
slf4j api+impl
== ie in the webapp we'll take the impl of the container from the webapp,
if in the container we'll use the container impl
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-07-01 2:56 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> Since I'm using provided scope I'm only referencing it at compile time, but
> I noticed my logback config is not picked up now. Do I need to put those
> jars in TOMEE/lib as well?
>
> On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Yes but you reuse container slf4j here instead of webapp one so leaking
> can
> > be "normal" depending slf4j impl config. Jul one - default - shouldnt
> leak.
> > Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
> >
> > > Here's what I did (removed slf4j from WEB-INF/lib) and ran on server:
> > >
> > > <dependency>
> > > <groupId>org.slf4j</groupId>
> > > <artifactId>slf4j-api</artifactId>
> > > <version>${slf4j.version}</version>
> > > <scope>provided</scope>
> > > </dependency>
> > >
> > > System.out.println(LoggerFactory.class.getClassLoader());
> > > System.out.println(log.getClass().getClassLoader());
> > >
> > > java.net.URLClassLoader@6438a396
> > > java.net.URLClassLoader@6438a396
> > >
> > > Does this look correct?
> > >
> > > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE &
> > OpenEJB] <
> > > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> > >
> > > > Im not sure what you mean but all good logging framework provide a
> > > > classloader friendly impl - juli, log4j2 etc... - which doesnt leak.
> > Know
> > > > logback has something like that but never tested it.
> > > >
> > > > The fact you load slf4j with app loader can mean you put it in the
> > > > classpath which sounds wrong, should only be in common loader and
> > > > optionally webapp one.
> > > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a écrit :
> > > >
> > > > > Also found http://java.jiderhamn.se/category/classloader-leaks
> > > > >
> > > > > As for java.util.logging (JUL), it will always be outside the web
> > > > > application, since it is part of the JDK. With it you can cause
> > > > classloader
> > > > > leaks by creating custom log Levels inside your web app. This is
> what
> > > > Frank
> > > > > Kieviet uses as example in his blog post on classloader leaks. It
> > seems
> > > > > also
> > > > > that JBoss Logging does exactly that if backed by JUL, and thereby
> > > > triggers
> > > > > such a leak if loaded within your web app. See report here.
> > > > >
> > > > > I just checked my TomEE 2.0.0 app and it leaks too! So do I just
> > switch
> > > > to
> > > > > JUL? This really sucks since logback is more refined.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > View this message in context:
> > > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > > >
> > > >
> > > >
> > > > ------------------------------
> > > > If you reply to this email, your message will be added to the
> > discussion
> > > > below:
> > > >
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > > <
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > > >
> > > > .
> > > > NAML
> > > > <
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Steven P. Goldsmith
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
Since I'm using provided scope I'm only referencing it at compile time, but
I noticed my logback config is not picked up now. Do I need to put those
jars in TOMEE/lib as well?
On Thu, Jun 30, 2016 at 8:47 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Yes but you reuse container slf4j here instead of webapp one so leaking can
> be "normal" depending slf4j impl config. Jul one - default - shouldnt leak.
> Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
>
> > Here's what I did (removed slf4j from WEB-INF/lib) and ran on server:
> >
> > <dependency>
> > <groupId>org.slf4j</groupId>
> > <artifactId>slf4j-api</artifactId>
> > <version>${slf4j.version}</version>
> > <scope>provided</scope>
> > </dependency>
> >
> > System.out.println(LoggerFactory.class.getClassLoader());
> > System.out.println(log.getClass().getClassLoader());
> >
> > java.net.URLClassLoader@6438a396
> > java.net.URLClassLoader@6438a396
> >
> > Does this look correct?
> >
> > On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE &
> OpenEJB] <
> > ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> >
> > > Im not sure what you mean but all good logging framework provide a
> > > classloader friendly impl - juli, log4j2 etc... - which doesnt leak.
> Know
> > > logback has something like that but never tested it.
> > >
> > > The fact you load slf4j with app loader can mean you put it in the
> > > classpath which sounds wrong, should only be in common loader and
> > > optionally webapp one.
> > > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a écrit :
> > >
> > > > Also found http://java.jiderhamn.se/category/classloader-leaks
> > > >
> > > > As for java.util.logging (JUL), it will always be outside the web
> > > > application, since it is part of the JDK. With it you can cause
> > > classloader
> > > > leaks by creating custom log Levels inside your web app. This is what
> > > Frank
> > > > Kieviet uses as example in his blog post on classloader leaks. It
> seems
> > > > also
> > > > that JBoss Logging does exactly that if backed by JUL, and thereby
> > > triggers
> > > > such a leak if loaded within your web app. See report here.
> > > >
> > > > I just checked my TomEE 2.0.0 app and it leaks too! So do I just
> switch
> > > to
> > > > JUL? This really sucks since logback is more refined.
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> > >
> > > ------------------------------
> > > If you reply to this email, your message will be added to the
> discussion
> > > below:
> > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > > <
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> > >
> > > .
> > > NAML
> > > <
> >
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Yes but you reuse container slf4j here instead of webapp one so leaking can
be "normal" depending slf4j impl config. Jul one - default - shouldnt leak.
Le 1 juil. 2016 02:05, "sgjava" <sg...@gmail.com> a écrit :
> Here's what I did (removed slf4j from WEB-INF/lib) and ran on server:
>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <version>${slf4j.version}</version>
> <scope>provided</scope>
> </dependency>
>
> System.out.println(LoggerFactory.class.getClassLoader());
> System.out.println(log.getClass().getClassLoader());
>
> java.net.URLClassLoader@6438a396
> java.net.URLClassLoader@6438a396
>
> Does this look correct?
>
> On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE & OpenEJB] <
> ml-node+s979440n4679161h2@n4.nabble.com> wrote:
>
> > Im not sure what you mean but all good logging framework provide a
> > classloader friendly impl - juli, log4j2 etc... - which doesnt leak. Know
> > logback has something like that but never tested it.
> >
> > The fact you load slf4j with app loader can mean you put it in the
> > classpath which sounds wrong, should only be in common loader and
> > optionally webapp one.
> > Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> > <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a écrit :
> >
> > > Also found http://java.jiderhamn.se/category/classloader-leaks
> > >
> > > As for java.util.logging (JUL), it will always be outside the web
> > > application, since it is part of the JDK. With it you can cause
> > classloader
> > > leaks by creating custom log Levels inside your web app. This is what
> > Frank
> > > Kieviet uses as example in his blog post on classloader leaks. It seems
> > > also
> > > that JBoss Logging does exactly that if backed by JUL, and thereby
> > triggers
> > > such a leak if loaded within your web app. See report here.
> > >
> > > I just checked my TomEE 2.0.0 app and it leaks too! So do I just switch
> > to
> > > JUL? This really sucks since logback is more refined.
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> > To unsubscribe from TomEE 7.01 heap leak in logging, click here
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5
> >
> > .
> > NAML
> > <
> http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
> --
> Steven P. Goldsmith
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
Here's what I did (removed slf4j from WEB-INF/lib) and ran on server:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
<scope>provided</scope>
</dependency>
System.out.println(LoggerFactory.class.getClassLoader());
System.out.println(log.getClass().getClassLoader());
java.net.URLClassLoader@6438a396
java.net.URLClassLoader@6438a396
Does this look correct?
On Thu, Jun 30, 2016 at 4:07 PM, Romain Manni-Bucau [via TomEE & OpenEJB] <
ml-node+s979440n4679161h2@n4.nabble.com> wrote:
> Im not sure what you mean but all good logging framework provide a
> classloader friendly impl - juli, log4j2 etc... - which doesnt leak. Know
> logback has something like that but never tested it.
>
> The fact you load slf4j with app loader can mean you put it in the
> classpath which sounds wrong, should only be in common loader and
> optionally webapp one.
> Le 30 juin 2016 22:37, "sgjava" <[hidden email]
> <http:///user/SendEmail.jtp?type=node&node=4679161&i=0>> a écrit :
>
> > Also found http://java.jiderhamn.se/category/classloader-leaks
> >
> > As for java.util.logging (JUL), it will always be outside the web
> > application, since it is part of the JDK. With it you can cause
> classloader
> > leaks by creating custom log Levels inside your web app. This is what
> Frank
> > Kieviet uses as example in his blog post on classloader leaks. It seems
> > also
> > that JBoss Logging does exactly that if backed by JUL, and thereby
> triggers
> > such a leak if loaded within your web app. See report here.
> >
> > I just checked my TomEE 2.0.0 app and it leaks too! So do I just switch
> to
> > JUL? This really sucks since logback is more refined.
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
>
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679161.html
> To unsubscribe from TomEE 7.01 heap leak in logging, click here
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=4679146&code=c2dqYXZhQGdtYWlsLmNvbXw0Njc5MTQ2fC0xNzc0MzgwNjE5>
> .
> NAML
> <http://tomee-openejb.979440.n4.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>
--
Steven P. Goldsmith
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679168.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Im not sure what you mean but all good logging framework provide a
classloader friendly impl - juli, log4j2 etc... - which doesnt leak. Know
logback has something like that but never tested it.
The fact you load slf4j with app loader can mean you put it in the
classpath which sounds wrong, should only be in common loader and
optionally webapp one.
Le 30 juin 2016 22:37, "sgjava" <sg...@gmail.com> a écrit :
> Also found http://java.jiderhamn.se/category/classloader-leaks
>
> As for java.util.logging (JUL), it will always be outside the web
> application, since it is part of the JDK. With it you can cause classloader
> leaks by creating custom log Levels inside your web app. This is what Frank
> Kieviet uses as example in his blog post on classloader leaks. It seems
> also
> that JBoss Logging does exactly that if backed by JUL, and thereby triggers
> such a leak if loaded within your web app. See report here.
>
> I just checked my TomEE 2.0.0 app and it leaks too! So do I just switch to
> JUL? This really sucks since logback is more refined.
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
Also found http://java.jiderhamn.se/category/classloader-leaks
As for java.util.logging (JUL), it will always be outside the web
application, since it is part of the JDK. With it you can cause classloader
leaks by creating custom log Levels inside your web app. This is what Frank
Kieviet uses as example in his blog post on classloader leaks. It seems also
that JBoss Logging does exactly that if backed by JUL, and thereby triggers
such a leak if loaded within your web app. See report here.
I just checked my TomEE 2.0.0 app and it leaks too! So do I just switch to
JUL? This really sucks since logback is more refined.
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679159.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
All the libs are in WEB-INF/lib (none in TOMEE/lib), so I'm not sure why
it's not loading right. I can try updating since I'm using 1.7.7 and you
guys are using 1.7.21 :)
On Thu, Jun 30, 2016 at 4:35 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Something is wrong, should be WebAppClassloader not app classloader
>
> You have slf4j-api in the webapp and not only logback? If so maybe slf4j
> code changed
> Le 30 juin 2016 22:15, "sgjava" <sg...@gmail.com> a écrit :
>
> > The other thing I do not understand is this is how I've configured web
> apps
> > for years and haven't had an issue with Tomcat. See
> >
> >
> https://wiki.base22.com/display/btg/How+to+setup+SLF4J+and+LOGBack+in+a+web+app+-+fast
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679156.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Something is wrong, should be WebAppClassloader not app classloader
You have slf4j-api in the webapp and not only logback? If so maybe slf4j
code changed
Le 30 juin 2016 22:15, "sgjava" <sg...@gmail.com> a écrit :
> The other thing I do not understand is this is how I've configured web apps
> for years and haven't had an issue with Tomcat. See
>
> https://wiki.base22.com/display/btg/How+to+setup+SLF4J+and+LOGBack+in+a+web+app+-+fast
>
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679156.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>
Re: TomEE 7.01 heap leak in logging
Posted by sgjava <sg...@gmail.com>.
The other thing I do not understand is this is how I've configured web apps
for years and haven't had an issue with Tomcat. See
https://wiki.base22.com/display/btg/How+to+setup+SLF4J+and+LOGBack+in+a+web+app+-+fast
--
View this message in context: http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146p4679156.html
Sent from the TomEE Users mailing list archive at Nabble.com.
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
sun.misc.Launcher$AppClassLoader@75b84c92
sun.misc.Launcher$AppClassLoader@75b84c92
private static final Logger log = LoggerFactory.getLogger(MasService.class);
sun.misc.Launcher$AppClassLoader@75b84c92
sun.misc.Launcher$AppClassLoader@75b84c92
On Thu, Jun 30, 2016 at 3:41 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> just do from the webapp :
>
> System.out.println(LoggerFactory.class.getClassLoader());
> System.out.println(LOGGER.getClass().getClassLoader());
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-06-30 21:36 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
>
> > Correct, I have placed no jars in TOMEE/lib except for hazelcast and the
> > catalina jmx connector. I cannot share the app, but let me look at
> removing
> > slf4j. So to make sure I understand I need to remove:
> >
> > <dependency>
> > <groupId>org.slf4j</groupId>
> > <artifactId>slf4j-api</artifactId>
> > <version>${slf4j.version}</version>
> > </dependency>
> >
> > and
> >
> > import org.slf4j.Logger;
> > import org.slf4j.LoggerFactory;
> >
> > So how should this line look?
> >
> > private static final Logger log =
> > LoggerFactory.getLogger(MasService.class);
> >
> > On Thu, Jun 30, 2016 at 3:12 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > Hi
> > >
> > > logback is only in the webapp?
> > >
> > > by default Logger shouldnt use slf4j at all
> > >
> > > Can you share the app or at least ensure slf4j-api is loaded from the
> > > webapp for your loggers?
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > > <http://rmannibucau.wordpress.com> | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > > <http://www.tomitribe.com> | JavaEE Factory
> > > <https://javaeefactory-rmannibucau.rhcloud.com>
> > >
> > > 2016-06-30 20:09 GMT+02:00 sgjava <sg...@gmail.com>:
> > >
> > > > OK, I left TomEE's logging configured as default and I'm still
> getting
> > a
> > > > heap
> > > > leak using logback+slf4j. Looks like it's int the loggerCache.
> > > >
> > > > The class "org.apache.openejb.util.Logger", loaded by
> > > > "java.net.URLClassLoader @ 0x805b90c0", occupies 316,141,928 (79.36%)
> > > > bytes.
> > > > The memory is accumulated in one instance of
> > > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> > class
> > > > loader>".
> > > >
> > > > Class Name
> > > > | Shallow Heap | Retained Heap
> > > >
> > > >
> > >
> >
> --------------------------------------------------------------------------------------------
> > > > loggerCache class org.apache.openejb.util.Logger @ 0x80960510|
> > > 48
> > > > | 316,141,928
> > > >
> > > >
> > >
> >
> --------------------------------------------------------------------------------------------
> > > >
> > > > Versions:
> > > >
> > > > <tomee.version>7.0.1</tomee.version>
> > > > <slf4j.version>1.7.7</slf4j.version>
> > > > <logback.version>1.1.2</logback.version>
> > > >
> > > > Web app:
> > > >
> > > > <dependency>
> > > > <groupId>org.slf4j</groupId>
> > > > <artifactId>slf4j-api</artifactId>
> > > > <version>${slf4j.version}</version>
> > > > </dependency>
> > > > <dependency>
> > > > <groupId>ch.qos.logback</groupId>
> > > > <artifactId>logback-classic</artifactId>
> > > > <version>${logback.version}</version>
> > > > </dependency>
> > > > <dependency>
> > > > <groupId>ch.qos.logback</groupId>
> > > > <artifactId>logback-core</artifactId>
> > > > <version>${logback.version}</version>
> > > > </dependency>
> > > >
> > > > Class has:
> > > >
> > > > private static final Logger log =
> > > > LoggerFactory.getLogger(MasService.class);
> > > >
> > > > I have same config running under TomEE 2.0.0 for 1.5 years without
> heap
> > > > leak. It logs a lot more too.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > >
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146.html
> > > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > > >
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
just do from the webapp :
System.out.println(LoggerFactory.class.getClassLoader());
System.out.println(LOGGER.getClass().getClassLoader());
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-06-30 21:36 GMT+02:00 Steve Goldsmith <sg...@gmail.com>:
> Correct, I have placed no jars in TOMEE/lib except for hazelcast and the
> catalina jmx connector. I cannot share the app, but let me look at removing
> slf4j. So to make sure I understand I need to remove:
>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <version>${slf4j.version}</version>
> </dependency>
>
> and
>
> import org.slf4j.Logger;
> import org.slf4j.LoggerFactory;
>
> So how should this line look?
>
> private static final Logger log =
> LoggerFactory.getLogger(MasService.class);
>
> On Thu, Jun 30, 2016 at 3:12 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Hi
> >
> > logback is only in the webapp?
> >
> > by default Logger shouldnt use slf4j at all
> >
> > Can you share the app or at least ensure slf4j-api is loaded from the
> > webapp for your loggers?
> >
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-06-30 20:09 GMT+02:00 sgjava <sg...@gmail.com>:
> >
> > > OK, I left TomEE's logging configured as default and I'm still getting
> a
> > > heap
> > > leak using logback+slf4j. Looks like it's int the loggerCache.
> > >
> > > The class "org.apache.openejb.util.Logger", loaded by
> > > "java.net.URLClassLoader @ 0x805b90c0", occupies 316,141,928 (79.36%)
> > > bytes.
> > > The memory is accumulated in one instance of
> > > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system
> class
> > > loader>".
> > >
> > > Class Name
> > > | Shallow Heap | Retained Heap
> > >
> > >
> >
> --------------------------------------------------------------------------------------------
> > > loggerCache class org.apache.openejb.util.Logger @ 0x80960510|
> > 48
> > > | 316,141,928
> > >
> > >
> >
> --------------------------------------------------------------------------------------------
> > >
> > > Versions:
> > >
> > > <tomee.version>7.0.1</tomee.version>
> > > <slf4j.version>1.7.7</slf4j.version>
> > > <logback.version>1.1.2</logback.version>
> > >
> > > Web app:
> > >
> > > <dependency>
> > > <groupId>org.slf4j</groupId>
> > > <artifactId>slf4j-api</artifactId>
> > > <version>${slf4j.version}</version>
> > > </dependency>
> > > <dependency>
> > > <groupId>ch.qos.logback</groupId>
> > > <artifactId>logback-classic</artifactId>
> > > <version>${logback.version}</version>
> > > </dependency>
> > > <dependency>
> > > <groupId>ch.qos.logback</groupId>
> > > <artifactId>logback-core</artifactId>
> > > <version>${logback.version}</version>
> > > </dependency>
> > >
> > > Class has:
> > >
> > > private static final Logger log =
> > > LoggerFactory.getLogger(MasService.class);
> > >
> > > I have same config running under TomEE 2.0.0 for 1.5 years without heap
> > > leak. It logs a lot more too.
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146.html
> > > Sent from the TomEE Users mailing list archive at Nabble.com.
> > >
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: TomEE 7.01 heap leak in logging
Posted by Steve Goldsmith <sg...@gmail.com>.
Correct, I have placed no jars in TOMEE/lib except for hazelcast and the
catalina jmx connector. I cannot share the app, but let me look at removing
slf4j. So to make sure I understand I need to remove:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
and
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
So how should this line look?
private static final Logger log = LoggerFactory.getLogger(MasService.class);
On Thu, Jun 30, 2016 at 3:12 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hi
>
> logback is only in the webapp?
>
> by default Logger shouldnt use slf4j at all
>
> Can you share the app or at least ensure slf4j-api is loaded from the
> webapp for your loggers?
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-06-30 20:09 GMT+02:00 sgjava <sg...@gmail.com>:
>
> > OK, I left TomEE's logging configured as default and I'm still getting a
> > heap
> > leak using logback+slf4j. Looks like it's int the loggerCache.
> >
> > The class "org.apache.openejb.util.Logger", loaded by
> > "java.net.URLClassLoader @ 0x805b90c0", occupies 316,141,928 (79.36%)
> > bytes.
> > The memory is accumulated in one instance of
> > "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> > loader>".
> >
> > Class Name
> > | Shallow Heap | Retained Heap
> >
> >
> --------------------------------------------------------------------------------------------
> > loggerCache class org.apache.openejb.util.Logger @ 0x80960510|
> 48
> > | 316,141,928
> >
> >
> --------------------------------------------------------------------------------------------
> >
> > Versions:
> >
> > <tomee.version>7.0.1</tomee.version>
> > <slf4j.version>1.7.7</slf4j.version>
> > <logback.version>1.1.2</logback.version>
> >
> > Web app:
> >
> > <dependency>
> > <groupId>org.slf4j</groupId>
> > <artifactId>slf4j-api</artifactId>
> > <version>${slf4j.version}</version>
> > </dependency>
> > <dependency>
> > <groupId>ch.qos.logback</groupId>
> > <artifactId>logback-classic</artifactId>
> > <version>${logback.version}</version>
> > </dependency>
> > <dependency>
> > <groupId>ch.qos.logback</groupId>
> > <artifactId>logback-core</artifactId>
> > <version>${logback.version}</version>
> > </dependency>
> >
> > Class has:
> >
> > private static final Logger log =
> > LoggerFactory.getLogger(MasService.class);
> >
> > I have same config running under TomEE 2.0.0 for 1.5 years without heap
> > leak. It logs a lot more too.
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146.html
> > Sent from the TomEE Users mailing list archive at Nabble.com.
> >
>
--
Steven P. Goldsmith
Re: TomEE 7.01 heap leak in logging
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi
logback is only in the webapp?
by default Logger shouldnt use slf4j at all
Can you share the app or at least ensure slf4j-api is loaded from the
webapp for your loggers?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://blog-rmannibucau.rhcloud.com> | Old Wordpress Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-06-30 20:09 GMT+02:00 sgjava <sg...@gmail.com>:
> OK, I left TomEE's logging configured as default and I'm still getting a
> heap
> leak using logback+slf4j. Looks like it's int the loggerCache.
>
> The class "org.apache.openejb.util.Logger", loaded by
> "java.net.URLClassLoader @ 0x805b90c0", occupies 316,141,928 (79.36%)
> bytes.
> The memory is accumulated in one instance of
> "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class
> loader>".
>
> Class Name
> | Shallow Heap | Retained Heap
>
> --------------------------------------------------------------------------------------------
> loggerCache class org.apache.openejb.util.Logger @ 0x80960510| 48
> | 316,141,928
>
> --------------------------------------------------------------------------------------------
>
> Versions:
>
> <tomee.version>7.0.1</tomee.version>
> <slf4j.version>1.7.7</slf4j.version>
> <logback.version>1.1.2</logback.version>
>
> Web app:
>
> <dependency>
> <groupId>org.slf4j</groupId>
> <artifactId>slf4j-api</artifactId>
> <version>${slf4j.version}</version>
> </dependency>
> <dependency>
> <groupId>ch.qos.logback</groupId>
> <artifactId>logback-classic</artifactId>
> <version>${logback.version}</version>
> </dependency>
> <dependency>
> <groupId>ch.qos.logback</groupId>
> <artifactId>logback-core</artifactId>
> <version>${logback.version}</version>
> </dependency>
>
> Class has:
>
> private static final Logger log =
> LoggerFactory.getLogger(MasService.class);
>
> I have same config running under TomEE 2.0.0 for 1.5 years without heap
> leak. It logs a lot more too.
>
>
>
>
>
> --
> View this message in context:
> http://tomee-openejb.979440.n4.nabble.com/TomEE-7-01-heap-leak-in-logging-tp4679146.html
> Sent from the TomEE Users mailing list archive at Nabble.com.
>