Another article on Distributed transactions

3 02 2009

I found this new article at at JavaWorld, written by Dr. David Syer, who works for SpringSource . The article elaborates on using different transactional strategies/patterns and provides some advice on which strategy/pattern to use in a particular scenario.

The emphasis was primarily on using distributed transactions without XA (read overhead), of course, with some trade-offs. I found it very informative.


Is JBOSS losing the sheen?

3 06 2008

We use JBoss a lot in our organization and as far as my responsibilities go, I am involved, in someway or the other, in design and architectural/infrastructural issues, which also include JBOSS based applications.

I noticed that the first Beta of JBoss 5.0 AS was released way back in 2006-11-17. And since then, there were 3 more Beta versions, the last one was released on 2008-02-10. It is almost 2 years and we don’t have a GA release available yet.

Could it be the RedHat acquisition and the related transition, the reason for this? Or is it the attrition rate at RedHat?

I hope the GA release, whenever it releases, will be worth the wait. They(Redhat) should also take note of the competition coming from other open source application servers, especially GlassFish. I have never used GlassFish, but based on what I heard from others, the list of features it provides, and the pace at which they are releasing, they definitely seem to have more momentum than JBoss.

Though the adoption of JEE5 based application servers has been very slow, it has been steady. The only commercial application server which is JEE5 compliant is Weblogic 10. Websphere is way behind, but I could be wrong. Websphere community edition (Geronimo?) has JEE5 compliant features (or shall we say compatible?) but I don’t think it has that much of a momentum, despite being open source.

I hope Redhat is listening.

And now, a memory appliance

16 02 2008

We now have an appliance for every component of the technology stack where high-performance and/or low latency is a requirement. I fumbled upon this new memory appliance from violin and was pretty impressed.

Their datasheet suggests that their appliance (Violin 1010) contains about 84 VIMM’s (Violin Intelligent Memory Module) which could have a combination of both DRAM and NAND flash memory. The DRAM module has a max of 6G and 6*84 gives us a max of 504G of memory. If one opts for a 64G flash memory, per VIMM, that gives us a max of 5TB.

The appliance itself could be hooked on to a server via the 10-20 Gbit/s PCI interface and the data is protected by both ECC and RAID. They claim to bring down the io latency to 3 microseconds, which is not a small feat. The device has the capacity to do 3 Million random I/O per second, per interface. The device also claims to be “green”, owing to its low power consumption.

What kind of applications benefit from using this device? Well, any application with large cache sizes, large datasets, applications which require extended memory, memory mapped files and so forth. How about if we can just dump all the database index files on this appliance (sort of a “RAM disk”), that could potentially boost the query performance by leaps and bounds? I also heard that they do have potential wall-street clients testing their devices in a stealth mode 😉

The benefits are definitely immense, but at what cost? Their site informs us that the starter kit will come for under $50K and comes with 20 6GB VIMM’s.

If you are too curious to take a look at this baby, go here.

Understanding JMS messaging

25 07 2007

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.

Messaging at wire speed?

21 07 2007

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 😉

XML appliances and SOA

24 05 2007

Enterprises trying to adopt SOA strategies are increasingly looking at the new breed of technologies like xml appliances. These appliances, typically, contain firmware and hardened chips to accelerate XML and XSLT based processing.

Products like DataPower (acquired by IBM), Reactivity (acquired by Cisco), Sarvega (acquired by Intel) and Layer7 have already made greater in-roads in terms of enterprise usage.

What are the real advantages of using these appliances? Since I have been exposed to DataPower, I can list them below:

  • Security – especially for internet facing applications. Handles DOS attacks, XML and XSL threats at wire-speeds. Supports WS-Security, SAML and LDAP. It also provides fine-grained access control.
  • Hardware based acceleration – Since SSL is, highly resource intensive, regular web servers like Apache or IIS can’t handle large volumes of SSL connections. Datapower comes with an SSL accelerator and can easily handle large volumes. Datapower also compiles XSL stylesheets and runs the compiled code on hardware which gives it dramatic performance.
  • Multi-protocol gateway – The X150, integration appliance from Datapower is a high-end version which includes multi-protocol gateway features besides security and routing capabilities. The multi-protocol gateway can talk multiple protocols (MQ, TIBCO EMS, FTP, HTTP, ODBC, SOAP based web services etc) and can act as an integration broker. The input and output can be text or binary and handles many data formats (XML, SOAP, Cobol copybook, SWIFT, EDI etc).
  • Firewalls and Proxies – XML firewalls and web serivce proxies can be configured easily to achieve service virtualization.

I am sure their competitors provide more or less the same set of features in their product lines. There was a comparison of XML gateways made in 2005, which rates Datapower very high when compared to other products.

I haven’t learned much about the drawbacks of these appliances, although I can list a few, I would like others who have used these appliances to post some.
The drawbacks, atleast for Datapower, are as follows:

  • Cost – X150 sells at $75,000 a piece. If the applications are primarily intranet based, one has to really justify the ROI on this piece of hardware.
  • Machine limitations – If the anticipated load increases (heavy concurrent usage, in a shared environment) the machine might be overloaded and will be subjected to CPU and memory limitations. The appliances themselves run on a very lightweight OS (usually Linux based).
  • No state and transaction management. The appliances, as of now, can’t handle state and can’t co-ordinate transactions (global). This may change in the future though and it might even threaten the existence of JEE servers.
  • Difficult to pin-point bugs and may end up as a firmware upgrade, which might take a long time. I happen to remember an issue we faced with DNS resolution and it took several weeks for us to come up with a workaround, let alone a fix.
  • Messaging support is not clean (i.e you don’t find all the features of JMS as a sender and a consumer) and is limited. So one should be vary of using messaging support and should be done on a case-by-case basis.