question about router deactivation order

[davissuber]

question about router deactivation order

[davissuber]

When using RIBs with simple-store - it's quite reasonable to use the lifecycle provided by RIBs to manage simple-store (or any other resource that can only be opened once and needs to be closed when done).

In the current ordering where the children outlives the parent RIB, if one opens the simple-store in the parent RIB with the intention that both the parent RIB itself and the child RIB will make use of the store - there's a small window where the parent RIB will be deactivated (and the store cleaned up) while there are still activities coming from the children that make use of the store.

We are seeing some sporadic "the store is already closed" errors that could be caused by the current parent-child-deactivation-ordering - but still collecting evidence of such claim / find other causes and want to do some tentative finger-pointing in the process.

[psteiger]

Did you encounter a specific use case where you would rather have your suggested behavior instead of the current behavior?

With that asked, in principle I agree with you: children must have a lifecycle less than or equal to the parent, so it makes sense for them to be deactivated before the parent.

[davissuber]

An update: we are able to repro the issue and it does seem that this ordering of children outliving the parent is creating problem for unsuspecting developers who binds an SimpleStore to the parent RIB's lifecycle, and use the store in the children lifecycle.

Perhaps the sharing of simple store across different scope provider per se is a bad way to use that library and one shouldn't make any strong assumption between parent and child scope deactivation order. 🤷

At any rate, given the potential impact of swapping the deactivation order at RIBs level - we are seeking alternative solutions to our problem at the moment, but it is our belief that the current behavior is creating some surprises in managing resources like simple store.