WebSphere Extended Deployment, Version 6.0.x
             Operating Systems: AIX, HP-UX, Linux, Solaris, Windows, z/OS


Troubleshooting business grid

You might encounter business grid behavior that is unexpected. This topic describes some common things to look for when business grid is not working as expected.

Common configuration issues

Failed to set up the WebSphere variables for the JDBC paths of the database used.

Having the same but incomplete WebSphere Application Server variables defined at the node level, causing the variables at the cell level to be overridden.

If the xJCL for a job specifies an incorrect application name, the long-running scheduler logs an IllegalStateException. The exception is harmless and the long-running scheduler continues to function correctly. The job state immediately changes to execution failed.

The processJobStep() or destroyJobStep() might go to a different enterprise bean instance

The processJobStep() or destroyJobStep() might go to an enterprise bean instance other than the instance under which the batch job step was originally dispatched, when setProperties() or createJobStep() was invoked. As a result, the processJobStep() or destroyJobStep() might run on a thread other than the thread under which it was previously dispatched. The reason is that an incorrect bean caching load policy was specified.

To correct this problem, modify the ibm-ejb-jar-ext.xmi file of the enterprise bean's module deployment descriptor to specify the activateAt and LoadAt variables. The step enterprise beans must have a caching policy of activating once and loading at activation, which is found in the ibm-ejb-jar-ext.xmi file of the enterprise beans module. The following is an example of a modified ibm-ejb-jar-ext.xmi file:

<enterpriseBean xmi:type="ejb:ContainerManagedEntity" href="META INF/ejb.jar.xml#PostingAccountData"/> 
<beanCache xmi:id="BeanCache_1131923814135" activateAt="ONCE" loadAt="ACTIVATION">

Changing this file ensures that in a given enterprise bean container, there will be at most one instance of a step enterprise bean with a given job ID in the cache, which ensures that every call that the long-running execution environment makes to processJobStep() for a given step will go to the same instance of the step enterprise bean. This is essential because global variables in the step enterprise bean (such as BDS references) are referenced across multiple processJobStep() calls.

administrative console freezes or gets an OutOfMemoryError when running a large number of jobs.

You can enlarge the scheduler server JVM memory by adding a generic JVM argument named -Xmx512m. To do this, go to the administrative console and follow these steps:
  1. Select Servers > Application servers > long-running scheduler server > Configuration > Server Infrastructure > Java and Process Management > Process Definition > Additional Properties > Java Virtual Machine.
  2. Type -Xmx512m in the Generic JVM arguments field.
  3. Restart the long-running scheduler server.
  4. Retry the administrative console.



Related information
Developing business grid applications
Reference topic    

Terms of Use | Feedback

Last updated: Oct 16, 2009 11:08:29 AM EDT
http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/scheduler/rbgtrouble.html