I have an EAR I deploy on JBoss. This EAR contains two main components, a set of EJBs, and a servlet. It also contains several other libraries.
In the current state of the code, there is a need to initialize some singletons so that the EJB can actually work. This init is made in the servlet, to start all data caches and initialize them. My problem is that because of this separate initialization, which can last up to 30 seconds, there is a moment during which the EJB are deployed and available, but calling them would lead to errors.
So the question is: is there a way to lock the EJB calls for the time of this initialization by the other component? Ideally, it would just queue them and execute them once the init finished, but it could also refuse them.
The only way I can think of for now would be to have a static boolean in the initializer, which would be checked in the EJB calls (their interceptor, actually). But this is far from convenient. So I'm wondering if there is another way to do it, less dirty.
Related
I don't see any difference in my code if I shut it down or not. Is it a mere practice to shut it down or am I missing something.
What is 'a mere practice'?
The javadoc of PersistService.stop() states that the method:
Stops the underlying persistence engine. For instance, with JPA, it closes the EntityManagerFactory.
Which means you absolutely should call it, as EntityManagerFactory should definitely be notified to relinquish any resources it may be holding (DB connection pool and the like).
I have a rest endpoint which would start the scheduler of loading a XML to memory. Whenever I hit that rest endpoint, it loads the XML in memory and would return the XML after its ready (would take 10 - 15 seconds). When the same endpoint is accessed again, it would return the cached XML. Everything works fine but for now I have to manually hit the endpoint for the scheduler to start. Is there a way to hit the endpoint automatically via a simple code in startup? Or is there any other solution for this?
Normally, a component in the Nucleus is instantiated at first access, not at system start-up.
The way to have anything done at start-up in ATG is to create your component, and then to add its nucleus path to the list of initial services in the /Initial component (or from one of the many other Initial components changed off of it)
The component should be globally scoped. Because /Initial is instantiated at start-up, the services it references will also be instantiated as dependencies.
If your component is a POJO, then the no argument constructor will be invoked on component start-up, then the setX method will be called for each property with a value defined in its properties file.
If your component is extended from Generic Service, then additionally, beforeSet and afterSet methods will be called, before and after the set methods are invoked, if they exist, and finally doStartUp will be called.
This is all part of the fundamental lifecycle of components that the Nucleus manages.
This gives you a number of hooks with which to invoke your custom code.
Now, in your question, you ask how to call a REST endpoint at start-up. However, I believe what you actually want to ask is how to ensure that a particular piece of code gets executed at system start-up. A REST endpoint is how you are triggering it today, manually, from outside the Nucleus. But that does not mean that it must call a REST end point if it is to be automatically called at start up.
The easiest way to achieve what you want is
define a class that extends GenericService
override the doStartUp method
put the code you want to execute in this method, or invoke the code on another component from here
define a globally scoped component for the class
Add the component to the initialServices property of the Initial component
Restart the server and check that your code is being called at start-up. Put some debug statements in, and switch debug logging on in your layer.
Note, you may actually also want to think about whether you really need to invoke your code at system start-up. Anything in initial services adds to the start time of the server. Depending on your requirements, it may be better to do it on first access of your application service rather than at server start-up.
When you override onStart in Global, would it block the thread running the bootstrap process?
In other words I want to make sure that Play does not start until call returns from onStart.
If this is not the case, what are good solution to do critical init process which need to happen before Play start accepting requests?
Yes, Global.onStart will block before the first request.
The GlobalSettings object in Play is a plugin. When the application is started, the routes are loaded first, then the plugins are loaded serially by calling the onStart method of each. The GlobalSettings plugin comes last in this initialization, which ensures that all other plugins are loaded first so that all of your db connections, cache, etc are available there.
The plugin initialization has to block a single thread to guarantee that:
All plugins are initialized in the exact order that is desired to prevent initialization order errors (if one plugin depends on another initializing first--for example the database plugin must always initialize before the evolutions plugin).
All plugins are initialized before the application can start processing requests. (Otherwise, you wouldn't be able to guarantee the the DB plugin was ready on the first request, for example).
I made an app that I'm deploying as EAR on WAS 8.5. This app works as an app that constantly checks on a DataQueue and transfer whatever message it finds to an MQ. Since I've been testing it, I realized that if I start it, it remains starting the application indefinitely (since it's an endless loop that checks on the queue). Even without the loop, the read() function of the dataqueue reads indefinitely until it finds a message, what also makes the starting of the app to don't end.
Reflecting on it, I realize that an EAR (with WARs, JARs, etc) it's an app that expects a request (if not all, most of the time). So if it's an endless loop, it won't end the starting of the EAR.
Maybe there's another way to deploy this application on WAS. Is there a way to deploy the app so it will be like a background process that does everything I previously mentioned?
There are 2 solutions to this:
Use MDBs and ensure that you receive the message is a message listener thread. This will ensure that threading is completely taken care by WAS.
Here is an article about using threads in WAS: http://wpcertification.blogspot.in/2010/09/developing-multi-threaded-application.html .
I have a managed bean / service running inside of JBOSS. I then have a quartz job that will occasionally wake up and call a method of the managed bean. This method is sometimes long and drawn out, and since I don't want the quartz job to time out, I have implemented a thread within the managed bean to perform the processing. When the thread is finished I need to update a database table with the results. This is a very serial process and it needs to be based upon some business rules, etc.
My main question is that I can use an EntityManager within the service without a problem however I can not use it from within the thread, I get a NullPointerException. What would be the best way to address this?
Thanks,
Scott
As creating threads in appservers is discouraged, I'd modify the setup a bit.
I'd move the core of processing to a message driven bean, and have the Quartz job just send a message to the queue on which the MDB is listening. The MDB in turn can call your EJB, and like this everything remains within what's allowed by the standard.
As per the documentation and specification the Entity Manager is not thread safe and can not be used across different child threads as I had originally had in mind. I ended up going back to the original design similar to the one provided by fvu, however I found some annotations that would allow me to modify the been timeout period and allow the long running process to work properly. Here's the annotation that I used:
#PoolClass(value=org.jboss.ejb3.StrictMaxPool.class, timeout=360000000L)