JAXWS and Http Post Timeout in GlassFish v3.0.1 - glassfish

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)

Related

aerospike connect timeout works incorrectly?

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.

Aerospike read times out before max retries is reached

I have the following config for aerospike read policy:
clientPolicy.timeout = 200; // timeout for refreshing cluster status, shouldn't affect reads
clientPolicy.readPolicyDefault.socketTimeout = 30;
clientPolicy.readPolicyDefault.totalTimeout = 110;
clientPolicy.readPolicyDefault.maxRetries = 2;
clientPolicy.readPolicyDefault.sleepBetweenRetries = 0;
According to what I found in Aerospike docs this should result in 3 read attempts 30ms max for each (1 initial + 2 retries), which in total is 90 ms and it is less than total timeout of 110 ms.
But in application logs I see timeout exceptions after 1 retry:
org.springframework.dao.QueryTimeoutException: Client timeout: iteration=1 connect=0 socket=30 total=110 maxRetries=2 node= inDoubt=false;
nested exception is com.aerospike.client.AerospikeException$Timeout: Client timeout: iteration=1 connect=0 socket=30 total=110 maxRetries=2 node= inDoubt=false
...
Caused by: com.aerospike.client.AerospikeException$Timeout: Client timeout: iteration=1 connect=0 socket=30 total=110 maxRetries=2 node= inDoubt=false
Is there anything I'm missing? Maybe there are more actions that occur and are included in this total timeout?
Seems like to me you don't have a connection to a node. Try with clientPolicy.timeout = 1000 (default). You may have timed out in trying to establish an initial connection to a node.

Some issues with AspNet Core SignalR KeepAlive timeout

In our project I have set the SignalR as follow :
services.AddSignalR()
.AddHubOptions<NotificationHub>(options =>
{
const int keepAliveIntervalInSeconds=60;
options.EnableDetailedErrors=true;
options.ClientTimeoutInterval = TimeSpan.FromSeconds(2 * keepAliveIntervalInSeconds);
options.HandshakeTimeout = TimeSpan.FromSeconds(keepAliveIntervalInSeconds);
options.KeepAliveInterval = TimeSpan.FromSeconds(keepAliveIntervalInSeconds);
});
but it is not working as it supposed to do. I am getting an error in the client that says :
[2020-06-03T09:48:44.367Z] Error: Connection disconnected with error 'Error: Server timeout elapsed without receiving a message from the server.'.
Is there anything that I am doing wrong here ?
Error: Connection disconnected with error 'Error: Server timeout elapsed without receiving a message from the server.'
In the "Configure server options" section of this doc, we can find:
The default value of KeepAliveInterval is 15 seconds. When changing KeepAliveInterval, we need to change the ServerTimeout/serverTimeoutInMilliseconds setting on the client side too. And the recommended ServerTimeout/serverTimeoutInMilliseconds value is double the KeepAliveInterval value.
And the default timeout value of serverTimeoutInMilliseconds is 30,000 milliseconds (30 seconds), if you just update KeepAliveInterval setting of your SignalR hub to 60 seconds but not change the serverTimeoutInMilliseconds value on your client side, which would cause above error.

Jaxrs ability to set a global timeout (connect + read)

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

Mono error when load testing

During load testing (using Load UI) of a new .Net web api using Mono hosted on a medium sized Amazon server I'm receiving the following results (in chronological order over the course of about ten minutes)
5 connections per second for 60 seconds
No errors
50 connections per second for 60 seconds
No errors
100 connections per second for 60 seconds
Received 3 errors, appearing later during the run
2014-02-07 00:12:10Z Error HttpResponseExtensions Error occured while Processing Request: [IOException] Write failure Write failure|The socket has been shut down
2014-02-07 00:12:10Z Info HttpResponseExtensions Failed to write error to response: {0} Cannot be changed after headers are sent.
5 connections per second for 60 seconds
No errors
100 connections per second for 30 seconds
No errors
100 connections per second for 60 seconds
Received 1 error same as above, appearing later during the run
100 connections per second for 45 seconds
No errors
Doing some research on this, this error seems to be a standard one received when a client closed the connection. As this is only occurring during the heavier load tests, I am wondering if it is just getting to the upper limits of what the server instance can support? If not any suggestions on hunting down the source of the errors?