I'm looking at my Vaadin app running on a local tomcat server with JProfiler. This shows that every time I start up the server and run my application, there are 3 instances of my main Application class. If I close the application in the browser or even close the browser completely, there are 2 left. I've noticed that the Application's init() method gets called 3 times during startup, even though I never explicitly call it myself. I am using the Threadlocal pattern (but with InheritableThreadlocal).
It doesn't look normal to me, is there anything that can cause this kind of behaviour?
(Copied this question from my post on the vaadin forums)
From your description, I gather that Application is a class written by you (and not something supplied by Vaadin) and that you somehow save the instances of this class in a ThreadLocal.
This would explain the behavior that you're seeing: Tomcat will start several threads to handle client requests. For each thread, a new Application instance will be saved in the ThreadLocal.
Try the (evil) Singleton pattern or (better) dependency injection with the singleton scope instead.
If you use the singleton pattern, make sure you use the code under "Construct in multi-threaded applications" or you will get odd errors in Tomcat. This article on JavaWorld explains it in depth: Simply Singleton
EDIT Based on your feedback: The behavior your see is expected and correct. Tomcat uses threads to handle requests and it will pre-spawn a couple to be ready for business (in your case, it spawns three).
Related
Maybe this is a very basic Java question. Forgive me if it is.
I have this Spring Boot project that needs to, for every registered user, automatically (in the background) connect periodically to a website and download many documents and/or check for changes.
The "download/check" system was externally developed. Every method was static.
Am I right thinking that it IS a problem when I want to have more than one simultaneous execution?
Even if it has all specific connection parameters through parameters?
Thinking of that, I removed the static annotation on almost every method. Now I need to create a new instance for every execution.
When I began adding it to my Spring boot project, I realized there are a bunch of services that make simultaneous connections to a web service, and there I didn't even care about concurrency.
AFAIK, each service is a singleton. Right? So there is no new instance for every connection. Right?
My question is: If I happen to have 100's of users... How should I integrate the jsoup code?
Should I create a new instance from a service?
Should I convert it to a Service itself and just #Autowire it to the service where the process is triggered?
Is it better to make it static? (this one I don't think so, but maybe I'm wrong)
Any other option?
If possible, please add a reason why I should follow your suggestion.
Thank you all for your help.
First of all I'd say if your classes are not maintaining any state then it is actually a good thing if everything is static cause this gets you rather close to functional programming. If you are then passing everything as an parameter to a method and don't have any state in the class (not the method) then everything is kept on the stack which is not shared amongst threads. Long story short: thread-safe.
If you maintain any type of state in your classes – be it services or components – then you have to make sure that they are executing in a thread safe way. One of the easiest ways is to change the #Scope of that particular bean to prototype or for instance request as you are running this as a web app.
I have tried to look online, and found only few places that says spring is actually multi-threaded. Even those, seems to hint it simply uses a multi-threaded servlet container (as far as I understood, the single-threaded servlet containers are mostly deprecated, hence they all are multi-threaded these days).
I was hoping someone could clarify and validate that information; is the multi threading truly comes from servlet container and not spring?
And the more important question is, how do I initialize a per-thread data? As part of my database connection managing, I am using a library which requires me to initialize data in each thread.
Currently, I am checking a value on every call to that library, to know to initialize it.
But I prefer to simply initialize it every time a thread starts.
I believe it should be possible; After all, someone is creating those threads that keep calling my spring controllers.
p.s.
I am using the default servlet container in spring, which is Tomcat. I also tried doing a quick search for per-thread initialization and multi-threading in tomcat, but couldn't find any clear information on when a new thread actually spawn, or some information about a thread pool being used. I could be wrong though, and the multi threading is
I do have a service "A" this service will be consumed from 11 other components. If I check all available services via the osgi console I do see only one instance and all 11 components consuming this service.
But for some strange reason, I don't understand, two of the components don't use the same service instance. If I debug I see two different IDs. How can this happen?
And I am not doing anything mentioned here.
I solved the problem by setting "This component is immediately activated" within eclipse. But as I red here, this is not the purpose of this checkbox. So maybe someone can explain how this happened in the first place and why it was fixed with this enabled.
When you use Declarative Services, the DS runtime may under certain circumstances re-instantiate your service, usually because some services it depends on have appeared/changed/got removed and the references are static. Check to see that all sites where service A is used are either static, or dynamic with both bind/unbind methods.
My team is using the "cmt-timeout-in-seconds" setting, in the "sun-ejb-jar.xml" file on a GlassFish 2.x server, to control the transaction timeout threshold for an EJB module.
I realize that this is a pretty broad question... but we're having issues (I'm not sure of all the details myself), and I've been asked to verify that the "cmt-timeout-in-seconds" actually is being used.
Does anyone know of a way to interrogate or determine this from the application server, short of writing new custom code to test it? I'm not even certain what kind of custom code I would write if I had to go down that path.
It seems that the most straightforward answer is simply to write a small test case. I just created a simple EJB, with a custom CMT timeout setting in "sun-ejb-jar.xml".
I then wrote a method on this EJB class, annotated to require its own new transaction. This method did three things: (1) write a log message, (2) use Thread.sleep() to pause execution for awhile, and (3) write a second log message.
By using sleep values that were greater than or less than the CMT timeout setting, I was able to confirm that the settings were being applied.
However, one interesting note that I learned from this... when a container-managed transaction times-out for an EJB3 method, it does not interrupt or halt the execution of that method! The method continues to execute (or stays hung), and the consequences of the timeout are not handled and logged until after the method returns. Interesting behavior, which can lead to some serious bugs if you're not aware of it. See this article for more detail.
We have a need to run a housekeeping thread in an EJB3.0 container. We currently have a "TimerService" #Stateless EJB (necessary because it has has other #EJBs injected), which creates an interval EJB Timer when it's startTimer() method is called. There should only be one instance of this timer thread. The current solution involves calling startTimer() from the init() method of one of our servlets, where the servlet is forced to load at startup using in the web.xml, but that feels like coincidental behaviour instead of the right way to do things. We've already had a problem because someone else subclassed that servlet, which meant that init() was called twice, which meant two timer threads.
This feels like it's not an unusual requirement, so what's the proper way to do this, if anything? It seems to me like there ought to be a simple way to ask the container to start a thread when it starts up, without having to tie it to other resources in the container.
For EJB < 3.1 you are going to have to get application server specific or hackish. Since you mention you are using JBoss, you can use the #Management tag which has defined lifecycle methods.
I want to suggest 2 solutions.
1 The fix to your implementation.
make your servlet final. this will avoid subclassing. But the servlet still may be deployed twice. To avoid this create static boolean variable into the servlet. The init should check this variable. If it is false it turns it to true and continues. Otherwise it throws exception.
This is fast fix that you can do now.
but it is not a "right" solution. For example this will not work in clustered environment.
2 There are 2 "right" solutions.
2.1. use quartz
2.2. Implement timer using JCA. Connector is the only place in J2EE where you can legally use threads and timers.
I mentioned JCA in other context in this article:
http://alexradzin.blogspot.com/2010/10/send-delayed-jms-messages.html
You are welcome to view it and see a short code sample that can probably help you.
Does your app server support "startup beans"? I ask because in WebSphere Application Server, there is an option in the administrative console to set the server to fire "startup beans" on server start up. We use it for certain applications we have that require a lot of "heavy loading" and initializing, so that way we can minimize start up time for the end-user experience.
Here is a link to WAS 6 documention (old, I know, but still helpful). Startup beans
I know this is specific to IBM WebSphere, but perhaps your app server (if not WebSphere) has something similar to help you kick them off?