Recovery in Hook.io listeners

41 views
Skip to first unread message

Alex G

unread,
Jun 18, 2012, 8:13:22 PM6/18/12
to hoo...@googlegroups.com
I am new to hook.io so hopefully this question makes sense.  I am considering using Hook.io to keep local caches within individual node processes in relative sync (the cache will be relatively small and fast - larger datasets will be stored in redis).  So, for example, one node updates a cache object and hook.io emits the change and the other hooks pick it up and invalidate the relevant cache entry.  What happens in the case of a listener being unable to listen for a period of time and possibly failing to capture a message or two?  I would assume I would need to invalidate the entire cache.  But how will a particular hook know it missed an event?  Is there a way to know if a hook.io becomes disconnected for any period of time?  

Thanks,
Alex

darinc

unread,
Jun 18, 2012, 9:46:35 PM6/18/12
to hoo...@googlegroups.com
Alex,

As of hook.io 0.8.10 you can listen for and handle a 'hook::disconnected' event.
hook.on('hook::disconnected', function(data) {
  console.log('hook disconnected ' + data.name + ' do something!');
});
When the hook is disconnected, you could keep an array of changes and then push the changes out when the other server reconnects.

A different strategy would involve keeping a counter on the master node and pushing the sequence number out with every update.  If a client node detects a gap in the sequence, then it could request a specific update by sequence number from the master server.  Simple methods like this can exist for multi-master environments also, just also post the node server name or other unique identifier as well as the sequence number.

Let us know what you end up doing.
<>Darin

Marak Squires

unread,
Jun 18, 2012, 9:52:15 PM6/18/12
to hoo...@googlegroups.com
Agreed.

You can also attempt to use the remote callback feature to ensure each transaction makes the round trip.

The current hook.io API doesn't have much built in support for guarantees or contracted messages. I suspect we'll add it soon, but usually I try to design towards architectures that don't require message guarantees. 

If you are looking for inspiration, Substack has a solution for doing this using native dnode. It's not too hard to implement. 

--
-- 
Marak Squires
Co-founder and Chief Evangelist
Nodejitsu, Inc.

Alex G

unread,
Jun 19, 2012, 11:22:58 PM6/19/12
to hoo...@googlegroups.com
Perfect.  I missed the disconnected event.  I am going to keep it even simpler than maintaining changes as that would require more overhead than I want.  Basically, if the hook disconnects, then I am simply going to invalidate the entire cache of that node and it will simply have to grab new objects from the database as requested and then pop them back into its cache.  The data is metadata which will rarely change (read:writes will be in the order of 10s of thousands of reads vs 1 write).  I am assuming that the disconnected even will rarely occur in our environment.  If it does, then I think I like the sequence number of option.

Thanks for the assist.

Alex

Alex G

unread,
Jun 19, 2012, 11:40:57 PM6/19/12
to hoo...@googlegroups.com
Had not considered dnode/substack.  Will take a look at that.  Thanks.
Reply all
Reply to author
Forward
0 new messages