I create a PR[1] about observation persistency.
I think this is in reviewable(mergeable?) state. So feedback are
welcome.
The next question is: In which branch should we integrate this ? 1.1
or 2.0 ?
We can avoid API break (this is mainly API addition), but the
behavior changed as now notifications are no more available on
MessageObserver but on NotificationListener.
[1]https://github.com/eclipse/californium/pull/16
Le 11/02/2016 15:44, Simon Bernard a
écrit :
Julien wrote a wiki page about that : https://github.com/eclipse/leshan/wiki/Cluster
.
Le 14/01/2016 17:56, Kai a écrit :
I
am not very familiar with the specifics of the state
Californium keeps in memory for maintaining observations.
However, what you write makes sense to me.
The problem actually
goes even deeper if you also consider the state kept by
Scandium (DTLS sessions).
My understanding is that
we are having this discussion in the context of making
leshan (and thus Californium) highly available, i.e. being
able to fail over between instances. Maybe we should start
to work on that in the context of a set of features adding
support for HA on each level of the stack (scandium,
californium, leshan) while trying to establish a mechanism
that allows for maintaining consistent state across all
layers.
I think it is important to address this problem
consistently at all layers ...
Kai
Not so
much success with this one :p.
@Matthias, @Kai, what do you think about that ?
Le 10/12/2015 15:45, Simon Bernard a écrit :
> Hi,
> In Leshan, we have an ObservationRegistry
interface. We provide an
> in memory implementation. The idea should be to let
users implements
> persistence if they need it.
> But for observe, we must be able to persist the
californium state
> too. Should it exist a way to do that? (I look at
the code, and I
> don't think so)
> I suppose if you want to do that we should mainly
persist data in
> org.eclipse.californium.core.network.Matcher.
(exchangesByMID,
> exchangesByToken)
> Does it make sense ?
> Simon
> _______________________________________________
> 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
_______________________________________________
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
_______________________________________________
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
|