Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Is there anyway to control when and how the Terracotta client creates its MBeanServer?

I ask because when running a web application in the Tomcat 5.5 container configured as a Terracotta DSO client, the application starts up normally except that app code that checks some Tomcat Mbeans is unable to find them.

Our web app registers its own MBeans with the JmxMBeanServer obtained in the "normal" way via, ManagementFactory.getPlatformMBeanServer().

Terracotta DSO though creates it's own MBean Server before our application.

When registering its MBeans, Tomcat uses MBeanServerFacotry.findMBeanServer() to get the first MBean server in the staticl list - in this case, the first one is the one created by Terracotta. There's no way I can see to force Tomcat to register with the MBeanServer instance it normally uses.

I'm not the authority on this subject, but it looks like the only control on the creation of the mbean server in the terracotta code happens in L1Management.shouldCreateMBeanServer() (at the bottom of this link): http://svn.terracotta.org/fisheye/browse/~raw,r=1164/Terracotta/dso/trunk/code/base/dso-l1/src/com/tc/management/L1Management.java

Given that code, I think the only way to force us to not create a server would be to run on 1.5+ JDK and to not define the "com.sun.management.jmxremote" system property. Those might not be acceptable constraints, but it looks like all one could do without changing the terracotta code (which if you want to do we can help you through)

I suspect there is a bug I should create for this, but I'd like to look at the tomcat code before opening it. Can you point me to the tomcat code that assumes the first mbean server MBeanServerFacotry.findMBeanServer() is the platform default?

Tomcat uses the jakarta modeler package. The relevant code is in its Registry.getMBeanServer() implementation.

It's hard to say who - if anyone - is really at fault here. As a quick workaround I just use that same code and am loading our Mbeans into the same mbean server that Tomcat is (Terracotta's).

Does this adversely affect performance in anyway?

I can't think of why there would be a performance issue with this, but maybe I'm missing something. Is there something in particular that prompted that question?

I opened http://jira.terracotta.org/jira/browse/CDV-260 to track this issue

I notice that when I have Tomcat setup as a Terracotta client the startup time is significantly longer. Starting our Tomcat-hosted application without Terracotta takes about 50 seconds or so.

Once I have it configured as a Terracotta client it takes about 100 seconds to startup.

In the Terracotta's config.xml file I only include a single instrumented class and exclude all of Tomcat's classes.

Keeping the scope of the instrumentation very narrow is the right thing to do in terms of decreasing startup time. 2x startup-time sounds a bit high with the instrumentation that you have described (compared to other implementations) - out of curiosity what version of Terracotta and can u attach your tc-config.xml...? Apart from that, we have a theory around some recent implementation changes around how we instrument, which might have a bit of an impact for apps that load a large number of classes - perhaps you could additionally attach a thread dump as Tomcat is starting up, which will help confirm that hypothesis..?

Thanks.

Below is the config file that the terracotta server and the clients are both referencing. The instrumented package only contains 3 stub classes with just a few strings for state. Only a single instance of the root class is created. The root is a HashMap with String as a key and one of the aforementioned "model" classes as a value.

Code:

 <?xml version="1.0" encoding="UTF-8"?>
 
 <tc:tc-config xmlns:tc="http://www.terracotta.org/config"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://www.terracotta.org/schema/terracotta-3.xsd">
 
   <servers>
     <server host="winter">
       <data>%(user.home)/terracotta/server-data</data>
       <logs>%(user.home)/terracotta/server-logs</logs>
     </server>
   </servers>
 
   <clients>
     <logs>%(user.home)/terracotta/client-logs</logs>
   </clients>
 
   <application>
     <dso>
       <instrumented-classes>
         <include>
           <class-expression>com.example.data.model.*</class-expression>
         </include>
         
         <exclude>org.apache.coyote..*</exclude>
         <exclude>org.apache.catalina..*</exclude>
         <exclude>org.apache.jasper..*</exclude>
         <exclude>org.apache.tomcat..*</exclude>
         
       </instrumented-classes>
       
       <locks> 
         <autolock>
           <lock-level>write</lock-level>
           <method-expression>* *..*.*(..)</method-expression>
         </autolock> 
       </locks>
       
       <roots>
         <root>
           <field-name>com.example.service.queue</field-name>
           <root-name>queue</root-name>
         </root>
       </roots>
 
     </dso>
   </application>
 </tc:tc-config>

I created JIRA https://jira.terracotta.org/jira/browse/CDV-265 to track the startup time degradation issue...If you could attach a thread dump to this JIRa, we could look at the specifics of the additional 50s... Thanks.

This is likely caused by auto-locking everything in the boot-jar. Try changing the auto-lock expression to not be everything, remove and rebuild the boot-jar, and try again.

Tim Eck wrote:

.... the creation of the mbean server in the terracotta code happens in L1Management.shouldCreateMBeanServer() .... I suspect there is a bug I should create for this ....

A bug has been created for this: CDV-260

It should be fixed for the 2.4 release.