[
https://issues.apache.org/jira/browse/KAFKA-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15311268#comment-15311268
]
John Lonergan commented on KAFKA-1995:
--------------------------------------
Is it problematic that JMS reads (rather the commits) are destructive.
Also there is no obvious JMS feature that could be used for the source offset.
> JMS to Kafka: Inbuilt JMSAdaptor/JMSProxy/JMSBridge (Client can speak JMS but
> hit Kafka)
> ----------------------------------------------------------------------------------------
>
> Key: KAFKA-1995
> URL: https://issues.apache.org/jira/browse/KAFKA-1995
> Project: Kafka
> Issue Type: Wish
> Components: core
> Affects Versions: 0.9.0.0
> Reporter: Rekha Joshi
>
> 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?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
