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 <[email protected]> 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 <[email protected]>: > >> 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 <[email protected]> >> 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 <[email protected]>: >>> >>>> 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 <[email protected]> >>>> 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 <[email protected]>: >>>>> >>>>>> 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 <[email protected]> >>>>>> 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 <[email protected]>: >>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
