Re: W3C XML Processing working group
On Mon, 2 Jan 2006, Gianugo Rabellino wrote: It strikes me how, in early 2006, people are still thinking that another XML domain-specific language is the way to go. We are all learning the hard way how the XML verbiage has been useless and, to some extents, detrimental: from Jelly onwards (and yes, I deserve some Hear hear ! Dw.
Re: Cocoon 2.1.7 hang
* Ralph Goers: OK. I ran some basic tests on one of my machines. Just for basic info it is a P4 2.5 GHz with 1 GB of memory running RHEL 3. The only thing I did was set up JMeter to login to the portal as user cocoon. In all the tests the computer was maxed at 100% cpu. Before the change: 5 threads login repeated 10 times: Avg 3.4 seconds, Max 27 seconds. 10 threads login repeaded 5 times: Avg 6.760 seconds, Max 22 seconds After the change: 5 threads login repeated 10 times: Avg 1.3 seconds, Max 2.6 seconds 5 threads login repeated 20 times: Avg 1.2 seconds, Max 2.5 seconds 10 threads login repeated 5 times: Avg 2.4 seconds, Max 10 seconds. 10 threads login repeated 10 times: Avg 2.1 seconds, Max 13 seconds. The change has been checked into 2.1. I'll test it on 2.2 and check it in also. Hello Ralph, Happy new year! Your change seems very interesting, thank you very much. However, I have a more radical solution to this portal login problem, see: Speedup portal loading http://issues.apache.org/jira/browse/COCOON-1709 Also requires: Allow CopletInstanceDataManager to be cloneable http://issues.apache.org/jira/browse/COCOON-1708 -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
[2.2] Problems with JMX Support and Tomcat
I'm trying to get the latest 2.2 running in a standard tomcat 5.5.12 With the default webapp, the following class can't be found: org.mortbay.log.LogFactory So it seems that the jetty-jmx-5.1.8.jar does not contain all required classes. Copying also jetty-5.1.8.jar into WEB-INF/lib of course solves this problem. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Stefano Mazzocchi wrote: late as well, +1 +1, welcome Jean-Baptiste !
RE: Happy New Year!, Re: Merry Christmas
Happy new year! May 2006 finally bring us the long awaited 2.2 and much more! Are you saying 2.2 will be released May 2006? ;-) Arje
RE: [RT] Simplifying component handling
... What's the contract for the auto-wiring? Just assuming ClassA and ClassB have public static fields called ROLE? Sounds somewhat strange. No, the contract would be to search for a component which is registered using the ClassA as the role name. Actually ClassA and ClassB are two interfaces. Hmm, so what do you do about the hints? Often enough, I see o.a.c.something.SomeInterface/hint (like o.a.c.caching.Cache/EventAware) in cocoon. This wouldn't work with your assumptions of always using FQCNs as service names. max
Re: [RT] Simplifying component handling
Max Pfingsthorn wrote: ... What's the contract for the auto-wiring? Just assuming ClassA and ClassB have public static fields called ROLE? Sounds somewhat strange. No, the contract would be to search for a component which is registered using the ClassA as the role name. Actually ClassA and ClassB are two interfaces. Hmm, so what do you do about the hints? Often enough, I see o.a.c.something.SomeInterface/hint (like o.a.c.caching.Cache/EventAware) in cocoon. This wouldn't work with your assumptions of always using FQCNs as service names. Right. Most times these are dynamic parts, for example pipeline processing, in this case, you can still use Serviceable. But as we can't get any consensus on any changes, I think we should drop the topic and wait until we have moved away from Avalon completly. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Problems with JMX Support and Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 2 Jan 2006, Carsten Ziegeler wrote: Date: Mon, 02 Jan 2006 11:00:32 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Problems with JMX Support and Tomcat I'm trying to get the latest 2.2 running in a standard tomcat 5.5.12 With the default webapp, the following class can't be found: org.mortbay.log.LogFactory So it seems that the jetty-jmx-5.1.8.jar does not contain all required classes. Copying also jetty-5.1.8.jar into WEB-INF/lib of course solves this problem. Hmm.. maybe we either need our own JMX ModelMBean base class, witching to commons modeler, or copy from jetty whats needed (as once Sylvain suggested)? - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDuUcuLNdJvZjjVZARAmQ9AJ9+emoxl4mH41w41F2OtdOzdf7gsgCfcbTb Ci2oXHEywc3tLQW7YPGAVOE= =c61x -END PGP SIGNATURE-
Re: [2.2] Problems with JMX Support and Tomcat
Giacomo Pati wrote: On Mon, 2 Jan 2006, Carsten Ziegeler wrote: Date: Mon, 02 Jan 2006 11:00:32 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: Cocoon-Dev dev@cocoon.apache.org Subject: [2.2] Problems with JMX Support and Tomcat I'm trying to get the latest 2.2 running in a standard tomcat 5.5.12 With the default webapp, the following class can't be found: org.mortbay.log.LogFactory So it seems that the jetty-jmx-5.1.8.jar does not contain all required classes. Copying also jetty-5.1.8.jar into WEB-INF/lib of course solves this problem. Hmm.. maybe we either need our own JMX ModelMBean base class, witching to commons modeler, or copy from jetty whats needed (as once Sylvain suggested)? witching? - LOL I can come up with a list of required classes for jetty's jmx support tomorrow. Perhaps it's only the LogFactory. If only some classes are missing, we can repackage them, but as soon as this gets more complex we can either ask the jetty guys to provide different packages or switch to something different. What about Spring? I don't know much about it but I think Spring has some jmx support as well. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: W3C XML Processing working group
Gianugo Rabellino wrote: On 1/1/06, Michael Wechner [EMAIL PROTECTED] wrote: I'm not that much interested into yet another DSL expressed in XML, and I don't feel alone at all. Actually I'd much rather drift towards a programmatic pipeline API. what do you mean by a programmatic pipeline API? Uhm, part of the story is on my blog[1] but I'll give you an excerpt and save you a click ;-) It strikes me how, in early 2006, people are still thinking that another XML domain-specific language is the way to go. We are all learning the hard way how the XML verbiage has been useless and, to some extents, detrimental: from Jelly onwards (and yes, I deserve some blame as well) it became crystal clear how programming in XML leads to unmaintainable, opaque and unreadable stuff. The fake myth that XML can be written by grandmas, coupled with the low entry barrier in creating new languages (no compiler's compiler needed, yay!) has produced a plethora of half-baked solutions that just don't get how grandmas aren't going to code anyway, while angle brackets get heavily in the way of anyone who understands even just the basics of programming. Now, don't get me wrong: XML is great when properly used. That is, data (some grandmas might even write data at a certain point), information interchange and tool-oriented stuff. But please, pretty please, when talking about programming (that is, data processing and component connections), take those angle brackets out of the picture and give us the power of effective syntaxes. There might be some exceptions: transformation languages such as XSLT, having to deal with XML all the way, are consistently expressed in XML, but that's not the case for XML pipelines. Pipelines are about connecting, chaining, concatenating: there's nothing there that needs XML to be expressed. It's meta-XML, in a way, a side order to the main XML dish. What we (well, I at least) need are APIs: a standard and effective way to tie XML processing components together so that data manipulation can work in a multistage environment. We then need some machinery around it that provides transparent adapters between the different XML processing world (SAX, DOM, StAX) and we could definitely use some services (logging, management, security) on top of it. But we don't need XML for that. We might want to use it at a later point, as a sort of wrapper around the pipeline language if, and only if, there is a clear need for tooling that could use a well-established and easy to parse data format, but please save our aging eyes and our carpal tunnels from angle brackets whenever possible. I agree that a programmatic pipeline API would be a great thing to have, but please don't underestimate the usefulness and appeal of an XML format. I think that those reading this mailing list don't get to hear the success stories of how things like Cocoon's XML sitemap format actually *do* lower the bar and allow less-technical people or those more comfortable with markup to implement Cocoon-based sites. It's not a myth, there actually *are* people out there who aren't programmers and aren't comfortable with Java or JS or other procedural code, but who are very good at XML markup (not just grandmas!), and the XML sitemap is ideal for these people. I know... I was one of them when I started using Cocoon and it's one of the main reasons I got hooked. So I'd say that the API you and others have suggested is a great idea, but having an XML wrapper/implementation of (a subset of) that API would be a must. Just because you wouldn't want to use it doesn't mean nobody would. Just my two cents. --Jason
Re: Cocoon 2.1.7 hang
I replied to that days ago in the issue (1709 I believe). In short, this is a good idea for sites (like mine) that only use anonymous users. However, the idea of permanantly caching millions of users profiles in memory is very scary and will be considered to be a memory leak by many people. So, I'm -1 on just checking that patch in as is. However, if there was a way to enable it for only anonymous users I'd be all for that. Ralph Jean-Baptiste Quenot wrote: * Ralph Goers: OK. I ran some basic tests on one of my machines. Just for basic info it is a P4 2.5 GHz with 1 GB of memory running RHEL 3. The only thing I did was set up JMeter to login to the portal as user cocoon. In all the tests the computer was maxed at 100% cpu. Before the change: 5 threads login repeated 10 times: Avg 3.4 seconds, Max 27 seconds. 10 threads login repeaded 5 times: Avg 6.760 seconds, Max 22 seconds After the change: 5 threads login repeated 10 times: Avg 1.3 seconds, Max 2.6 seconds 5 threads login repeated 20 times: Avg 1.2 seconds, Max 2.5 seconds 10 threads login repeated 5 times: Avg 2.4 seconds, Max 10 seconds. 10 threads login repeated 10 times: Avg 2.1 seconds, Max 13 seconds. The change has been checked into 2.1. I'll test it on 2.2 and check it in also. Hello Ralph, Happy new year! Your change seems very interesting, thank you very much. However, I have a more radical solution to this portal login problem, see: Speedup portal loading http://issues.apache.org/jira/browse/COCOON-1709 Also requires: Allow CopletInstanceDataManager to be cloneable http://issues.apache.org/jira/browse/COCOON-1708
Re: [RT] Simplifying component handling
That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Carsten Ziegeler wrote: But as we can't get any consensus on any changes, I think we should drop the topic and wait until we have moved away from Avalon completly. Carsten
Re: Cocoon 2.1.7 hang
* Ralph Goers: I replied to that days ago in the issue (1709 I believe). Sorry, I didn't notice your comment on JIRA, strangely. I will followup to your comment. -- Jean-Baptiste Quenot Systèmes d'Information ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.com/
[jira] Commented: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361536 ] Jean-Baptiste Quenot commented on COCOON-1709: -- I understand your concerns about scalability. However, your comment is only relevant when a lot of profiles are defined, eg profiles/copletdata/portal-0001.xml, profiles/copletdata/portal-0002.xml upto profiles/copletdata/portal-.xml. In our case, all users use the same profile: profiles/copletdata/portal.xml. However, I believe that in most cases, the profiles are loaded with a pipeline, and unfortunately SitemapSource.getURI() returns the URL with a query string like eg load-role-profile?user=user-1299, which will then produce a lot of copies in memory indeed, because we use source.getURI() as key and not the requested source itself. In our case, we use a source that returns the real file location, so that source.getURI() returns very few different results: portal-user-admin.xml, portal-role-public.xml, or portal.xml. Please find attached my portal configuration for profiles, and the UserRoleSource used for resolving them. Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, portal-config Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=all ] Jean-Baptiste Quenot updated COCOON-1709: - Attachment: portal-config Configuration of profiles location Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, portal-config Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] Simplifying component handling
On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
[jira] Updated: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=all ] Jean-Baptiste Quenot updated COCOON-1709: - Attachment: UserRoleSourceFactory.java Custom SourceFactory used to locate a profile, depending on role and user available in session context Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, UserRoleSourceFactory.java, portal-config Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] Simplifying component handling
This thread got me thinking about alternatives to dependency injection. The only credible alternative I can think of for Cocoon is a Service Locator. One of the things I liked about Avalon was its combination of dependency injection and service locator. This combination made sense for a general purpose framework. The drawback is that there is a great deal of complexity due to its use of interface injection. (probably the real reason Carsten started this thread) To simplify this all one need do is remove the interface injection. Once the injection is removed each component is responsible for constructing its self. The drawback of using a service locator is the dependency on the locator itself. Cocoon is a coherent framework that provides its own locator so this is a minimal stumbling block. There are two ways we could proceed using a service locator. One would be to add a static method to a SeviceManager implementation public static ServiceManager getServiceManager() The other would be to use constructor injection public MyComponent(ServiceManager m) No reflection, no tricks, no jumping through hoops and a simple contract. This also provides a way to move away from Avalon while providing the benefits of life-cycle management by allowing a component to request its parameters, disposer, etc. by creating other locators. I don't believe it would be to difficult to keep backwards compatibility using this technique and all future components will be greatly simplified. WDYT? Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
Re: [RT] Simplifying component handling
On Dec 30, 2005, at 4:05 PM, Berin Loritsch wrote: Seriously, I agree that writing less code is good, but not at the price of too black magic implying weaker contracts. Agreed. To achieve the goal of less code would require major overhauls of the entire system. Yes. I think Cocoon could be greatly simplified knowing what we know now. This would be a worthwhile endeavor but not one that should be undertaken at the cost of slowing advancement. Remember Netscape. Glen Ezkovich HardBop Consulting glen at hard-bop.com A Proverb for Paranoids: If they can get you asking the wrong questions, they don't have to worry about answers. - Thomas Pynchon Gravity's Rainbow
mvn compile for core block fails in 2.2 snapshot
Hi, I checked out the 2.2 source code and use 'mvn compile' to compile the source code and got the following error:[INFO] Compilation failureC:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\fl ow\ContinuationsManagerImplMBean.java:[20,28] package org.mortbay.util.jmx doesnot existC:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\flow\ContinuationsManagerImplMBean.java:[25,24] package javax.management does notexistC:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\flow\ContinuationsManagerImplMBean.java:[26,24] package javax.management does notexist C:\apache\cocoon.home\svn\trunk\core\..\src\java\org\apache\cocoon\components\flow\ContinuationsManagerImplMBean.java:[35,8] cannot resolve symbolsymbol : class ModelMBeanImpllocation: class org.apache.cocoon.components.flow.ContinuationsManagerImplMBean It seems the dependency set is not well maintained.Regards,Rice
[jira] Commented: (COCOON-1709) Speedup portal loading
[ http://issues.apache.org/jira/browse/COCOON-1709?page=comments#action_12361572 ] Carsten Ziegeler commented on COCOON-1709: -- I agree with Ralph - we have a lot of portals with hundreds and thousands of users - each one having an own profile. So why not providing a simple boolean switch? Speedup portal loading -- Key: COCOON-1709 URL: http://issues.apache.org/jira/browse/COCOON-1709 Project: Cocoon Type: Improvement Components: Blocks: Portal Versions: 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Attachments: 20051212-portal-MapProfileLS, 20051222-MapProfileLS.java, 20051222-MapProfileLS.java, UserRoleSourceFactory.java, portal-config Portal loads user profiles (when using eg AuthenticationProfileManager) with Castor every time the user logs in and this is very slow. This patch allows to cache the result for further invocations. However the coplet instance profiles are handled in a special way, after being obtained by mapping the CopletInstanceDataManager they are cloned to ensure that every user gets its own copy of the coplets. Thus this bug depends on http://issues.apache.org/jira/browse/COCOON-1708 Allow CopletInstanceDataManager to be cloneable. An improvement would be to store cached objects in Cocoon Store, the provided patch currently uses a simple HashMap to store profiles. Note that the key of the object is the URI returned by the source. This is important because different values of uri in resolver.resolveURI(uri) could return the same source, ie source.getURI() could be the same, so only different objects are stored in the Map. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] Simplifying component handling
Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Problems with JMX Support and Tomcat
Carsten Ziegeler wrote: I can come up with a list of required classes for jetty's jmx support tomorrow. Only the log package from the jetty jar is required, so rebundling shouldn't be that hard. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] Simplifying component handling
Le 3 janv. 06, à 08:11, Carsten Ziegeler a écrit : ...So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility... I'm +1 on this change, as you say it maintains compatibility, and it can simplify component writing. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon 2.1.7 hang
Ralph Goers wrote: OK. I ran some basic tests on one of my machines. Just for basic info it is a P4 2.5 GHz with 1 GB of memory running RHEL 3. The only thing I did was set up JMeter to login to the portal as user cocoon. In all the tests the computer was maxed at 100% cpu. Before the change: 5 threads login repeated 10 times: Avg 3.4 seconds, Max 27 seconds. 10 threads login repeaded 5 times: Avg 6.760 seconds, Max 22 seconds After the change: 5 threads login repeated 10 times: Avg 1.3 seconds, Max 2.6 seconds 5 threads login repeated 20 times: Avg 1.2 seconds, Max 2.5 seconds 10 threads login repeated 5 times: Avg 2.4 seconds, Max 10 seconds. 10 threads login repeated 10 times: Avg 2.1 seconds, Max 13 seconds. The change has been checked into 2.1. I'll test it on 2.2 and check it in also. Did you use in both tests the source from 2.1.8? I'm just curious if the changes I did to the CastorConverter from 2.1.7 to 2.1.8 are improving performance as well. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Problems with JMX Support and Tomcat
This strikes me as being kind of bad. So when we do maven builds we will have to build this dependency and publish it? Is there any way to get the Jetty folks to package this for us to use? Carsten Ziegeler wrote: Carsten Ziegeler wrote: I can come up with a list of required classes for jetty's jmx support tomorrow. Only the log package from the jetty jar is required, so rebundling shouldn't be that hard. Carsten
Re: [RT] Simplifying component handling
--- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! -- Reinhard ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Cocoon 2.1.7 hang
I used the latest source for both 2.1 and trunk. Carsten Ziegeler wrote: Ralph Goers wrote: OK. I ran some basic tests on one of my machines. Just for basic info it is a P4 2.5 GHz with 1 GB of memory running RHEL 3. The only thing I did was set up JMeter to login to the portal as user cocoon. In all the tests the computer was maxed at 100% cpu. Before the change: 5 threads login repeated 10 times: Avg 3.4 seconds, Max 27 seconds. 10 threads login repeaded 5 times: Avg 6.760 seconds, Max 22 seconds After the change: 5 threads login repeated 10 times: Avg 1.3 seconds, Max 2.6 seconds 5 threads login repeated 20 times: Avg 1.2 seconds, Max 2.5 seconds 10 threads login repeated 5 times: Avg 2.4 seconds, Max 10 seconds. 10 threads login repeated 10 times: Avg 2.1 seconds, Max 13 seconds. The change has been checked into 2.1. I'll test it on 2.2 and check it in also. Did you use in both tests the source from 2.1.8? I'm just curious if the changes I did to the CastorConverter from 2.1.7 to 2.1.8 are improving performance as well. Carsten
Re: [RT] Simplifying component handling
Reinhard Poetz wrote: --- Carsten Ziegeler [EMAIL PROTECTED] schrieb: Gianugo Rabellino wrote: On 1/2/06, Ralph Goers [EMAIL PROTECTED] wrote: That seems to be a catch-22. How do you move away from Avalon without making these kind of changes? Good question - I think noone is able to answer that one. Honestly, I don't see how anything in the 2.x series could move away from Avalon. Too much refactoring needed, too many issues on the table. Yeah, and I really don't understand this - I (and others) propose small but simple steps to a) improve using Cocoon and b) provide a smooth migration path. But even if these proposals do not include heavy refactoring and do not come with problems, people are blocking it and always point to the we need a rewrite. Then if people are suggestion, let's rewrite, the same people (and others) complain that that is currently not an option. So in the end we are doomed. So I'm coming back to my idea, is anyone against adding constructor injection to ECM++ or at least make it pluggable so I can add it for my own projects? The change adds only a feature while maintaining 100% compatibility. Without having time to understand in depth what you guys are talking about, I'd say that we should not block any features that don't introduce any backwards incompatibilities. If people disagree here, I would be very intersted in their reasons ... So +1 for your enhancements Carsten! Even more - Gianugo makes some valid points about the future. However, at this point, we cannot prove that his opinion is correct. So in my view, we should be taking multiple paths until one shows up to be the clear winner. So, I'd say, Carsten, get on with improving 2.2 to address the issues people have mentioned, and others, get on with prototyping a new implementation of Cocoon. If/when that new implementation comes along, we can see if it can be redone as a refactoring rather than a rewrite. Until then, let's move on on all fronts. We stand a better chance of winning that way. Regards, Upayavira, who's been away for a few days and hasn't read the full thread
