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:32:41 GMT
Romain you are right I am to tired now... Maybe I am quite stupid for
putting @RequestScoped on it since that is how I used to do it when I did
tomcat.  It should not even do anything when I think about it.

This problem seems very related to how I use @Async. Maybe I should move my
topic with a new mail to tomee list?

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

> 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