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

[Péter Gergely Horváth]

Hi Michael,

Thank you for looking into this issue. I believe it would be a valuable
improvement that would help a lot of people out there.

Please let me know if there is any way I can help you.

Thanks,
Peter


On Tue, May 1, 2018 at 10:48 AM, Michael McMahon <
michael.x.mcmahon at oracle.com> wrote:

> Peter,
>
> Just to followup on this. We are still investigating a few options for
> doing this
> and it might be a few more weeks before we get a decision. I did take your
> patch
> as a starting point, and modified it to also work with NIO, and also to
> preserve
> the original exception (with original stack trace) which I think is
> desirable.
> I don't think there is much point in reviewing the webrev until we get the
> decision
> mentioned above. But, we should be able to push it soon after that.
>
> Thanks,
> Michael
>
> On 23/04/2018, 10:05, Péter Gergely Horváth wrote:
>
> 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/20180502/16e2ab52/attachment.html>