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 18:13:16 GMT
Romain,

Deltaspike Data wants a @RequestScoped entityManager. If I want to use Data
module from my batches, how to combine that?

Also, this whole problem seems linked to @Async not batch (I thought batch
was implemented with @Async)

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

> 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