Turns out the memory problem was caused by a special transformer component we were using, not anything to do with BackgroundEnvironment.
However, it's still worth noting that the api for background Cocoon processing isn't very pretty, imho. I've currently actually got the JMS listener making an http request to localhost, rather than use BackgroundEnvironment. It's a bit of a strange way to go about it though, I know. But I'd rather not try and manage my on Cocoon environment to this detail. Cheers all, merry Christmas, Ollie -----Original Message----- From: Ard Schrijvers [mailto:[EMAIL PROTECTED] Sent: Tuesday, 20 December 2005 4:17 a.m. To: users@cocoon.apache.org Subject: RE: JMS Listener invokes Cocoon pipeline (RE: How do I create a context from a background task in cocoon?) Hi, I eventually also got it running with a BackgroundEnvironment. I have not yet experienced the java.lang.OutOfMemory but this may merely be a result that it is not yet in production. At least I know to test it now :-) The way it now works for me, is to create a BackgroundEnvironment, then lookup a SourceResolver, and use resolveUri. Probably, at the end, your also nicely releasing your evironment?? CocoonComponentManager.leaveEnvironment(); CocoonComponentManager.endProcessing(env, key); if (processor != null) { manager.release(processor); } And indeed, I don't want to use cron job this either (think I even needen the quartz block). It seems to me it is way to hard to do something with for example a class that acts on a JMS message and wants to process a pipeline. AS > > > Hi, we've got a similar need to invoke Cocoon in the background: > > > We have a JMS Listener component configured to startup when Cocoon > starts up (in cocoon.xconf). When its asynch onMessage() method is > called, we want the method to then invoke a Cocoon pipeline. We expect > the JMS topic to be pushing a steady, reasonably constant supply of > messages every few seconds or less, sometimes there will be spikes. > What is the best way to implement this? > > Our current implementation uses the BackgroundEnvironment class from > the cron block that Sylvain Wallez mentions below. Unfortunately > however, under our soak test the server collapses after 24 hours with > a java.lang.OutOfMemory error. > > > One thing I can see I've probably done wrong is I fully establish the > Cocoon environment entirely within the onMessage() method, every time. > That's a lot of work to do for EVERY message we get. So should I > instead establish the BackgroundEnvironment (and lookup the > SourceResolver) on initialisation of the Listener component? Then the > only work performed within onMessage is to call > SourceResolver.resolveURI()? > > If so, exactly how much setup should I do in initialise()? Is it ok if > it goes as far as: > > ... > CocoonComponentManager.enterEnvironment(env, new > WrapperComponentManager(this.manager), processor); this.resolver = > (SourceResolver) this.manager.lookup(SourceResolver.ROLE); > > Then in onMessage() I can simply call: src = > this.resolver.resolveURI(uri); > > At what point should I close down and clean up the > BackgroudEnvironment? > In dispose()? > > I'm a bit nervous using BackgroundEnvironment and > CocoonComponentManager in this way - especially when the > CocoonComponentManager javadoc says > 'WARNING: This is a "private" Cocoon core class - do NOT use this > class directly'! I'm tempted to instead have the onMessage() method > simply make an http request to the "proper" Cocoon environment on > localhost:8080. It feels like it would be the safer way to go. Then I > can let the normal CocoonServlet look after the environment. > (Also note, > I'd rather not use the cron block). > > Any advice? Thanks in advance, > Oliver Powell > > -----Original Message----- > From: Sylvain Wallez [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, 7 December 2005 10:26 a.m. > To: users@cocoon.apache.org > Subject: Re: How do I create a context from a background task in > cocoon? > > Ard Schrijvers wrote: > > Does anybody have experience with calling a pipeline from a > background > task resulting from an eventHandler? > > > > So, on an event, a java class is executed which implements > Contextualizable. > > > > I am trying something like > > > > import org.apache.avalon.framework.context.Contextualizable; > > import org.apache.avalon.framework.context.Context; > > import org.apache.avalon.framework.context.ContextException; > > > > implements Contextualizable, ... > > > > private Context context; > > > > public void contextualize(Context context) throws > ContextException > { > > this.context = context; > > > > } > > PipelineUtil pipeUtil = new PipelineUtil(); try { > > pipeUtil.contextualize(context); > > pipeUtil.service(serviceManager); > > pipeUtil.processToSAX(uri, null, somehandler); } catch > (Exception > > > e) { > > throw new CascadingRuntimeException("Cannot process > pipeline from > > > '" + uri + "'", e); } finally { > > pipeUtil.dispose(); > > } > > > > Now, this does not work, because it does not have a > context, since the > class is not called from a sitemap but from an external event. > > > > So, I tried instead of with the context, the SourceResolver, like > > > > SourceResolver resolver = (SourceResolver) > > > manager.lookup(SourceResolver.ROLE); > > > > and then something like > > Source inputSource = > > > > resolver.resolveURI("cocoon://dasl/references/content/test/Passage.xml > > "); > > > > But, nothing happens, I suppose because the cocoon:// is only > > > available when the call is initiated from a sitemap (or flow of > > > course) > > > > So, does anybody know how to solve this/solved this before? > > > > > Yes. Running a Cocoon pipeline in a background task requires to setup > a "fake" environment so that the SourceResolver can do its job. You > can achieve that either by using the scheduler (cron block) to fire a > job immediately, or directly use the BackgroundEnvironment class that > it uses under the hoods. > > Sylvain > > -- > > Sylvain Wallez Anyware Technologies > http://bluxte.net http://www.anyware-tech.com > Apache Software Foundation Member Research & Technology Director > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > ===================================================================== > CAUTION: This e-mail and any attachment(s) contains information that > > is intended to be read only by the named recipient(s). It may contain > > information that is confidential, proprietary or the subject of legal > > privilege. This information is not to be used by any other person > > and/or organisation. If you are not the intended recipient, please > > advise us immediately and delete this e-mail from your system. Do not > > use any information contained in it. > > > ================================================================ > For more information on the Television New Zealand Group, visit us > > online at http://www.tvnz.co.nz > > ================================================================ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ===================================================================== CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz ================================================================ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
