(missed CCing the list on my reply to Oliver)
> 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
>
That's interesting. I think it's not quite in the spirit of the
protocol, but there may not be much more we can do, and it's certainly
a reasonable behavior. I'd like to spend some more time with the FEBE
spec tomorrow and then I'll submit a patch based on this approach.
Thanks,
--
Maciek Sakrejda | Software Engineer | Truviso
(650) 242-3500 Main
(650) 242-3501 F
msakrejda@truviso.com
www.truviso.com
