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 19:07:22 GMT
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