Ok I get it :)
(I know this is not defined like this in the
spec, but should it be simpler to precise ETag
on GET (block2) ? This way server may be able to
return the right block or just said I don't have
this block anymore)
That
does not really help. REST enables the server to
be simple. This is what we want to exploit, and
hence put the servers on the small devices
(which are sensors and actuators, and hence
naturally the origin of data). Thus, the client
should not attempt to burden the server by
asking for specific representations.
This shows, that we need
more information than just the initial request
in the shared persistence store. We need the
Exchange object as usual, and actually extend it
with the ETag information to have this feature.
Sharing the
whole Exchange object does not make sense. (see
how many complex attributes there is in this
class)
We should determine which attributes we need to
share.
We currently share the request, the
correlationContext. This conversation show that
we will surely need the ETag information too.
About blockwise status, I think we should not
shared it between instance, we should keep it in
memory. (We don't need to
handle cross instance blockwised transfer)
As
I said, I do not care how you implement the
shared ObservationStore. Optimize the hell out
of it! :D
It
simply must store all the information necessary
to run the protocol correctly.
It is indeed missing in
1.0.x and must be added for correct behavior.
(We cannot do anything if a server does not
include an ETag, but sends out notifications
faster than all blocks can be retrieved.)
My current PR
doesn't handle this correctly but if this is not
implemented in 1.0.x, I think this should be
part of another PR than the clustering one ?
I would like to limit the scope of the PR or I'm
afraid we never integrate it :/
Yes,
sure. This work simply triggered a lot of
concerns that should be answered. Yet of course
the changes should be done incrementally through
nicely packaged pull requests.
My recommendation for the
implementation is to have the ObservationStore
Interface, with the local hashmap class and the
shared persistence store class as described in
my other mail.
(not sure to see
which mail you talked about)
Copied:
“I agreed on the separate
ObservationStore. I understood that it will have
an interface, so it can be backed by a local
implementation similar to the hashmaps we
already have. In cluster mode, it is backed by a
class that connects to an external shared
persistence store, so each node can be made
aware of existing Observe relationships. I don't
care if this class creates an Exchange object
every time or actually persists the original.
The Exchange object returned through the
interface must simply have all the information
necessary to process the incoming message
locally. As long you do not remove the entry
from the shared persistence store, I don't see
the Exchange as completed, but it will not be in
the local hashmaps anyway. We will not need it
in the Deduplicator either, if you have a
NotificationOrderer further up...”
Whoever decided to observe
something, must let one node do the
registration, but also make sure the information
is put into the shared persistence store (maybe
by the node doing the registration). Once this
decision maker decides to cancel, it must remove
the information from the shared persistence
store. Then, any node will reject the next
notification. Additionally, one node could be
tasked with a proactive cancellation.
This is what I
tried to implement in the current PR.
(The tests we did in Leshan seems to show that
this works)
https://github.com/eclipse/leshan/pull/113
Okay.
This is still a bit clouded for me, since I do
not understand the idea behind the
NotificationListeners.
Then, the initial response
as well as all notification must go to the same
handler. This should not be different from a
regular response handler.
Currently the
initial response is not accessible through the
notificationListener but I can change it.
Even if I'm not totally convinced that was a
good idea ... The spec clearly made the
difference between the registration and
notification (https://tools.ietf.org/html/rfc7641#section-1.2)
The central decision maker
must be informed when the initial response does
not contain the Observe option; it then needs to
fall back to polling and task a node with it.
This reinforce
that the initial response and the notifications
should not be handle in a same way.
You
must be prepared to receive a response without
Observe option at any time. The “usual” case is
when you receive an error message. The
initiative is with the client to ensure it gets
the representations it wants.
Anyway, this is pretty much what it is currently
implemented in the PR. MessageObserve allow to
get the initial response and so knowing if the
observation is ok or not and so fall back to
polling if necessary.
NotificationListerner is used to get
notifications (We just need to decide if the
first response is a notification or not)
You
still did not answer my question from previous
mails and the PR comments: what is the idea
behind the list of NotificationListeners? Does
each one correspond to a node in the cluster?
How does this help?
Now the
NotificationOrderer is still missing. As noted
in the other mail (or was it GitHub?), this
depends on the application. It could be a
similar thing to the ObservationStore that is
synced across all nodes. Or it could be done in
the handler itself when writing to a database
(also in a synchronized fashion).
Ok, I think this
should be part of another PR too.
It
should, but you cannot ignore this for the
architecture. You will need something similar to
the shared ObservationStore that ensures node A
does not process an old notification after node
B processed the newest. You also must ensure a
synchronized write to a database. And you need
to make sure this decision maker has a
consistent view on the status of the Observe
relationship.
So
far we used a ConcurrentHashmap for performance
reasons. Responses and Notifications are in the
same hashmap, and hence we can have a race
condition of two notifications climbing up the
stack in different stacks. The synchronization
was only done for notifications (the
NotificationOrderer). Now that we have to
notification exchanges in a separate store and
need to synchronize it anyway, we could use this
directly to order the notifications (i.e., only
accept the newest and let it climb up the stack
to the handler).
Now
that the ordering is solved (:P), why do we need
a list of NotificationListeners?
Does this help?
Yes it does,
thanks for your time Matthias ;).
I hope my answer show that the content of the
current PR is near of what you expect.
(I will not be available the next 3 weeks, so no
surprise if I don't answer during this period)
Okay,
I hope it is enjoying vacation :)
It
would be great if you could solve the riddle of
the NotificationListeners before you leave! ;)
Ciao
Matthias
_______________________________________________
cf-dev mailing list
cf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cf-dev
