You can't do anything about the inefficient use of the servlet except for reducing the timeout. Of course, doing so is a trade-off. Regarding the timeout exception - how to treat it depends on the app and your intentions. The simplest way in general is to pretend the request has never happened in the first place. Another way would be to store the fact that it's been made and let the user know that that specific request has failed and maybe should be retried. There might be other reasonable approaches as well. "Malformed request" seems to be tangential and, if I had to guess, is probably a result of the timeout exception being used instead of the request body in the content negotiation/parsing code.

I think it’s not desirable to consider connection lost as malformed json request. Decoding process over successfully transmitted data is good because you can tell what was wrong, network or user.

I suspect that I might have misconfigured the Jetty or Muuntaja middleware.

Another potential source of that error - the body gets decoded not as a fully read byte array but as a stream. If a stream has {"a": [<EOF>, that would also probably lead to that error, without anything being misconfigured. But whether or not it's specifically EOF that's the problem should've been specified in the exception itself.

That's a good point. Can you give me a hint to make such request for debugging?

IIRC curl has an option to transmit slowly.