Adding SocketChannel toString to connection exception messages
sean.coffey at oracle.com
Fri Dec 22 14:59:42 UTC 2017
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.
On 22/12/17 09:57, Chris Hegarty wrote:
> On 22/12/17 01:27, David Holmes wrote:
>> cc'ing net-dev as that might be the more appropriate list.
>> On 22/12/2017 10:59 AM, Steven Schlansker wrote:
>>>> On Dec 21, 2017, at 4:35 PM, David Holmes <david.holmes at oracle.com>
>>>> On 22/12/2017 10:29 AM, Steven Schlansker wrote:
>>>>>> On Dec 21, 2017, at 11:11 AM, Steven Schlansker
>>>>>> <stevenschlansker at gmail.com> wrote:
>>>>>> What if ConnectException included the attempted hostname / IP /
>>>>>> port SocketAddress?
>>>>>> java.net.ConnectException: Connection to
>>>>>> 'foo.mycorp.com[10.x.x.x]:12345' refused
>>>>>> Much more useful! This could also be extended to various other
>>>>>> socket exceptions.
>>>> I believe there are concerns with too much information that can be
>>>> considered "sensitive" (like host names and IP addresses) appearing
>>>> in error messages due to them ending up in log files and bug reports.
>>> Unfortunately that's exactly the information that is crucial to
>>> someone trying to diagnose issues...
> And to someone trying to discern private information about a network.
>>> Could it be an opt-in policy? Perhaps by a system property?
> Well, you don't know where a log file or exception will end up.
> Most likely on stackoverflow.
>> The expectation is that such information should be added by layers
>> higher in the call chain, rather than the JDK libraries assuming it
>> is okay to do.
> Agreed. It may be some work, but if the issue is significant
> enough to the user then it may be worth their effort, as well
> as affording the opportunity to opt-out at any particular
> point in the code.
>>> Currently the alternative I'm faced with is going through every
>>> piece of user code and library that *might*
>>> throw this exception and wrapping it to add this critical diagnostic
>>> information. For an application that uses
>>> java.net heavily, you can imagine how that is a tall task and
>>> possibly even not realistically achievable...
>>> (Is there a written policy regarding this somewhere, or is it up to
>>> the personal feelings of the contributors?)
>> This is covered by the secure coding guidelines, under 'Confidential
>> "Guideline 2-1 / CONFIDENTIAL-1: Purge sensitive information from
>> I know for a fact that we'd have to scrub this information from test
>> failures when putting the info into a bug report.
>> If net-dev folk can't expand further on this then I suggest filing a
>> CSR request so that the CSR group can consider it. But I think this
>> will be a no-go (I'm a member of the CSR group).
> I have to agree with David here. I don't think that such a request
> could be supported.
More information about the core-libs-dev