FAQ
Hi all,

We've been using Camel for a while now and we are very happy with it! :-)

Currently we are looking at using ZooKeeper in our project. As our project already uses Camel it makes sense to use Camel to interact with ZooKeeper. I've played around a bit with the ZooKeeper component and I've noticed that when a znode is deleted, the NodeDeleted event is not triggering my Camel route. Is this by design or could this point to an issue in the component?

I am using Camel 2.9.1 and ZooKeeper 3.4.3.

Kind regards,

Arnoud Glimmerveen


------------------------------------------------------------------------------------------------------------
Disclaimer:

If you are not the intended recipient of this email, please notify the sender and delete it.
Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
------------------------------------------------------------------------------------------------------------

Search Discussions

  • Claus Ibsen at Apr 11, 2012 at 4:00 am

    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with it!  :-)

    Currently we are looking at using ZooKeeper in our project. As our project already uses Camel it makes sense to use Camel to interact with ZooKeeper. I've played around a bit with the ZooKeeper component and I've noticed that when a znode is deleted, the NodeDeleted event is not triggering my Camel route. Is this by design or could this point to an issue in the component?

    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent. But
    it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
  • Claus Ibsen at Apr 14, 2012 at 7:31 am
    Hi

    I logged a JIRA ticket
    https://issues.apache.org/jira/browse/CAMEL-5170
    On Wed, Apr 11, 2012 at 5:59 AM, Claus Ibsen wrote:
    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with it!  :-)

    Currently we are looking at using ZooKeeper in our project. As our project already uses Camel it makes sense to use Camel to interact with ZooKeeper. I've played around a bit with the ZooKeeper component and I've noticed that when a znode is deleted, the NodeDeleted event is not triggering my Camel route. Is this by design or could this point to an issue in the component?

    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent. But
    it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
  • GLIMMERVEEN Arnoud at Apr 16, 2012 at 8:11 am
    Hi Claus,

    I did spent some time looking at the source code of the zookeeper component. I found that the NodeDelete event is being received and triggers the "DataChangedOperator". In the current design, the changed data is retrieved by a subsequent "GetDataOperation" that is preceded by a "ExistsOperation" or "ExistenceChangedOperation". In case of a Delete event, the ExistsOperation returns false (!ok) and the ExistenceChangedOperation starts waiting for NodeCreated or NodeDeleted events. The actual delete event is never completely handled.
    From what I've seen, the DataChangedOperation is where the delete event should be handled. In the current implementation, the DataChangedOperation returns no result (as the changed data is retrieved later on), is it an idea that in the case of NodeDeleted event to let DataChangedOperation return an empty OperationResult, resulting in an Exchange with a null body?
    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Saturday, 14 April, 2012 09:31
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper component

    Hi

    I logged a JIRA ticket
    https://issues.apache.org/jira/browse/CAMEL-5170
    On Wed, Apr 11, 2012 at 5:59 AM, Claus Ibsen wrote:
    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with it!
    :-)

    Currently we are looking at using ZooKeeper in our project. As our project already uses Camel it makes sense to use Camel to interact with ZooKeeper. I've played around a bit with the ZooKeeper component and I've noticed that when a znode is deleted, the NodeDeleted event is not triggering my Camel route. Is this by design or could this point to an issue in the component?

    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent. But
    it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    ---------------------------------------------------------------------
    ---------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ---------------------------------------------------------------------
    ---------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/

    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------
  • Claus Ibsen at Apr 16, 2012 at 8:57 am
    Hi

    Thanks for looking into this.

    1)
    Maybe we can have an option on the endpoint to control this, similar
    to this option on the file component: sendEmptyMessageWhenIdle

    For example naming it: sendEmptyMessageOnDelete, and then have it
    enabled by default. I would assume people want all the events. But
    then they can disable it to use the old behavior.


    2)
    I wonder if we know what event type it really is: changed, deleted, created etc.
    Maybe we should have a header on the message with that detail. So its
    easier to people to know that.

    We got the number of different implements of the operations, but in a
    content based router it would be easier to match against an new enum
    that has the different operation types.





    On Mon, Apr 16, 2012 at 10:09 AM, GLIMMERVEEN Arnoud
    wrote:
    Hi Claus,

    I did spent some time looking at the source code of the zookeeper component. I found that the NodeDelete event is being received and triggers the "DataChangedOperator". In the current design, the changed data is retrieved by a subsequent "GetDataOperation" that is preceded by a "ExistsOperation" or "ExistenceChangedOperation". In case of a Delete event, the ExistsOperation returns false (!ok) and the ExistenceChangedOperation starts waiting for NodeCreated or NodeDeleted events. The actual delete event is never completely handled.

    From what I've seen, the DataChangedOperation is where the delete event should be handled. In the current implementation, the DataChangedOperation returns no result (as the changed data is retrieved later on), is it an idea that in the case of NodeDeleted event to let DataChangedOperation return an empty OperationResult, resulting in an Exchange with a null body?

    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Saturday, 14 April, 2012 09:31
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper component

    Hi

    I logged a JIRA ticket
    https://issues.apache.org/jira/browse/CAMEL-5170
    On Wed, Apr 11, 2012 at 5:59 AM, Claus Ibsen wrote:
    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with it!
    :-)

    Currently we are looking at using ZooKeeper in our project. As our project already uses Camel it makes sense to use Camel to interact with ZooKeeper. I've played around a bit with the ZooKeeper component and I've noticed that when a znode is deleted, the NodeDeleted event is not triggering my Camel route. Is this by design or could this point to an issue in the component?

    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent. But
    it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    ---------------------------------------------------------------------
    ---------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ---------------------------------------------------------------------
    ---------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/

    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
  • GLIMMERVEEN Arnoud at Apr 17, 2012 at 3:45 pm
    Hi,

    1) Makes sense to do it this way. I am working on this and will attach a patch to the JIRA issue when finished.

    2) Having the EventType from ZooKeeper's WatchedEvent attached to the Exchange in a header would I think be very useful. I was just wondering on how to deal with Exchanges from the ZooKeeper component that do not originate from a Watch, but are the result of the initial connection of the consumer. Is it acceptable that such a header is optional, in this case only assigned when the Exchange originates from a Watch event?

    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Monday, 16 April, 2012 10:57
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    Hi

    Thanks for looking into this.

    1)
    Maybe we can have an option on the endpoint to control this, similar to this
    option on the file component: sendEmptyMessageWhenIdle

    For example naming it: sendEmptyMessageOnDelete, and then have it
    enabled by default. I would assume people want all the events. But then
    they can disable it to use the old behavior.


    2)
    I wonder if we know what event type it really is: changed, deleted, created
    etc.
    Maybe we should have a header on the message with that detail. So its
    easier to people to know that.

    We got the number of different implements of the operations, but in a
    content based router it would be easier to match against an new enum that
    has the different operation types.





    On Mon, Apr 16, 2012 at 10:09 AM, GLIMMERVEEN Arnoud
    wrote:
    Hi Claus,

    I did spent some time looking at the source code of the zookeeper
    component. I found that the NodeDelete event is being received and
    triggers the "DataChangedOperator". In the current design, the changed data
    is retrieved by a subsequent "GetDataOperation" that is preceded by a
    "ExistsOperation" or "ExistenceChangedOperation". In case of a Delete
    event, the ExistsOperation returns false (!ok) and the
    ExistenceChangedOperation starts waiting for NodeCreated or NodeDeleted
    events. The actual delete event is never completely handled.
    From what I've seen, the DataChangedOperation is where the delete
    event should be handled. In the current implementation, the
    DataChangedOperation returns no result (as the changed data is retrieved
    later on), is it an idea that in the case of NodeDeleted event to let
    DataChangedOperation return an empty OperationResult, resulting in an
    Exchange with a null body?
    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Saturday, 14 April, 2012 09:31
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    Hi

    I logged a JIRA ticket
    https://issues.apache.org/jira/browse/CAMEL-5170
    On Wed, Apr 11, 2012 at 5:59 AM, Claus Ibsen wrote:
    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with it!
    :-)

    Currently we are looking at using ZooKeeper in our project. As our
    project already uses Camel it makes sense to use Camel to interact with
    ZooKeeper. I've played around a bit with the ZooKeeper component and I've
    noticed that when a znode is deleted, the NodeDeleted event is not
    triggering my Camel route. Is this by design or could this point to an issue in
    the component?
    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent.
    But it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    --------------------------------------------------------------------
    -
    ---------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the
    sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by
    this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the
    Chamber of Commerce under number 06061578.
    --------------------------------------------------------------------
    -
    ---------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/

    ----------------------------------------------------------------------
    --------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender
    and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this
    email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber
    of Commerce under number 06061578.
    ----------------------------------------------------------------------
    --------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------
  • Claus Ibsen at Apr 21, 2012 at 9:07 am

    On Tue, Apr 17, 2012 at 5:44 PM, GLIMMERVEEN Arnoud wrote:
    Hi,

    1) Makes sense to do it this way. I am working on this and will attach a patch to the JIRA issue when finished. Great.
    2) Having the EventType from ZooKeeper's WatchedEvent attached to the Exchange in a header would I think be very useful. I was just wondering on how to deal with Exchanges from the ZooKeeper component that do not originate from a Watch, but are the result of the initial connection of the consumer. Is it acceptable that such a header is optional, in this case only assigned when the Exchange originates from a Watch event?
    Yeah I would assume so. Just that we document this so people can
    understand this.
    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Monday, 16 April, 2012 10:57
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    Hi

    Thanks for looking into this.

    1)
    Maybe we can have an option on the endpoint to control this, similar to this
    option on the file component: sendEmptyMessageWhenIdle

    For example naming it: sendEmptyMessageOnDelete, and then have it
    enabled by default. I would assume people want all the events. But then
    they can disable it to use the old behavior.


    2)
    I wonder if we know what event type it really is: changed, deleted, created
    etc.
    Maybe we should have a header on the message with that detail. So its
    easier to people to know that.

    We got the number of different implements of the operations, but in a
    content based router it would be easier to match against an new enum that
    has the different operation types.





    On Mon, Apr 16, 2012 at 10:09 AM, GLIMMERVEEN Arnoud
    wrote:
    Hi Claus,

    I did spent some time looking at the source code of the zookeeper
    component. I found that the NodeDelete event is being received and
    triggers the "DataChangedOperator". In the current design, the changed data
    is retrieved by a subsequent "GetDataOperation" that is preceded by a
    "ExistsOperation" or "ExistenceChangedOperation". In case of a Delete
    event, the ExistsOperation returns false (!ok) and the
    ExistenceChangedOperation starts waiting for NodeCreated or NodeDeleted
    events. The actual delete event is never completely handled.
    From what I've seen, the DataChangedOperation is where the delete
    event should be handled. In the current implementation, the
    DataChangedOperation returns no result (as the changed data is retrieved
    later on), is it an idea that in the case of NodeDeleted event to let
    DataChangedOperation return an empty OperationResult, resulting in an
    Exchange with a null body?
    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Saturday, 14 April, 2012 09:31
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    Hi

    I logged a JIRA ticket
    https://issues.apache.org/jira/browse/CAMEL-5170

    On Wed, Apr 11, 2012 at 5:59 AM, Claus Ibsen <claus.ibsen@gmail.com>
    wrote:
    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with it!
    :-)

    Currently we are looking at using ZooKeeper in our project. As our
    project already uses Camel it makes sense to use Camel to interact with
    ZooKeeper. I've played around a bit with the ZooKeeper component and I've
    noticed that when a znode is deleted, the NodeDeleted event is not
    triggering my Camel route. Is this by design or could this point to an issue in
    the component?
    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent.
    But it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    --------------------------------------------------------------------
    -
    ---------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the
    sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by
    this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the
    Chamber of Commerce under number 06061578.
    --------------------------------------------------------------------
    -
    ---------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/

    ----------------------------------------------------------------------
    --------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender
    and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this
    email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber
    of Commerce under number 06061578.
    ----------------------------------------------------------------------
    --------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
  • GLIMMERVEEN Arnoud at Apr 25, 2012 at 3:50 pm
    Hi Claus,

    I submitted a patch to JIRA-5170 you created for tracking this enhancement. Can you take a look at the patch and see if it can be committed?

    Regards,

    Arnoud.
    -----Original Message-----
    From: Claus Ibsen
    Sent: Saturday, 21 April, 2012 11:07
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    On Tue, Apr 17, 2012 at 5:44 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi,

    1) Makes sense to do it this way. I am working on this and will attach a
    patch to the JIRA issue when finished.
    Great.
    2) Having the EventType from ZooKeeper's WatchedEvent attached to the
    Exchange in a header would I think be very useful. I was just wondering on
    how to deal with Exchanges from the ZooKeeper component that do not
    originate from a Watch, but are the result of the initial connection of the
    consumer. Is it acceptable that such a header is optional, in this case only
    assigned when the Exchange originates from a Watch event?
    Yeah I would assume so. Just that we document this so people can
    understand this.
    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Monday, 16 April, 2012 10:57
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    Hi

    Thanks for looking into this.

    1)
    Maybe we can have an option on the endpoint to control this, similar
    to this option on the file component: sendEmptyMessageWhenIdle

    For example naming it: sendEmptyMessageOnDelete, and then have it
    enabled by default. I would assume people want all the events. But
    then they can disable it to use the old behavior.


    2)
    I wonder if we know what event type it really is: changed, deleted,
    created etc.
    Maybe we should have a header on the message with that detail. So its
    easier to people to know that.

    We got the number of different implements of the operations, but in a
    content based router it would be easier to match against an new enum
    that has the different operation types.





    On Mon, Apr 16, 2012 at 10:09 AM, GLIMMERVEEN Arnoud
    wrote:
    Hi Claus,

    I did spent some time looking at the source code of the zookeeper
    component. I found that the NodeDelete event is being received and
    triggers the "DataChangedOperator". In the current design, the
    changed data is retrieved by a subsequent "GetDataOperation" that is
    preceded by a "ExistsOperation" or "ExistenceChangedOperation". In
    case of a Delete event, the ExistsOperation returns false (!ok) and
    the ExistenceChangedOperation starts waiting for NodeCreated or
    NodeDeleted events. The actual delete event is never completely
    handled.
    From what I've seen, the DataChangedOperation is where the delete
    event should be handled. In the current implementation, the
    DataChangedOperation returns no result (as the changed data is
    retrieved later on), is it an idea that in the case of NodeDeleted
    event to let DataChangedOperation return an empty OperationResult,
    resulting in an Exchange with a null body?
    Regards,

    Arnoud.

    -----Original Message-----
    From: Claus Ibsen
    Sent: Saturday, 14 April, 2012 09:31
    To: users@camel.apache.org
    Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
    component

    Hi

    I logged a JIRA ticket
    https://issues.apache.org/jira/browse/CAMEL-5170

    On Wed, Apr 11, 2012 at 5:59 AM, Claus Ibsen
    <claus.ibsen@gmail.com>
    wrote:
    On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
    wrote:
    Hi all,

    We've been using Camel for a while now and we are very happy with
    it!
    :-)

    Currently we are looking at using ZooKeeper in our project. As
    our
    project already uses Camel it makes sense to use Camel to interact
    with ZooKeeper. I've played around a bit with the ZooKeeper component
    and I've noticed that when a znode is deleted, the NodeDeleted event
    is not triggering my Camel route. Is this by design or could this
    point to an issue in the component?
    I am using Camel 2.9.1 and ZooKeeper 3.4.3.
    I dont think that is by design. Fell free to work on a patch to
    fix/improve this.
    We love contributions
    http://camel.apache.org/contributing.html

    The documentation though don't mention that delete events is sent.
    But it would make sense to get this event as well, as its also an
    important event.
    http://camel.apache.org/zookeeper

    Kind regards,

    Arnoud Glimmerveen


    -----------------------------------------------------------------
    ---
    -
    ---------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please
    notify the
    sender and delete it.
    Any unauthorized copying, disclosure or distribution of this
    email or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage
    caused by
    this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the
    Chamber of Commerce under number 06061578.
    -----------------------------------------------------------------
    ---
    -
    ---------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/ Author of Camel in Action:
    http://www.manning.com/ibsen/


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/ Author of Camel in Action:
    http://www.manning.com/ibsen/

    -------------------------------------------------------------------
    ---
    --------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify
    the sender
    and delete it.
    Any unauthorized copying, disclosure or distribution of this email
    or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused
    by this
    email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the
    Chamber
    of Commerce under number 06061578.
    -------------------------------------------------------------------
    ---
    --------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
    ----------------------------------------------------------------------
    --------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender
    and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its
    attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this
    email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber
    of Commerce under number 06061578.
    ----------------------------------------------------------------------
    --------------------------------------


    --
    Claus Ibsen
    -----------------
    CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
    FuseSource
    Email: cibsen@fusesource.com
    Web: http://fusesource.com
    Twitter: davsclaus, fusenews
    Blog: http://davsclaus.blogspot.com/
    Author of Camel in Action: http://www.manning.com/ibsen/
    ------------------------------------------------------------------------------------------------------------
    Disclaimer:

    If you are not the intended recipient of this email, please notify the sender and delete it.
    Any unauthorized copying, disclosure or distribution of this email or its attachment(s) is forbidden.
    Thales Nederland BV will not accept liability for any damage caused by this email or its attachment(s).
    Thales Nederland BV is seated in Hengelo and is registered at the Chamber of Commerce under number 06061578.
    ------------------------------------------------------------------------------------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedApr 10, '12 at 2:40p
activeApr 25, '12 at 3:50p
posts8
users2
websitecamel.apache.org

2 users in discussion

Claus Ibsen: 4 posts GLIMMERVEEN Arnoud: 4 posts

People

Translate

site design / logo © 2022 Grokbase