[
https://issues.apache.org/jira/browse/CXF-8410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17265673#comment-17265673
]
Francisco Mateo commented on CXF-8410:
--------------------------------------
[~reta],
Okay, all of that makes sense and using .subscribeOn(Schedulers.elastic()) was
something I tried already which worked, but it did not make sense to me why
there still was a blocking operation.
>From reading over the linked FAQ, my simple example doesn't make any usages of
>the exceptions which may cause blocking.
My understanding so far from looking into to it more, the blocking operations
starts here:
[https://github.com/apache/cxf/blob/cxf-3.4.2/core/src/main/java/org/apache/cxf/endpoint/ClientImpl.java#L525]
Drilling further down you'll eventually come to this reflection operation:
[https://github.com/apache/cxf/blob/cxf-3.4.2/core/src/main/java/org/apache/cxf/transport/TransportFinder.java#L255]
The blocking occurs when the static class field *DEFAULT_NAMESPACES* is
retrieved from *HTTPTransportFactory*.
This causes the static logger to be initialized which is where the blocking
happens.
With that said, my understanding of the following:
{code:java}
JaxWsProxyFactoryBean factoryBean = new JaxWsProxyFactoryBean();
factoryBean.setServiceClass(Foobar.class);
factoryBean.setAddress("https://example.com";);
Foobar fooBar = (Foobar) factoryBean.create();
{code}
Is that everything would have already been "initialized" already thus
potentially avoiding the reflection usage, but that doesn't seem to be the case.
I can certainly go with using a different scheduler if the above simply can't
be avoided.
> HTTPTransportFactory's logger performs blocking call
> ----------------------------------------------------
>
> Key: CXF-8410
> URL: https://issues.apache.org/jira/browse/CXF-8410
> Project: CXF
> Issue Type: Bug
> Components: Transports
> Affects Versions: 3.4.1
> Reporter: Francisco Mateo
> Priority: Major
> Attachments: stacktrace.log
>
>
> I'm doing a POC using clients generated from wsdl2java and Spring Webflux.
> When I enable [BlockHound|https://github.com/reactor/BlockHound] to check for
> any blocking calls, the logger from HTTPTransportFactory blocks:
> [https://github.com/apache/cxf/blob/cxf-3.4.2/rt/transports/http/src/main/java/org/apache/cxf/transport/http/HTTPTransportFactory.java#L71]
> From debugging, when the logger is initialized, it attempts to load
> [https://github.com/apache/cxf/blob/cxf-3.4.2/rt/transports/http/src/main/java/org/apache/cxf/transport/http/Messages.properties]
> Loading that file from the containing JAR via ResourceBundle is a blocking
> operation as far as I can tell.
> My expectation is that when I use an async method from the generated client,
> there should not be any blocking calls made.
> I've created a sample project and a failing test that showcases the issue:
> [https://github.com/ciscoo/cxf-blockhound-webflux]
> I've also attached the stacktrace as well which shows the blocking call.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
