batchee-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Kildén <karl.kil...@gmail.com>
Subject Re: TomEE mem leak using batchee with JTA transactions
Date Mon, 02 Mar 2015 17:44:16 GMT
I was wrong - this problem is in many other places not just batches!

regarding batch:

Interesting, I have not done anything (what I know) to enable
requestscoped...

I thought Mark once told me that the impl in batchee for creating threads
is actually @Asynchronous. I also kind of recall not getting any extra
threads in my batchee jobs until I increased the @Async thread pool.

I do use @Async myself also here and there... In fact I think in one or two
cases Asynchronous will start the batch. I
use <class>org.apache.deltaspike.jpa.impl.transaction.EnvironmentAwareTransactionStrategy</class>

Then I use this producer:

@PersistenceContext(unitName = APP_NAME)
private EntityManager entityManager;

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



And a normal stateless that uses either the entityManager or a repository
from deltaspike data (actually almost always the repository). This is the
only way I produce entityManagers.


Anyways my problem seems to be also in JSF @ViewScoped beans and whatnot.
Can it be that I must dispose my entitymanagers myself somehow?



On 2 March 2015 at 18:15, Romain Manni-Bucau <rmannibucau@gmail.com> wrote:

> 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
> it
>
>
>
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <http://rmannibucau.wordpress.com> | Github
> <https://github.com/rmannibucau> | LinkedIn
> <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com>
>
> 2015-03-02 18:10 GMT+01:00 Karl Kildén <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 that the async thread seems to keep a
>> reference 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 it
>> is produced like this:
>>
>> @PersistenceContext(unitName = 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
>>
>
>

Mime
View raw message