Adding SocketChannel toString to connection exception messages

[Chris Hegarty]

> On 29 Dec 2017, at 00:33, Steven Schlansker <stevenschlansker at gmail.com> wrote:
> 
> Thanks for the discussion!
> 
> So, it sounds like amending the message by default is going to be a non-starter -- but at least adding the information otherwise might be possible.
> 
> One possibility would be to add new fields to SocketException, for example an InetSocketAddress representing both the local and remote (if available).

You would need to careful to not disclose resolved addresses to untrusted code. SocketException, since a subtype of IOException, can wind up in many places.

Would you be proposing to add these new fields to the serial-form of SocketException? What behaviour do you envisage for deserializing instances from previous releases? This will have an impact of any potential API.

> This would not be rendered by default, but could be retrieved by a cooperating application or library.  Or maybe a second step could be a '-Djavax.net.debug=exceptions' that then appends this information by default, but that sounds more controversial.

Logging seems like a better alternative than a system property, to me.

> Then at least libraries and applications have the ability to get these diagnostics, even if they choose not to.
> Is this an acceptable approach?  Would it be accepted as a patch?

I suspect that a webrev/patch would help drive the discussion, rather than a commitment to accepting it into the JDK.

-Chris.



>> On Dec 22, 2017, at 8:42 AM, Bernd Eckenfels <ecki at zusammenkunft.net> wrote:
>> 
>> Hello,
>> 
>> I also dearly miss Socket addresses in connection exceptions, however it looks like it is not going to make it. However if we add a getter for the Peer address (not included in toString) then logging frameworks could detect instances of ConnectException and process them accordingly.
>> 
>> Gruss
>> Bernd
>> --
>> http://bernd.eckenfels.net
>> ________________________________
>> From: net-dev <net-dev-bounces at openjdk.java.net> on behalf of Chris Hegarty <chris.hegarty at oracle.com>
>> Sent: Friday, December 22, 2017 4:17:31 PM
>> To: Seán Coffey; David Holmes; Steven Schlansker
>> Cc: core-libs-dev; net-dev at openjdk.java.net
>> Subject: Re: Adding SocketChannel toString to connection exception messages
>> 
>> 
>>> On 22/12/17 14:59, Seán Coffey wrote:
>>> As someone who works with alot of log files, I'd like to chime in and
>>> support Steven's end goal. Looking at a "Connection refused" error in
>>> the middle of a log file that possibly extends to millions of lines is
>>> near useless. In the era of cloud compute, diagnosing network issues is
>>> sure to become a more common task.
>>> 
>>> While we may not be able to put the sensitive information in an
>>> exception message, I think we could put it behind a (new?) system
>>> property which might be able to log this information. Logs contain all
>>> sorts of sensitive data. Take javax.net.debug=ssl output for example.
>> 
>> I have some sympathy for (capital-L)ogging such detail messages
>> ( given the reasonable restriction on access to log files ), but
>> a system property that effectively amends exception detail
>> messages, or prints to stdout/stderr is not a runner in my
>> opinion.
>> 
>> Maybe we should be looking at instrumentation with JFR events, or
>> similar. My point being, if someone has time and energy enough
>> to spend on this, then we can do better than javax.net.debug=ssl.
>> Also, someone should check that divulging such sensitive information,
>> even in log files, is acceptable from a security perspective. I'm
>> personally still dubious.
>> 
>> -Chris.
>