After implementing Stomper, the Java STOMP server, I wanted an easy way to test it and demonstrate its functionality. As of today, Stompee, the Java STOMP client is available at GitHub. Stompee is a generic STOMP client, and therefore should work with any STOMP server, but was designed and tested against Stomper.
In most cases, you're probably better off just using the HazelcastMQ JMS APIs rather than using Stompee, but there may be some cases where you want all your components, regardless of language, using STOMP for message passing.
While working on Stompee, I found and fixed a couple of bugs in HazelcastMQ. Most importantly, I switched the queue MessageConsumer implementation from listening to Hazelcast events to using a separate polling thread. This should result in better performance and handle the case were messages queued before the consumer started are properly consumed immediately.
I added a few new examples in the hazelcastmq-examples module that demonstrates how to use Stomper, Stompee, and the JMS APIs together. At this point I'm ready to begin some serious production testing and push for a 1.0 release. Let me know what you think.
Thursday, February 7, 2013
Sunday, February 3, 2013
Patio Bench Project Complete
I took a small break from coding this weekend and spent some time in the workshop. I completed my first large project, a patio bench, using the plans from Woodworking for Mere Mortals. I ran into a few issues with incorrect measurements in the published cut list but overall it was a fun and pretty easy project. Now I just need to wait for the temperature to get above freezing for a few days so I can drag it outside and get it painted.
I'm already on to building a table saw sled to fix the fact that my cheap fence is always out of square. I also owe a few people some children's toys for gifts but after that I'll be looking for my next large project. I'm thinking maybe a name puzzle step stool for my daughter.
I'm already on to building a table saw sled to fix the fact that my cheap fence is always out of square. I also owe a few people some children's toys for gifts but after that I'll be looking for my next large project. I'm thinking maybe a name puzzle step stool for my daughter.
HazelcastMQ Stomper Now Available
As I mentioned in a previous post, to completely move off of ActiveMQ as my message broker, I would need a messaging solution for some of the C and C++ components in my system. Currently these components use the STOMP interface exposed by the ActiveMQ broker. After getting the initial version of HazelcastMQ pushed to GitHub, I started working on a STOMP server implementation. Today I'm happy to announce that the first cut at the server is now also available in GitHub as HazelcastMQ Stomper.
Stomper is implemented as a layer on HazelcastMQ so it uses all the standard JMS components for message sending and receiving. Using the JMS components allows a STOMP client to easily interact with JMS clients creating a language agnostic messaging solution on Hazelcast. While Stomper was written and tested with HazelcastMQ JMS components, it should work with any JMS provider if you wanted to use it as a generic STOMP server implementation. You can also use Stomper's STOMP server without dealing with any of the JMS APIs other than creating the initial connection factory.
With Stomper and HazelcastMQ you can now send a message to a queue or topic via the STOMP API and receive it via the JMS API (all on a distributed cluster of Hazelcast nodes). The same works in the opposite direction. This is extremely useful in a mixed language environment where Python, Ruby, C, or C++ components need to interact with Java components without having to implement a custom message passing solution.
Check out the examples in the hazelcastmq-examples module and give it a try. The next step is to write a simple STOMP client (to be named HazelcastMQ Stompee) which will allow me to write some simple producer/consumer examples using just the STOMP API (i.e. no direct JMS interaction).
Stomper is implemented as a layer on HazelcastMQ so it uses all the standard JMS components for message sending and receiving. Using the JMS components allows a STOMP client to easily interact with JMS clients creating a language agnostic messaging solution on Hazelcast. While Stomper was written and tested with HazelcastMQ JMS components, it should work with any JMS provider if you wanted to use it as a generic STOMP server implementation. You can also use Stomper's STOMP server without dealing with any of the JMS APIs other than creating the initial connection factory.
With Stomper and HazelcastMQ you can now send a message to a queue or topic via the STOMP API and receive it via the JMS API (all on a distributed cluster of Hazelcast nodes). The same works in the opposite direction. This is extremely useful in a mixed language environment where Python, Ruby, C, or C++ components need to interact with Java components without having to implement a custom message passing solution.
Check out the examples in the hazelcastmq-examples module and give it a try. The next step is to write a simple STOMP client (to be named HazelcastMQ Stompee) which will allow me to write some simple producer/consumer examples using just the STOMP API (i.e. no direct JMS interaction).
Subscribe to:
Posts (Atom)