Introduction
James Cooper
Hans Lellelid
On 04/20/2011 09:03 PM, James Cooper wrote:
> Hi there,
>
> Thanks for creating the group. I'm a consultant/hacker based in Seattle
> who is currently very interested in queueing systems. I have a client
> who is actively evaluating different options. So far we've looked at
> ActiveMQ, HornetQ, and RabbitMQ. STOMP is the prefered wire protocol
> given its simplicity and language availability.
Yeah, no prob on group creation. Thanks for prompting that. For now
it's just the two of us, but I think it's good to have ideas captured in
a public forum anyway :)
> My findings so far have been less than amazing. ActiveMQ supports all
> the functional requirements, but seems to have stability problems. I've
> gotten messages stuck in queues, trivially corrupted the KahaDB, etc.
> It's not something I would trust in production.
>
> HornetQ doesn't support temporary queue creation via STOMP (JMS only).
>
> RabbitMQ eval is still in progress. I don't like that queues have to be
> defined in advance. STOMP is also not part of the core so I'm not sure
> how well supported it is.
Yeah, we ended up using ActiveMQ, though after having it running in
production for awhile (with relatively low load), I would concur that
there are stability issues. (We're using KahaDB.) We were using it for
a very non-critical component in the application (server push messaging
to Flex clients, which was mostly redundant with polling anyway, but
more instantaneous) so the stability wasn't a huge problem, but I would
definitely have qualms about using ActiveMQ for something serious/critical.
> The hacker in me says that any broker based architecture is going to
> have problems. If you accept and embrace that then you'd benefit from
> using a broker you can debug.
>
> This led me to CoilMQ. The code is straightforward and easy to read.
Yeah, this was really the motivation behind development. Well, that and
it was really a learning project for me; I wanted to take a stab at
writing a socket server, learning about testing multi-threaded code,
etc. The Ruby stompserver project seemed to get decent respect and
certainly was a very simple codebase -- so that provided a lot of
inspiration. So, that being said ...
> A few questions:
>
> (a) Are you guys using this in production anywhere?
No, we're not. Not because I wouldn't trust it, but only because I
decided to write CoilMQ after we had already stood up the ActiveMQ
implementation.
> (b) Would you recommend it for production use?
I would recommend trying it out in development, but I wouldn't feel
confident enough in how much its been used to recommend it for
production immediately. I know there are some other people using CoilMQ
and while I'm not aware of any outstanding big bugs, I don't know that
it's gotten enough exercise.
I do think the codebase is relatively clean and that it would be easy to
track down problems (with the caveat that sometimes debugging in
multi-threaded context can be tricky) and there are unit & functional
tests, so I think there's a solid starting point.
> (c) Any future dev plans you have in mind?
I'm not very actively involved in new development on CoilMQ. I'm kinda
hoping for an opportunity to need to use it day-to-day before I start
adding features, though I'm certainly committed to managing the project,
fix bugs, etc.
(I'm also overseeing the related stompclient project:
https://bitbucket.org/hozn/stompclient/wiki/Home)
> I may be available to help add in some features that my client needs.
> But I'd like to get a sense for where you guys are at and where you want
> to go.
Well, I may have answered that above, but essentially there is no active
new feature development right now. I'd certainly be open to
contributions and more developer participation and am happy to help
support development as I can.
Hans