L1nq0 opened a new issue, #9074: URL: https://github.com/apache/storm/issues/9074
While testing Storm 3.0.0 locally (official binary distribution, local Docker cluster, default configuration), we found that a worker process terminates whenever Netty frame decoding throws anything other than an `IOException`. `StormServerHandler.exceptionCaught` (storm-client, `messaging/netty/StormServerHandler.java`) only tolerates `IOException`. Any other throwable raised while decoding a frame - for example `IllegalArgumentException` from Kryo for an unregistered class name, or `KryoException` on a truncated buffer - escalates to `Utils.handleUncaughtException` and terminates the worker process (exit code 20, then supervisor restart). On a stock 3.0.0 cluster with default settings, a single malformed 27-byte frame sent to a worker port deterministically kills the worker before the message is routed to any task. We verified two independent frames, two kills, each within about three seconds. Since this failure happens at the decode stage and involves no topology logic, widening the tolerated exception set for decode-stage errors (or skipping the offending frame with a log line) and reserving process termination for executor-stage failures would make workers resilient to arbitrary malformed input without changing behavior for valid traffic. Happy to share our reproduction steps or a prototype patch if that would be useful. -- 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]
