JBM2 Getting bigger, JBM2 Getting smaller

I have aways been posting about how great JBM2 is getting, how fast and how good it will be to support very high performance demands.

But today I want to talk about another aspect. What about small computers? Who knows, maybe you want to distribute messages to and from an ATM.

We have developed a way to page messages to disk, what will avoid the server from running out of memory by storing messages on disk when the memory is low.

There is probably nothing new with that, as JBM 1.4 and JBoss MQ already have it. (Well.. some products out there dont :-) )

The great news here is, this is really fast, and the deployment is really simple.. no RDBMS. We have developed a system where the producers will write directly to NIO files when the memory is low, and the server will start depaging those messages as soon as you have more memory available. (i.e. as soon as you consume some messages).

I have sent 500K messages to a server with only 64M on the JVM without any consumers, and it ran as fast as if they were being consumed. Later when the consumer connected, it started getting the messages as nothing special was happening.

JBM2 just buffered the messages on file protecting the server from running out of memory.

So if you have some hardware with low memory and a hard disk JBM2 still your best choice.

Redeployment leaks fixed on Apache BeanUtils

I'm really glad as I could use some of my spare time to help this project. Especially because I found a lot of people with redeployment problems, not only on JBAS but in several other projects. Just google it and you will see what I mean.

We have identified some hard to solve memory leaks on BeanUtils caused by very complex circular references on the Reflection metadata which is now fixed.

The use of the jvmti library from jboss-profiler (the same library we use to chase memory leaks on the JBAS testsuite) simplified the process a lot, and even better we have added some testcases preventing regressions, using the same techniques we have applied to solve our own redeployment leakages on JBAS.

You can find more information about what was done here:

BEANUTILS-291

JBM 2 is getting even faster and better

When we released JBM 2 Alpha1, we released some performance results and we thought they were already great.

I have recently spent a lot of time working on the journal, testing and improving it, making it as reliable as possible, and because of one of the improvements we achieved the Journal is at least 40% faster on persistent messages than it was on JBM 2 alpha. Depending how you configured Alpha that could mean 100% improvement.

We are aways reusing files on the journal, putting them back as fast as we can. Because of the data format we are now using we don't need to refill the file, and that saved a lot of time on I/O as records were being added on the journal.

And what's great is, we still have room for improvements in performance.

JBoss Messaging 2 rocks!

Playing Music, Coding and JBoss Messaging :-)

Probably not many people know that but I'm also a musician, a Jazz and Bossa Nova piano player and if I invested just a little bit more of my time (which I don't have now :-) ) I could become a professional musician. Some of the feelings I have while playing in a band I'm also getting this week after the JBoss Messaging Alpha release:

I - It's cool to improvise: You feel great by inventing new things and you got that feeling! I have been part of writing a totally cool Asynchronous IO module and helped improving the Persistent of JBoss Messaging. I totally get that feeling here.

II - It's cool when a band (or team) member also improvise: When Jeff Mesnil was working on the new transport, Andy Taylor doing a lot of hard work or Tim Fox orchestrating or playing the whip.. it's all the same... I'm part of the band, and we are jazzing a beautiful song.

III - Applauses! Yeah... musician needs that.. and we are getting that this week.


And the main point is: JBoss Messaging Alpha it's just a rehearsal. It will be much better when we are in concert :-)

It is really cool to be part of this Messaging revolution :-)

Speeding UP IO with Asynchronous IO

Have you ever wondered how to make IO faster?

We have this dilemma on the messaging world where we need to provide a framework where users are able to send thousands messages per second and we have found our way on doing it, and we are quite excited about it.

In our tests we have been able to send 25,000 persistent messages per second being very close to the the limits of the disk not consuming a lot of CPU on this process, on a computer with 2 QuadCores and a SAS/SCSI disk which is a very modest workstation. And about 10,000 messages/sec on my crappy Laptop because of my slow disk.

We have implemented a very generic JNI layer in top of AIO where you send a Java Callback Interface on every write, and you get informed when the data is on the disk.

With that we avoided requiring to send a sync on every commit we perform. We can just wait for the commit completion so a transaction commit will not affect other transactions.

This JNI layer is also using DMA (Direct Memory Access) when sending the data to the disk, so the CPU will be free doing other things while the data is being written.

At this point we are focusing on making this libaio layer very performatic and stable on JBoss Messaging and depending on the demand we might do it as a separate project very easily since it is ready.

Consider this blog just a teaser. I can't wait the release of JBoss Messaging Alpha showing these numbers so everyone will be able to produce these numbers, and we are almost there. It's amazing to be part of this!

If you want a very fast and reliable Java Messaging System, JBoss Messaging 2 will be your only choice :-)