We Keep Coding

About SpringBoot Tomcat acceptCount pool

I'm dealing with the Tomcat configuration on springboot.
Let's supposse i have the following configuration:
server:
tomcat:
min-spare-threads: ${min-tomcat-threads:20}
max-threads: ${max-tomcat-threads:20}
accept-count: ${accept-concurrent-queue:1}
max-connections: ${max-tomcat-connections:100}
I have a simple RestController with this code:
public String request(#Valid #RequestBody Info info) {
log.info("Thread sleeping");
Thread.sleep(8000);
return "OK";
}
Then i make the following test:
I send 200 HTTP request per second.
I check the log and as I expected I see 100 simultaneous executions and after 8 seconds I see the last one (queued).
Other executions are rejected.
The main problem that i have with this is that if i have a timeout control on client call (for example, 5 seconds), the queued operation will be processed on server anyways even if it was rejected on client.
I want to avoid this situation, so I tried:
server:
tomcat:
min-spare-threads: ${min-tomcat-threads:20}
max-threads: ${max-tomcat-threads:20}
accept-count: ${accept-concurrent-queue:0}
max-connections: ${max-tomcat-connections:100}
But this "0" is totally ignored (i think in this case it means "infinite").
So, my question is:
¿Is it possible to configure Tomcat to don't queue operations if the max-connections limit is reached?
Or maybe
¿Is it possible to configure Tomcat to reject any operation queued?
Thank you very much in advance.
Best regards.

The value of the acceptCount parameter is passed directly to the operating system: e.g. for UNIX-es it is passed to listen. Since an incoming connection is always put in the OS queue before the JVM accepts it, values lower than 1 make no sense. Tomcat explicitly ignores such values and keeps its default 100.
However, the real queue in Tomcat are the connections that where accepted from the OS queue, but are not being processed due to a lack of processing threads (maxThreads). You might have at most maxConnections - maxThreads + 1 such connections. In your case it's 81 connections waiting to be processed.

java ldap connection pool timeout property not working as expected

In java LDAP connection pooling, I have noticed that the pool timeout setting property is not working properly. Given below are the ldap connection pooling logs while testing my application.
Following are the values for initSize & pool timeout properties
com.sun.jndi.ldap.connect.pool.initsize = 10
com.sun.jndi.ldap.connect.pool.timeout = 300000
==================== LDAP LOGS ======================
21:38:48,480 Create com.sun.jndi.ldap.LdapClient#e2d0ca3
21:38:48,480 Create com.sun.jndi.ldap.LdapClient#4f652edf
21:38:48,495 Create com.sun.jndi.ldap.LdapClient#53bb2d84
21:38:48,558 Create com.sun.jndi.ldap.LdapClient#45766ee8
21:38:48,558 Create com.sun.jndi.ldap.LdapClient#703c62f5
21:38:48,573 Create com.sun.jndi.ldap.LdapClient#279dd5ca
21:38:48,589 Create com.sun.jndi.ldap.LdapClient#51c329b8
21:38:48,605 Create com.sun.jndi.ldap.LdapClient#7ec5afb0
21:38:48,605 Create com.sun.jndi.ldap.LdapClient#3e3659c6
21:38:48,620 Create com.sun.jndi.ldap.LdapClient#5bef29e1
21:38:48,620 Create and use com.sun.jndi.ldap.LdapClient#332bf735
21:38:50,102 Release com.sun.jndi.ldap.LdapClient#332bf735
21:41:05,661 Expired com.sun.jndi.ldap.LdapClient#e2d0ca3 expired
21:41:05,661 Expired com.sun.jndi.ldap.LdapClient#4f652edf expired
21:41:05,661 Expired com.sun.jndi.ldap.LdapClient#53bb2d84 expired
21:41:05,661 Expired com.sun.jndi.ldap.LdapClient#45766ee8 expired
21:41:05,662 Expired com.sun.jndi.ldap.LdapClient#703c62f5 expired
21:41:05,693 Expired com.sun.jndi.ldap.LdapClient#279dd5ca expired
21:41:05,693 Expired com.sun.jndi.ldap.LdapClient#51c329b8 expired
21:41:05,693 Expired com.sun.jndi.ldap.LdapClient#7ec5afb0 expired
21:41:05,693 Expired com.sun.jndi.ldap.LdapClient#3e3659c6 expired
21:41:05,709 Expired com.sun.jndi.ldap.LdapClient#5bef29e1 expired
21:46:05,724 Expired com.sun.jndi.ldap.LdapClient#332bf735 expired
When the application requested for a first LDAP connection, 10 new connections are created (as init size is set to 10) along with the requested connection. After the used connection is released back to pool, it is not expired after 5 mins and same is the case with other 10 connections. I am not sure why the ldap pool timeout property is not working properly as I am getting different behaviors (some times connections getting expired in 1 min) while testing the same scenario different times. Has any one has experienced the same kind of behavior and any resolution for this?

Finally, after breaking my head for while I understand that the connection pool timeout property is working as designed and I have interpreted this in a wrong way.
My first LDAP connection pool was created at 16:36:04. So, starting from that time the pool cleaning job will run every 5 minutes. So, lets say if new LDAP connections are created just few seconds or minutes before this scheduled job, they will be removed from the pool as part of the cleaning process. So, all the connections shown in the above log were expired at 21:41:05 even though they were created at 21:38:48.
So, don't expect that the LDAP connection will be removed from the pool only after 5 minutes of idle time.

WebSphere Commerce - How does ReLogonFormView / Session Expiration Work?

Sorry for the broad topic. Basically, WSC is supposed to have out-of-the-box session timeout handling by forwarding the user to the ReLogonFormView, which the user can presumably configure (through Struts) to any jsp that they choose. We use a custom logoff command, and it seems to be affecting that view showing up.
I'm not looking for a specific solution to this problem, I'm just looking for general knowledge about how WSC (v6) handles session timeouts (how it determines that the session has timed out) and what command(s) it runs by default when / if / to determine the session has expired.

This is my current knowledge on this subject...
The session timeout is a global value for all web modules and can be found in the wc-server.xml and is set to 30 minutes OOTB.
When a timout occurs, the OOTB LogoffCmd would normally be called, which will set up the necessary URLs to navigate to the ReLogonFormView URL while keeping hold of the URL where the session timeout occurred.
If the ReLogonFormView contains userid/password fields to allow the user to logon again, the user will then be redirected back to the page they were originally on.
More info can be found in IBM InfoCenter under "LoginTimeout".
If you extend the OOTB LogonCmdImpl, you should not try and set the forwarding URL, or that will interfere with the OOTB navigation.
I think you should perform your custom logoff functionality and then call super.performExecute() to allow the OOTB navigation logic to take over.
Note: You can retrieve the URL you were originally on via a call to getReferrerURL() and the ReLogonFormView should be returned from getURL().

Read timeout on a web service, but the operation still completes?

I have a Java web service client running on Linux (using Axis 1.4) that invokes a series of web services operations performed against a Windows server. There are times that some transactional operations fail with this Exception:
java.net.SocketTimeoutException: Read timed out
However, the operation on the server is completed (even having no useful response on the client). Is this a bug of either the web service server/client? Or is expected to happen on a TCP socket?

This is the expected behavior, rather than a bug. The operation behind the web service doesn't know anything about your read timing out so continues processing the operation.
You could increase the timeout of the connection - if you are manually manipulating the socket itself, the socket.connect() method can take a timeout (in milliseconds). A zero should avoid your side timing out - see the API docs.
If the operation is going to take a long time in each case, you may want to look at making this asynchronous - a first request submits the operations, then a second request to get back the results, possibly with some polling to see when the results are ready.
If you think the operation should be completing in this time, have you access to the server to see why it is taking so long?

I had similar issue. We have JAX-WS soap webservice running on Jboss EAP6 (or JBOSS 7). The default http socket timeout is set to 60 seconds unless otherwise overridden in server or by the client. To fix this issue I changed our java client to something like this. I had to use 3 different combinations of propeties here
This combination seems to work as standalone java client or webservice client running as part of other application on other web server.
//Set timeout on the client
String edxWsUrl ="http://www.example.com/service?wsdl";
URL WsURL = new URL(edxWsUrl);
EdxWebServiceImplService edxService = new EdxWebServiceImplService(WsURL);
EdxWebServiceImpl edxServicePort = edxService.getEdxWebServiceImplPort();
//Set timeout on the client
BindingProvider edxWebserviceBindingProvider = (BindingProvider)edxServicePort;
BindingProvider edxWebserviceBindingProvider = (BindingProvider)edxServicePort;
edxWebserviceBindingProvider.getRequestContext().put("com.sun.xml.internal.ws.request.timeout", connectionTimeoutInMilliSeconds);
edxWebserviceBindingProvider.getRequestContext().put("com.sun.xml.internal.ws.connect.timeout", connectionTimeoutInMilliSeconds);
edxWebserviceBindingProvider.getRequestContext().put("com.sun.xml.ws.request.timeout", connectionTimeoutInMilliSeconds);
edxWebserviceBindingProvider.getRequestContext().put("com.sun.xml.ws.connect.timeout", connectionTimeoutInMilliSeconds);
edxWebserviceBindingProvider.getRequestContext().put("javax.xml.ws.client.receiveTimeout", connectionTimeoutInMilliSeconds);
edxWebserviceBindingProvider.getRequestContext().put("javax.xml.ws.client.connectionTimeout", connectionTimeoutInMilliSeconds);

Session/cookie management in Apache JMeter

We have a simple performance test flow in an application.
We login
Search based on some criteria
repeat searches for different parameters.
We are using Jmeter to do a performance testing. We need to have multiple threads running to test this in a scalable manner.
The way we currently have this arranged is:
-Test Plan
- Thread Group
- Cookie Manager
- Login To application
- Search on param 1
- Search on param 2
- results summary table
- Summary report
So basically we have summary return table and report present on plan level while cookie manager is present on thread group level.
When I run for one thread it runs fine and completes well. When I scale it to multiple threads, as soon as the next thread kicks off, the session for the last thread is invalidated. This causes failures for all the already running threads due to newly spawned thread.
I reached this result with observation:
1. If I run multiple threads, only last thread has got valid responses in result summary tree
2. If I run with 2 threads with ramp up period as 10 seconds, which means each thread gets time to finish itself, then both of them run successfully.
As per my understanding each thread login's into application and since cookie manager is at thread level, the values will be maintained for session id for each thread respectively? But what is causing the override of the session id value between threads?
Any help will be much appreciated.

Copied from jmeter documentation:
The last element is a HTTP Cookie
Manager . A Cookie Manager should be
added to all web tests - otherwise
JMeter will ignore cookies. By adding
it at the Thread Group level, we
ensure that all HTTP requests will
share the same cookies.
From chapter "4.2.2 Logic Controllers" in http://jmeter.apache.org/usermanual/test_plan.html.
EDIT: I guess you should use http://jmeter.apache.org/usermanual/component_reference.html#Simple_Controller to group your requests together with Cookie Manager.

I think that Andrey's answer cannot help. He quotes that each request will use the same cookies BUT according to jmeter manual:
Each JMeter thread has its own "cookie storage area".
As far as I understand the question, you want each thread to share the same session ID cookie. So it seems to me you need to have two thread groups and execute them consecutively. First thread group (with a single thread that executes once only) should login and save the session cookie value to a global parameter (perhaps you need to use jmeter's scripting capabilities).
Then set that cookie in the cookie manager of the second thread group.
Hope that helps.

Try to increase the ramp up time. I ran into the same issue where the ramp up time was about 1 second then I increased it to 3 seconds per thread and it ran fine.

Try this:
Open the user.properties present in the bin folder of JMeter
Edit it and add the following line:
CookieManager.check.cookies=false
Save it and run the script. I hope it will solve your problem.

First change your code to:
jmeter.properties
CookieManager.save.cookies=true
CookieManager.name.prefix=mycookie_
Next, add a HTTP cookie manager in the same thread group as your java sampler.
Then in your java sampler add:
JMeterVariables jmv = JMeterContextService.getContext().getVariables();
Iterator<Map.Entry<String,Object>> it = jmv.getIterator();
while(it.hasNext()){
Map.Entry<String,Object> v = it.next();
System.out.println("name: " + v.getKey() + " value: " + v.getValue());
}