The bug ID is https://bugs.openjdk.java.net/browse/JDK-8252996 .
On Wed, Sep 9, 2020 at 3:14 PM Chris Hegarty wrote:
>
> Seems like a bug. Can you please file an issue for it.
>
> Thanks,
> -Chris.
>
> > On 2 Sep 2020, at 14:16, David Lloyd wrote:
> >
> >
The default proxy selector field in java.net.ProxySelector is
essentially a global variable with no thread safety measures taken to
ensure that accesses are valid. Anecdotally, a symptom of this bug
*may* be that the field appears `null` after assignment (based on an
IRC discussion with a confused
This is, AFAICT, expected based on the differences between the socket
layers of the various operating systems involved and their handling of
closed sockets. If you write a similar test program in C using OS specific
APIs, I believe you will see similar results. I don't think this is a
problem wit
While doing some GraalVM work, it was discovered that there's an
apparently unused declaration in PlainDatagramSocketImpl.c. I've
attached a trivial patch to remove it; do with it what you will.
--
- DML
pdsi.patch
Description: Binary data
On Mon, Apr 29, 2019 at 10:54 AM Michael McMahon
wrote:
>
>
>
> On 29/04/2019, 13:08, Chris Hegarty wrote:
> >
> > On 29/04/2019 12:17, Alan Bateman wrote:
> >> ...
> >> Changing SIS.close and SOS.close to caller super.close raises a
> >> number of questions. These close should never be called
> >
On Fri, Oct 12, 2018 at 6:01 AM Chris Hegarty wrote:
> That is correct. While not intuitive, I don't propose
> that we change this. ( if this were a new implementation
> then I think it should throw IOE for this scenario, but
> we are where we are ).
I am glad then that it is not a new implementa
Fantastic! I'm glad to hear it.
On Fri, Sep 14, 2018 at 1:39 AM Andre Naujoks wrote:
>
> On 9/10/18 10:36 AM, Andre Naujoks wrote:
> > On 9/8/18 11:49 AM, Andre Naujoks wrote:
> >> On 9/7/18 6:08 PM, David Lloyd wrote:
> >>> On Fri, Sep 7, 2018 at 6:56 AM An
On Fri, Sep 7, 2018 at 11:08 AM David Lloyd wrote:
> On Fri, Sep 7, 2018 at 6:56 AM Andre Naujoks wrote:
> > On 9/7/18 1:15 PM, Alan Bateman wrote:
> > > On 07/09/2018 10:49, Decke, Hendrik (K-GERFA/A) wrote:
> > >>
> > >> Hello,
> > >>
On Fri, Sep 7, 2018 at 6:56 AM Andre Naujoks wrote:
> On 9/7/18 1:15 PM, Alan Bateman wrote:
> > On 07/09/2018 10:49, Decke, Hendrik (K-GERFA/A) wrote:
> >>
> >> Hello,
> >>
> >> it seems one of our external developers (Andre Naujoks, CC) found a
> >> bug while binding a IPv6 multicast UDP-socket
On Wed, Jul 25, 2018 at 9:43 AM Chris Hegarty wrote:
>
> Clearly the request builder `timeout` method can be used to avoid
> extremely long connection timeouts ( as demonstrated below ), but I see
> Bernd's call for more fine grained control over various aspects of the
> request.
>
> I'm not oppos
According to http://man7.org/linux/man-pages/man2/close.2.html it is currently
platform-dependent whether close() must or must not (seems to be no middle
ground) be retried. Might have to do some #ifdef guarding?
--
- DML
> On Jun 27, 2018, at 6:15 PM, Ivan Gerasimov wrote:
>
> Hello!
>
>
R);
> >>> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-151-
> >>> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-152-return rv;
> >>> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c-153-}
> >>>
> >>> Do yo
On Wed, Jun 27, 2018 at 6:52 PM Ivan Gerasimov
wrote:
> Here I'm patching only the Linux-specific file
> src/java.base/linux/native/libnet/linux_close.c
> So no #ifdefs seem necessary.
>
> MacOS variant also uses the same pattern, but I'm not touching it exactly
> because the behavior not quite
+1 from me (non-reviewer). Semantically, it is impossible to
distinguish the difference between the OS dropping bytes when it
receives an RST compared to Java doing the same thing, so there is no
observable behavior change here AFAICT.
On Wed, Mar 14, 2018 at 9:30 AM, Alan Bateman wrote:
>
> Cla
On Tue, Feb 20, 2018 at 2:15 PM, Ashton Hogan wrote:
> David, I understand that you don't use this feature of the JDK and that's
> absolutely fine. I'm not the type of person to impose my way of doing things
> on anyone. I hope that you aren't either. There are obviously many people in
> the commu
Ashton, I don't think anyone disagrees with your four points at a high
level (though #4 might be a bit subjective, and #2 and #3 are
obviously design points that would theoretically be subject to
debate).
However, at the same time, you're not really going to see anyone
lining up and clamoring for
On Fri, Dec 29, 2017 at 11:15 AM, Chris Hegarty
wrote:
> On 29 Dec 2017, at 00:33, Steven Schlansker
> 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
>> poss
On Thu, Dec 7, 2017 at 8:32 AM, Chris Hegarty wrote:
> David,
>
> On 07/12/17 13:14, David Lloyd wrote:
>>
>> On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman
>> wrote:
>>>
>>> This thread is getting a little off-topic but...
>>
>>
>> G
On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman wrote:
> This thread is getting a little off-topic but...
Getting it back on topic again:
> Proposal for the standard module name: java.net.httpclient. Proposal for the
> standard package name: java.net.http.
I think it would be better if both the m
On Wed, Dec 6, 2017 at 6:31 AM, Chris Hegarty wrote:
> Viktor,
>
> The reference to byte buffer pools is not relevant here. They were
> introduced as a performance optimization that allowed better reuse of
> byte buffers between the socket channel and the SSL engine, in the
> implementation. That'
On Tue, Dec 5, 2017 at 5:48 AM, dalibor topic wrote:
> On 04.12.2017 22:56, David Lloyd wrote:
>>
>> saying "Here it is, it's all done, what do you think?". I've
>> certainly never had opportunity to try it out: given its status as an
>> incubating
On Mon, Dec 4, 2017 at 5:01 PM, Chris Hegarty wrote:
> On 4 Dec 2017, at 22:03, David Lloyd wrote:
>
> ...
>
> You mention general-purpose concepts such as ByteBufferReference and
> ByteBufferPool. Note that these are tiny implementation classes (150 lines
> in total) and n
On Mon, Dec 4, 2017 at 3:56 PM, David Lloyd wrote:
> On Mon, Dec 4, 2017 at 2:01 PM, Alan Bateman wrote:
>> On 04/12/2017 18:41, David Lloyd wrote:
>>>
>>> :
>>> Speaking *solely* in the interests of platform quality and integrity,
>>> I th
On Mon, Dec 4, 2017 at 2:01 PM, Alan Bateman wrote:
> On 04/12/2017 18:41, David Lloyd wrote:
>>
>> :
>> Speaking *solely* in the interests of platform quality and integrity,
>> I think that before _any_ high-level non-blocking/asynchronous
>> protocol API is ever
On Mon, Dec 4, 2017 at 10:17 AM, wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/321
I have concerns.
This will be the first public, NIO-based, asynchronous/non-blocking
network protocol API introduced into the JDK proper, _ever_.
First, I want to note that the API seems to bear no re
On Mon, Nov 14, 2016 at 12:16 PM, Chris Hegarty
wrote:
> David,
>
> On 14/11/16 16:47, David M. Lloyd wrote:
>>
>> The following statement:
>>
>> URI uri = URI.create("local:");
>>
>> fails with an exception like this:
[...]
>> However AFAICT scheme-only URIs are, while not strictly allowed by RFC
On Thu, Oct 26, 2017 at 4:44 AM, Bernd Eckenfels wrote:
> What is currently returned at the end of a stream? This looks like a
> dangerous thing to do, if a existing implementation only read when something
> is available it might never detect that it reached EOF.
At present it ultimately delegate
27 matches
Mail list logo
