Comments : Leave a Comment »
Tags: jms spring messaging eai java
Categories : EAI, Java, Messaging, Spring
To my surprise, I am learning that there are very few java developers/programmers who understand the JMS specificaiton. There was this application which was consuming messages using a synchronous recieve call (with an AUTO_ACK mode), the programmer was expecting that the message be re-delivered if his application fails after the receive() and eventually blames the JMS server. The programmers fail to understand the difference between synchronous receive() and asynchornous receive (via MessageListener).
In another instance, I was informed that the JMS server was not JMS compliant just because it wasn’t closing the producer explicitly. The architects of that application were thinking that java’s garbage collection would take care of cleaning up the producers, if not explicitly closed. The JMS 1.1 spec is pretty clear on this and I find it very difficult to understand why and how one can interpret this differently.
The same is the case when a standalone application uses Spring MDP’s for consuming messages. Spring has this DefaultMessageListenerContainer which does a synchronous receive(). If one were to set the AUTO_ACK acknowledge mode, and the application fails after the receive() call, the message is lost. This is not clear to many of the users.
Maybe it is time for someone to come up with a list of messaging anti-patterns and educate the JMS/messaging community in general.
Comments : Leave a Comment »
Tags: soa messaging java hardware eai low-latency appliance
Categories : appliance, EAI, hardware, Java, low-latency, Messaging, SOA
My ex-boss mentioned about Tervela a while ago and I finally got a chance to learn more about it.
Coming from the Java world and having been exposed to JMS implementations like Tibco EMS, Websphere MQ and ActiveMQ; this came as a surprise to me and I would like to share this with everyone.
Tervela’s product is a messaging appliance which runs on the metal.
Its key features are as follows:
- Message transformation and routing at the network level (layers 1-3). This will pretty much eliminate the network interrupts, which would otherwise overload the processor with interrupts for every packet that was received (thus increasing the latency). Besides this, the requirement for queuing of messages at the entire network stack, which is pretty common with software based messaging systems running at the application level messaging, is eliminated too.
- Native instruction sets optimized for specific tasks and its pipelined architecture (no scheduling and interrupts so reduced latency).
- No broadcast storms (a result of crybaby phenomenon). A typical scenario will be when a consumer is unable to catch up with the message load and thus drops some packets and requests for re-transmission. This is very common in multicast based communications and the re-transmitted message is eventually sent to all the consumers, instead of sending it to the consumer who requested it.
- Custom routing algorithms eliminating filtering of the messages at the client level.
As you can see, the appliance mainly targets the financial verticals and will be a good fit for handling market data feeds at wire speeds (pub-sub domains). If you are looking for JMS semantics, look elsewhere 😉