Disconnect causing READ_OP?

[Remon van Vliet]

(e-mail address removed) wrote:
[yards of offensive & irrelevant matter snipped]

Sigh. Ignoring, with great difficulty, 98% of your message which
consists of an ad hominem attack on me, I will deal with the
ever-decreasing factual content, for the last time. Isnt that the truth.

Socket.shutdownInput() does not close the socket, contrary to what you
said about a hundred messages ago, and Socket.shutdownOutput() doesn't
either, although it can give the other end the impression that it has.
The only two APIs that close the socket from the OS point of view are
Socket.close(), or SocketChannel.close() which is equivalent: if the
channel is registered this cycle must be completed by
Selector.selectXXX() for all the selectors concerned. There was a bug in
this area concerning blocking socket channels with timeouts which is now
closed, and there were lots of Channel I/O/select bugs in the early
releases of JDK 1.4 which AFAIK are also now closed (although I
certainly do not claim that NIO is error-free).

True, however, i did find that using Socket.close() or SocketChannel.close()
did not cause my server to see a new OP_READ, the shutdown methods did. As
opposed to the person you're argueing with i do consider this a workaround
though.

 

[iksrazal]

Esmond Pitt escreveu:

(e-mail address removed) wrote:
[yards of offensive & irrelevant matter snipped]

Sigh. Ignoring, with great difficulty, 98% of your message which
consists of an ad hominem attack on me, I will deal with the
ever-decreasing factual content, for the last time.

Sigh likewise. This will also be my last post as you just continue to
provably mis-represent my previous posts. And lets not forget that the
"ad hominem attack" started with your comment:

"Keep taking the pills."

Play with fire, burn your fingers.

Socket.shutdownInput() does not close the socket, contrary to what you
said about a hundred messages ago, and Socket.shutdownOutput() doesn't
either,

For the second time I will say I qualified Socket.shutdownInput() with
'IIRC' . I note that the last bug report leaves Socket.shutdownInput()
in the 'if(workAround) ' .

although it can give the other end the impression that it has.

The local connection going from CLOSE_WAIT to TIME_WAIT is no
impression but a simple fact shown by running code via the
shutdownOutput() method. And of course it has nothing to do with the
other end as in that case the server side is completely closed. There
probably are other situations regarding close() but that is
demonstrated in the test case I suppled which you responed to with mere
speculation.

Even still, if you admitted that posibility in the beginning - which I
stated I personally seen from my first post and took time to prove - it
would have saved a lot of time and could have avoided bad feelings.
Others have seen the same thing.

The only two APIs that close the socket from the OS point of view are
Socket.close(), or SocketChannel.close() which is equivalent: if the
channel is registered this cycle must be completed by
Selector.selectXXX() for all the selectors concerned. There was a bug in
this area concerning blocking socket channels with timeouts which is now
closed, and there were lots of Channel I/O/select bugs in the early
releases of JDK 1.4 which AFAIK are also now closed (although I
certainly do not claim that NIO is error-free).

So the bug reports were not futile? "must be completed by
Selector.selectXXX()" is pure moonshine.

I'm sorry if you can't understand that, or if you think that ad hominem
attacks on me constitute debate, but I can't follow you down any of
those paths. The 'yet another bug report' you cite is a duplicate, was
closed by Sun in 2002, and does not bear on any of the issues you have
raised. Neither do any of the related bugs, which are also closed. None
of them supports your contention.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4726957

"This is still reproducible with java 1.5.0beta2"

"CUSTOMER WORKAROUND :
-use Socket.shutdownOutput() and shutdownInput() instead of
close(). The former results in a FIN segment.
-use "new Socket(..)" instead of SocketChannel.open(..) if
non-blocking IO is not needed
-don't use setSoTimeout() if not needed
(Review ID: 160421) "

Perhaps your pounding on the table works elsewhere - you seem to try it
a lot.

It is curious that you are prepared to regard Sun, the author of these
bugs, as an authority, but not the TCP/IP RFC or W.R. Stevens who is
indeed dead and white and male, but who knew more about it that either
you or I. I'm not so concerned with your own misunderstandings, as you
evidently know very little about TCP/IP and even less about rational
problem solving (profiling constitutes debugging?), but I don't like to
see misinformation spread on the newsgroups to mislead others.

Pure mis-representation and confirms your condescending fallback
approach when the facts are clearly against you.

Concerning profiling, a mere look at my posts irrefutably show I was
curious if there was a non-trivial performance difference between
selectNow() and shutdownOutput() , and in general is what I rely on
before changing code and blindly assumming a performace boost. As
stated I believe profilers before specs.

Concerning TCP, you shouldn't need to know a lot at the API level of
Java. Nevertheless and at the risk of every syllable I write being
analysed and needlessly attacked, the CLOSE_WAIT state can be caused by
at least two methods; The first being far more common and is what I
have seen:

a) The remote side has closed the
connection, but the local socket is still open.
b) remote side has called shutdown(SHUT_WR). This would make the TCP
connection unidirectional, from the local to the remote side.

The SocketChannel.close() method provably does not change the state of
CLOSE_WAIT up until at least v1.4.2 when used with setSoTimeout().

A call to shutdownOutput() performs a final read() to
the filedescriptor of the port and clears CLOSE_WAIT.

I am just trying to correct an error which you perpetrated, but I would
agree that at this point I have lost track of what you are now actually
trying to prove. The appearances are that you have too.

The whole thing got started when I tried to help someone out by
pointing out the shutdown*() calls, who thanked me as it worked for
him. You've been as rude as you are wrong ever since. Goodbye.

iksrazal

 

[iksrazal]

Low signal to noise for sure. It is a workaround - no doubt about it.
SocketChannel.close() should by itself do the job.

iksrazal