On Sun, 27 Mar 2022 08:48:12 GMT, Christoph Langer wrote:
> Remove double semicolon
This pull request has now been integrated.
Changeset: cdef087a
Author: Christoph Langer
URL:
https://git.openjdk.java.net/jdk/commit/cdef087aae5d0edb3ad3421107d7dc2b5e18dd28
Stats: 1 line i
On Sun, 27 Mar 2022 13:07:54 GMT, Sean Mullan wrote:
> Regarding the bug, the `noreg-self` label is used for fixes to tests.
> `noreg-trivial` seems more appropriate for this issue.
You're right, I changed this. Thanks also for the review.
-
PR: https://git.openjdk.java.net/jdk/pu
Remove double semicolon
-
Commit messages:
- JDK-8283727
Changes: https://git.openjdk.java.net/jdk/pull/7976/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7976&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8283727
Stats: 1 line in 1 file changed: 0 ins;
On Thu, 15 Jul 2021 15:04:04 GMT, Christoph Langer wrote:
> The test is failing since 8th of July. Let's exclude it for now.
This pull request has now been integrated.
Changeset: 1350e2bd
Author:Christoph Langer
URL:
https://git.openjdk.java.net/jdk1
The test is failing since 8th of July. Let's exclude it for now.
-
Commit messages:
- 8270556: Exclude
security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA
Changes: https://git.openjdk.java.net/jdk17/pull/251/files
Webrev: https://webrevs.openjdk.java.ne
On Fri, 5 Mar 2021 08:38:54 GMT, Christoph Langer wrote:
> Exclude some failing tests from
> security/infra/java/security/cert/CertPathValidator
This pull request has now been integrated.
Changeset: a9b4f033
Author:Christoph Langer
URL: https://git.openjdk.java.net/jdk/
Exclude some failing tests from
security/infra/java/security/cert/CertPathValidator
-
Commit messages:
- 8263069: Exclude some failing tests from
security/infra/java/security/cert/CertPathValidator
Changes: https://git.openjdk.java.net/jdk/pull/2840/files
Webrev: https://webrevs.
On Wed, 10 Feb 2021 23:29:14 GMT, Christoph Langer wrote:
> Fix exception in test
> sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java:
>
> java.security.AccessControlException: access denied
> ("java.security.SecurityPermission" "removePr
On Fri, 12 Feb 2021 19:10:36 GMT, Martin Balao wrote:
>> LGTM
>
> I'm not a JDK main line reviewer but the proposed fix looks good to me as
> well.
Thanks for the reviews!
-
PR: https://git.openjdk.java.net/jdk/pull/2518
On Fri, 12 Feb 2021 08:50:14 GMT, Matthias Baesken wrote:
> There seems to be an early return in
> Java_sun_nio_ch_sctp_SctpChannelImpl_receive0 that misses freeing memory.
>
> Sonar reports :
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=c&open=AXck8Cl0BBG2CXpcnjFu&resolved=
Fix exception in test
sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java:
java.security.AccessControlException: access denied
("java.security.SecurityPermission" "removeProvider.SUN")
at
java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at
java
On Thu, 10 Dec 2020 08:34:31 GMT, Christoph Langer wrote:
> The fix for [JDK-8257884](https://bugs.openjdk.java.net/browse/JDK-8257884)
> had a flaw which made the test fail even more often on Windows than before.
> Here is the correction.
This pull request has now been integrated.
The fix for [JDK-8257884](https://bugs.openjdk.java.net/browse/JDK-8257884) had
a flaw which made the test fail even more often on Windows than before. Here is
the correction.
-
Commit messages:
- 8257997: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java again reports
leaks after
On Tue, 8 Dec 2020 07:27:07 GMT, Christoph Langer wrote:
> The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic
> noise because sometimes it opens more file handles than expected. It was
> moved to a manual test to quiesce this
> ([JDK-82
On Tue, 8 Dec 2020 22:34:44 GMT, Xue-Lei Andrew Fan wrote:
>> The failing cases I've seen in SAP's infrastructure have all been on Windows
>> and the number of handles was marginally above the 10 percent threshold. Do
>> you have seen otherwise in Oracle's tests? The test prints out the handle
On Tue, 8 Dec 2020 16:27:19 GMT, Xue-Lei Andrew Fan wrote:
>> The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic
>> noise because sometimes it opens more file handles than expected. It was
>> moved to a manual test to quiesce this
>> ([JDK-8257670](https://bugs.openjdk.
The test sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java caused sporadic
noise because sometimes it opens more file handles than expected. It was moved
to a manual test to quiesce this
([JDK-8257670](https://bugs.openjdk.java.net/browse/JDK-8257670))
It would be good, however, to have this te
On Mon, 7 Dec 2020 23:35:49 GMT, Xue-Lei Andrew Fan wrote:
> This test case, sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java, may be not
> reliable if there are some other test cases or applications running at the
> same time. It's a good manual test, but might be not suitable for OpenJDK
>
On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer wrote:
> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
> leaking socket resources after JDK-8224829.
>
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of
> an exception
On Wed, 2 Dec 2020 18:01:04 GMT, Xue-Lei Andrew Fan wrote:
>> Christoph Langer has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Small test improvement
>
> test/jdk/sun/security/ssl/SSLSocketImpl/SSLSoc
On Sat, 21 Nov 2020 23:21:15 GMT, Christoph Langer wrote:
>> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
>> leaking socket resources after JDK-8224829.
>>
>> The close method calls duplexCloseOutput() and duplexCloseInput(). In case
>
en connected.
>
> Secondly, I'm proposing to improve exception handling a bit. So in case
> there's an IOException on the path of duplexClose, it is caught and logged.
> But the real close moves to the finally block since it should be done
> unconditionally.
Christoph
en connected.
>
> Secondly, I'm proposing to improve exception handling a bit. So in case
> there's an IOException on the path of duplexClose, it is caught and logged.
> But the real close moves to the finally block since it should be done
> unconditionally.
Chri
On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer wrote:
> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
> leaking socket resources after JDK-8224829.
>
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of
> an exception
There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to
leaking socket resources after JDK-8224829.
The close method calls duplexCloseOutput() and duplexCloseInput(). In case of
an exception in any of these methods, the call to closeSocket() is bypassed,
and the underlying Soc
On Fri, 13 Nov 2020 17:40:54 GMT, Sean Coffey wrote:
> Meant to comment earlier. Thanks for cleaning this one up!
Thanks :) Glad you like it.
-
PR: https://git.openjdk.java.net/jdk/pull/1166
On Wed, 11 Nov 2020 14:36:07 GMT, Christoph Langer wrote:
> Working on 11u backports of JDK-8218021 and JDK-8250968, I found some minor
> points for improvement in tests
> test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java and
> test/jdk/sun/security/too
Working on 11u backports of JDK-8218021 and JDK-8250968, I found some minor
points for improvement in tests
test/jdk/sun/security/tools/jarsigner/PosixPermissionsTest.java and
test/jdk/sun/security/tools/jarsigner/SymLinkTest.java
The details
PosixPermissionsTest:
- it can run on any system, no
On Thu, 29 Oct 2020 15:11:09 GMT, Christoph Langer wrote:
> It seems that there exists a memory/performance regression that was
> introduced with JDK-8210985: Update the default SSL session cache size to
> 20480.
>
> The idea to limit the maixmum SSL session cache size by
On Thu, 29 Oct 2020 18:02:47 GMT, Xue-Lei Andrew Fan wrote:
>>> > Benchmarking is probably hard because we don't know the average occupancy
>>> > of the map.
>>>
>>> I agreed. No matter what the default value is, it will not fit perfectly in
>>> all situations. The value 1 may be fit for small
On Thu, 29 Oct 2020 16:21:47 GMT, Xue-Lei Andrew Fan wrote:
>>> Did you have a benchmark with various cache sizes (for example, from 1 to
>>> 10K) and various connections (for example from 1 to 10K) for those
>>> components (including TLS implementation) that use Cache?
>>
>> Nope, we've just
On Thu, 29 Oct 2020 15:54:27 GMT, Xue-Lei Andrew Fan wrote:
> Did you have a benchmark with various cache sizes (for example, from 1 to
> 10K) and various connections (for example from 1 to 10K) for those components
> (including TLS implementation) that use Cache?
Nope, we've just seen the mem
It seems that there exists a memory/performance regression that was introduced
with JDK-8210985: Update the default SSL session cache size to 20480.
The idea to limit the maixmum SSL session cache size by itself is good.
Unfortunately, as per the current implementation of
sun.security.util.Memo
33 matches
Mail list logo
