RE: Multiple or single cocoon instances
Hi Jose, well I guess that depends a bit on what your environment is. We at Hippo have used mulitple project -> 1 cocoon in the past, but switched to using 1 cocoon instance per project. The problem with multiple project in 1 cocoon is that if one project causes your server to fail it will drag down all the others. Also with updates it can be more easy to update only one application instead of shutting down all project because 1 project needs a new dependency. I guess it's more a personal taste, but a good topic IMO to see how people handle their cocoon environments. Regards, Jeroen -Original Message- From: José Miguel Vieira [mailto:[EMAIL PROTECTED] Sent: Mon 3/31/2008 11:37 AM To: users@cocoon.apache.org Subject: Multiple or single cocoon instances Hello, At the moment we have several cocoon projects, about 20 or so, running inside the same cocoon, version 2.1.10. Is this the best way to do it, or would it be better to have one cocoon instance per project? Thanks, Miguel --- José Miguel Vieira Centre for Computing in the Humanities King's College London 26 - 29 Drury Lane WC2B 5RL London Email: [EMAIL PROTECTED] Tel: +44 (0)20 7848 1242 Faxl: +44 (0)20 7848 2980 http://www.kcl.ac.uk/cch/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multiple or single cocoon instances
We have multiple "applications" in one cocoon. I guess it depends on what you are doing, how much you can afford to spend on hardware and how important is zero down time. If you have loads of money to spend on hardware (including maintenance), and you are bundling Java classes with Cocoon, then go with multiple instances of Cocoon. If you have one application server, what I don't recommend, is a scenario with multiple instances of Cocoon, all sitting in an a single application server. This is a disaster IMHO. Cocoon is a beast it is difficult to manage this well. Another thing I don't recommend is using mount tables. They seem like a good idea, but they are not as they are managed within Cocoon it is harder to change. In fact, if you are using an application server, you should try to get as much of the application off the application server. I am actually curious as to how people run Cocoon. That is, do you use an application server (JBoss, SJSAS) or do people get by with Jetty. Jeroen Reijn wrote: Hi Jose, well I guess that depends a bit on what your environment is. We at Hippo have used mulitple project -> 1 cocoon in the past, but switched to using 1 cocoon instance per project. The problem with multiple project in 1 cocoon is that if one project causes your server to fail it will drag down all the others. Also with updates it can be more easy to update only one application instead of shutting down all project because 1 project needs a new dependency. I guess it's more a personal taste, but a good topic IMO to see how people handle their cocoon environments. Regards, Jeroen -Original Message- From: José Miguel Vieira [mailto:[EMAIL PROTECTED] Sent: Mon 3/31/2008 11:37 AM To: users@cocoon.apache.org Subject: Multiple or single cocoon instances Hello, At the moment we have several cocoon projects, about 20 or so, running inside the same cocoon, version 2.1.10. Is this the best way to do it, or would it be better to have one cocoon instance per project? Thanks, Miguel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.1] schedule some actions
You can use Cocoon Cron Block: see this for an example and doc: http://cocoon.zones.apache.org/demos/release/samples/blocks/cron/samples Bye - Original Message Follows - From: nanomonk <[EMAIL PROTECTED]> To: users@cocoon.apache.org Subject: [2.1] schedule some actions Date: Tue, 1 Apr 2008 03:31:18 -0700 (PDT) > hmm.. Can I to schedule some actions? > I need something like a thread that always works and do > something at custom time. I just can't understand how to > start\stop it with cocoon. I don't know, maybe I should to > use servlet, but how to start own servlets in cocoon?:) > maybe there is exist true-way?;) > -- > View this message in context: > http://www.nabble.com/-2.1--schedule-some-actions-tp16417868p16417868.html > Sent from the Cocoon - Users mailing list archive at > Nabble.com. > > > -- > --- To unsubscribe, e-mail: > [EMAIL PROTECTED] For additional > commands, e-mail: [EMAIL PROTECTED] > -- This Email Was brought to you by WebMail A Netwin Web Based EMail Client http://netwinsite.com/webmail/tag.htm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.1] schedule some actions
On Apr 1, 2008, at 6:47 AM, [EMAIL PROTECTED] wrote: You can use Cocoon Cron Block: see this for an example and doc: http://cocoon.zones.apache.org/demos/release/samples/blocks/cron/samples There is a better, lightweight thread scheduler built in into Cocoon. API is: http://cocoon.apache.org/2.1/apidocs/org/apache/cocoon/components/thread/RunnableManager.html You just need to lookup RunnableManager and use any of schedule() methods to schedule a one-time, or periodic job. Vadim Bye - Original Message Follows - From: nanomonk <[EMAIL PROTECTED]> To: users@cocoon.apache.org Subject: [2.1] schedule some actions Date: Tue, 1 Apr 2008 03:31:18 -0700 (PDT) hmm.. Can I to schedule some actions? I need something like a thread that always works and do something at custom time. I just can't understand how to start\stop it with cocoon. I don't know, maybe I should to use servlet, but how to start own servlets in cocoon?:) maybe there is exist true-way?;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[2.1] schedule some actions
hmm.. Can I to schedule some actions? I need something like a thread that always works and do something at custom time. I just can't understand how to start\stop it with cocoon. I don't know, maybe I should to use servlet, but how to start own servlets in cocoon?:) maybe there is exist true-way?;) -- View this message in context: http://www.nabble.com/-2.1--schedule-some-actions-tp16417868p16417868.html Sent from the Cocoon - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Redirect to GET, strange bug
[EMAIL PROTECTED] wrote:
FYI: Cocoon's redirects usually escape from the current processing.
The redirect is sent to the browser, but the request may not have
been processed. That does not appear to be what you need.
I don't quite understand what you mean here.
The Redirect from submitting a Form cannot be internal to Cocoon (or
any web engine).
Of course.
In fact I'm issuing a global, client-side redirect (no cocoon:
protocol and a true isGlobal argument to cocoon.redirectTo) and that
part works flawlessly, regardless of the errors I get in my logs. The
problem is, what is causing those errors?
Vadim Gritsenko wrote:
This redirect URL does not seem to be correct: should start with '?'
if passing continuation id as parameter or have '/' instead of '='
if passing continuation id in URL path.
We all know URLs can be pretty arbitrary in Cocoon... this is not even
what my url looks like, it was just an example.
Hm, what is this exit() method? I don't see it defined neither in
Cocoon 2.1 nor 2.2. To terminate script processing and send
redirect to browser you should be using suicide method.
AFAIK cocoon.exit() is the recommended way to call FOM_Cocoon.suicide()
It's mentioned here http://cocoon.apache.org/2.1/userdocs/flow/api.html#exit
(while suicide isn't) and its implementation is:
FOM_Cocoon.prototype.exit = function() {
FOM_Cocoon.suicide();
}
In fact, using FOM_Cocoon.suicide() yields the same results as
cocoon.exit(), that is, "ProcessingException: Attempted to process
incomplete pipeline".
Do you have any idea what's causing this message?
Who is attempting to process which incomplete pipeline? I'm issuing a
global, client-side redirect, and stopping the flow. Why is Cocoon
complaining?
Also, it is often a good idea to invalidate the form processing
continuation tree, to free up memory and--even if user manages to
submit the form again--he will receive 404.
Interesting. How do I do this?
Tobia
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Built-in properties available in the sitemap
On Apr 1, 2008, at 2:44 AM, Luca Morandini wrote: Vadim Gritsenko wrote: On Mar 28, 2008, at 2:07 PM, Luca Morandini wrote: Could some point me to the list of the properties available by default in the sitemap ? IIRC, in default setup, system properties + contents of all /META- INF/cocoon/properties/* of deployed blocks. Do you refer to the default Maven ones as "system properties" ? I meant java.lang.System.getProperties(). These usually include java version, vendor, classpath, user home, etc. What are 'maven properties'? Vadim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
Thanks Joerg...I was actually lurking this thread on the dev list to check on the progress. I'll check out the new code and report back here with the results. --- Joerg Heinicke <[EMAIL PROTECTED]> wrote: > On 27.03.2008 00:31, Joerg Heinicke wrote: > > >> Sure, here is the hierarchy from bottom to top. At this point, I ran > >> the test for about five > >> minutes (running longer would increase the percentage) and the > >> retained size of the one > >> ContinuationsManagerImpl object is 58% of the total. The > >> BufferedOutputStream is 50% of the > >> total, so the other 8% is consumed by the objects in between. > >> > >> org.apache.cocoon.util.BufferedOutputStream > >> secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment > >> env of > >> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector > >> > >> > >> redirector of org.apache.cocoon.components.flow.java.ContinuationContext > > > > What I was so much concerned about here was the fact of storing the > > whole environment in the continuation, especially since we have this > > non-flushing BufferedOutputStream at the end. Is there any point in > > storing the environment? Do we get anything useful out of it after > > continueing the continuation? > > I committed a fix [1] that limits the data that is stored with the > ContinuationContext which at least removes the redirector and so the > BufferedOutputStream instances from the Continuation's memory footprint. > This should give you a big improvement if the BufferedOutputStream took > 50% of the memory for you. > > Joerg > > [1] http://svn.apache.org/viewvc?view=rev&revision=642694 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
connection pooling
Hello together! Is it better (inside production environment) to use cocoon-configured connection pool or better to use the pooling mechanisms from App-server/Servlet-container via JNDI (in my case it is Tomcat). And where should one configure the pool inside testing-environment? Jetty? Is there some general docu available for cocoon 2.2? With best regards, Patrick Heiden -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
Just ran a very simple test using the changes from revision 642694 and had unusual results. Byte arrays, and consequently the BufferedOutputStream still took up large amounts of retained space in the total memory usage. So, this didn't change. However, the memory did not clean up neatly like it did before...after about 10 minutes. Before, I would do, say 1000 samples, and total Tomcat memory would balloon to a point. Then I'd wait 10 minutes and would observe the byte array data cleaning up in the profiler with total Tomcat memory staying the same. After that, I'd run another 1000 samples and the total Tomcat memory would not increase again until hitting around the 1000th sample and the cycle would repeat. With these new changes, the memory cleaned up a little bit, but not nearly as much as before. And the total memory would start increasing before I hit the control sample size. The BufferedOutputStream path appears to be the same as well - flowing up to ContinuationsManagerImpl. Perhaps I'm doing something wrong? I did make this changes to version 2.1.10 NOT 2.1.11 since I haven't upgraded my site to the new version yet. --- footh <[EMAIL PROTECTED]> wrote: > Thanks Joerg...I was actually lurking this thread on the dev list to check on > the progress. > > I'll check out the new code and report back here with the results. > > > --- Joerg Heinicke <[EMAIL PROTECTED]> wrote: > > > On 27.03.2008 00:31, Joerg Heinicke wrote: > > > > >> Sure, here is the hierarchy from bottom to top. At this point, I ran > > >> the test for about five > > >> minutes (running longer would increase the percentage) and the > > >> retained size of the one > > >> ContinuationsManagerImpl object is 58% of the total. The > > >> BufferedOutputStream is 50% of the > > >> total, so the other 8% is consumed by the objects in between. > > >> > > >> org.apache.cocoon.util.BufferedOutputStream > > >> secureOutputStream of org.apache.cocoon.environment.http.HttpEnvironment > > >> env of > > >> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor$TreeProcessorRedirector > > >> > > >> > > >> redirector of org.apache.cocoon.components.flow.java.ContinuationContext > > > > > > What I was so much concerned about here was the fact of storing the > > > whole environment in the continuation, especially since we have this > > > non-flushing BufferedOutputStream at the end. Is there any point in > > > storing the environment? Do we get anything useful out of it after > > > continueing the continuation? > > > > I committed a fix [1] that limits the data that is stored with the > > ContinuationContext which at least removes the redirector and so the > > BufferedOutputStream instances from the Continuation's memory footprint. > > This should give you a big improvement if the BufferedOutputStream took > > 50% of the memory for you. > > > > Joerg > > > > [1] http://svn.apache.org/viewvc?view=rev&revision=642694 > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > You rock. That's why Blockbuster's offering you one month of Blockbuster > Total Access, No Cost. > > http://tc.deals.yahoo.com/tc/blockbuster/text5.com > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost. http://tc.deals.yahoo.com/tc/blockbuster/text5.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Javaflow - major memory issue
On 01.04.2008 18:52, footh wrote: Just ran a very simple test using the changes from revision 642694 and had unusual results. Byte arrays, and consequently the BufferedOutputStream still took up large amounts of retained space in the total memory usage. So, this didn't change. However, the memory did not clean up neatly like it did before...after about 10 minutes. Before, I would do, say 1000 samples, and total Tomcat memory would balloon to a point. Then I'd wait 10 minutes and would observe the byte array data cleaning up in the profiler with total Tomcat memory staying the same. After that, I'd run another 1000 samples and the total Tomcat memory would not increase again until hitting around the 1000th sample and the cycle would repeat. With these new changes, the memory cleaned up a little bit, but not nearly as much as before. And the total memory would start increasing before I hit the control sample size. The BufferedOutputStream path appears to be the same as well - flowing up to ContinuationsManagerImpl. Perhaps I'm doing something wrong? I did make this changes to version 2.1.10 NOT 2.1.11 since I haven't upgraded my site to the new version yet. That's no good news :( And I can't see how this should be possible. Which changes exactly did you apply? Only rev 642694 [1]? The actual two files changed are ContinuationContext (added method onSuspend()) and AbstractContinuable (calling context.onSuspend() right before Continuation.suspend()). The method only nulls out some values, so I can't see how this should have worsen the situation. Both files had not changed between 2.1.10 and 2.1.11, so this can neither be a reason. Second, this was only the first approach. After Torsten's review I did a more "brave" approach setting the complete context to null before the continuation gets suspended [2]. Here I reverted the above 2 changes to AbstractContiuable and ContinuationsContext. The fix went into Continuation (storing functionName and setting context to null in suspend()) and JavaInterpreter (instantiating Continuation with functionName and retrieving it from there later on). Again I can't see how this should have worsen the situation. Both files had again not changed since 2.1.10. Then in order to fix COCOON-2109 [3] I applied another fix [4]. If that one helps you at all pretty much depends on whether you access old continuations or not (when using a wizard you not only go forward along the expected path (page 1, page 2, etc.) but also go back). The last important fix is for synchronization issues in ContinuationsManagerImpl [5]. This definitely has some impact, it's usually unlikely that fixing synchronization improves performance. If you don't have this fix I can imagine that the situation is as bad as you describe it for the following reasons: If something creates a new continuation while the clean up thread for removing expired continuations is active it kicks the latter one with a ConcurrentModificationException - and the clean up just stops. This would mean though that it was just bad luck in your new test. I don't know how exactly you profiled your system. You should definitely NOT run on debug log level. I fixed the synchronization issues in favor of the debug log level: There are no longer two sets maintained but the second set (which was for debugging purposes only) gets recreated "on demand", i.e. debug log level, which locks the manager for that time. But it should improve the overall situation though. Joerg [1] http://svn.apache.org/viewvc?view=rev&revision=642694 [2] http://svn.apache.org/viewvc?view=rev&revision=642756 [3] https://issues.apache.org/jira/browse/COCOON-2109 [4] http://svn.apache.org/viewvc?view=rev&revision=642843 [5] http://svn.apache.org/viewvc?view=rev&revision=643295 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [2.2] Built-in properties available in the sitemap
Vadim Gritsenko wrote: On Apr 1, 2008, at 2:44 AM, Luca Morandini wrote: Vadim Gritsenko wrote: On Mar 28, 2008, at 2:07 PM, Luca Morandini wrote: Could some point me to the list of the properties available by default in the sitemap ? IIRC, in default setup, system properties + contents of all /META-INF/cocoon/properties/* of deployed blocks. Do you refer to the default Maven ones as "system properties" ? I meant java.lang.System.getProperties(). These usually include java version, vendor, classpath, user home, etc. What are 'maven properties'? Maven's own properties ? ;) http://docs.codehaus.org/display/MAVENUSER/MavenPropertiesGuide IIUC, Cocoon doesn't add properties of its own (bar the ones defined in blocks). Hence we can just put a reference to Maven properties, an example of how to use them in the sitemap and we're done, right ? Regards, Luca Morandini www.lucamorandini.it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
