On Thu, Aug 21, 2014 at 3:34 PM, Sage Weil <[email protected]> wrote: > Sam and Josh and I discussed the state of watch/notify a couple weeks > back. Here are our notes: > > http://pad.ceph.com/p/watch-notify > > I've mapped most of these to tickets or bugs and noted them in the pad. > > Ignore the fact that these are in the v0.86 sprint currently; it's just > easier to enter them that way. > > If there are other issues we're missing here, let's address them now. The > API changes so far can be seen at > > > https://github.com/ceph/ceph/commit/7ba30230505c6eede06cb2e2cb64210fdd4025a8 > > https://github.com/ceph/ceph/commit/d179dd970e52db8b0c07b20f69c9e3be6bc43f09
I'm not entirely up on how watch-notify is implemented right now because it's been a bit of a mess, but this set of patches is a lot smaller than I was expecting when I started hearing about reworking it. The specific problem I remember remaining is: 1) Notifiers can specify a timeout after which point the notify gets completed regardless of the status of the watchers 2) Watchers have a separate timeout (which is often larger) 3) There's no notification to either the watchers or the notifier if the notify timeout is hit. So it looks like this patch set addresses point 3 by telling the *notifier* that the notification didn't actually happen; correct? Are there plans to change this so that either we don't have the overlapping timeouts, or a timeout triggers a watch failure for the timed-out watcher (and a callback to them, if possible), or the notifier has some recourse under this failure scenario? This might be #9195, but there's not enough detail in that series of tickets for me to be certain. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
