Costin Manolache wrote:
I have to disagree with any statement like this - nobody can decide that his
use case is the 'main' use case for tomcat.
Yes, tomcat is used in a lot of production environments where speed
and manageability
are important. But it is also used by developers ( and I suspect for
each production site
you have few dozen developer instances ), it is used in IDEs like
eclipse/idea/etc.
Tomcat is also used to deploy large number of very small apps, or
small number of large apps, or small set of small apps :-)
Not sure what is the plan for commons-modeler, I think it is worth to
bring it back to tomcat or fork a separate implementation, not using
model mbeans and simplifying the model.
I think JMX is a great tool, and is essential to support it - but
there are ways to do it
without bloat, and it's a valid target for optimizations.
More power to such efforts as well.
I just see performance/scalability, management functionality,
robustness, spec compliance, etc, as higher priorities.
If there is time and energy, I'd love see to all redundant MBeanInfo
objects eliminated such that a single instance was used in all cases
where the MBeanInfo is identical. There certainly is no point to having
such a see of small, long-lived, redundant data objects cluttering up
the heap.
--
Jess Holle
On 4/25/06, Jess Holle <[EMAIL PROTECTED]> wrote:
Remy Maucherat wrote:
Abhi Karmos wrote:
Has anybody looked in the code where the DescriptorSupport class is
used? 22 thousand of these things is simply absurd. Nearly 100
thousand DescriptorSupport.ValueHolder objects is even crazier. My
guess is that the HashMap usage is related to the DescriptorSupport.
It is completely irrelevant compared to the memory usage of a single
"modern" web application, and at the same time it provides a useful
monitoring feature without being intrusive coding wise. Sure, we could
use standard MBeans, but the code would then be a mess. I don't
understand the point of bothering with this sort of stuff when there's
so little benefit.
Despite my tone in my previous e-mail on this thread, I tend to agree
with Remy that the Tomcat folk have bigger fish to fry. An extra 10MB
of overhead is not the top priority for most Tomcat users.
Even without using standard MBeans I could certainly see dynamic MBeans
with per-target-object-class caching eliminating most of this additional
memory footprint. Modeled MBeans are likely as capable of this as any
other dynamic MBeans -- and if not that would be a reason not to use
them in *future* projects. [Commons "Dynamic" anyone?]
All the same, the MBeans generally do what's needful in Tomcat and I'd
thus hate to see any "cleanup" in this area take precendence over "real"
stuff.
If you want the smallest web container in terms of memory usage or
size, I think you should not be using Tomcat. Tomcat is more geared
towards speed, GC friendliness and feature completeness than memory
usage.
Agreed.
I notice that many of the Tomcat MBeans actually provide fairly useful
attribute and MBean descriptions. I also notice a good number of MBeans
with no MBean-level description, however. Same for operations,
operation parameter names and operation parameter descriptions. Fixing
this seems like a higher priority than introducing MBean
descriptor/MBeanInfo sharing at this point.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
