[manishsharan]

I wish the authors good luck with this but I don't think I would be able to use it for collecting metrics in my "enterprise applications" as we already have several messaging systems e.g. (i) TIBCO (ii) MQ Series (iii)ActiveMQ ; the infrastructure guys will throw a hissy fit if I try to sneak in yet another messaging system -- especially for only metrics collection.

In my current setup ( a java enterprise application) , we have a ActiveMQ adapter for log4j which pushes of all the Error and Warning messages to an MQ Series Queue asynchronously. There is a consumer which reads the messages off the queue and processes them and writes results to a SQL database. we have a simple webapp that allows people to download this data as CSV files , load it into Excel and do analysis.

[tptacek]

Have you worked with Tibco or MQ Series? I have; when you do security assessments of trading systems, you end up spending a day or two building client libraries for these message systems.

They're horrible.

I do not doubt that projects like NSQ will have a hard time securing adoption in Tibco shops, because Tibco is a sort of guaranteed-employment scheme for its administrators. But the developers that work with these things tend to hate them (Tibco in particular tends never to work except in its one delicate production configuration, and projects routinely flatline because the bus goes down in the dev environment).

One thing I see a lot of in enterprise dev shops is that there tends to be a huge investment in a particular stack (J2EE, JMS, MQ, Struts, &c) and then once every other year a skunkworks project happens with some new system that deliberately uses a different stack. Last year, I saw a lot of Websockets and JMS. This year, maybe it'll be decent message queues.

[manishsharan]

Agree with your view on Tibco. I am forced to use it ; simple JMS with ActiveMQ would have sufficed in almost all the propjects that we have in-house ( other than the trading apps). But arguing with Tbco/management-ecosystem is a waste of time.

I do think that messaging solutions at this point are nearly indistinguishable from each other.

[wglb]

I used http://www.zeroc.com/ice.html on one high-throughput system. Wonder if that has made any inroads.

[matticakes]

Thanks.

For the record... NSQ is a generic messaging platform and is data format agnostic, there is nothing specific about metrics collection (it was just my contrived example).