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 21:46:50 GMT
Depend your conf for both but a thread stack will say you in 2s
Le 2 mars 2015 22:35, <karl.kilden@gmail.com> a écrit :

> Hrmm. Probably not. But maybe, I would expect a clear error message
> though? Maybe some other pool like stateless? Or will it get tired of
> waiting and throw?
>
> Skickat från min iPhone
>
> 2 mar 2015 kl. 21:58 skrev Romain Manni-Bucau <rmannibucau@gmail.com>:
>
> Full db connection pool?
> Le 2 mars 2015 21:04, "Karl Kildén" <karl.kilden@gmail.com> a écrit :
>
>> 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