Tuesday, March 13, 2007

JBossWeb, Tomcat and Apache...

JBossWeb is said to be faster when it comes to secure connections. However, my two-days-testing didn't show any significant difference on how it handles regular http connections.

The first day was spend on testing Tomcat against 1500 http connections, and Tomcat reasonably handled the connections. JBossWeb did the same job with quite less CPU usage, which was not really impressive (around 2 percent CPU usage difference, and no significant performance gain). Both Tomcat and JBossWeb crapped out when bombarded with too many connections on the same hardware. In this test JBoss crashed with a running out of native threads errors message, and Tomcat did not throw any exception but it did not respond to any other request.

The second day was spend on configuring Apache to accept http requests, parse them into AJP1.3, and redirecting parsed requests to Tomcat. This test showed a better performance improvement, but still it was not impressive enough (around 3 percent performance gain) for us.

These tests had been run with a test client we have for our online game engine, and the results do not generally stand for a reasonable comparision of these technologies. I still need to see if I can tweak them so that I can get a better performance, in terms of CPU usage or speed, in our game engine.

Thursday, March 8, 2007

Java 7

I am nervous to see where this is going...

Wednesday, March 7, 2007

JBoss JMX and remote monitoring

Java 5 comes with a nice monitoring console, JConsole, which is able to connect localy/remotely to a Java program and tell you basic stuffs about the program. This will require an application to start with a -Dcom.sun.management.jmxremote parameter. How easy! However, this parameter forces the JVM to start an MBeanServer. Well, so far so good, but I tried to use this with JBoss and boom! The JBoss didn't start up successfully. Actually, It was our application that fell apart. Why?

Our application uses Spring to manage its in-container beans. We also use MBeanProxyFactory to get a reference to the MBeans defined within JBoss deployment descriptors. The problem here is that MBeanProxyFactory looks up in the first MBeanServer it finds and ignores the others. It's more likely that this MBeanServer is not the JBoss MBeanServer one when JBoss is started with the monitoring paramter. 

Today I dug up the whole internet for a solution, and it seriously took me a long time to find a solution. First, I started to define a server connection factory but I couldn't find the right service url for the JBoss JMX. The more I tried the less I found :( However, I happened to see a post in spring forums on a similar problem, and it turned out that JBoss has a utility class that gives you access to its MBeanServer. So, the solution for now is to use a base bean for all other proxied mbeans, and set the server:

 

<bean id="baseMBeanProxyFactory" class="org.springframework.jmx.access.MBeanProxyFactoryBean" abstract="true">
<property name="server">
<bean class="org.jboss.mx.util.MBeanServerLocator" factory-method="locateJBoss"/>
</property>
</bean>

 


This works fine, but it would be easier to specify which MBeanServer should be queried for an MBean lookup. I have requested Spring people to add a new property to the MBeanProxyFactory.


 


ps. For the ones who are still wondering what the JBoss MBeanServer is called, it is 'jboss'.