Full db connection pool? Le 2 mars 2015 21:04, "Karl Kildén" <[email protected]> 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 <[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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
