Camel › Camel - Users

Receiving NodeDeleted event using Camel's ZooKeeper component

Classic

List

Threaded

8 messages Options

GLIMMERVEEN Arnoud

Receiving NodeDeleted event using Camel's ZooKeeper component

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.
------------------------------------------------------------------------------------------------------------

Claus Ibsen-2

Re: Receiving NodeDeleted event using Camel's ZooKeeper component

On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
<[hidden email]> 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-2

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 <[hidden email]> wrote:

> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
> <[hidden email]> 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: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/

GLIMMERVEEN Arnoud

RE: Receiving NodeDeleted event using Camel's ZooKeeper component

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 [mailto:[hidden email]]
Sent: Saturday, 14 April, 2012 09:31
To: [hidden email]
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 <[hidden email]> wrote:

> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
> <[hidden email]> 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: [hidden email]
> 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: [hidden email]
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-2

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
<[hidden email]> 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 [mailto:[hidden email]]
> Sent: Saturday, 14 April, 2012 09:31
> To: [hidden email]
> 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 <[hidden email]> wrote:
>> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
>> <[hidden email]> 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: [hidden email]
>> 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: [hidden email]
> 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.
> ------------------------------------------------------------------------------------------------------------
>

GLIMMERVEEN Arnoud

RE: Receiving NodeDeleted event using Camel's ZooKeeper component

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 [mailto:[hidden email]]
> Sent: Monday, 16 April, 2012 10:57
> To: [hidden email]
> 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
> <[hidden email]> 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 [mailto:[hidden email]]
> > Sent: Saturday, 14 April, 2012 09:31
> > To: [hidden email]
> > 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 <[hidden email]>
> wrote:
> >> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
> >> <[hidden email]> 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: [hidden email]
> >> 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: [hidden email]
> > 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: [hidden email]
> 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-2

Re: Receiving NodeDeleted event using Camel's ZooKeeper component

On Tue, Apr 17, 2012 at 5:44 PM, GLIMMERVEEN Arnoud
<[hidden email]> 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 [mailto:[hidden email]]
>> Sent: Monday, 16 April, 2012 10:57
>> To: [hidden email]
>> 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
>> <[hidden email]> 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 [mailto:[hidden email]]
>> > Sent: Saturday, 14 April, 2012 09:31
>> > To: [hidden email]
>> > 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 <[hidden email]>
>> wrote:
>> >> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
>> >> <[hidden email]> 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: [hidden email]
>> >> 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: [hidden email]
>> > 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: [hidden email]
>> 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.
> ------------------------------------------------------------------------------------------------------------
>

GLIMMERVEEN Arnoud

RE: Receiving NodeDeleted event using Camel's ZooKeeper component

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 [mailto:[hidden email]]
> Sent: Saturday, 21 April, 2012 11:07
> To: [hidden email]
> Subject: Re: Receiving NodeDeleted event using Camel's ZooKeeper
> component
>
> On Tue, Apr 17, 2012 at 5:44 PM, GLIMMERVEEN Arnoud
> <[hidden email]> 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 [mailto:[hidden email]]
> >> Sent: Monday, 16 April, 2012 10:57
> >> To: [hidden email]
> >> 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
> >> <[hidden email]> 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 [mailto:[hidden email]]
> >> > Sent: Saturday, 14 April, 2012 09:31
> >> > To: [hidden email]
> >> > 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
> >> > <[hidden email]>
> >> wrote:
> >> >> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud
> >> >> <[hidden email]> 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: [hidden email]
> >> >> 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: [hidden email]
> >> > 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: [hidden email]
> >> 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: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/