[
https://issues.apache.org/jira/browse/CAMEL-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16135213#comment-16135213
]
Ruslan Belinskyy commented on CAMEL-11666:
------------------------------------------
Ok, let me give you scenario:
# We have *one* of boxes which will be receiving some messages
# Once it has received it should publish message to queue
# Once messages in Queue now work will be distributed among all hosts
participating in Hazelcast cluster.
# Each message is processed* only once* (by single host)
Now how it would look like if i would choose any JMS provider (Active MQ for
example):
# First host is picking up messages and puts into the queue.
# Any hosts which are listening to the queue will pick up message and process
it (Just One host processing One message)
In case of current Camel Hazelcast implementation:
# First host is picking up messages and puts into the queue.
# *All* hosts which are subscribed to the queue will pick up message event:
# Now you have to:
## Lock object in memory to avoid duplicated processing on all hosts (*One
message All hosts*)
## *Poll message* from queue (because message listener doesn't remove item from
queue)
# If for some reason host didn't perform "Poll message from queue" (any reason:
restart, failure). Message will be stuck in queue until whole cluster rebooted
and message will be lost.
But in case above how it differs from Topic? Absolutely the same
implementation. No need to have queue.
Topic and Queue can't have the same implementation.
Topic = Subscription
Queue = Polling
> Camel Hazelcast Queue Cosumer implementation
> --------------------------------------------
>
> Key: CAMEL-11666
> URL: https://issues.apache.org/jira/browse/CAMEL-11666
> Project: Camel
> Issue Type: Bug
> Components: camel-hazelcast
> Reporter: Ruslan Belinskyy
> Labels: documentation, features
>
> Guys,
> i have following concern / question about Hazelcast Queue Consumer:
> # I do understand why Topic is build based on CamelItemListener as
> ItemListener in HazelcastTopicConsumer. But the same behavior in
> HazelcastQueueConsumer doesn't look meaningful:
> ## Unlike Topic, Queue has state and someone subscribed to Queue and didn't
> process it (any reason here) no one will take it from queue (Event Already
> happened and will not happen again). Message will be stuck there. Until you
> explicitly poll it, which Camel-Hazelcast doesn't support (as consumer). I
> had to do Polling via Camel-Timer as workaround.
> ## Another problem is that ItemListener doesn't actually drain the Queue. It
> just listens to events. As for me it doesn't make any sense to receive
> message from Queue and don't have it removed from Queue. In current
> implementation you'll have to inject queue in Processor to actually Poll the
> message after ADD Event.
> If you won't change the code just please warn user here
> (http://camel.apache.org/hazelcast-component.html#HazelcastComponent-queue)
> that Queue consumer doesn't drain the queue. And Processor should actually
> drain it.
> If node has failed to process message it should be explicitly polled to drain
> the queue via for example Timer.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
