View feed: Tim Fox's messaging blog.
Navigation
Posts of this feed on this page
- Updates on JBM 2.0 progress
- Shiny new remoting layer for JBM
- Invoking Greek goddesses to get your test suite in order
- JBM 2.0.0 alpha released with blistering performance
- New Linux asynchronous IO layer for JBM 2.0
- Get the latest news on JBoss Messaging 2.0 at the Munich JBUG
- Google Summer of Code ideas for JBoss Messaging
- High performance persistence with JBoss Messaging
- Get the scoop on JBoss Messaging 2.0 at the London JBUG
- The mysteries of flow control explained
- (to view more posts, click the next/previous link)
Recent posts from all feeds
- esbgen: An easy way to create JBoss ESB Projects
- IBM Websphere - officially better than anything, ever
- Book review and NHibernate Search
- Red Hat Launches New JBoss SOA Assessment Tool
- Thank you !
- Jbpm Mail delivery
- JBoss Marshalling Framework 1.0.0.Beta1 Released
- Performance Comparison between NIO Frameworks
- Mobicents Metamorphosis
- JBoss Jbpm superstates
Updates on JBM 2.0 progress
JBoss Messaging 2.0 is making further great progress... here's an update with what's been going on recently:I have just completed some further changes to our remoting layer, which allows new transports to plugged in even easier.
So far JBM 2.0 has plug-ins for Netty and MINA, and I'm looking forward to creating one for XNIO soon. Users will be able to easily configure at deploy-time which transports they wish to use.
Clebert about to finish our "paging" functionality. "Paging" in JBoss Messaging, means the ability for the system to page messages between RAM and disk, so JBM can support very large queues - much larger than can fit it in memory at one time. This allows the server to run with a small memory footprint but still handle very large queues.
The difficult bit for successful paging is doing performantly. Clebert reports he can depage around 40K 1K messages per sec on his simple home server! :)
Jeff has been finishing off our management API and he's almost there. JBM 2.0 will boast an enhanced management api with JMX and POJO support, notifications, and an ability to manage over the connection.
Shiny new remoting layer for JBM
I've just completed a refactoring of our JBoss Messaging remoting layer.This is a thin layer that sits between the majority of the JBM core code and the actual transport provider (E.g. Apache MINA).
Most of the leg-work is done in our remoting layer - ordering of sessions, pinging (heartbeats) etc.
The core remoting code now has zero dependencies on any particular transport provider. This means we can easily plug-in different providers with the minimum of pain - e.g. Apache MINA, Trustin Lee's Netty 3, and David Lloyd's XNIO.
Integrating a new transport provider is simple. JBM provides a spi (service provider interface) set of interfaces that need to implemented for each transport provider. Once that is done, you just add the ConnectorFactory and AcceptorFactory class names to the config file and you're done.
The implementations of the spi interfaces are typically very simple, since all the generic code is in our remoting layer and doesn't change.
Invoking Greek goddesses to get your test suite in order
One thing we're really proud of in JBoss Messaging is our testing. Very soon our unit test suite will be giving close to 100% coverage of our code, and, what's more it runs very fast.Having a solid unit test suite that runs like lightning is critical for fast effective refactoring of the code.
Long running test suites are a bad test smell. More than likely you've experienced this yourself (I certainly have), you're working on a project and it takes about three hours to run the test suite. So before every commit, you have to wait three hours to see if your changes have broken anything. Or even worse, the test suite takes so long that it's not practical to run it every time you commit, so developers are constantly breaking each others code and progress slows to a crawl. Sounds familiar?
This kind of situation is very expensive to fix retrospectively, and comes down to poor testing techniques from the offset, and too much reliance on integration testing. Familiar bad test smells here include having to start and stop the entire server on each test, usage of Thread.sleep, and start and restart the third party components e.g. databases, jgroups... All these times add up.
In JBM 2.0 we're making sure all our classes are thoroughly unit tested. We use mock or fake objects where appropriate, these nullifies any startup/shutdown times associated with starting any real implementations of the third party components. Then we have a smaller number of integration tests which tests how the objects interact together.
One other thing we've done here is to invoke the law of Demeter
This basically means that you're avoiding doing things like this in your code:
int id = connectionFactory.getConnection().getSession().getConsumer().getID();
Avoiding ugly stuff like the above does two things:
1) Makes your code more maintainable and simpler to refactor since each component does not have such a deep knowledge of other components
2) Make writing mocks a lot easier, since you're not constantly having to tell the mock to expect these nasty chains of invocations.
JBM 2.0.0 alpha released with blistering performance
JBoss messaging 2.0.0 alpha is released!The goal of JBM 2.0 is simple and uncompromising- to bring unrivalled levels of performance to reliable messaging, and to be the fastest, best featured and most scalable open source messaging system. Period.
JBM 2.0 alpha is a technology preview of our next generation messaging system and demonstrates that we are well on the way to achieving that goal, with class-beating performance results.
We don't like to make unfalsifiable claims about our performance in our marketing literature. We prefer science to religion. So, in this release, we back up our assertions with a set of simple performance measurements comparing JBM 2.0 alpha with a selection of other open source messaging systems.
The tests are all reproducable by you, using only the tools shipped in the distribution. I think you'll agree that the facts speak for themselves.
Remember that JBM 2.0 is only an alpha release but we demonstrate results that outstrip competing production, or near production releases.
The success of JBM 2.0 comes down to a few factors:
1) An elegant simple architecture - 100% POJO based, allowing embeddable messaging in any product. The JMS API is provided as a thin optional facade on the client side.
2) An ultra high performance intelligent journal which can automatically flip into using pure Java NIO, or Linux asynchronous IO (via a thin native layer) depending on whether AIO is available on the system. This gives us astonishing persist rates even on commodity hardware. (See performance results). The journal is written in 95% Java, deliberately keeping the native layer to a minimum, making it far simpler to manage and port to other operating systems in the future.
3) A high performance new transport based on Apache MINA.
And not forgetting that none of this would be possible without our team. We have a small, but highly experienced, highly motivated team who have worked their butts off all hours of the day and night for as long as I can remember.
Many thanks to the "dream team", in no particular order, Andy Taylor, Clebert Suconic and Jeff Mesnil. Also thanks to Trustin Lee for working closely with us to build our new transport.
The release is available here:
Enjoy...
New Linux asynchronous IO layer for JBM 2.0
Clebert has just posted a blog on the new asynchronous IO layer he has written for JBoss Messaging 2.0.This is very cool technology.
Get the latest news on JBoss Messaging 2.0 at the Munich JBUG
As well as the London JBUG next week, I'll also be talking at the next Munich JBUG in Germany on the 2nd June.Anyone who wants to hear about the exciting developments with JBM 2.0, it would be great to see you there :)
More details here
Google Summer of Code ideas for JBoss Messaging
JBoss Messaging is looking for students to take part in Google Summer of Code 2008.If you're a student who wants get involved with the cutting edge of messaging technology then why not take a look at our project suggestions.
High performance persistence with JBoss Messaging
Anyone who has been to JBoss World, or talked to anyone about JBM recently will know that one of the main new things in JBM 2.0 is extended persistence functionality.Whereas JBM 1.x uses only JDBC for persistence, JBM 2.0 will also provide a fast "journal" approach to persistence.
For those not familiar with journalling techniques, it basically means that the persistence store is just a log (another name for a journal, a diary) which just gets appended too. One major advantage of a journal approach is since the file is only ever added too, the disk head doesn't move too much thus improving performance (disk seek times are typically slow). I will do a more thorough blog explaining the technology around this at a later date.
The journal can run in two modes:
1) Using 100% Java NIO for persistence. This is very fast and of course 100 % portable.
2) Using a thin JNI wrapper around Linux asynchronous IO for its persistence (thanks to Clebert for this). This is *even faster*, but only runs on Linux. There is a possibility that this can be ported to other OSes in the future.
Suffice to say, for now, that 1) is now committed and 2) is very shortly on its way.
The idea is this will allow us to provide the very top end of persistent messaging performance.
Exciting times for JBM 2.0... watch this space for more developments
Get the scoop on JBoss Messaging 2.0 at the London JBUG
The London JBoss User Group (JBUG), has reconvened and will be holding a meeting on Thursday 10th April 2008.The topics for discusssion revolve around various SOA subjects, and I'll be presenting about all the new shiny, fast and sexy things in JBoss Messaging 2.0.
There will also be talks about JBoss ESB and web services.
Come along and hear the scoop...
See here for more details.
The mysteries of flow control explained
I'd thought I'd write a few words about flow control in messaging, since that is what I have working on in JBM 2.0 the past week or two.Consumer flow control
Consumer flow control basically does what it says on the tin - it controls the flow of messages to the consumer.
Say you had a consumer on a queue which had lots of messages in it (or messages were arriving fast at that queue), and a TCP connection between the consumer and the server over which the messages are delivered.
A naive messaging implementation might not send any messages to the consumer unless the consumer has specifically asked for one, e.g. the consumer might make a client to server request for a message every time the receive() message is called on the consumer.
This would certainly work, but it would involve a network round trip every time a message is required, in other words the throughput of message consumption would be limited by the network round trip time (RTT) - (2 times the latency of the network). This is not likely to give you good performance.
An alternative approach would be just to send the messages (write the messages to the socket) on the server as soon as they are available and read them off the socket on the client side and pass them to the receive() method (or message listener).
This can be fast, but the main problem is that if the consumer cannnot process messages as fast as they arrive, then eventually the TCP buffer will fill and backup and the call to write on the server side will block until more messages are consumed. This will block the entire server delivery thread making it unavailable for anything, and also the TCP connection cannot be used for anything else during this period - e.g. sending messages from client to server.
To remedy these problems, pretty much every message system implements some kind of consumer flow control. JBM uses a "window" technique for consumer flow control.
In this technique the server maintains a pot of "tokens" for each consumer. The size of the initial pot of tokens determines the window size. As long as it has tokens it can send a message to the consumer. Each time it sends a message it reduces the number of available tokens by an amount. If the number of tokens reaches zero it can't send any more messages to the consumer.
On the other side, the consumer reads messages and is it processes then it sends tokens back to the server. When the server receives more tokens it can send more messages... you get the picture.
As you can see, since the flow of messages one way and flow of tokens the other way are decoupled the throughput is no longer limited by the network RTT and we can benefit from its bandwidth.
This kind of consumer flow control is already implemented in JBM 1.4.
Producer flow control
Now, conversely, as well as controlling the flow of messages from the server to the client, we might also want to control the flow of messages from the client to the server.
There are several reasons for wanting to do this:
1) You want to prevent the number of messages in a queue from exceeding some limit. As the number of messages in a queue increases so does the latency (from client->server->consumer) and you may want to limit that. (You don't want messages processed 3 hours after they have arrived in the queue)
2) You want to prevent certain clients from sending messages to fast so as not to reduce quality of service for other users.
This is known as "Producer flow control", and again does pretty much what it says on the tin.
This is nice new feature of JBM 2.0 and is more or less complete now in SVN TRUNK. Producer flow control comes in two different flavours:
1) A window (token) based flow control that works very similarly to how consumer flow control works - but in reverse. Each producer maintains a set of tokens and can only send messages as long as it has tokens. It starts off with a specific sized "pot" of tokens (this is the "window size"). As messages arrive on the server, more tokens are sent back to the client.
JBM 2.0 goes a step further than most messaging systems and also adjusts the number of tokens sent back so that the queue size never exceeds a hard limit if specified. In such a way the producers are automatically throttled to prevent the queue size being exceeded. If there are multiple producers then the free tokens are shared out in a fair way to prevent any of them starving.
Currently flow control is implemented with the window size measured in number of messages produced / consumed, but we will also soon support window size specified in number of bytes produced / consumed. This makes more sense in many situations.
2) That's not all. JBM 2.0 will also allow you to specify a specific maximum send rate for a particular producer. So you can say "producer A is only allowed to send messages at a rate of 100 msgs / sec", but "producer B can send messages at a rate of 1000 msgs / sec".