You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@camel.apache.org by "Andrea Cosentino (JIRA)" <ji...@apache.org> on 2017/08/23 11:46:00 UTC

[jira] [Resolved] (CAMEL-11666) Camel Hazelcast Queue Cosumer implementation

     [ https://issues.apache.org/jira/browse/CAMEL-11666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrea Cosentino resolved CAMEL-11666.
--------------------------------------
    Resolution: Fixed

> 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
>            Assignee: Andrea Cosentino
>              Labels: documentation, features
>             Fix For: 2.20.0
>
>
> 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)