I have some trouble trying to find root cause on why soap call timeout is being ignored at times. I also can't replicate it locally.
It only happens on production server during peak hours/heavy load. Timeout is working off-peak hours.
Below is how timeout out is being setup on code
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.setServiceClass(serviceClass);
factory.setAddress(address);
Object object = factory.create();
Client client = ClientProxy.getClient(object);
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setReceiveTimeout(10000);
httpClientPolicy.setConnectionTimeout(25000);
httpClientPolicy.setAllowChunking(false);
http.setClient(httpClientPolicy);
Apache cxf 2.2.5 is the library being used.
Updating library might not be an option as this is an old project and updating might break or bring more problems as is.
Any ideas?
Related
I'm trying to setup up an http client to authenticate with spnego (apache http client 4.5.2)
Here's the code that setups the client
System.setProperty("javax.security.auth.useSubjectCredsOnly", "false");
final CredentialsProvider credsProvider = new SystemDefaultCredentialsProvider();
credsProvider.setCredentials(new AuthScope(null, -1, null), new KerberosCredentials(null));
final HttpClientBuilder builder = HttpClientBuilder.create();
builder.setDefaultCredentialsProvider(credsProvider);
final ApacheHttpClient4Engine engine = new ApacheHttpClient4Engine(builder.build());
final Client client = new ResteasyClientBuilder().httpEngine(engine).build();
On the server, I have a JAX-RS service which is sitting behind a waffle.servlet.NegotiateSecurityFilter to allow for ntlm or spnego authentication.
When I send my HTTP request from my chrome rest client, it works, authentication is successfully completed using negotiate.
When I try and use the apache http client however, it fails with the message in the log:
2018-03-05 16:47:16,048 DEBUG o.a.h.impl.auth.GGSSchemeBase main Authentication already attempted
2018-03-05 16:47:16,048 DEBUG o.a.h.i.auth.HttpAuthenticator main Authentication failed
After some further investigation I've discovered that the waffle filter is encoutingering GSS_S_CONTINUE_NEEDED and responding with an additional challenge which the apache client is simply ignoring and giving up on.
I've tested my apache client setup against another service which uses spnego (provided by a 3rd party) and it works properly, although doesn't employ the continue token.
I'm not sure if my system is setup incorrectly, and that the continue token shouldn't be happeneing or if the apache http client is improperly configured (or doesn't support continue tokens at all)
There's a very old ticket here https://issues.apache.org/jira/browse/HTTPCLIENT-1107 indicating that something was added to handle additional challenges, but from reading the code in org.apache.http.impl.auth.GGSSchemeBase.parseChallenge(CharArrayBuffer, int, int) it looks as though only the first challange is ever accepted.
I am working on the integration testcases, as part of that different testcase i have set http timeout for a request means i would like to issue the http request to server but timeout should happen from client side before it receives the request. Since i am using CXF, i have changed as according the solution provided in official site,
How to configure the HTTPConduit for the SOAP Client?
I already a question exists,
changing client timeout for a particular request in Apache CXF
My problem,
I have java classes generated from cxf codegen plugin, where a interface is generated which has all the soap web service operations.
URL wsdl = getClass().getResource("wsdl/CustomerService_1.wsdl");
QName serviceName = new QName("srv.retail.app:ws:customer:1", "CustomerService_1");
QName portName =
new QName("srv.retail.app:ws:customer:1", "CustomerService_1PortTypeSoap11");
CustomerService_1 service = new CustomerService_1(wsdl, serviceName);
CustomerService1PortType customerServicePortType = service.getPort(portName, CustomerService1PortType.class);
Client client = ClientProxy.getClient(customerServicePortType);
HTTPConduit http = (HTTPConduit) client.getConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
httpClientPolicy.setReceiveTimeout(300);
http.setClient(httpClientPolicy);
Tried different ways those are not working, will be great if you give inputs on this.
I am using OkHttp3 in my Android app to make HTTP/1.x requests to my backend servers via a forward proxy, like so:
List<Protocol> protos = new ArrayList<>();
protos.add(Protocol.HTTP_2);
protos.add(Protocol.HTTP_1_1);
InetSocketAddress proxyAddr = new InetSocketAddress("proxy.example.com", 80);
Proxy proxy = new Proxy(Proxy.Type.HTTP, proxyAddr);
OkHttpClient cli = new OkHttpClient.Builder()
.proxy(proxy)
.protocols(protos)
.build();
String url = "http://www.example.com/";
Request req = new Request.Builder().url(url).build();
Response res = cli.newCall(req).execute();
I would like to upgrade to HTTP2. However, it seems to me that OkHttp3 can make HTTP2 requests only if we are not going via a HTTP proxy. So, the above code wouldn't work.
In other words, OkHttp3 supports the first 3 cases below but not the fourth. HTTP/2 below means h2 (HTTP/2 over TLS) not h2c (HTTP/2 over clear text).
a) client <-- HTTP/1.x --> upstream server
b) client <-- HTTP/1.x --> forward proxy <-- HTTP/x --> upstream server
c) client <-- HTTP/2 --> upstream server
d) client <-- HTTP/2 --> forward proxy <-- HTTP/x --> upstream server
Does anyone confirm or deny my understanding? Thanks.
OkHttp will do HTTP/2 over an HTTP proxy. You’ll need HTTPS on the server since OkHttp doesn’t implement plaintext HTTP/2.
Jesse, I tried retrieving https://www.google.com/ with Proxy.Type.HTTP via nghttp2's forward proxy nghttpx, which supports HTTP2 over TLS. Unfortunately, TLS handshaking did not happen and the forward proxy reported the following error.
... tls: handshake libssl error: error:1407609B:SSL routines:SSL23_GET_CLIENT_HELLO:https proxy request
From what I gather, this error means that okhttp3's proxy code is not doing TLS handshaking with the forward proxy.
This makes me think that HTTP2 over TLS via a forward proxy is kind of pointless, because the forward proxy won't be able to add any value to encrypted requests - the forward proxy is just a pass-through pipe. In fact, I think TLS via any forward proxy is pointless. End-to-end HTTP2 over TLS does make sense, but via a forward proxy doesn't.
I have a machine running Jetty. On there I have multiple jetty instances running on different ports. For instance I have the "live" version running on the default port 80. I also have the "R&D" version running on the same machine but on port 2280. This works just fine, however the client needed to add SSL so the default would now be running off port 443. The issue is when I try to run both at the same time the R&D version will fail because it is trying to map to 443 because of the SSL. The config still has the R&D pointing to 2280 but does not start. Is there a way to run both at the same time using the single SSL certificate? I tried adding connectors in the jetty.xml file but that did not work. Thanks.
How are you adding the connector? You can definitely configure the port of the connector.
I typically run Jetty programmatically, and my code is as follows:
int httpsPort = ...;
HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSecureScheme("https");
httpConfig.setSecurePort(httpsPort);
SslContextFactory sslContextFactory = new SslContextFactory();
// configure sslContextFactory: keystore, session timeout, exlcluded protocols etc...
ServerConnector httpsCon = new ServerConnector(server, new SslConnectionFactory(sslContextFactory, "http/1.1"), new HttpConnectionFactory(httpConfig));
httpsCon.setPort(httpsPort);
server.addConnector(httpsCon);
Sorry, I am not sure how to configure that via XML server configuration, but they tend to map very closely between XML config and programmatic config.
I have to set a different timeout in Apache cxf request based on some condition in my request
my current code looks like this
<http-conf:client ReceiveTimeout="120000" AcceptEncoding="gzip, deflate"/>
Now is there any way to change this receive timeout for a particular request based on some condition.
Current we don't provide this kind of setting in CXF.
If you still want to do that, you can get the HttpConduit from the CXF client proxy and set the HTTPClientPolicy directly to the HttpConduit.
// Get the HttpConduit
HttpConduit httpConduit = (HttpConduit) ClientProxy.getClient(greeter).getConduit();
// Set your custom HTTPClientPolicy directly to the httpConduit
httpConduit.setHTTPClientPolicy(httpClientPolicy);
In this way, you can update the timeout before sending the request to the server.