I am using below code to create a Redis connection pool
GenericObjectPool<StatefulRedisConnection> poolConnections = ConnectionPoolSupport.createGenericObjectPool(
() -> client.connect(), genericObjectPoolConfig);
System.out.println(new Date()+ "..gettign conn from pool..11")
StatefulRedisConnection connection = poolConnections.borrowObject();
It is working fine. However, in 1 use case when redis machine went down then it take borrowObject takes 10 sec to throw exception. I know it may be due to redis lettuce implementation.
Sun Jul 05 17:35:45 IST 2020..gettign conn from pool..11
Sun Jul 05 17:35:55 IST 2020Exception in pushInList() : io.lettuce.core.RedisConnectionException: Unable to connect to 10.32.17.242:11896
Any one suggest how to reduce this time. I want it to throw exception in less than 10 sec. Is there any configuration ?
This is most likely the cause of a socket timeout. In the Lettuce documentation here you can see the default connect timeout is 10 seconds.
You can customize this default socket timeout by updating your RedisClient. In the example below I changed the timeout to be one second.
SocketOptions socketOptions = SocketOptions.builder().connectTimeout(Duration.ofSeconds(1)).build();
ClientOptions clientOptions = ClientOptions.builder().socketOptions(socketOptions).build();
RedisClient redisClient = RedisClient.create(DefaultClientResources.builder().build());
redisClient.setOptions(clientOptions);
Related
I'm using aerospike java client v 6.0.1 and use the following configs from client read policy:
clientPolicy.readPolicyDefault.connectTimeout = 1000;
clientPolicy.readPolicyDefault.socketTimeout = 30;
clientPolicy.readPolicyDefault.totalTimeout = 110;
clientPolicy.readPolicyDefault.maxRetries = 2;
clientPolicy.readPolicyDefault.sleepBetweenRetries = 0;
but I'm getting the following errors from time to time, which say that not all retries were used and timeout occurred:
org.springframework.dao.QueryTimeoutException: Client timeout: iteration=0 connect=1000 socket=30 total=110 maxRetries=2 node=null inDoubt=false; nested exception is com.aerospike.client.AerospikeException$Timeout: Client timeout: iteration=0 connect=1000 socket=30 total=110 maxRetries=2 node=null inDoubt=false
org.springframework.dao.QueryTimeoutException: Client timeout: iteration=1 connect=1000 socket=30 total=110 maxRetries=2 node=A2 node_ip 3000 inDoubt=false; nested exception is com.aerospike.client.AerospikeException$Timeout: Client timeout: iteration=1 connect=1000 socket=30 total=110 maxRetries=2 node=A2 node_ip 3000 inDoubt=false
Does it mean that total operation timeout also involves connect to Aerospike node? Aerospike docs state that total timeout starts after connect timeout finishes:
If connectTimeout is greater than zero, it will be applied to creating a connection plus optional user authentication and TLS handshake. When the connect completes, socketTimeout/totalTimeout is then applied. In this case, totalTimeout starts after the connection completes. see https://discuss.aerospike.com/t/understanding-timeout-and-retry-policies/2852
99% of all my requests to aerospike take less than 20 ms and it doesn't make sense for me to increate total timeout.
Originally I had 200-300 ms connect timeout and I increased it to 1000 ms, but it didn't help much
Transactions can sometimes timeout before the transaction has started. For example, async transactions can be throttled and can exist in the delay queue for longer than totalTimeout. If this occurs, a timeout exception is generated with iteration=0.
Anytime totalTimeout is reached, the transaction is cancelled regardless of the number of retries.
If connectTimeout is used and a new connection is required (no available connections in the pool) for the transaction, the connectTimeout is applied to connection creation and the totalTimeout stopwatch does not start until the new connection is created.
If connectTimeout is used and an existing connection is available from the pool, the connectTimeout is not applicable and the totalTimeout stopwatch starts from the beginning of the transaction.
Since most transactions are able to obtain connections from the pool, it's not surprising that increasing connectTimeout has little effect.
I am using com.jcraft.jsch version 0.1.55 and connecting to a number of Linux servers, one at a time. Some server connections are successful, while others are not.
Ostensibly the code in the servers is identical. I need to find out why the different behaviour.
Client code. Set up
JSch jsch = new JSch();
Session session = jsch.getSession("username", ip_address, 22);
session.setPassword("password");
session.setConfig("StrictHostKeyChecking","no");
session.connect()
Hangs on calling UserAuthGSSAPIWithMIC.start()
Working flow:
Session.start()
line 22 super.start(session) sets buf[5] = 51
line 25 this.buf.putByte((byte)50) sets buf[5] = 50
flow continues to line 39 this.buf = session.read(this.buf) which returns
and has set buf[5] to 51 forcing the auth to move on the next auth method.
Eventually succeeds using the password method
Broken flow:
Session.start()
super.start() sets buf[5] = 51
this.buf.putByte((byte)50) sets buf[5] = 50
flow continues to line 39 this.buf = session.read(this.buf) which returns
and has set buf[5] to 60 which sends the code to create a new context,
part of which calls oid.equals() which hangs on line 160 -
return this.oid.equals.((Object) ((Oid) other).oid);
There are no log messages in this part of the code, so no information about what the code is doing.
I can make the problem go away by setting session.setConfig("PreferredAuthentications", "password");
I want to know why the code is hanging on the UserAuthGSSAPIWithMIC on some servers but not others. Also how I can get some informative logging information.
In Jaxrs (WebClient for instance) we can set a connect timeout and a read timeout.
ClientConfiguration c = WebClient.getConfig(client);
HTTPConduit http = c.getHttpConduit();
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(timeout);
httpClientPolicy.setReceiveTimeout(timeout);
httpClientPolicy.setAllowChunking(false);
http.setClient(httpClientPolicy);
I would like to set a timeout that includes both, I don't really care how much time is spent in connecting or in receiving, my requirement is to get a response in X seconds or just discard the search.
There is no way with CXF to set a maximum timeout for a request that consider both connection and receive durations. The maximum timeout for a request will be:
maximum_timeout = connection_timeout + receive_timeout
See this similar question for Apache HTTP client. The workaround could be to set a timer in a separate Thread to abort the connection when the desired maximum timeout expires
I'm maintaining an antedeluvian Notes application which connects to a SAP back-end via a manually done 'Webservice'
The server is running Domino Release 7.0.4FP2 HF97.
The Webservice is not the more recently Webservice Consumer, but a large Java agent which is using Apache soap.jar (org.apache.soap). Below an example of the calling code.
private Call setupSOAPCall() {
Call call = new Call();
SOAPHTTPConnection conn = new SOAPHTTPConnection();
call.setSOAPTransport(conn);
call.setEncodingStyleURI(Constants.NS_URI_SOAP_ENC);
There has been a change in the SAP system which is now taking 8 minutes to complete (verified by SAP Team).
I'm getting an error message as follows:
[SOAPException: faultCode=SOAP-ENV:Client; msg=For input string: "906 "; targetException=java.lang.NumberFormatException: For input string: "906 "]
I found a blog article describing the error message quite closely:
https://thejavablog.wordpress.com/category/jmeter/
and I've come to the hypothesis that it is a timeout message that is returning to my Call object and that this timeout message is being incorrectly parsed, hence the NumberFormat Exception.
Looking at my logs I can see that there is a time difference of 62 seconds between my call and the response.
I recommended that the server setting in the server document, tab Internet Protocols/HTTP/Timeouts/Request timeouts be changed from 60 seconds to 600 seconds, and the http task restarted with
tell http restart
I've re-run the tests and I am getting the same error, and the time difference is still slightly more than 60 seconds, which is not what I was expecting.
I read Michael Rulnau's blog entry
http://www.mruhnau.net/2014/06/how-to-overcome-domino-webservice.html
which points to this APR
http://www-01.ibm.com/support/docview.wss?uid=swg1LO48272
but I'm not convinced that this would apply in this case, since there is no way that IBM would know that my Java agent is in fact making a Soap call.
My current hypothesis is that I have to use either the setTimeout() method on
org.apache.axis.client.Call
https://axis.apache.org/axis/java/apiDocs/org/apache/axis/client/Call.html
or on the org.apache.soap.transport.http.SOAPHTTPConnection
https://docs.oracle.com/cd/B13789_01/appdev.101/b12024/org/apache/soap/transport/http/SOAPHTTPConnection.html
and that the timeout value is an apache default, not something that is controlled by the Domino server.
I'd be grateful for any help.
I understand your approach, and I hope this is the correct one to solve your problem.
Add a debug (console write would be fine) that display the default Timeout then try to increase it to 10 min.
SOAPHTTPConnection conn = new SOAPHTTPConnection();
System.out.println("time out is :" + conn.getTimeout());
conn.setTimeout(600000);//10 min in ms
System.out.println("after setting it, time out is :" + conn.getTimeout());
call.setSOAPTransport(conn);
Now keep in mind that Dommino has also a Max LotusScript/Java execution time, check this value and (at least for a try) change it: http://www.ibm.com/support/knowledgecenter/SSKTMJ_9.0.1/admin/othr_servertasksagentmanagertab_r.html (it's version 9 help but this part should be identical)
I've since discovered that it wasn't my code generating the error; the default timeout for the apache axis SOAPHTTPConnetion is 0, i.e. no timeout.
I am trying to set connect and request timeout for a JAX WS and Http Post calls.
My code works, but only a maximum of 20 seconds.
That is I can change the timeout value to 5 seconds, 2 seconds, it works, but setting the timeout value to 30 seconds will time out at 20 seconds, setting the time out value to 60 seconds will still timeout at 20 seconds.
Does anybody know where is that maximum of 20 seconds set??
For JAXWS:
//This works, timed out in 10 seconds
((BindingProvider) soapPort).getRequestContext().put(JAXWSProperties.CONNECT_TIMEOUT, 10000);
// This would time out in 20 seconds!!!
((BindingProvider) soapPort).getRequestContext().put(JAXWSProperties.CONNECT_TIMEOUT, 60000);`
For Http:
// This works, timed out in 10 seconds
HttpConnectionParams.setConnectionTimeout(params, 10000);
// This would time out in 20 seconds!!!
HttpConnectionParams.setConnectionTimeout(params, 50000);
The default JAX-WS runtime for Glassfish is Metro 2.0. See the 5.6. HTTP Timeouts section in the Metro guide, so we have:
// setConnectTimeout()
int timeout = ...;
Map<String, Object> ctxt = ((BindingProvider)proxy).getRequestContext();
ctxt.put(JAXWSProperties.CONNECT_TIMEOUT, timeout);
// setReadTimeout()
int timeout = ...;
Map<String, Object> ctxt = ((BindingProvider)proxy).getRequestContext();
ctxt.put("com.sun.xml.ws.request.timeout", timeout);
Only as a guide, you can see that there are three parameters for Websphere (in Metro 2.0 only two), which are:
CONNECTION_TIMEOUT: The amount of time WebSphere JAX-WS client would wait to establish a http/https connection (default is 180 seconds)
WRITE_TIMEOUT: The amount of time the client would wait to finish sending the request (default is 300 seconds)
RESPONSE_TIMEOUT: The amount of time the client would wait to finish receiving the response (default is 300 seconds)