I am using below code in my spring webflow application running on weblogic server.
RequestContextHolder.getRequestContext()
.getExternalContext().getNativeRequest()).getSession()
I know that RequestContextHolder uses ThreadLocal to store the requestContext during start and resume steps.
Now coming to the question is there any remote possibility that one thread may access requestContext of other thread (may be because thread is being reused by weblogic or beacuse of some other reason) ?
Upgrading to SWF 2.3.0 solved the issue (data shared between threads)
The SWF version (2.2.1) had a bug. Its ExpressionParser was not thread-safe (JIRA).
Related
I have a Weblogic 10.3 server and an ear application deployed on it.
I want that one of the servlets (that this application uses) always will have free threads to perform requests. Can I set for this servlet a separate thread pool? Or can you advise me something else?
Thank you,
Alex
Figured it out by myself.
I needed to define a workmanager in weblogic.xml of my application and in web.xml I needed to apply the new workmanager to my servlet.
More about creating and using workmanagers in WebLogic:
http://docs.oracle.com/cd/E23943_01/web.1111/e13701/self_tuned.htm#CNFGD117
http://www.itbuzzpress.com/weblogic-tutorials/weblogic-pools-configuration/using-workmanagers-in-your-applications.html
I'm trying to execute subprocesses from within my application server (Glassfish 3.1.2)
Therefore I discovered the Apache Commons Exec library. The problem is that this library creates threads which should not be done on an application server because the server is not aware of these threads.
What could be a solution to this problem?
Would it be possible to create a message component written in Java SE who consumes messages containing information about pending jobs and register it with the application server?
The application server would then not have to deal with runtime exceptions and threads but just consume messages which contain the result or an exception.
Do you have any better ideas?
You could either use:
MDB (as pointed by duffymo),
Servlets 3.0 asynchronous processing,
Asynchronous EJB invocation.
Effectively, it should give you similar functionality as plain subprocesses.
Using Java SE component which communicates with Java EE just to overcome using threads on your own sounds a bit like an overkill. Just read about mentioned solutions and try if any of them fits your needs.
Message driven beans were designed for asynchronous processing. It could be a solution to your problem. You can create a separate listener thread pool sized to handle the traffic.
I am trying to determine the "approved" or best practices approach while in a Java EE environment for doing the following: A client is on a web page and clicks a button. This starts a thread for monitoring a process, i.e. database activity, network, etc. This process will continue to run until the user clicks a button that tells the process to end. Other clients, and/or the same client then clicks a button to listen to the status being sent from that process which will continue to listen until the user clicks a button to stop listening.
I have already done the above by using a WebSocket to communicate with a servlet which gets an injected a singleton EJB that extends WebSocketApplication. But, this EJB is spawning the process thread to do the monitoring. Although it works and should continue to work since it is a singleton, it is not the "approved" way of doing it.
Some suggestions I have reviewed discuss using JMS to spawn the thread, but, unless I am misunderstanding something, this doesn't solve anything since a Message Driven Bean isn't supposed to spawn a thread either. So, what is the approved/best practices method of doing this? How does one start and stop a background process in a Java EE environment? Again, the requirements are, only one process can be spawned, it must communicate to all WebSockets that register with the servlet, it must be able to die when told to (although that doesn't mean the server closes the sockets, since it could be started back up and would still communicate to all the previously registered clients).
Thanks.
this EJB is spawning the process thread
EJBs are not permitted to start threads. Quoth the standard:
The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt
to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enter-
prise bean must not attempt to manage thread groups.
These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads
would decrease the container’s ability to properly manage the runtime environment.
This is by design; the specification states the following
The Enterprise JavaBeans architecture will make it easy to write applications: application
developers will not have to understand low-level transaction and state management details,
multi-threading, connection pooling, or other complex low-level APIs.
Have you considered using a stateful session bean? Clicking on the button causes the bean to enter the "started" state. Click on the second button causes the bean to enter the "stopped" state.
To create threads in an enterprise environment, you should use either ManagedThreadFactory or ManagedExecutorService.
Please see here
The answer is an asynchronous EJB 3.1 bean. Thanks for the reply.
As of Java EE 7 you can use the ManagedExecutorService to give your EJBs access to a managed thread pool.
i have a webapp written with spring 3 and struts 2 that is hosted on a glassfish server. In this app i have two webservices that need to do some background work without delaying the accessed method response.
So, now i use a spring bean that uses an instance of org.springframework.core.task.TaskExecutor and from there i run my new thread.
Is this the correct/best practice approach in context of using this app on glassfish? or should find another method of doing this ?
It's discouraged to create your own threads because the app server is meant to be in charge. See the answers to Why is spawning threads in Java EE container discouraged?
However in practice, especially if it's the only application on there, you might be OK, especially if you use a fixed thread pool. Be sure all the threads are gone when you undeploy the app. (I expect Spring classes will handle disposal on undeploy / shutdown correctly, if you declare them within the Spring container).
I have a traditional 3-tier application with spring. One of my repositories needs > 3 minutes for initialization so I thought about some multi-threaded approach in order to speed up the whole process - I think most service and controllers in my dependency tree can already be started so only a few must wait for the last repository to come up.
Is there any best practice approach?
Use Spring's Executor abstraction. And if you are within a app server then I suggest you use application server's work-manager (spring supports it). For e.g. WebSphere app server and Weblogic both support registering the workmanagers in JNDI. You can then pass the jndi name to spring. Task Executors