On Mon, 19 Sep 2022 14:32:24 GMT, Darragh Clarke wrote:
> No tests were affected so this is purely a removal PR apart from updating
> copyright headers.
> I ran tests for Tier 1,2&3 and everything seems to be passing
Looks OK to me, i build/run this patch at my Linux env and worked as expected
On Wed, 28 Sep 2022 18:55:09 GMT, Viktor Klang (Oracle)
wrote:
> Removes the `defaultIndex`since it is no longer used.
Looks OK to me.
-
Marked as reviewed by vtewari (Committer).
PR: https://git.openjdk.org/jdk/pull/10471
On Mon, 28 Nov 2022 14:21:01 GMT, Darragh Clarke wrote:
>> Currently if a `HttpResonseInputStream` gets interrupted while reading it
>> will just swallow the exception and continue,
>>
>> This PR changes it to close the stream and throw an IOException, I added a
>> test to cover this which jus
On Wed, 30 Nov 2022 11:00:58 GMT, Daniel Fuchs wrote:
>> src/java.net.http/share/classes/jdk/internal/net/http/ResponseSubscribers.java
>> line 491:
>>
>>> 489: // Throw InterruptedIOException where the
>>> initCause is
>>> 490: // set to the caught Inte
On Fri, 2 Dec 2022 16:17:32 GMT, Darragh Clarke wrote:
>> Currently if a `HttpResonseInputStream` gets interrupted while reading it
>> will just swallow the exception and continue,
>>
>> This PR changes it to close the stream and throw an IOException, I added a
>> test to cover this which just
On Fri, 2 Dec 2022 16:17:32 GMT, Darragh Clarke wrote:
>> Currently if a `HttpResonseInputStream` gets interrupted while reading it
>> will just swallow the exception and continue,
>>
>> This PR changes it to close the stream and throw an IOException, I added a
>> test to cover this which just
On Fri, 13 Jan 2023 18:21:46 GMT, Ralf Schmelter wrote:
>> This change adds the resolved IP address to the exception text of a failed
>> socket connection. This helps if the connection failed because of stale DNS
>> entries.
>
> Ralf Schmelter has updated the pull request incrementally with one
On Tue, 17 Jan 2023 09:22:36 GMT, Ralf Schmelter wrote:
>> This change adds the resolved IP address to the exception text of a failed
>> socket connection. This helps if the connection failed because of stale DNS
>> entries.
>
> Ralf Schmelter has updated the pull request incrementally with one
On Fri, 3 Feb 2023 17:58:28 GMT, Darragh Clarke wrote:
> Currently there is a race condition that can allow for too many
> 'idleConnections' in `ServerImpl`
>
> This PR adds a lock to make sure only one connection can be marked Idle at a
> time as well as a test that consistently failed before
On Tue, 7 Feb 2023 15:40:48 GMT, Darragh Clarke wrote:
>> Currently there is a race condition that can allow for too many
>> 'idleConnections' in `ServerImpl`
>>
>> This PR adds a lock to make sure only one connection can be marked Idle at a
>> time as well as a test that consistently failed b
On Sun, 26 Feb 2023 20:12:09 GMT, Andrey Turbanov wrote:
> LinkedList is used in a few places in `ServerImpl`.
> There is only add/iterator/clear/size calls on this lists. No removes from
> the head or something like this. ArrayList should be preferred as more
> efficient and widely used (more
On Thu, 30 Mar 2023 16:05:08 GMT, Varada M wrote:
>> Breaking this into two parts :
>>
>> 1. Implementing socket options for AIX
>> 2. DontFragmentTest failure
>>
>> - Implementing socket options for AIX :
>>
>> Unlike the linux, windows and macOS, AIX uses the default implementation for
>
On Fri, 14 Apr 2023 07:59:49 GMT, Varada M wrote:
>> Breaking this into two parts :
>>
>> 1. Implementing socket options for AIX
>> 2. DontFragmentTest failure
>>
>> - Implementing socket options for AIX :
>>
>> Unlike the linux, windows and macOS, AIX uses the default implementation for
>
Please review the simple fix for the issue
[JDK-8309591](https://bugs.openjdk.org/browse/JDK-8309591). In this issue sys
call is incorrectly setting the socket option(TCP_QUICKACK) at wrong
level(SOL_TCP). After fix all the existing tests are passing.
Note: I did the similar changes for AIX po
On Tue, 27 Jun 2023 09:23:49 GMT, Vyom Tewari wrote:
> Please review the simple fix for the issue
> [JDK-8309591](https://bugs.openjdk.org/browse/JDK-8309591). In this issue sys
> call is incorrectly setting the socket option(TCP_QUICKACK) at wrong
> level(SOL_TCP). After
Please review the code change for
[JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden
"available" method of "HttpResponseInputStream" we are returning 1 after
exploring all the code path.
-
Commit messages:
- 8306040:HttpResponseInputStream.available() re
On Mon, 10 Jul 2023 07:42:35 GMT, Daniel Fuchs wrote:
>> Please review the code change for
>> [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the
>> overridden "available" method of "HttpResponseInputStream" we are returning
>> 1 after exploring all the code path.
>
> src/java.n
On Thu, 20 Jul 2023 16:49:04 GMT, Terry Chow wrote:
>> The PR adds support for the keepalive extended socket options on Windows.
>> For TCP_KEEPIDLE and TCP_KEEPINTVL, these options are supported starting
>> from Windows 10 version 1709. TCP_KEEPCNT is supported starting from Windows
>> 10 ver
On Thu, 20 Jul 2023 18:52:53 GMT, Terry Chow wrote:
>> The PR adds support for the keepalive extended socket options on Windows.
>> For TCP_KEEPIDLE and TCP_KEEPINTVL, these options are supported starting
>> from Windows 10 version 1709. TCP_KEEPCNT is supported starting from Windows
>> 10 ver
On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari wrote:
> Please review the code change for
> [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden
> "available" method of "HttpResponseInputStream" we are returning 1 after
> exploring al
> Please review the code change for
> [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden
> "available" method of "HttpResponseInputStream" we are returning 1 after
> exploring all the code path.
Vyom Tewari has updated the pul
> Please review the code change for
> [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden
> "available" method of "HttpResponseInputStream" we are returning 1 after
> exploring all the code path.
Vyom Tewari has updated the pul
On Sat, 8 Jul 2023 06:15:13 GMT, Vyom Tewari wrote:
> Please review the code change for
> [JDK-8306040](https://bugs.openjdk.org/browse/JDK-8306040). In the overridden
> "available" method of "HttpResponseInputStream" we are returning 1 after
> exploring all t
With the current implementation of HttpURLConnection if server rejects the
“Expect 100-continue” then there will be ‘java.net.ProtocolException’ will be
thrown from 'expect100Continue()' method.
After the exception thrown, If we call any other method on the same instance
(ex getHeaderField()
eption and getOutputStream0() will re-throw ‘rememberedException’
> if the ‘rememberedException’ is not null.
>
> Note: getOutputStream0() also call’s ‘expect100Continue()’ if
> ‘expectContinue’ is true.
Vyom Tewari has updated the pull request incrementally with one additional
comm
On Mon, 4 Sep 2023 07:22:46 GMT, Jaikiran Pai wrote:
>> Vyom Tewari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> modified the junit tests names
>
> src/java.base/share/classes/sun/net/www/protocol/http/
On Sun, 3 Sep 2023 09:16:24 GMT, Vyom Tewari wrote:
>> With the current implementation of HttpURLConnection if server rejects the
>> “Expect 100-continue” then there will be ‘java.net.ProtocolException’ will
>> be thrown from 'expect100Continue()' method.
>&
On Mon, 4 Sep 2023 16:49:39 GMT, Daniel Fuchs wrote:
> IIRC the `ProtocolException` here is caught higher in the stack - I believe
> that's what the comment `// responseCode will be returned to caller` means.
> @DarraghClarke might remember. There is much history here. The fix may appear
> sim
On Fri, 8 Sep 2023 11:32:26 GMT, Daniel Fuchs wrote:
> If another code than 100 is returned there's no point in sending the request
> body, hence the exception. You can get the 200 and the response at this point
> by looking at the status code and reading the response input stream. IMHO
> it's
On Tue, 12 Sep 2023 12:05:51 GMT, Daniel Fuchs wrote:
> Hi Vyom, the HttpClient is a different API. We're talking about the
> HttpURLConnection here. You're calling `HttpURLConnection::getOutputStream()`
> ; it blocks for a while waiting for 100 from the server. If the server
> returns 100, or
On Fri, 15 Sep 2023 15:29:52 GMT, Daniel Fuchs wrote:
> I am concerned that you are reusing the `rememberedException` field, which is
> used by getInputStream(). A server doesn't need to read the request body if
> it doesn't need it to send the response. So it could close the socket input
> an
eption and getOutputStream0() will re-throw ‘rememberedException’
> if the ‘rememberedException’ is not null.
>
> Note: getOutputStream0() also call’s ‘expect100Continue()’ if
> ‘expectContinue’ is true.
Vyom Tewari has updated the pull request incrementally with one additional
com
On Sun, 3 Sep 2023 09:16:24 GMT, Vyom Tewari wrote:
>> With the current implementation of HttpURLConnection if server rejects the
>> “Expect 100-continue” then there will be ‘java.net.ProtocolException’ will
>> be thrown from 'expect100Continue()' method.
>&
eption and getOutputStream0() will re-throw ‘rememberedException’
> if the ‘rememberedException’ is not null.
>
> Note: getOutputStream0() also call’s ‘expect100Continue()’ if
> ‘expectContinue’ is true.
Vyom Tewari has updated the pull request incrementally with one additional
commit s
On Mon, 2 Oct 2023 13:17:16 GMT, Daniel Fuchs wrote:
>> Vyom Tewari has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Incorporated the review comments
>
> test/jdk/java/net/HttpURLConnection/HttpURLConnectio
On Wed, 30 Aug 2023 09:23:34 GMT, Vyom Tewari wrote:
> With the current implementation of HttpURLConnection if server rejects the
> “Expect 100-continue” then there will be ‘java.net.ProtocolException’ will be
> thrown from 'expect100Continue()' method.
>
> After
On Mon, 9 Oct 2023 13:52:39 GMT, Daniel Fuchs wrote:
> Trivial one liner fix.
>
> The fix for [JDK-8308310](https://bugs.openjdk.org/browse/JDK-8308310)
> introduced a reentrant `stateLock` but also a regression. In
> Stream::handleReset the lock is locked twice.
Looks OK
-
Mark
On Sun, 5 Nov 2023 19:05:48 GMT, Marc R. Hoffmann wrote:
> 8319450: New methods java.net.InetXAddress.ofLiteral() miss @since tag
Looks OK to me.
-
Marked as reviewed by vtewari (Committer).
PR Review: https://git.openjdk.org/jdk/pull/16511#pullrequestreview-1716858237
On Mon, 20 Nov 2023 08:23:51 GMT, Matthias Baesken wrote:
>> There are a few places in the JDK C coding where the setsocktopt return
>> value is not handled but better should be handled.
>
> Matthias Baesken has updated the pull request incrementally with one
> additional commit since the last
On Wed, 24 Apr 2024 16:21:39 GMT, Daniel Jeliński wrote:
> This patch fixes leak reporting in `ForbiddenHeadTest.java` and
> `ProxySelectorTest.java`.
>
> The tests were checking for leaks, but the detected problems were not
> reported to the test harness. Additionally, `ForbiddenHeadTest.java
On Fri, 10 May 2024 12:02:49 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this change which proposes to address
>> https://bugs.openjdk.org/browse/JDK-8332020?
>>
>> `jwebserver` when it is launched prints a URL where the server is
>> accessible. When launched using an IPv6 bind ad
41 matches
Mail list logo
