Previously, we were using JMS to make asyncronous calls at various points in our business logic. We had message persistence configured to use a PostgreSQL database.
We found that our database node, which was fairly well tuned for our needs, was really struggling. After some investigation, we saw that the majority of the CPU time on our database node was being taken up with INSERT and DELETE statements for JMS message persistence. We needed an alternative, and we needed it quickly.
After investigating Remoting, we decided to make some changes. We have now had JBoss Remoting deployed in our production environment for one month. Our database node's CPU load has dropped by almost 80%. We experienced an increase in the average transaction time of our entire system by over 100%!
Now, to be honest, this speaks to a few things. We had specific needs that may not be applicable to all situations, and the current JMS implementation as a whole is regarded as something that needs some work.
However, for what we needed, in comparison to the JMS alternative, JBoss Remoting was far simpler to integrate into our system, resulting in greatly improved performance and managability. At the risk of waxing a little poetic, the simplicity of JBoss Remoting gives it a genuine elegance that is often lacking in open source solutions currently available.
Thank you to Tom Elrod, and everyone who contributes to this project, for developing such a great solution.
Your friendly neighbourhood remoting fanboy,
Thanks for the kind words. It means a lot.