I have few questions regarding ejb pool size in websphere.
It is mentioned in the documentation here http://www.ibm.com/support/knowledgecenter/SS7JFU_7.0.0/com.ibm.websphere.express.doc/info/exp/ae/rejb_ecnt.html that the default ejb pool size is 50 - 500.
My question is, is it for all the ejbs together or is it per ejb? What i understood is, it is per ejb. Am I right?
Is there any tool to monitor the ejb pool size in websphere?
A1. You are correct, a pool exists per EJB and the default for each pool will be minimum 50 / maximum 500. The link you provided does show how to use the com.ibm.websphere.ejbcontainer.poolSize property to change the pool size for individual EJBs or change the default that applies to all types. In all cases, there is a pool per EJB.
A2. The EJB pool size may be monitored using the Tivoli Performance Viewer. The EJB counters available are documented here:
https://www.ibm.com/support/knowledgecenter/SSAW57_7.0.0/com.ibm.websphere.nd.doc/info/ae/ae/rprf_datacounter1.html
And the specific ones relevant to the EJB pool are : RetrieveFromPoolCount, RetrieveFromPoolSuccessCount, ReturnsToPoolCount, ReturnsDiscardCount, DrainsFromPoolCount, DrainSize, PooledCount
Related
I recently read an article regarding Tomcat architecture and a high level overview of its working and monitoring.
Key metrics for monitoring Tomcat - DataDog
In this article, it mentions Tomcat having a pool of worker threads per connector that can be configured.
It also mentions about Executors and how it is mainly a thread pool that is shared with multiple connectors.
I have some doubts regarding Spring Boot and its Embedded Tomcat Server
How many Connectors are configured by default for this embedded Tomcat Server?
Does the embedded Tomcat have an Executor configured? Or is it just the basic pool of worker threads.
I can see that we can configure the accept count using application.properties by using the following property
server.tomcat.accept-count
I believe acceptCount sets the max number of connections that can be queued up in the OS level queue when no worker thread is available. ( As per the mentioned article )
Does this mean that there is no Executor configured for the default Connector? If there is, how do we configure the queue size of that executor?
I would be grateful if someone could shed some light on the above.
In short, I just wanted to know if the server configuration via application.propeties is for an Executor or for the Connector specific pool of worker threads.
I am migrating application from WebSphere to liberty.
It uses WebSphere timer managers.
What is the use of timer manager?
Is this supported in liberty. Is it the same as timer service in liberty?
Liberty does not have TimerManager, but it has similarly capability for scheduling tasks via the EE Concurrency spec-defined javax.enterprise.concurrent.ManagedScheduledExecutorService, which is provided by the Liberty concurrent-1.0 feature. A knowledge center page includes some examples and describes how to configure. Another knowledge center page provides helpful information on migrating to EE Concurrency from CommonJ or AsyncBeans.
To answer you question about the difference between timer manager and timer service, timer service typically refers to the EJB Timer Service, which has a mechanism to schedule persistent and non-persistent timers. EJB non-persistent timers are another alternative in Liberty to the CommonJ TimerManager, if you happen to be using EJBs. Otherwise, ManagedScheduledExecutorService can be used regardless of whether or not you use EJBs. Both provide mechanisms for scheduling timers/tasks for execution in the future, where the timers/tasks do not persist across server start and do not have the ability to be rolled back and retried (those are additional value that is provided by EJB persistent timers).
SpringBoot already is managing dataConnection then why is Hikari CP needed?
I have just started using SpringBoot so do not know much about SpringBoot and Hikari relation, although i read about Hikari but couldn't find any explicit explanation about its relationship with Springboot in presence of Spring data connection.
I read that Hikari is used when we need heavy db operations with lots of connections, if it is true then should we not use Hikari in follwoing scenario?
Scenario:
There is a small application, having maximum 8-10 REST calls once in a month or maximum fortnightly.That application needs to perform some probability and statistics related calculation.
Users login on that app at a time are of maximum 2-3 in numbers.
Do we still need to use Hikari?
There are two ways to communicate with the database from your application. You can either open a new DB connection any time you wish execute some query there, or you have a connection pool. Connection pool is a collection of reusable connections that application uses for DB communication. As establishing a new connection is relatively expensive operation, using connection pool gives you a significant performance improvement.
HikariCP is one of the connection pools libraries available in java and SpringBoot uses it as a default. As you don't need to do anything special to have it in your application, just enjoy your free lunch :)
HikariCP is used as the default connection pool in SpringBoot2, it was TomcatJDBC in SpringBoot 1. You must be using it as a default in your settings. You can overwrite it by setting another connection pool in your setting properties if you need. Please find more details about the connection pools and the default configurations of Spring Boot versions here.
Hikari is the default DataSource implementation with Spring Boot 2. This means we need not add explicit dependency in the pom.xml. The spring-boot-starter-JDBC and spring-boot-starter-data-JPA resolve it by default. To sum up, you require no other steps with Spring Boot 2.
Compared to other implementations, it promises to be lightweight and better performing.
Tuning Hikari Configuration Parameters:
spring.datasource.hikari.connection-timeout = 20000 #maximum number
of milliseconds that a client will wait for a connection
spring.datasource.hikari.minimum-idle= 10 #minimum number of idle
connections maintained by HikariCP in a connection pool
spring.datasource.hikari.maximum-pool-size= 10 #maximum pool size
spring.datasource.hikari.idle-timeout=10000 #maximum idle time for
connection
spring.datasource.hikari.max-lifetime= 1000 # maximum lifetime in
milliseconds of a connection in the pool after it is closed.
spring.datasource.hikari.auto-commit =true #default auto-commit
behavior.
HikariCP is a reliable, high-performance JDBC connection pool. It is much faster, lightweight, and has better performance as compared to other connection pool APIs. Because of all these compelling reasons, HikariCP is now the default pool implementation in Spring Boot 2. In this article, we will have a closer look to configure Hikari with Spring Boot.
This is probably a rather peculiar question. I am using Spring Boot 2.0.2 with the default Tomcat container. In order to set up a test in our QA environment that simulates many servers, I would like to set up a Spring Boot-based REST service that listens on a very large number of ports simultaneously. I'm able to do this using the technique previously described in in another SO post (Configure Spring Boot with two ports) which basically adds connectors using TomcatServletWebServerFactory.addAdditionalTomcatConnectors().
The difficulty is that a large number of threads seem to be created for each additional port activated; some empirical measurements show the total to be 17 + (15 * number of ports). This means listening on 250 ports result in 3767 threads created and 500 ports result in 7517 threads created and I would like to go somewhat beyond that number. The test program used to take the above measurements is the bare minimum to bring up a Spring service and there is no code that creates threads explicitly so insofar, as I know, all of those threads were created by Spring/Tomcat.
Is there a way to accomplish this using Spring that doesn't use so many threads per active port? Would an alternate container like Jetty be more efficient?
You can configure the embedded tomcat container properties in spring boot configuration file and set the appropriate numbers for these properties to limit the threads created by Tomcat container -
server.tomcat.max-threads=200 # Maximum amount of worker threads.
server.tomcat.min-spare-threads=10 # Minimum amount of worker threads.
I'm looking for a way to configure the SLSB Pool size in Websphere. Is it possible to configure it from the Admin Console ?
Looking at the IBM Red Books it's mentioned how to configure the ORB Pool which is however used by remote EJB clients. My Requests are arriving from the same JVM by servlets
Thanks
Max
There is a system property called com.ibm.websphere.ejbcontainer.poolSize that can be used to tune bean pool sizes.