|
(In reply to Milos Fabian from comment #4)
> (In reply to Claudio D. Gasparini from comment #3)
> > (In reply to Milos Fabian from comment #2)
> > > (In reply to Milos Fabian from comment #1)
> > > > Reminds me https://bugs.opendaylight.org/show_bug.cgi?id=4488
> > > > My theory:
> > > > When new peer ("A") connects, it register itself to the
> > > > "ExportPolicyPeerTracker" (it's shared resource). Before the LocRibWriter
> > > > gets a data change notification about peer "A", another peer ("B") has
> > > > disconnected and it's routes are removed from Loc-RIB and from RIB-Outs of
> > > > other peers (based on peers registered in ExportPolicyPeerTracker). So we
> > > > are also trying to remove routes from peer "A" RIB-Out, however there no
> > > > routes.
> > > >
> > > > Simply it is a race condition on shared resource.
> > >
> > > This ExportPolicyPeerTracker registration change was done because of
> > > https://bugs.opendaylight.org/show_bug.cgi?id=6747
> > > We might consider adding some additional flag to ExportPolicyPeerTracker,
> > > set when LocRibWriter discovers a new peer, until that peer is excluded from
> > > RIB-Out modification operations.
> >
> > I don't think that is the cause of the issue, when we do remove something
> > that doesn't exist there is no Exception error, indeed not change event is
> > produced under RibOutListener since nothing has changed.
> > Indeed for check this, I
> > - commented out addPathToDataStore -> therefore not path will be write under
> > Loc
> > - Post IPV4 Route via App Peer
> > - Remove previously route
> >
> > and as expected, AbstractRouteEntry#deleteRoute is executed and not
> > exception is thrown even that path is not there.
> >
> > I think the cause is removing when parent doesn't exist.
> > 1- It can be because peer still going up.
> > 2- Changes is listen meanwhile peer is closing.
>
> Yeah, you are right, it is complaining because of missing parent.
> Still, shared ExportPolicyPeerTracker is an issue.
> So, the peer's empty tables (including RIB-Out) are created in RibInWriter,
> so peer's registration to ExportPolicyPeerTracker should be done once the
> tables are successfully written (write TX submit future is done)?
register the flag once tables are written is not possible, since
LocRib initialize Peer with existent routes once it detects that new table has been created, then it can be a race between adding the peer to registry and the route initialization itself under LocRib.
Best solution as you mentioned before is to add a flag under Registry.
Aside from that, this is not the issue of this bug ( I will create a bug for previous issue).
Here the race is when peers are going down. They close and do clean up, but at the same time LocRib listen changes from the others peers removal and try to remove routes.
|