JBAS-2448 - Pooled Invoker Patch

[adrian.brock]

This is the discussion thread for
http://jira.jboss.com/jira/browse/JBAS-2448

[adrian.brock]

"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.

[tr0000]

> 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.

If you set a socket timeout, the read will terminate after
the timeout. But this is completely unrelated to the interrupt.
(Tested even with Java 1.5)
The interrupt won't make it terminate faster.
So if you set a timeout of say 120 seconds, an unused connection
won't be reused immediately. On the other hand, if there
are pooled connections, they will be terminated if they are
unused for the time, even if they are not needed and could
stay pooled.

[adrian.brock]

"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.

[adrian.brock]

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?

[tr0000]

The only behaviour I could reliably reproduce so far depends on socket timeout 0. The rest of the analysis at this point comes from looking at the code. So changing the status from bug to patch is fine with me.

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

I don't unterstand the reason behind using interrupt in the
original code. The only place I see where interrupt could possibly affect the ServerThread is the this.wait() call.
The comments in the code suggest otherwise.

[starksm64]

The patch is really a significant rewrite that needs to be reviewed for the underlying issue. Since I have updated the pooled invoker to support propagation of the ssl session id, the current patch is out of date.