[jira] [Reopened] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Montaz reopened CXF-7122: - Hi Fang, thank you for your answer. I disagree on several points : - for the sync, we had no problem, so no need to remove the wait(scPolicy.getReceiveTimeout()). I had to actually put it back because that was breaking the syncTimeout test. - for the async, the old code was doing the wait anyway, so the race condition you describe already applies on all previous versions of CXF ? Your analysis seems wrong -> if HttpResponse is given back by the callback, then when the thread enters getHttpResponse, it will found that httpResponse is not null (line 619) and thus will never wait. If httpresponse is null, it will wait. Since both setHttpResponse and getHttpresponse are synchronized, we have correct happens-before relationship. Correct behavior here. - the solution you describe does not help with the fact that a thread will timeout even if no real tcp traffic occurs. it can be a pain to debug such a behavior, seing SocketReadTimeoutException in the log without any outgoing request. - with the solution you describe, The IOReactor thread can still try to write some stuff in the socket, like headers (that’s actually what happened when we discovered the problem), and then is told not to do anything more. This is because there is a competition between thread shutting down the buffer and writing to the socket from the buffer. Such a behavior can lead to real troubles since the server will get an incomplete HttpRequest. Finally, the solution I provide has been tested on our preproduction platform. Could you dig further ? Thank you > Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection > pool > - > > Key: CXF-7122 > URL: https://issues.apache.org/jira/browse/CXF-7122 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: William Montaz >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2.0, 3.1.9 > > > Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, > requests waiting for a connection will lead to an infinite loop if they reach > receive timeout. > The problem occured on all versions of CXF above 3.0.5 (we did not tested > other ones). > Let's imagine a backend that's broken and leads to timeout for all requests. > When handling requests, the cxf worker thread will eventually go in wait > state (AsyncHTTPConduit:618), with a timeout that matches the > HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to > complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). > The timeout on the wait is the big problem : > With our broken backend, the connection pool is exhausted waiting for other > requests to timeout. When a new request is made by cxf against this backend, > after timeout time this will happen : > - on the one side the reactor threads will get a connection from the pool > and try to write to the output stream. Waiting in the pool is not considered > as receive timeout. > - on the other side the cxf worker thread will wake up (because of the > timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer > (AsyncHTTPClient:624) > - reactor threads will go to infinite loop because they will try to > produceContent from a shutdown buffer (SharedOutputBuffer:120) > > From there, application recovery is compromised. > > To fix that, timeout should be handled only via the client callback > (AsyncHTTPConduit:463). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freeman Fang updated CXF-7122: -- Attachment: AsyncHTTPConduitTest.java > Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection > pool > - > > Key: CXF-7122 > URL: https://issues.apache.org/jira/browse/CXF-7122 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: William Montaz >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2.0, 3.1.9 > > Attachments: AsyncHTTPConduitTest.java > > > Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, > requests waiting for a connection will lead to an infinite loop if they reach > receive timeout. > The problem occured on all versions of CXF above 3.0.5 (we did not tested > other ones). > Let's imagine a backend that's broken and leads to timeout for all requests. > When handling requests, the cxf worker thread will eventually go in wait > state (AsyncHTTPConduit:618), with a timeout that matches the > HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to > complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). > The timeout on the wait is the big problem : > With our broken backend, the connection pool is exhausted waiting for other > requests to timeout. When a new request is made by cxf against this backend, > after timeout time this will happen : > - on the one side the reactor threads will get a connection from the pool > and try to write to the output stream. Waiting in the pool is not considered > as receive timeout. > - on the other side the cxf worker thread will wake up (because of the > timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer > (AsyncHTTPClient:624) > - reactor threads will go to infinite loop because they will try to > produceContent from a shutdown buffer (SharedOutputBuffer:120) > > From there, application recovery is compromised. > > To fix that, timeout should be handled only via the client callback > (AsyncHTTPConduit:463). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[
https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635539#comment-15635539
]
Freeman Fang commented on CXF-7122:
---
Hi William,
To demonstrate your patch doesn't work, please take a look at the
AsyncHTTPConduitTest.java I just appended(that use 1 connection intended to
mimic the connection ran out situation).
You can check out the latest CXF master code, revert my last commit, apply your
patch, override the AsyncHTTPConduitTest.java I appended here, than run the
test with
{code}
mvn clean install -Dtest=AsyncHTTPConduitTest#testTimeoutAsync
{code}
You can debug and see with the 30 secs this test duration, the Infinite loop
call into SharedOutputBuffer.produceContent still there
Or you can add a print log in SharedOutputBuffer.produceContent
{code}
if (this.shutdown) {
System.out.println("the SharedOutputBuffer is shutdown");
return -1;
}
{code}
to see the Infinite loop is there more clearly.
Hope this can clarify
Freeman
> Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection
> pool
> -
>
> Key: CXF-7122
> URL: https://issues.apache.org/jira/browse/CXF-7122
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Reporter: William Montaz
>Assignee: Freeman Fang
>Priority: Critical
> Fix For: 3.2.0, 3.1.9
>
> Attachments: AsyncHTTPConduitTest.java
>
>
> Using AsyncHTTPConduit, when the underlying connection pool gets exhausted,
> requests waiting for a connection will lead to an infinite loop if they reach
> receive timeout.
> The problem occured on all versions of CXF above 3.0.5 (we did not tested
> other ones).
> Let's imagine a backend that's broken and leads to timeout for all requests.
> When handling requests, the cxf worker thread will eventually go in wait
> state (AsyncHTTPConduit:618), with a timeout that matches the
> HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to
> complete and call notifyAll via responseCallback (AsyncHTTPConduit:455).
> The timeout on the wait is the big problem :
> With our broken backend, the connection pool is exhausted waiting for other
> requests to timeout. When a new request is made by cxf against this backend,
> after timeout time this will happen :
> - on the one side the reactor threads will get a connection from the pool
> and try to write to the output stream. Waiting in the pool is not considered
> as receive timeout.
> - on the other side the cxf worker thread will wake up (because of the
> timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer
> (AsyncHTTPClient:624)
> - reactor threads will go to infinite loop because they will try to
> produceContent from a shutdown buffer (SharedOutputBuffer:120)
>
> From there, application recovery is compromised.
>
> To fix that, timeout should be handled only via the client callback
> (AsyncHTTPConduit:463).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15635570#comment-15635570 ] William Montaz commented on CXF-7122: - Thank you, I will be able to test that in a few hours. Beside the fact that my approach to this problem might not be the good one did you take in account my other remarks (ReadTimeoutException even if nothing is written on the socket, partial request written on the socket, etc...) , > Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection > pool > - > > Key: CXF-7122 > URL: https://issues.apache.org/jira/browse/CXF-7122 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: William Montaz >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2.0, 3.1.9 > > Attachments: AsyncHTTPConduitTest.java > > > Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, > requests waiting for a connection will lead to an infinite loop if they reach > receive timeout. > The problem occured on all versions of CXF above 3.0.5 (we did not tested > other ones). > Let's imagine a backend that's broken and leads to timeout for all requests. > When handling requests, the cxf worker thread will eventually go in wait > state (AsyncHTTPConduit:618), with a timeout that matches the > HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to > complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). > The timeout on the wait is the big problem : > With our broken backend, the connection pool is exhausted waiting for other > requests to timeout. When a new request is made by cxf against this backend, > after timeout time this will happen : > - on the one side the reactor threads will get a connection from the pool > and try to write to the output stream. Waiting in the pool is not considered > as receive timeout. > - on the other side the cxf worker thread will wake up (because of the > timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer > (AsyncHTTPClient:624) > - reactor threads will go to infinite loop because they will try to > produceContent from a shutdown buffer (SharedOutputBuffer:120) > > From there, application recovery is compromised. > > To fix that, timeout should be handled only via the client callback > (AsyncHTTPConduit:463). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7125) Automatically expose logging feature as intent for DOSGi
Christian Schneider created CXF-7125: Summary: Automatically expose logging feature as intent for DOSGi Key: CXF-7125 URL: https://issues.apache.org/jira/browse/CXF-7125 Project: CXF Issue Type: Improvement Components: logging Affects Versions: 3.1.8 Reporter: Christian Schneider Assignee: Christian Schneider Fix For: 3.2.0, 3.1.9 To use logging in DOSGi you need to publish an intent service by yourself. It would be a lot easier if the logging feature would export a logging intent by default that you then can simply add to the intents of your remote service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7120) Can CXF REST sync and async WS compatible with JavaScript client?
[ https://issues.apache.org/jira/browse/CXF-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636008#comment-15636008 ] Sergey Beryozkin commented on CXF-7120: --- Please do not be disappointed and at no point of time I was considering your questions be unreasonable. Please also note there are no 'must' commitments on the CXF part - we do our best to address various issues but whenever one feels something is missing and no immediate support is coming - it is a great opportunity to roll the sleeves and provide a patch or a piece of the documentation as opposed to requesting the actions from the CXF developers and/or becoming upset. In this particular case: it is a not JIRA issue. Please ask for the advice on the CXF users list. IMHO (and I may be missing the point) this question is not CXF-related. If it is a piece of a JAX-RS interface then the client (JavaScript or not) can simply continue using basic HTTP library support. And I do not know anything about doing JavaScript and Soap. Please ask on the users or check the web for the answers. > Can CXF REST sync and async WS compatible with JavaScript client? > - > > Key: CXF-7120 > URL: https://issues.apache.org/jira/browse/CXF-7120 > Project: CXF > Issue Type: Wish > Components: JAX-RS >Reporter: Colbert Philippe >Assignee: Sergey Beryozkin >Priority: Critical > Labels: async, asynchronous, javascript, jscript, perl, python, > ruby, sync, synchronous > > When writing a real web application the client is likely going to be written > in JavaScript in a web-browser and if the server uses CXF then it's in Java. > I think it's the case for a vast majority of CXF users. > 1) QUESTION: Can we write a synchronous web service using CXF JAX-RS (REST) > in Java and invoke it from JavaScript? Are there any features that are not > supported by JavaScript? > 2) QUESTION: Can we write an asynchronous web service using CXF JAX-RS > (REST) in Java and invoke it from JavaScript? Are there any features that > are not supported by JavaScript? > I think many of us would appreciate a chapter in the documentation that talks > about scenarios when using different languages as clients, JavaScript is one, > but the client could as well be in Python, Ruby, Perl.You should > recommend frameworks from other languages that have been tested to work with > CXF.Please, cover both the synchronous and asynchronous case. A > compatibility table should be given to out all client frameworks that have > been tested to work with CXF. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636082#comment-15636082 ] Sergey Beryozkin commented on CXF-7122: --- Hi William, do you think your patch can help with ReadTimeoutException/partial writes in addition to the fix provided by Freeman or a new patch may be needed ? thanks > Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection > pool > - > > Key: CXF-7122 > URL: https://issues.apache.org/jira/browse/CXF-7122 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: William Montaz >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2.0, 3.1.9 > > Attachments: AsyncHTTPConduitTest.java > > > Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, > requests waiting for a connection will lead to an infinite loop if they reach > receive timeout. > The problem occured on all versions of CXF above 3.0.5 (we did not tested > other ones). > Let's imagine a backend that's broken and leads to timeout for all requests. > When handling requests, the cxf worker thread will eventually go in wait > state (AsyncHTTPConduit:618), with a timeout that matches the > HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to > complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). > The timeout on the wait is the big problem : > With our broken backend, the connection pool is exhausted waiting for other > requests to timeout. When a new request is made by cxf against this backend, > after timeout time this will happen : > - on the one side the reactor threads will get a connection from the pool > and try to write to the output stream. Waiting in the pool is not considered > as receive timeout. > - on the other side the cxf worker thread will wake up (because of the > timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer > (AsyncHTTPClient:624) > - reactor threads will go to infinite loop because they will try to > produceContent from a shutdown buffer (SharedOutputBuffer:120) > > From there, application recovery is compromised. > > To fix that, timeout should be handled only via the client callback > (AsyncHTTPConduit:463). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6969) CXF Async HTTP Transport - add supports to configure httpclient with new method
[ https://issues.apache.org/jira/browse/CXF-6969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636145#comment-15636145 ] Sergey Beryozkin commented on CXF-6969: --- [~ffang] Hi Freeman, given you are well into the async client code right now :-), may be you can look at this issue when you get a chance ? > CXF Async HTTP Transport - add supports to configure httpclient with new > method > --- > > Key: CXF-6969 > URL: https://issues.apache.org/jira/browse/CXF-6969 > Project: CXF > Issue Type: Improvement > Components: Transports >Reporter: Chester Kim > > Refer to https://issues.apache.org/jira/browse/CXF-6964 > Configuration of timeout and etc of httpclient with properties are deprecated > in the latest version of apache httpcomponents. We need to go with new way > (Configuration class). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7124) PackageUtils.getSharedPackageName(List>) has bug
[ https://issues.apache.org/jira/browse/CXF-7124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-7124. --- Resolution: Fixed Assignee: Sergey Beryozkin Thanks for the patch > PackageUtils.getSharedPackageName(List>) has bug > - > > Key: CXF-7124 > URL: https://issues.apache.org/jira/browse/CXF-7124 > Project: CXF > Issue Type: Bug > Components: Core, JAX-RS >Affects Versions: 3.1.7 > Environment: mac swagger >Reporter: Neal Hu >Assignee: Sergey Beryozkin > Fix For: 3.2.0, 3.1.9, 3.0.12 > > Attachments: org.apache.cxf.common.util.PackageUtils.patch, > org.apache.cxf.common.util.PackageUtilsTest.patch > > > The swagger feature scans undefined api, the root cause is the util in > PackageUtils has bug. For example: > String packageName = PackageUtils.getSharedPackageName( > Arrays.asList(org.apache.cxf.common.util.PackageUtils.class, > org.apache.cxf.bus.CXFBusFactory.class, > org.apache.cxf.common.jaxb.JAXBContextCache.class)); > Currently we get org.apache, but we should get org.apache.cxf. > I have uploaded the patch and verified in the local environment, please > review. > -- > org.apache.cxf.jaxrs.swagger.AbstractSwaggerFeature.setResourcePackage(String) > --> > org.apache.cxf.common.util.PackageUtils.getSharedPackageName(List>) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CXF-7125) Automatically expose logging feature as intent for DOSGi
[ https://issues.apache.org/jira/browse/CXF-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Schneider resolved CXF-7125. -- Resolution: Fixed > Automatically expose logging feature as intent for DOSGi > > > Key: CXF-7125 > URL: https://issues.apache.org/jira/browse/CXF-7125 > Project: CXF > Issue Type: Improvement > Components: logging >Affects Versions: 3.1.8 >Reporter: Christian Schneider >Assignee: Christian Schneider > Fix For: 3.2.0, 3.1.9 > > > To use logging in DOSGi you need to publish an intent service by yourself. > It would be a lot easier if the logging feature would export a logging intent > by default that you then can simply add to the intents of your remote service. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CXF-7126) WebTarget Doesn't Set Origin Header
James Carman created CXF-7126:
-
Summary: WebTarget Doesn't Set Origin Header
Key: CXF-7126
URL: https://issues.apache.org/jira/browse/CXF-7126
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.8
Reporter: James Carman
When trying to execute a simple "hello world" GET request such as:
{code}
WebTarget target = ClientBuilder.newClient().target("http://localhost:8080/";);
String answer = target.path("hello").path("World")
.request(MediaType.TEXT_PLAIN)
.header("Origin", "http://localhost/";)
.get(String.class);
{code}
I do not see the "Origin" header on the server when the request gets there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7127) WebTarget Doesn't Set Origin Header
James Carman created CXF-7127:
-
Summary: WebTarget Doesn't Set Origin Header
Key: CXF-7127
URL: https://issues.apache.org/jira/browse/CXF-7127
Project: CXF
Issue Type: Bug
Components: JAX-RS
Affects Versions: 3.1.8
Reporter: James Carman
When trying to execute a simple "hello world" GET request such as:
{code}
WebTarget target = ClientBuilder.newClient().target("http://localhost:8080/";);
String answer = target.path("hello").path("World")
.request(MediaType.TEXT_PLAIN)
.header("Origin", "http://localhost/";)
.get(String.class);
{code}
I do not see the "Origin" header on the server when the request gets there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CXF-7126) WebTarget Doesn't Set Origin Header
[
https://issues.apache.org/jira/browse/CXF-7126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman closed CXF-7126.
-
Resolution: Duplicate
> WebTarget Doesn't Set Origin Header
> ---
>
> Key: CXF-7126
> URL: https://issues.apache.org/jira/browse/CXF-7126
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: James Carman
>
> When trying to execute a simple "hello world" GET request such as:
> {code}
> WebTarget target = ClientBuilder.newClient().target("http://localhost:8080/";);
> String answer = target.path("hello").path("World")
> .request(MediaType.TEXT_PLAIN)
> .header("Origin", "http://localhost/";)
> .get(String.class);
> {code}
> I do not see the "Origin" header on the server when the request gets there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7127) WebTarget Doesn't Set Origin Header
[
https://issues.apache.org/jira/browse/CXF-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636577#comment-15636577
]
James Carman commented on CXF-7127:
---
The issue is HttpURLConnection. It filters out headers that it doesn't like
(including Origin). You need to force it to use the HttpClient:
1. Add a dependency to the cxf-rt-transports-http-hc module:
{code}
org.apache.cxf
cxf-rt-transports-http-hc
${cxf.version}
{code}
2. Set the "use.async.http.conduit" property:
{code}
WebTarget target = ClientBuilder.newClient().target("http://localhost:8080/";);
String answer = target.path("hello").path("World")
.property("use.async.http.conduit", true)
.request(MediaType.TEXT_PLAIN)
.header("Origin", "http://localhost/";)
.get(String.class);
{code}
> WebTarget Doesn't Set Origin Header
> ---
>
> Key: CXF-7127
> URL: https://issues.apache.org/jira/browse/CXF-7127
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: James Carman
>
> When trying to execute a simple "hello world" GET request such as:
> {code}
> WebTarget target = ClientBuilder.newClient().target("http://localhost:8080/";);
> String answer = target.path("hello").path("World")
> .request(MediaType.TEXT_PLAIN)
> .header("Origin", "http://localhost/";)
> .get(String.class);
> {code}
> I do not see the "Origin" header on the server when the request gets there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CXF-7127) WebTarget Doesn't Set Origin Header
[
https://issues.apache.org/jira/browse/CXF-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Carman closed CXF-7127.
-
Resolution: Workaround
There is a work-around for this issue involving the HTTP Client transport (see
comment).
> WebTarget Doesn't Set Origin Header
> ---
>
> Key: CXF-7127
> URL: https://issues.apache.org/jira/browse/CXF-7127
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
>Reporter: James Carman
>
> When trying to execute a simple "hello world" GET request such as:
> {code}
> WebTarget target = ClientBuilder.newClient().target("http://localhost:8080/";);
> String answer = target.path("hello").path("World")
> .request(MediaType.TEXT_PLAIN)
> .header("Origin", "http://localhost/";)
> .get(String.class);
> {code}
> I do not see the "Origin" header on the server when the request gets there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7117) Swagger2Feature not working in OSGi container when jaxrs server address not attached to CXF servlet
[
https://issues.apache.org/jira/browse/CXF-7117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636794#comment-15636794
]
Sergey Beryozkin commented on CXF-7117:
---
Hi
Can you please remove a "basePath" and "usePathBasedConfig" properties ?
thanks
> Swagger2Feature not working in OSGi container when jaxrs server address not
> attached to CXF servlet
> ---
>
> Key: CXF-7117
> URL: https://issues.apache.org/jira/browse/CXF-7117
> Project: CXF
> Issue Type: Bug
> Components: OSGi
>Affects Versions: 3.1.8
> Environment: Apache Karaf 3.0.8
>Reporter: Concombre Masqué
>
> Just modify sample description_swagger2_osgi as follows:
>
> class="org.apache.cxf.jaxrs.swagger.Swagger2Feature">
>
>
>
>
>
>
>
>
> address="http://localhost:9091/test/swaggerSample";>
>
>
>
>
>
>
>
>
>
>
>
>
> Then deploy modified bundle into Karaf and browse Swagger service definition
> at http://localhost:9091/test/swaggerSample/swagger.json
> Result is:
> {"swagger":"2.0"}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CXF-7128) Review the possibility of using OWASP Sanitizer in FormattedServiceListWriter
Sergey Beryozkin created CXF-7128: - Summary: Review the possibility of using OWASP Sanitizer in FormattedServiceListWriter Key: CXF-7128 URL: https://issues.apache.org/jira/browse/CXF-7128 Project: CXF Issue Type: Improvement Components: Transports Reporter: Sergey Beryozkin Fix For: NeedMoreInfo https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project project (and related projects) offer a number of ways to protect against XSS. Right now CXF ServletController uses BaseUrlHelper to recreate an absolute URL it listens upon, by removing all the matrix parameters which were shown to pose a risk (CXF-6216). The question is: is CXF-6216 fix sufficient or some more formal approach is needed. My own opinion right now is that a CXF-6216 fix is good and there's no obvious need to add another library unless a new concrete attack is discovered. CXF-6216 fix results in all the matrix parameters, if any, being removed. The encoding approach will keep them in the encoded form in service URIs which will be shown to the user. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-6216) No output sanitizing in FormattedServiceListWriter
[
https://issues.apache.org/jira/browse/CXF-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636852#comment-15636852
]
Sergey Beryozkin commented on CXF-6216:
---
https://issues.apache.org/jira/browse/CXF-7128 has been created to review the
possibility of using OWASP sanitizers.
The 'matrix param' attack has been fixed by removing all the matrix parameters
from the absolute URL which is built by ServletController with the help of
BaseUrlHelper. This constitutes a concrete form of sanitizing the URI.
> No output sanitizing in FormattedServiceListWriter
> ---
>
> Key: CXF-6216
> URL: https://issues.apache.org/jira/browse/CXF-6216
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.0.1
>Reporter: Donald Kwakkel
>Assignee: Sergey Beryozkin
>Priority: Critical
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> No output sanitizing is done, which makes the code vulnerable for injection.
> I do not have a specific use case, but it is good habit to do. Maybe you can
> use the OWASP Sanitizer:
> https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project
> One example from the file:
> writer.write("Endpoint address: " +
> ""
> + absoluteURL + "");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6216) No output sanitizing in FormattedServiceListWriter
[
https://issues.apache.org/jira/browse/CXF-6216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-6216.
---
Resolution: Fixed
> No output sanitizing in FormattedServiceListWriter
> ---
>
> Key: CXF-6216
> URL: https://issues.apache.org/jira/browse/CXF-6216
> Project: CXF
> Issue Type: Bug
> Components: Transports
>Affects Versions: 3.0.1
>Reporter: Donald Kwakkel
>Assignee: Sergey Beryozkin
>Priority: Critical
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
>
> No output sanitizing is done, which makes the code vulnerable for injection.
> I do not have a specific use case, but it is good habit to do. Maybe you can
> use the OWASP Sanitizer:
> https://www.owasp.org/index.php/OWASP_Java_HTML_Sanitizer_Project
> One example from the file:
> writer.write("Endpoint address: " +
> ""
> + absoluteURL + "");
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CXF-7116) AsyncResponse.resume() infinitely hangs up after first call
[
https://issues.apache.org/jira/browse/CXF-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15636995#comment-15636995
]
Sergey Beryozkin commented on CXF-7116:
---
I've added a single synchronization block which fixes the issue. It is quite
hard to identify why exactly it is happening in case of the embedded Jetty
transport. I can only think of the spurious retries which this block protects
again.
FYI, in the case of using Jetty embedded transport, AsyncResponse is not 100%
feature complete, it is not built on top of the standard AsyncContext but on
Jetty specific Continuation API, and multiple timeouts (something one can do
with JAX-RS 2.0 TimeoutHandler) do not work in this case, Jetty would throw the
exceptions (see CXF JettyContinuationWrapper.reset()) - but admittedly multiple
timeouts is not a mainstream case.
Please give 3.1.9-SNAPSHOT a try next week
> AsyncResponse.resume() infinitely hangs up after first call
> ---
>
> Key: CXF-7116
> URL: https://issues.apache.org/jira/browse/CXF-7116
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
> Environment: * Java - 1.8.0_66 (build 1.8.0_66-b17)
> * CXF - 3.1.8
> * Jetty - 9.3.13.v20161014
> * OS - OS X El Capitan 10.11.6
>Reporter: Dmytro Khrystiuk
> Labels: async
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
> Attachments: cxf-issue.zip
>
>
> Issue with AsyncResponse happened after upgrade from CXF 3.1.7 to 3.1.8.
> After the second call to REST method server stops to respond. Implementation
> of method uses AsyncResponse and call to resume() in a separate thread:
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> @Path("/doesNotWork")
> public void doesNotWork(@Suspended AsyncResponse response) {
> executorService.submit(() -> {
> LOGGER.debug("Async task...");
> response.resume("Success!");
> });
> }
> First call to method above works as it should but subsequent calls just hangs
> up forever. No thread deadlocks were detected.
> The example test (Maven project) is attached to this item.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-7116) AsyncResponse.resume() infinitely hangs up after first call
[
https://issues.apache.org/jira/browse/CXF-7116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin resolved CXF-7116.
---
Resolution: Fixed
Assignee: Sergey Beryozkin
Fix Version/s: 3.0.12
3.1.9
3.2.0
> AsyncResponse.resume() infinitely hangs up after first call
> ---
>
> Key: CXF-7116
> URL: https://issues.apache.org/jira/browse/CXF-7116
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
>Affects Versions: 3.1.8
> Environment: * Java - 1.8.0_66 (build 1.8.0_66-b17)
> * CXF - 3.1.8
> * Jetty - 9.3.13.v20161014
> * OS - OS X El Capitan 10.11.6
>Reporter: Dmytro Khrystiuk
>Assignee: Sergey Beryozkin
> Labels: async
> Fix For: 3.2.0, 3.1.9, 3.0.12
>
> Attachments: cxf-issue.zip
>
>
> Issue with AsyncResponse happened after upgrade from CXF 3.1.7 to 3.1.8.
> After the second call to REST method server stops to respond. Implementation
> of method uses AsyncResponse and call to resume() in a separate thread:
> @GET
> @Produces(MediaType.TEXT_PLAIN)
> @Path("/doesNotWork")
> public void doesNotWork(@Suspended AsyncResponse response) {
> executorService.submit(() -> {
> LOGGER.debug("Async task...");
> response.resume("Success!");
> });
> }
> First call to method above works as it should but subsequent calls just hangs
> up forever. No thread deadlocks were detected.
> The example test (Maven project) is attached to this item.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CXF-6904) Unable to read swagger annotations if the file is in another osgi bundle
[ https://issues.apache.org/jira/browse/CXF-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin resolved CXF-6904. --- Resolution: Fixed Assignee: Sergey Beryozkin Fix Version/s: 3.1.8 > Unable to read swagger annotations if the file is in another osgi bundle > > > Key: CXF-6904 > URL: https://issues.apache.org/jira/browse/CXF-6904 > Project: CXF > Issue Type: Bug > Components: JAX-RS, OSGi >Reporter: Christian Lutz >Assignee: Sergey Beryozkin > Fix For: 3.1.8 > > > I created a simple example to reproduce the error. > https://github.com/ChristianLutz/cxf-swagger-osgi-bug > = > JAX-RS Swagger2Feature OSGI Issue > = > This example is based on the code from > https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/description_swagger2_osgi > How to reproduce the issue: > mvn install (on the example) > bin/karaf (I used the current karaf 4.0.5) > > on karaf@root()> > feature:repo-add cxf 3.1.6 > feature:install cxf-rs-description-swagger2 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-base/2.6.5 > install mvn:com.fasterxml.jackson.jaxrs/jackson-jaxrs-json-provider/2.6.5 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-api/1.0.0 > install -s mvn:de.kreeloo/cxf-swagger2-osgi-impl/1.0.0 > > It may happen that one component is complaining about a missing guava class > even if you provided it before. All you have todo is copy guava-18.jar into > your deploy folder. I think this is a karaf bug. I have to create a ticket > for. After you place the guava file into your deploy folder and type list, > all bundles should be active. > Now open your web browser and type: > http://localhost:8181/cxf/swaggerSample/swagger.json > And all you see is the swagger header. > > I guess the problem is the ClasspathHelper.class from org.reflections it > looks like that this one is not able to access the osgi component. > > The behavior is similar to this error description: > > http://cxf.547215.n5.nabble.com/Swagger2Feature-via-blueprint-config-does-not-produce-the-expected-results-td5761841.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CXF-6865) Add cache for target resouce method matching
[
https://issues.apache.org/jira/browse/CXF-6865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Beryozkin updated CXF-6865:
--
Fix Version/s: 3.1.9
3.2.0
> Add cache for target resouce method matching
>
>
> Key: CXF-6865
> URL: https://issues.apache.org/jira/browse/CXF-6865
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
>Affects Versions: 3.1.6, 3.0.9
> Environment: mac, windows
>Reporter: Neal Hu
> Fix For: 3.2.0, 3.1.9
>
> Attachments: JAXRSInInterceptor.patch, ResourceMethodCache.java
>
>
> Find the target resouce method in JAXRSInInterceptor is time comsuming:
> JAXRSInInterceptor.java:159==>JAXRSUtils.selectResourceClass(resources,
> rawPath, message);
> Adding cache for the ori, matchedvalues and mediatype will improve the
> performence.
> The bottleneck of the CXF implementation is recursiive searching the target
> root resouce classes.
> {code:java}
> String ckey = message.get(Message.BASE_PATH) + ":" + rawPath + ":" +
> httpMethod + ":" + requestContentType + ":" + acceptTypes;
> if (resourceMethodCache != null) {
> ResourceMethodCache rmCache = resourceMethodCache.get(ckey);
> if (rmCache != null) {
> ori = rmCache.getOperationResourceInfo();
> matchedValues = rmCache.getValues();
> String mediaType = rmCache.getMediaType();
> if (!ori.isSubResourceLocator() && mediaType != null) {
> message.getExchange().put(Message.CONTENT_TYPE,
> mediaType);
> }
> setExchangeProperties(message, exchange, ori, matchedValues,
> resources.size());
> shouldFind = false;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CXF-7001) Update JAX-RS SpringBoot starter to support scanning JAX-RS Applications
[ https://issues.apache.org/jira/browse/CXF-7001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Beryozkin updated CXF-7001: -- Fix Version/s: 3.1.9 3.2.0 > Update JAX-RS SpringBoot starter to support scanning JAX-RS Applications > > > Key: CXF-7001 > URL: https://issues.apache.org/jira/browse/CXF-7001 > Project: CXF > Issue Type: Improvement > Components: JAX-RS >Reporter: Sergey Beryozkin >Priority: Minor > Fix For: 3.2.0, 3.1.9 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CXF-7122) Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection pool
[ https://issues.apache.org/jira/browse/CXF-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15637147#comment-15637147 ] William Montaz commented on CXF-7122: - Hi Sergey, just to give you a little feedback. Since Freeman gave me another test case, I could reproduce the infinite loop on his test case and discovered that Freeman patch still leads to problems and my patch is not sufficient at the moment. The description might be quite long and I have to try a solution against different tests cases that I can access only from office. I will give you more feedback monday. Regards > Infinite loop due to AsyncHTTPConduit read timeout with exhausted connection > pool > - > > Key: CXF-7122 > URL: https://issues.apache.org/jira/browse/CXF-7122 > Project: CXF > Issue Type: Bug > Components: Transports >Reporter: William Montaz >Assignee: Freeman Fang >Priority: Critical > Fix For: 3.2.0, 3.1.9 > > Attachments: AsyncHTTPConduitTest.java > > > Using AsyncHTTPConduit, when the underlying connection pool gets exhausted, > requests waiting for a connection will lead to an infinite loop if they reach > receive timeout. > The problem occured on all versions of CXF above 3.0.5 (we did not tested > other ones). > Let's imagine a backend that's broken and leads to timeout for all requests. > When handling requests, the cxf worker thread will eventually go in wait > state (AsyncHTTPConduit:618), with a timeout that matches the > HTTPClientPolicy.setReceiveTimeout() value, waiting for the NIO stack to > complete and call notifyAll via responseCallback (AsyncHTTPConduit:455). > The timeout on the wait is the big problem : > With our broken backend, the connection pool is exhausted waiting for other > requests to timeout. When a new request is made by cxf against this backend, > after timeout time this will happen : > - on the one side the reactor threads will get a connection from the pool > and try to write to the output stream. Waiting in the pool is not considered > as receive timeout. > - on the other side the cxf worker thread will wake up (because of the > timedout wait), and shutdown SharedOutputBuffer and SharedInputBuffer > (AsyncHTTPClient:624) > - reactor threads will go to infinite loop because they will try to > produceContent from a shutdown buffer (SharedOutputBuffer:120) > > From there, application recovery is compromised. > > To fix that, timeout should be handled only via the client callback > (AsyncHTTPConduit:463). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
