On Tue, Apr 17, 2012 at 5:44 PM, GLIMMERVEEN Arnoud <[email protected]> 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:[email protected]] >> Sent: Monday, 16 April, 2012 10:57 >> To: [email protected] >> 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 >> <[email protected]> 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:[email protected]] >> > Sent: Saturday, 14 April, 2012 09:31 >> > To: [email protected] >> > 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 <[email protected]> >> wrote: >> >> On Tue, Apr 10, 2012 at 4:39 PM, GLIMMERVEEN Arnoud >> >> <[email protected]> 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: [email protected] >> >> 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: [email protected] >> > 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: [email protected] >> 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: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
