> > > >>>> Ard Schrijvers escribió: > >>>>> We are using many continuations in our projects, implying > >>>> have load on memory use (apparantly continuations can be very > >>>> large in memory..?). > >>>>> > >>>>> Since in a deployed environment we want to have some idea > >>>> about the number of continuations out there, I have added > >>>> this to the StatusGenerator, in the same manner as for the > >>>> StoreJanitor is done. > >>>>> > >>>>> Also added to the "Memory" group is the max memory > >>>> available (Runtime.getRuntime().maxMemory()) > >>>>> > >>>>> Can I send in a patch to have it standard in the > StatusGenerator? > >>>>> > >>>> hi Ard, > >>>> > >>>> It is a nice enhancement. I will like to see it in cocoon. ;-) > >>>> > >>> > >>> Shall I send in a patch before trying to add status of any > >> database connection pools, or first try to add this one as well? > >> > >> Wouldn't a JMX bean be of much more value? > >> > > > > Yes it would be very nice to have, but does it not imply that all > > interfaces should be adjusted to what they expose? > > Well, normally you will have different interfaces for a MBeans > (management) than for your components (system design/architecture) > because the MBean interface reflects the manageability of a > implementation whereas the component interface reflects a > design aspect > of a system part. As an example take the Store interface. For a > DiskStore you'd probably have different manageability > requirements than > for a MemoryStore. But both implement the same design interface which > has method you really don't want to see on a JMX-Console (i.e. > store(key,value)) because they don't make much sense there. > > There are tools to automatically create MBeans out of components but > those I personally never had good results with them because of the > reasons I explained above. > > > Is it not a little out of scope at the moment? > > What scope are you referring to?
The scope about my knowledge of MBeans and that I thought it would mean adjusting many interfaces, but as you explained above, this is not necessary. > > > And does it not require java 1.5..? > > No, JMX is available back to Java 1.3 IIRC (i.e. MX4J). > > For 2.1.X I remember having made JMX support available but > could find it > anymore (just the jetty config in > tools/jetty/conf/main-jmx.xml). Has it > been removed? I found you committing JMXUtils to the trunk but can not find it back in the trunk: http://mail-archives.apache.org/mod_mbox/cocoon-cvs/200512.mbox/[EMAIL PROTECTED] > > For 2.2 with Spring you almost get JMX for free. For now, as Antonio suggested, I will send in my patch with respect to the continuations. I hope to have time in short notice to explore the MBeans more. Regards Ard >
