[jira] [Comment Edited] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664639#comment-16664639 ] Freeman Fang edited comment on CXF-7361 at 10/26/18 4:27 AM: - Since JDK 11 won't have Unsafe.defineClass anymore, we need to use MethodHandles.Lookup.defineClass instead, which exists since JDK9 was (Author: ffang): Since JDK 11 won't have Unsafe.defineClass anymore, we need to use MethodHandles.Lookup.defineClass instead > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang resolved CXF-7883. --- Resolution: Fixed Fix Version/s: 3.2.7 3.3.0 > Handle connectionRequestTimeout in AsyncHTTPConduitFactory > -- > > Key: CXF-7883 > URL: https://issues.apache.org/jira/browse/CXF-7883 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Györgyey Tamás >Assignee: Freeman Fang >Priority: Major > Labels: pull-request-available > Fix For: 3.3.0, 3.2.7 > > > This issue is a follow-up to CXF-7878. > If connections are contended towards a slow target, it may make sense > to set connectionTimeout and connectionRequestTimeout to values much lower > than > the receiveTimeout. Expected client behavior is to receive an error if a > connection > does not become available within connectionRequestTimeout. Current behavior > however > is that the error is only received after up to receiveTimeout has passed, > when a > current request to the target has finished and the connection is released or > returned > to the pool. > This causes a possible build-up of pending requests in memory for the > duration of receiveTimeout instead of connectionRequestTimeout. > See github PR: [https://github.com/apache/cxf/pull/466] > The reference solution in the PR works well, but it may not be the most > elegant one due to my currently limited understanding of the overall design > of the connection handling code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664585#comment-16664585 ] Freeman Fang commented on CXF-7883: --- a follow up commit[1] to ensure connectionMaxIdle kick in when connectionTTL is 0, keeping the behavior as before [1]https://github.com/apache/cxf/commit/bcf43396043673166ca88093e8d8597d1504888b > Handle connectionRequestTimeout in AsyncHTTPConduitFactory > -- > > Key: CXF-7883 > URL: https://issues.apache.org/jira/browse/CXF-7883 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Györgyey Tamás >Assignee: Freeman Fang >Priority: Major > Labels: pull-request-available > > This issue is a follow-up to CXF-7878. > If connections are contended towards a slow target, it may make sense > to set connectionTimeout and connectionRequestTimeout to values much lower > than > the receiveTimeout. Expected client behavior is to receive an error if a > connection > does not become available within connectionRequestTimeout. Current behavior > however > is that the error is only received after up to receiveTimeout has passed, > when a > current request to the target has finished and the connection is released or > returned > to the pool. > This causes a possible build-up of pending requests in memory for the > duration of receiveTimeout instead of connectionRequestTimeout. > See github PR: [https://github.com/apache/cxf/pull/466] > The reference solution in the PR works well, but it may not be the most > elegant one due to my currently limited understanding of the overall design > of the connection handling code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664583#comment-16664583 ] Freeman Fang commented on CXF-7883: --- patch applied on behalf of Györgyey Tamás with thanks! > Handle connectionRequestTimeout in AsyncHTTPConduitFactory > -- > > Key: CXF-7883 > URL: https://issues.apache.org/jira/browse/CXF-7883 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Györgyey Tamás >Assignee: Freeman Fang >Priority: Major > Labels: pull-request-available > > This issue is a follow-up to CXF-7878. > If connections are contended towards a slow target, it may make sense > to set connectionTimeout and connectionRequestTimeout to values much lower > than > the receiveTimeout. Expected client behavior is to receive an error if a > connection > does not become available within connectionRequestTimeout. Current behavior > however > is that the error is only received after up to receiveTimeout has passed, > when a > current request to the target has finished and the connection is released or > returned > to the pool. > This causes a possible build-up of pending requests in memory for the > duration of receiveTimeout instead of connectionRequestTimeout. > See github PR: [https://github.com/apache/cxf/pull/466] > The reference solution in the PR works well, but it may not be the most > elegant one due to my currently limited understanding of the overall design > of the connection handling code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[
https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664507#comment-16664507
]
ASF GitHub Bot commented on CXF-7883:
-
ffang closed pull request #466: [CXF-7883] fix: handle connectionRequestTimeout
in AsyncHTTPConduitFactory
URL: https://github.com/apache/cxf/pull/466
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
b/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
index d616dda5fce..15445bc33db 100644
---
a/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
+++
b/rt/transports/http-hc/src/main/java/org/apache/cxf/transport/http/asyncclient/AsyncHTTPConduitFactory.java
@@ -375,11 +375,9 @@ public void addCookie(Cookie cookie) {
client = httpAsyncClientBuilder.build();
// Start the client thread
client.start();
-if (this.connectionTTL == 0) {
-//if the connection does not have an expiry deadline
-//use the ConnectionMaxIdle to close the idle connection
-new CloseIdleConnectionThread(connectionManager, client).start();
-}
+//Always start the idle checker thread to validate pending requests and
+//use the ConnectionMaxIdle to close the idle connection
+new CloseIdleConnectionThread(connectionManager, client).start();
}
//provide a hook to customize the builder
@@ -401,20 +399,28 @@ public CloseableHttpAsyncClient createClient(final
AsyncHTTPConduit c) throws IO
public CloseIdleConnectionThread(PoolingNHttpClientConnectionManager
connMgr,
CloseableHttpAsyncClient client) {
-super();
+super("CXFCloseIdleConnectionThread");
this.connMgr = connMgr;
this.client = client;
}
@Override
public void run() {
+long nextIdleCheck = System.currentTimeMillis() +
connectionMaxIdle;
try {
while (client.isRunning()) {
synchronized (this) {
-sleep(connectionMaxIdle);
-// close connections
-// that have been idle longer than specified
connectionMaxIdle
-connMgr.closeIdleConnections(connectionMaxIdle,
TimeUnit.MILLISECONDS);
+sleep(selectInterval);
+// make sure pending leases fail in a timely manner,
+// not just when a connection becomes available
+connMgr.validatePendingRequests();
+
+if (connectionMaxIdle > 0 &&
System.currentTimeMillis() >= nextIdleCheck) {
+nextIdleCheck += connectionMaxIdle;
+// close connections
+// that have been idle longer than specified
connectionMaxIdle
+connMgr.closeIdleConnections(connectionMaxIdle,
TimeUnit.MILLISECONDS);
+}
}
}
} catch (InterruptedException ex) {
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Handle connectionRequestTimeout in AsyncHTTPConduitFactory
> --
>
> Key: CXF-7883
> URL: https://issues.apache.org/jira/browse/CXF-7883
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.2.6
>Reporter: Györgyey Tamás
>Assignee: Freeman Fang
>Priority: Major
> Labels: pull-request-available
>
> This issue is a follow-up to CXF-7878.
> If connections are contended towards a slow target, it may make sense
> to set connectionTimeout and connectionRequestTimeout to values much lower
> than
> the receiveTimeout. Expected client behavior is to receive an error if a
> connection
> does not become available within connectionRequestTimeout. Current behavior
> however
> is that the error is only received after up to receiveTimeout has passed,
> when a
> current request to the target has finished and the connection is released or
> returned
> to
[jira] [Commented] (CXF-7883) Handle connectionRequestTimeout in AsyncHTTPConduitFactory
[ https://issues.apache.org/jira/browse/CXF-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16664180#comment-16664180 ] ASF GitHub Bot commented on CXF-7883: - gyoetam commented on issue #466: [CXF-7883] fix: handle connectionRequestTimeout in AsyncHTTPConduitFactory URL: https://github.com/apache/cxf/pull/466#issuecomment-433171534 Looks like the Jenkins build runs out of memory during the build, it is not related to the change in the PR. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Handle connectionRequestTimeout in AsyncHTTPConduitFactory > -- > > Key: CXF-7883 > URL: https://issues.apache.org/jira/browse/CXF-7883 > Project: CXF > Issue Type: Bug > Components: Transports >Affects Versions: 3.2.6 >Reporter: Györgyey Tamás >Assignee: Freeman Fang >Priority: Major > Labels: pull-request-available > > This issue is a follow-up to CXF-7878. > If connections are contended towards a slow target, it may make sense > to set connectionTimeout and connectionRequestTimeout to values much lower > than > the receiveTimeout. Expected client behavior is to receive an error if a > connection > does not become available within connectionRequestTimeout. Current behavior > however > is that the error is only received after up to receiveTimeout has passed, > when a > current request to the target has finished and the connection is released or > returned > to the pool. > This causes a possible build-up of pending requests in memory for the > duration of receiveTimeout instead of connectionRequestTimeout. > See github PR: [https://github.com/apache/cxf/pull/466] > The reference solution in the PR works well, but it may not be the most > elegant one due to my currently limited understanding of the overall design > of the connection handling code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CXF-7838) Remove illegal reflective access in ReflectionUtil
[
https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-7838:
-
Assignee: Freeman Fang
> Remove illegal reflective access in ReflectionUtil
> --
>
> Key: CXF-7838
> URL: https://issues.apache.org/jira/browse/CXF-7838
> Project: CXF
> Issue Type: Task
>Reporter: Tim Allison
>Assignee: Freeman Fang
>Priority: Major
>
> Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache
> Tika, and we're still getting the following when we run our unit tests with
> Java 11.
> {quote}Illegal reflective access by
> org.apache.cxf.common.util.ReflectionUtil$11
> ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar])
> to field java.net.Authenticator.theAuthenticator
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cxf.common.util.ReflectionUtil$11
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> {quote}
> Let us know if you need more info to solve this. Thank you!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang reassigned CXF-7361: - Assignee: Freeman Fang > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Assignee: Freeman Fang >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CXF-7838) Remove illegal reflective access in ReflectionUtil
[
https://issues.apache.org/jira/browse/CXF-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663448#comment-16663448
]
Lukasz Lech commented on CXF-7838:
--
There are 3 illegal operations involved:
WARNING: Illegal reflective access by
org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to
field java.net.Authenticator.theAuthenticator
WARNING: Illegal reflective access by
org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to
method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Illegal reflective access by
org.apache.cxf.common.util.ReflectionUtil$11 (file:./lib/cxf-core-3.2.6.jar) to
field java.net.URLClassLoader.acc
> Remove illegal reflective access in ReflectionUtil
> --
>
> Key: CXF-7838
> URL: https://issues.apache.org/jira/browse/CXF-7838
> Project: CXF
> Issue Type: Task
>Reporter: Tim Allison
>Priority: Major
>
> Apologies if this is a duplicate. We're about to upgrade to 3.2.6 on Apache
> Tika, and we're still getting the following when we run our unit tests with
> Java 11.
> {quote}Illegal reflective access by
> org.apache.cxf.common.util.ReflectionUtil$11
> ([file:.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar|file://.m2/repository/org/apache/cxf/cxf-core/3.2.6/cxf-core-3.2.6.jar])
> to field java.net.Authenticator.theAuthenticator
> WARNING: Please consider reporting this to the maintainers of
> org.apache.cxf.common.util.ReflectionUtil$11
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> {quote}
> Let us know if you need more info to solve this. Thank you!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CXF-7361) Java 9 support for CXFAuthenticator
[ https://issues.apache.org/jira/browse/CXF-7361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16663447#comment-16663447 ] Lukasz Lech commented on CXF-7361: -- Wow, over a year and no reaction. Is the project dead? Unfortunately, other Apache projects like Tika depends on it... Java 10 tolerates such misuse with warnings, but with subsequent versions, it's likely not to work at all. It should be reported as bug, not improvement. > Java 9 support for CXFAuthenticator > --- > > Key: CXF-7361 > URL: https://issues.apache.org/jira/browse/CXF-7361 > Project: CXF > Issue Type: Improvement >Affects Versions: 3.1.11 >Reporter: Romain Manni-Bucau >Priority: Major > > with java 9, Authenticator getDefault() should be used instead of field.get() > (setAccessible fails) + unsafe should be used to define the class instead > of the failing ClassLoader.defineClass. > All that with reflection of course and in fallback mode probably since for > java 8 it is better to not do it (or it is not available - getDefault() > typically). > Workaround ATM is to call CXFAuthenticator.addAuthenticator(); manually and > ignore the exception, it initializes the instance then it doesn't fail but > the feature is lost until it gets fixed as mentionned before. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
