L1nq0 commented on issue #9074: URL: https://github.com/apache/storm/issues/9074#issuecomment-5525438001
Thanks — a PR with tests is doable. Before I start, the design question is which exceptions should follow the existing "log + close connection, worker survives" path instead of terminating the worker. Today `exceptionCaught` tolerates only `IOException`, and notably it already closes the connection after a tolerated exception, so "close the connection, not the worker" isn't a new mechanism — it's extending an existing one. The client-side handler (`StormClientHandler.exceptionCaught`) also never terminates the process, so this would bring the two sides closer. Two directions: 1. Extend the tolerated set at `StormServerHandler` with the decode exception types. Smallest diff, but the observed failure arrives as `IllegalArgumentException` / `IllegalStateException` from Kryo's registration lookup, and those types are broad enough that extending the set with them could also downgrade genuine bugs elsewhere in the handler into connection-closes. `KryoException` alone wouldn't cover the observed case. 2. Catch at the deserialization boundary (inside the server's received/decode path, not in `exceptionCaught`): any throwable from tuple deserialization becomes the tolerated path — WARN log + `ctx.close()`, worker survives. Everything not from the decode stage keeps today's fail-fast semantics. Slightly larger diff, but precise: it can't mask bugs outside the decode path, and it covers every decode failure mode (`KryoException`, `IllegalArgumentException`, truncated buffers, future Kryo changes) without maintaining an exception-type list. My lean is (2). Happy to hear your take — or if you see a better direction, I'll build that instead. Tests would cover: a decode failure closes the connection and the worker keeps serving, plus valid-traffic regression. -- 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]
