"For example, it relies on the fact, that Thread.interrupt() interrupts IO Operations such as read on network sockets. "

This is wrong for a start. JDK1.4 was fixed/changed such that interrupt works on I/O.
One some OSes/JVMs it worked in JDK1.3 as well.
It doesn't help if the thread is spinning without hitting I/O or a wait() block, but then
nothing helps there.

Setting the read timeout to zero is a stupid configuration.

The other issues, I leave for somebody more familiar with the code.

The user provides changed source code rather than a diff, so the barrier to entry
too great to understand what is changed.

"If you set a socket timeout, the read will terminate after
the timeout. But this is completely unrelated to the interrupt. "

Correct. That is why I put it in a different paragraph.

Having a read timeout of zero means you are open to hanging sockets
due to network splits, TCP/IP RST packets getting lost, etc.

What I want to see is some proof that the problem is really that I/O is not interrupted
rather than some other issue, including the usual suspects
* broken/misconfigured tcp/ip stack
* broken network card or firewall problem
* broken or mismatching JVM/c library
* etc.

I don't see any evidence of getting to the cause in your "bug" report.
Just assertion that this is the cause. Which is why I changed it to a patch.
It obviously fixes whatever it is you are seeing.

Interrupting the wrong thread sounds more like the cause to me?