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 20:03:55 GMT
Hi Romain, I removed all @Async usage and now it's the request thread that
hangs :D

Actually when I dump the thread it seems to work forever being here and
there inside Eclipselink internals. Wonder if I triggered some kind of
endless loop. It looks like it because my heap is going way up and down and
I am the only one using the app and whatever task I started should be done
aaaages ago.

Big help getting my attention away from batch and async :-)

I will keep analyzing. If it's not local to my app I will try to reproduce
it in a sample (but it's always quite hard to do that :/)

thanks again



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

> yes surely
>
> if you can put some effort to create a github project it can really help
> since we'll identify the issue really faster (and where it comes from ;))
>
>
> 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:32 GMT+01:00 Karl Kildén <karl.kilden@gmail.com>:
>
>> 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