Guillaume Nodet's blog

I have spent some time profiling ServiceMix a bit, and particularly the WSDL-First example from the distribution. Here are the results while running a SOAP UI load tests on the example from the 3.1 distribution and the upcoming 3.1.1 distribution: Version, min, max, avg, last, cnt, tps, bytes, bps, err SMX 3.1, 9, 234, 20.64, 14, 57724, 484.43, 19106644, 159450, 0 SMX 3.1.1, 5, 204, 16.75, 14, 71065, 596.99, 23522515, 196095, 0 The most interesting number is the tps (transaction per seconds) absolute number: roughly 600 transactions per seconds sounds like a reasonable number (this small tests were running on my laptop without any particular tuning on the JVM or ServiceMix configuration) ! The other one is the tpc increase between 3.1 and 3.1.1: 595.99 / 484.43 = 1.2324 which means this sample performances for this sample has been boosted by 23 percents !

For those who don't know all of Maven 's features, I will show how to leverage maven at built-time to easily share run-time properties between service units in ServiceMix . Let's say that you expose a few services over HTTP/SOAP using servicemix-http . If you are building several service assemblies, you will end up having several files containing: <http:endpoint service="test:MyConsumerService" endpoint="myConsumer" role="consumer" locationURI="http://0.0.0.0:8192/Service/" soap="true" soapVersion="1.1" /> You will certainly want all your services to be exposed on the same port, so it can become a bit tedious if you need to change them all, or if you need to change between different work environments (test, production, etc...). When working with several service assemblies at the same time, I would recommend to use a hierachical organiz...

I have just fixed a small bug in ServiceMix (SM-865) and this makes ServiceMix a *very* lightweight ESB. The bare minimum dependencies to run the following example are: servicemix-core servicemix-jbi servicemix-services backport-util-concurrent spring xbean-spring The example I ran is very simple, and of course dependencies need to be added depending on the JBI components you use. Anyway, here is the servicemix.xml file: <beans xmlns:sm="http://servicemix.apache.org/config/1.0" xmlns:test="urn:test"> <sm:container id="jbi" embedded="true"> <sm:activationSpecs> <sm:activationSpec service="test:echo"> <sm:component> <bean class="org.apache.servicemix.components.util.EchoComponent" /> </sm:component> </sm:activationSpec> </sm:activationSpecs> </sm:container> <sm:client id="client" con...

Woohooo ! ServiceMix 3.1 has just been released officially. This is a very important version with tons of new features, enhancements and bug fixes.

Dan Diephouse just blogged about the announcement of a public review of a JMS SOAP binding and IRI scheme from BEA, IBM, Sonic and Tibco. This is a great news for JMS/SOAP interoperability ! He mentioned that the content-type header has a limited value because of the lack of support for very large messages in JMS. While this may be true for some providers, ActiveMQ provides such a feature . Also, I'd like to mention I would have been very happy to have a JMS Binding for non-SOAP WSDLs, like the WSDL2 HTTP Binding. I think it would be even more useful ! Anyway, hopefully ServiceMix will have support for the spec soon ...

Jencks 2.0 has been released. This is a major release because there are lots of incompatibilities, but the main point has been to upgrade to Geronimo 1.2 Transaction Manager, which leads to a much simpler configuration. The release also includes the ActiveMQ Pool from my previous blog entry.

Over the past weeks, I spend some times load testing ServiceMix and ActiveMQ . I discovered two things: * ActiveMQ broker is currently single threaded for a given JMS connection. The main effect is that if you send messages from several threads on the same connection, all threads will be processing sequentially (well, not exactly, but they will all be processed by a single thread on the broker side). * ActiveMQ Resource Adapter does not pool sessions and producers: this means that sending a single message with Jencks using the JMS best practices in a J2EE environment (create a connection, create a session, create a producer, send, close all) will take three consecutive roundtrips to the JMS broker and is very CPU intensive for the broker (at least, when using JMX). The first problem is mainly apparent when using persistent messages and there are a few things than can be used to speed up things (see the LogicBlaze tuning guide for ActiveMQ). However these tuning tweaks are no...