-
1. Re: Should users be notified of replication failures via a c
This confused me. Is this meant to be done on the replication recipient side? In that case I understand the callback idea, as an Exception will just propagate back to the RPC handler and be dropped.
-
2. Re: Should users be notified of replication failures via a c
Here's the use case:
- Node A and B
- A made a modification, sends the replication *asynchronously* to B. Can also be synchronous, just *no* TX
- B cannot apply it, e.g. because some other TX has locked the data
- The lock acquisition timeout on B kicks in and we don't apply the change on B
- A will have applied the change, but not B
- This is without TXs, or even with a TX but in async mode
- It would be good if we had a callback that was called on B if the replication could not be applied successfully.
- A cache exception does not work here, as the caller doesn't wait, and even if it did, we cannot throw an exception if we send the modification to B,C,D, and only B fails -
3. Re: Should users be notified of replication failures via a c
Ok, this is clearer. I thought you were talking about A being notified of B's failure.
Ok, makes sense, but still not something I'd like to have in the CacheListener since this should not be the way to deal with exceptional circumstances.
Perhaps another listener to deal with such asynchronous exceptional cases? Still ugly, but at least we don't clutter the "regular use" listener, listening for normal events. -
4. Re: Should users be notified of replication failures via a c
Yes, I know it is clutter, but I think it is important. Your call. I mean, after all, we do log this exception. It is just for the case when a user wants to take some corrective action if repl fails
-
5. Re: Should users be notified of replication failures via a c
Agreed that this is important. Perhaps a separate listener then? An exception listener of sorts?