anton-vinogradov commented on code in PR #13095:
URL: https://github.com/apache/ignite/pull/13095#discussion_r3579430984
##########
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/transactions/IgniteTxHandler.java:
##########
@@ -430,12 +432,21 @@ public IgniteInternalFuture<GridNearTxPrepareResponse>
prepareNearTxLocal(
IgniteTxEntry firstEntry;
try {
- IgniteTxEntry firstWrite = unmarshal(req.writes());
- IgniteTxEntry firstRead = unmarshal(req.reads());
+ IgniteTxEntry firstWrite = initialize(req.writes(),
req.topologyVersion());
+ IgniteTxEntry firstRead = initialize(req.reads(),
req.topologyVersion());
firstEntry = firstWrite != null ? firstWrite : firstRead;
}
catch (IgniteCheckedException e) {
+ try {
+ req.onClassError(e);
Review Comment:
The receive pipeline split moved the heavy unmarshalling (and its
class-error handling — `onClassError` + `processFailedMessage`, which is what
makes the near node fail fast instead of waiting out the timeout) into
`GridCacheIoManager`'s message pass. What's left here — `initialize()` binding
entry contexts — can still throw (`CacheInvalidStateException` when the cache
is stopped concurrently), and that happens *past* the io-manager's catch.
Without this block such a request would produce no response at all, leaving the
near node hanging. So the catch just repeats the same failed-message handling
for the residual failure mode. Exercised by the
`IgniteCacheP2pUnmarshalling*ErrorTest` family (green).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
