Return-Path: X-Original-To: apmail-batchee-user-archive@minotaur.apache.org Delivered-To: apmail-batchee-user-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B7A9717BA9 for ; Mon, 2 Mar 2015 17:16:44 +0000 (UTC) Received: (qmail 22201 invoked by uid 500); 2 Mar 2015 17:16:38 -0000 Delivered-To: apmail-batchee-user-archive@batchee.apache.org Received: (qmail 22171 invoked by uid 500); 2 Mar 2015 17:16:38 -0000 Mailing-List: contact user-help@batchee.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@batchee.incubator.apache.org Delivered-To: mailing list user@batchee.incubator.apache.org Received: (qmail 22161 invoked by uid 99); 2 Mar 2015 17:16:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Mar 2015 17:16:38 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rmannibucau@gmail.com designates 209.85.216.50 as permitted sender) Received: from [209.85.216.50] (HELO mail-qa0-f50.google.com) (209.85.216.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Mar 2015 17:16:34 +0000 Received: by mail-qa0-f50.google.com with SMTP id f12so23937901qad.9 for ; Mon, 02 Mar 2015 09:16:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=T4ZRrTG0SR2B3ydyhrCzNoPkV2xLNy4OnWTgUJNtMnA=; b=dy4vB/50ePwI6SdnqLEBfLI+cwJaexr6qf1L+yNgfSwIz+8SZtPop/JjMvKwMqomdU U/ZYi5C0+caEakC3lQk0A4R1ff78H8zGoVSGx07/IthcnlzMRalPhwg1vNIPm9wCRf94 HguduYIWazvvXRXSSKs4X2wSabLfi2BvxgwGQXavGn6UzFAISASXoiDrN3wKpaf75lc/ ThGSx34oNJSHOjdIz12kgl83Uk5tkOlBOPvsJNS2k8OgiYadojPAny1bjDSLiPCGacwn 5NgPbe0nBuXf3O3p8ez8JbrmUU9r7SIaDWg1X9B72w0/GWggh23xtf/zNtJJBqd79jq7 S5sw== X-Received: by 10.140.234.17 with SMTP id f17mr54606069qhc.64.1425316573550; Mon, 02 Mar 2015 09:16:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.96.219.69 with HTTP; Mon, 2 Mar 2015 09:15:53 -0800 (PST) In-Reply-To: References: From: Romain Manni-Bucau Date: Mon, 2 Mar 2015 18:15:53 +0100 Message-ID: Subject: Re: TomEE mem leak using batchee with JTA transactions To: user@batchee.incubator.apache.org Content-Type: multipart/alternative; boundary=001a11354b940f1ed60510516074 X-Virus-Checked: Checked by ClamAV on apache.org --001a11354b940f1ed60510516074 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hmm for a batch this code doesnt mean anything - request scope. Did you hack something around detaspike to make it working? If this entity manager is used in an EJB this should be fine, if not then you need to ensure transaction are handled as you expect - should be the case with batchee but doesnt cost anything to validate it . Finally do you use @Asynchronous in your code otherwise you shouldn't see i= t Romain Manni-Bucau @rmannibucau | Blog | Github | LinkedIn | Tomitriber 2015-03-02 18:10 GMT+01:00 Karl Kild=C3=A9n : > Hello, > > I have some @Stateless that I use from batches. After the job has finishe= d > I can see after a heap dump that the async thread seems to keep a referen= ce > to the RepeatableWriteUnitOfWork. When I google I understand that this is > the EclipseLink entitymanager and since nobody seems to have called clear > on it my heap is getting pretty full... > > I have defined my Batches with normal read process write. They are @Named > and simply inject my @Stateless. They @Stateless uses EntityManager and i= t > is produced like this: > > @PersistenceContext(unitName =3D APP_NAME) > private EntityManager entityManager; > > @Produces > @RequestScoped > protected EntityManager createEntityManager() { > return this.entityManager; > } > > > Not sure if I am missing some kind of disposal here? I don't think so > because only the jobs get the UnitOfWork stuck on the heap. > > Not sure I understand any of this very well. I can just clearly see that > my entire heap is now RepeatableWriteUnitOfWork tied to @ASynchronous > threads. > > My memory dump could of course be sent to someone or shared desktop if > someone want's to help me understand this... Or maybe a pointer on where = to > debug? > > cheers > --001a11354b940f1ed60510516074 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm

for a batch this code doesnt mean a= nything - request scope. Did you hack something around detaspike to make it= working?

If this entity manager is used in an EJB= this should be fine, if not then you need to ensure transaction are handle= d as you expect - should be the case with batchee but doesnt cost anything = to validate it .

Finally=C2=A0do you use @Asynchronous in your code otherwise you shouldn't see it<= /span>





Romain Manni-Bucau
<= a href=3D"https://twitter.com/rmannibucau" target=3D"_blank">@rmannibucau | =C2=A0B= log=C2=A0| Github=C2=A0| LinkedIn=C2=A0| Tomitriber

2015-03-02 18:10 GMT+01:00 Karl Kild=C3=A9n = <karl.kilden@gmail.com>:
Hello,

I have some @Stateless that I= use from batches. After the job has finished I can see after a heap dump t= hat the async thread seems to keep a reference to the=C2=A0RepeatableWriteU= nitOfWork. When I google I understand that this is the EclipseLink entityma= nager and since nobody seems to have called clear on it my heap is getting = pretty full...

I have defined my Batches with norm= al read process write. They are @Named and simply inject my @Stateless. The= y @Stateless uses EntityManager and it is produced like this:

<= span style=3D"white-space:pre-wrap"> @PersistenceContext(unitName = =3D APP_NAME)
privat= e EntityManager entityManager;

@Produces
@RequestScoped
protected EntityManager createEntityManager() {
return this.entityManager;
}

=

Not sure if I am missing some kind of disposal here?=C2= =A0 I don't think so because only the jobs get the UnitOfWork stuck on = the heap.

Not sure I understand any of this very w= ell. I can just clearly see that my entire heap is now RepeatableWriteUnitO= fWork tied to @ASynchronous threads.

My memory dum= p could of course be sent to someone or shared desktop if someone want'= s to help me understand this... Or maybe a pointer on where to debug?
=

cheers

--001a11354b940f1ed60510516074--