I think this is great. I assume the form this would take would be a library that implements the JMS api that wraps the existing java producer and consumer?
Our past experience has been that trying to maintain all this stuff centrally is too hard and tends to stifle rather than support innovation. So if you are interested in doing this I would recommend doing a small github project. We will definitely help promote it. Several people have asked for it so I suspect you would definitely get some usage. I would also love to hear how well that adaption works in practice--i.e. what percentage of JMS features are supportable by Kafka. -Jay On Thu, Mar 5, 2015 at 6:30 PM, Joshi, Rekha <rekha_jo...@intuit.com> wrote: > Hi, > > Kafka is a great alternative to JMS, providing high performance, > throughput as scalable, distributed pub sub/commit log service. > > However there always exist traditional systems running on JMS. > Rather than rewriting, it would be great if we just had an inbuilt > JMSAdaptor/JMSProxy/JMSBridge by which client can speak JMS but hit Kafka > behind-the-scene. > Something like Chukwa's > o.a.h.chukwa.datacollection.adaptor.jms.JMSAdaptor, which receives msg off > JMS queue and transforms to a Chukwa chunk? > > I have come across folks talking of this need in past as well.Is it > considered and/or part of the roadmap? > http://grokbase.com/t/kafka/users/131cst8xpv/stomp-binding-for-kafka > > http://grokbase.com/t/kafka/users/148dm4247q/consuming-messages-from-kafka-and-pushing-on-to-a-jms-queue > > http://grokbase.com/t/kafka/users/143hjepbn2/request-kafka-zookeeper-jms-details > > Looking for inputs on correct way to approach this so to retain all good > features of Kafka while still not rewriting entire application.Possible? > > Thanks > Rekha >
