batchee-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: TomEE mem leak using batchee with JTA transactions
Date Mon, 02 Mar 2015 17:50:21 GMT
batchee default impl shouldnt be @Async excepted if you imported the module
Mark added for WAS - but your thread naming is closer to tomee ;).

batches are by design asynchronous so no need of @Async to launch them.

then all depends your @requestScoped. if it matches nothing the container
handles (http request or synchronous ejb call) then you should handle it
yourself but sounds like a workaround more than a fix which would be using
a correct scope.



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:44 GMT+01:00 Karl Kildén <karl.kilden@gmail.com>:

> 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