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 18:27:21 GMT
well

deltaspike data doesn't want @RequestScoped, it just used the contextual
entity manager - this comes from what JSF guys do AFAIK.

Wonder if you could reproduce it with OpenJPA or if it is due to the fact
eclipselink is storing itself a state somewhere. Any idea?



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

> 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