The Backplane is a powerful component in FusionCache, and as it is today is already a pretty good feature that works really well.
Some edge cases though are not currently handled in the best way:
β Better handle connection/subscription errors
FusionCache should be more reactive regarding connections and re-connections of the underlying backplane implementations: in this way the system as a whole can react faster to these types of events.
For example this can be used to start an auto-recovery queue processing sooner, instead of the way it currently is where the processing starts at the first message received: in a highly used system this is not a problem, but with less traffic this may be noticeable.
β Change the defualt AutoRecoveryMaxSize to null (unlimited)
Currently it is 100, which is honestly too low: it's better to make it unlimited so that the default experience will be to not loose any message.
β Add support for fake connection strings in MemoryBackplane for better concurrency
The MemoryBackplane used in testing scenarios uses a private singleton to keep track of all the subscribers connected: the problem is that in this way multiple tests running concurrently may interfere with each others.
We should introduce a ConnectionId, which is just an opaque string that can have any value, which would be equivalent to a connection string in a standard client-server implementation.
In the tests, it will then be possible to just create a random one with every test, so that collisions will be avoided completely.
β More control on circuit breaker manual closing (when receiving a message)
Currently there's no way to force a circuit breaker to close, and this may be useful for when the circuit breaker is open but something happens that guarantee it can be closed again.
An example of this can be when the circuit-breaker is used with the backplane, and a new message comes in: in this case we'll know for sure that the backplane is functioning again, so we can forcibly close (re-enable) it.
Solution
Fix the issues above and more, and optimize the shit out of it.
Problem
The Backplane is a powerful component in FusionCache, and as it is today is already a pretty good feature that works really well.
Some edge cases though are not currently handled in the best way:
β Better handle connection/subscription errors
FusionCache should be more reactive regarding connections and re-connections of the underlying backplane implementations: in this way the system as a whole can react faster to these types of events.
For example this can be used to start an auto-recovery queue processing sooner, instead of the way it currently is where the processing starts at the first message received: in a highly used system this is not a problem, but with less traffic this may be noticeable.
β Change the defualt
AutoRecoveryMaxSize
tonull
(unlimited)Currently it is
100
, which is honestly too low: it's better to make it unlimited so that the default experience will be to not loose any message.β Add support for fake connection strings in MemoryBackplane for better concurrency
The
MemoryBackplane
used in testing scenarios uses a private singleton to keep track of all the subscribers connected: the problem is that in this way multiple tests running concurrently may interfere with each others.We should introduce a
ConnectionId
, which is just an opaque string that can have any value, which would be equivalent to a connection string in a standard client-server implementation.In the tests, it will then be possible to just create a random one with every test, so that collisions will be avoided completely.
β More control on circuit breaker manual closing (when receiving a message)
Currently there's no way to force a circuit breaker to close, and this may be useful for when the circuit breaker is open but something happens that guarantee it can be closed again.
An example of this can be when the circuit-breaker is used with the backplane, and a new message comes in: in this case we'll know for sure that the backplane is functioning again, so we can forcibly close (re-enable) it.
Solution
Fix the issues above and more, and optimize the shit out of it.