batchee-ee6 is the one, using an ejb so request scoped is implicitely started. remove it and you should get context not active exception. jbatch just use a plain old trheadpoolexecutor
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-04 16:47 GMT+01:00 Karl Kildén <[email protected]>: > Well I have it @RequestScoped and @PersistenceContext because of a > mistake and it works everywhere including stateless and Jbatch and I do no > tricks. I will however remove it and try again because it does not make > sense. > > I copied by dependencies from Caroline or something: > > <dependency> > <groupId>org.apache.geronimo.specs</groupId> > <artifactId>geronimo-jbatch_1.0_spec</artifactId> > <version>${jbatch-api.version}</version> > <scope>compile</scope> > <!-- this JSR spec API is not yet provided in our EE6 containers --> > </dependency> > > <dependency> > <groupId>org.apache.batchee</groupId> > <artifactId>batchee-jbatch</artifactId> > <version>${batchee.version}</version> > </dependency> > <dependency> > <groupId>org.apache.batchee</groupId> > <artifactId>batchee-extras</artifactId> > <version>${batchee.version}</version> > </dependency> > <dependency> > <groupId>org.apache.batchee</groupId> > <artifactId>batchee-jsefa</artifactId> > <version>${batchee.version}</version> > </dependency> > <dependency> > <groupId>org.apache.batchee</groupId> > <artifactId>batchee-cdi</artifactId> > <version>${batchee.version}</version> > </dependency> > <dependency> > <groupId>org.apache.batchee</groupId> > <artifactId>batchee-ee6</artifactId> > <version>${batchee.version}</version> > </dependency> > > > > Does that mean I have that extra module that uses stateless instead > activated or not? Would be good to know how the batch threads are started... > > On 4 March 2015 at 13:23, Romain Manni-Bucau <[email protected]> > wrote: > >> @Mark: this has no link with EE 6 or 7, this is just a feature you want - >> which is fine. JBatch doesn't deal with request scoped at all for instance. >> That said for batches we have @JobScoped and @StepScoped which are still >> exeprimental in batchee-cdi but can be more adapted. I know you are used to >> it but I just find it a non-sense to have named request scoped something >> which is not bound to any http request but that's another topic ;) >> >> >> 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-04 13:11 GMT+01:00 Mark Struberg <[email protected]>: >> >>> I did not read the full thread, but @Stateless and a @RequestScoped >>> EntityManager doesn’t make sense. >>> @Stateless basically _only_ works well with @PersistenceContext. If you >>> use DeltaSpike JPA then I’d rather use @AppliationScoped + @Transactional >>> (from deltaspike, not the half-broken one from EE7). >>> >>> >>> The EE support module btw is not just for WAS - it’s for all >>> environments which support EE but not yet EE7. The point is that with >>> wrapping new thread creating in @Asynchronous ejb call you get all the >>> ThreadLocals set up for free. And it’s even needed on some EE7 container as >>> the concurrency-utils spec doesn’t define that the Context for >>> @RequestScoped needs to get started. Some containers do it, others don’t… >>> >>> LieGrue, >>> strub >>> >>> >>> >>> > Am 02.03.2015 um 22:46 schrieb Romain Manni-Bucau < >>> [email protected]>: >>> > >>> > Depend your conf for both but a thread stack will say you in 2s >>> > >>> > Le 2 mars 2015 22:35, <[email protected]> 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 <[email protected]>: >>> > >>> >> 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 | Blog | Github | LinkedIn | Tomitriber >>> >> >>> >> 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 | Blog | Github | LinkedIn | Tomitriber >>> >> >>> >> 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 | Blog | Github | LinkedIn | Tomitriber >>> >> >>> >> 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 | Blog | Github | LinkedIn | Tomitriber >>> >> >>> >> 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 >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >>> >> >
