In order to control the amount of threads on the jetty main embedded server I load a EmbeddedServletContainerCustomizer using the #Component annotation. Im using a different port for the management context and so it seems that a different jetty instance is executed for that port. How can I do the same process for that port or Jetty instance?
Regards
Bruno
Just found out how to solve my issue.
Using the application properties
server.jetty.acceptors
server.jetty.selectors
I can control the amount of threads on both ports. It is not very customisable but it gets the job done. For the main service port, configuring with a EmbeddedServletContainerCustomizer will override these configurations.
Regards
Related
I wanted to run my Grails application (version 4.0.4) in a cluster. I tried to apply Hazelcast to replicate the HTTP session across the nodes/instances but somehow I couldn’t override/replace the SessionRepository bean that Grails uses with the Hazelcast implementation.
My working configuration in Spring Boot is: I declare the Hazelcast bean and annotate the Application with #EnableHazelcastHttpSession which in turn introduces the new SessionRepository from Hazelcast.
But I couldn’t make this configuration work in Grails and override the SessionRepository. (Although the app starts, it acts very strange.)
Any ideas?
Or do you suggest an alternative approach to implement a distributed session in Grails? How did you replicate session from your past experience?
(P.S The reason I chose Hazelcast is, since it is a distributed cache which can be embedded with the application itself, I can avoid dependency on external service such as Redis, to run the app. That is part of the requirement).
Thank you.
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.
Need to call a EJB service from the servlet context listener's contextInitialized() method. Application is running on JBOSS, though the context listener works fine, I'm not able to access the EJB bean through JNDI look up.
Because the web deployment in JBOSS happens before EJB beans are bound with JNDI tree. How to overcome from this? Is there a way to configure JNDI bind early or start the web deployment later once EJB's are completely deployed?
I had put Thread.sleep() before the service call in the contextInitialized() method, it is working fine in my JBoss5.1.0 GA, and the same did not work in other machines JBoss of same version.
Applications needs this because, we want to load some master data from the DB and make it available in the web layer (kind of caching). Does JBOSS startupmbean suit this requirement? If yes how can I make the data available to web layer?
Also if any alternative ways are available, please suggest.
Poll for the EJBs in contextInitialized(). So instead of just sleeping for a certain time, try to connect to the EJB. If that fails, sleep, and retry, until the EJBs are available. In this case the context initialization is blocked.
Implement the cache as a lazy one: Fill the cache during the first query (and use the same polling procedure: connect to the EJB, retry until it becomes available). In this case the cache blocks.
You could split your deployment into two parts: One for the EJBs, one for the web application. Then deploy the first, and delay deployment of the web application until the EJBs are bound (either by watching the log file or by trying bind to the EJB from a command line app)
i saw some code use ShutdownHook like this
Runtime.getRuntime().addShutdownHook(new Thread(){
ConfigurableApplicationContext.stop();
//close spring context;
threadpool.shutdownnow();
//close theadpool
});
is there anything useful to do like this?
i thought
when jvm exit ,maybe thread will be shutdown immediately
and spring context will close too；
what shall we do next when we need to call System.exit() ?
It really depends on your application and the lifecycle of your objects and those threads you appear to have outside of your context. If you are running the spring container inside a standalone java process, then trapping the shutdown hook like this is one way to do that. Another way is to have it listen on a tcp port and send a command to begin the shutdown process. If you are running in a web container like tomcat, then you should follow the standards on normal webapp shutdown, which Spring supports with Context Listeners.
I would also consider redesigning your app so that the threads are all managed with a bean that lives inside your spring container. For instance using a bean that is configured with directives (attributes) for start/stop methods and then that bean would use an Executor for thread pooling. This way, your shutdown is ONLY shutting down the Spring container, and Spring provides very good support for orderly shutdown of beans. One of those beans is your object holding the threads within the Executor. Its a much cleaner way than trying to integrate Spring beans with external threads.
Hope this helps.
We have a spring application that publishes and listens to queues on a remote application server. My publisher and listener which are spring based listen within our own application server.
One of the problems we have for our test environments is the other app. server is not up so when our test application goes to start and it tries to inject JmsTemplate with its connectionFactory it blows up because it is not a valid connection and our entire application fails to load. This is causing grief with the other developers in our group that have nothing to do with JMS. All they want to do is run and test their code but the JmsTemplate connectionFactory is down.
Does anyone have any suggestion for enabling spring ignore some bad injections which will allow our application to start properly?
Thanks
I believe this could be achieved by defining separate spring profiles and then passing it as a parameter in your test environments while starting your application. You could mock or ignore any beans then.
Example
import org.springframework.context.annotation.Profile;
#Profile("test")
public class AppConfigTest {
....
....
}
JVM param / System property
-Dspring.profiles.active=test