Re: Question about librados notification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 25, 2014 at 5:50 AM, Shinji Matsumoto
<shinji.matsumoto@xxxxxxxxxxx> wrote:
> Hello all,
>
> I have a question about Ceph notification mechanism.
> http://ceph.com/docs/master/architecture/#object-watch-notify
>
> Scenario:
>
> (1) 3 clients (client1, client2, client3) have interests on a Ceph
> object (object A). Each client calls rados_watch() to register
> notification callback on the object..
>
> (2) Client1 calls rados_notify()  on object A. On client1 and client2,
> the notification is delivered and processed successfully within a
> timeout period.
>
> (3) However on client3, the notification is delivered, but it doesn't
> complete within a timeout period for a temporary reason, such as
> temporarily busy process for instance.
>
> (4) On client1, rados_notify() returns a status of timeout.
>
> (5) On client3, the temporary reason goes away and the notification is
> processed.
>
> (6) Then, client3 attempts to read from object A by a call to rados_read().
>
> Question:
>
> Will the call to rados_read() attempted at step (6) always succeed,
> always fail or is the behavior unpredictable, which is, it's affected
> by the factors that are not defined in this scenario?

The success of the read is not impacted by the notify timeout -- you
can order reads using watch-notify, but issues in the watch-notify
framework won't impact reads. Watch-notify is a voluntary thing. IIRC
the OSD involved might kill client3's connection, but it'll just
establish a new one transparently.
-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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [CEPH Users]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux