Maciek Sakrejda wrote:
> Any thoughts?
How about, instead of using raw monitor synchronization to provide
mutual exclusion on access to the stream, we use a lock object (i.e.
something similar to java.util.concurrent.locks.Lock, though we can't
use exactly that class before 1.5 obviously), try to grab the lock
before close, and behave differently depending on if we succeeded or not.
So the close logic can look something like this:
if (lock.tryLock()) {
// we have exclusive access to the connection
// do a normal shutdown
try {
sendTerminate();
stream.close();
} finally {
lock.unlock();
}
} else {
// something is concurrently using the connection
// just abruptly close the connection
stream.close();
}
In the concurrent case, we don't send Terminate, but we also don't risk
sending it at the wrong point in the stream.
This means that a concurrent Connection.close() while something is
happening will result in an "unexpected client EOF" logged on the server
side, but that's almost what you want in this case anyway .. concurrent
close pretty much means "help, abort this!" ..
-O
