java.net.Socket should report the attempted address and port

[Péter Gergely Horváth]

Hi Tobias,

Thank you for pointing me to that thread: it's good to have that context
(it was sent before I joined the mailing list, so please bear with me).

I understand the JDK developers want to be safe than sorry around reporting
target addresses and I absolutely agree with that point.

However considering how useful it would be to have this _optionally_ for
debugging, I am wondering if it would be possible to have a dedicated Java
system property defined for this (e.g.
'java.net.socket.reportAddressInException' or something like that), which
would enable this behaviour (retaining the current behaviour of *not
reporting anything by default.*).

What do you think about this, guys? With this in place both the
secure-by-default requirement would be met, and there would be a powerful
tool available to fight the horrors of debugging a running complex
distributed application from its logs.

Thanks,
Peter





On Sun, Apr 22, 2018 at 10:21 PM, James Roper <james at lightbend.com> wrote:

> This would be especially useful in asynchronous applications - since in
> those cases the exception rarely maps back to a place in user code that
> would indicate what is being connected to. As someone who has spent a lot
> of time supporting developers who use asynchronous libraries and post
> exceptions of this nature (supporting both in open source, eg on stack
> overflow, as well as providing commercial support), where I don't have
> access to their code base so I can't do the necessary investigations
> directly myself, having the attempted address and port in the error message
> would save a lot of time, and probably even prevent a lot of people from
> requiring support in the first place.
>
> On 22 April 2018 at 20:59, Péter Gergely Horváth <
> peter.gergely.horvath at gmail.com> wrote:
>
>> Hi All,
>>
>> I am wondering if it would be possible to make a minor improvement to the
>> way *java.net.Socket* reports connectivity errors and incorporate the
>> attempted address, port and the timeout used into the exception message.
>>
>> The current implementation emits a generic error message, which is not
>> that helpful when one is operating a _large_ application. (Consider e.g.
>> Big Data or complex legacy systems written by someone else).
>>
>> java.net.ConnectException: Connection refused (Connection refused)
>> at java.net.PlainSocketImpl.socketConnect(Native Method)
>> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSock
>> etImpl.java:350)
>> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPl
>> ainSocketImpl.java:206)
>> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocket
>> Impl.java:188)
>> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
>> at java.net.Socket.connect(Socket.java:589)
>> at java.net.Socket.connect(Socket.java:538)
>> at java.net.Socket.<init>(Socket.java:434)
>> at java.net.Socket.<init>(Socket.java:211)
>> at Sample.main(Sample.java:9)
>>
>>
>> I have looked into the JDK code base and implemented a patch that reports
>> the address, port and timeout used in the error message without touching
>> any native parts (see attached patch file). I have tested this (created my
>> own build of the JDK and run a sample application against it) and it seems
>> to work properly.
>>
>> Would it be possible to incorporate this change into the official JDK
>> code base? I do believe it would help a lot of people out there.
>>
>> Based on my understanding, once I have signed the OCA, I should simply
>> write an email to the group and request a sponsor to pick up this issue.
>> Could someone help me with this?
>>
>> Thank you,
>> Peter
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> *James Roper*
> *Senior Octonaut*
>
> Lightbend <https://www.lightbend.com/> – Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180423/b5338b0c/attachment.html>