Performance Issues In Soa Suite 11g (ps5+)

Do you release that after PS5 in case of working threads are full and scheduled threads are increasing then there will be locks on java threads. This will lead to a decrease in performance. To avoid that; be sure to put some limit on your work sources (such as putting minimumDelayBetweenMessages on dequeue mediators). So we can say that it is crucial to monitor your "invoke" and "worker" threads all time but it's not flexible to monitor it from EM console. Using the code parts below you can write your small java code to monitor all threads in all your servers.

1) Connect to admin server

JMXConnector m_connector;

MBeanServerConnection m_connection;

JMXServiceURL serviceURL = new JMXServiceURL("t3","192.168.1.1",7000,"/jndi/weblogic.management.mbeanservers.domainruntime");

System.out.println("Connecting to: " + serviceURL);

Hashtable h = new Hashtable();

h.put("java.naming.security.principal", "wladmin");

h.put("java.naming.security.credentials", "Welcome1");

h.put("jmx.remote.protocol.provider.pkgs", "weblogic.management.remote");

m_connector = JMXConnectorFactory.newJMXConnector(serviceURL, h);

m_connector.connect();

m_connection = m_connector.getMBeanServerConnection();

2) Read Dispatcher Trace

String result=(String)m_connection.invoke("oracle.as.soainfra.bpm:Location=SERVER_NAME,name=CubeDispatcher,type=bpel", "readXMLDispatcherTrace",null,null);

3) Query the results

DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

DocumentBuilder builder = factory.newDocumentBuilder();

Document doc ;

XPathFactory xPathfactory = XPathFactory.newInstance();

XPath xpath = xPathfactory.newXPath();

XPathExpression expr;

String invokeScheduled="//dispatcher-trace/invokeSet/invokeQueue/scheduled/@count";

String invokeWorking="//dispatcher-trace/invokeSet/invokeQueue/working/@count";

String engineScheduled="//dispatcher-trace/engineSet/instanceQueue/scheduled/@count";   

String engineWorking="//dispatcher-trace/engineSet/instanceQueue/working/@count";   

int is=0;   

int iw=0;   

int es=0;

int ew=0;   

inStream.setCharacterStream(new StringReader(result));  

is=Integer.parseInt(xpath.evaluate(invokeScheduled,inStream)); 

System.out.println("Invoke Scheduled: "+is);   

  

inStream.setCharacterStream(new StringReader(result));  

iw=Integer.parseInt(xpath.evaluate(invokeWorking,inStream));   

System.out.println("Invoke Working: "+iw); 

  

inStream.setCharacterStream(new StringReader(result));  

es=Integer.parseInt(xpath.evaluate(engineScheduled,inStream)); 

System.out.println("Engine Scheduled: "+es);   

  

inStream.setCharacterStream(new StringReader(result));  

ew=Integer.parseInt(xpath.evaluate(engineWorking,inStream));   

System.out.println("Engine Working: "+ew);  

4) Make a loop mechanism in order to query all your servers.

Things You Should Know About "Endpoint Address" In Soa Suite 11G

In Soa Suite 11g, you can update an endpoint address of a reference point using EM. To do that first get into composite dashboard and click on the reference point. In the properties tab you can change the "Endpoint Address" attribute. After you click apply, new invokes will go to new endpoint. (even you did this procedure in one managed server it will propagate to all servers in your cluster)
I need to say two important thing here first you should keep in mind that this should be a temporary change because when you deploy a new revision of this composite you should repeat the update each time again. Second; if an instance receives a fault from a reference with a modified end point then it will automatically try the original address just after the first invoke (only you can see it in diagnostic logs, not in audit trail).

Running BPEL 10.1.2.0.2 with Java 1.5+

Hi Everybody,

If you are running on Oracle Bpel 10.1.2.0.2 and stuck with java version 1.4 then I have a great news for you!

Previously you may already tried to run bpel with newer versions of java by adding "java-bin" element to opmn.xml;

opmn.xml

<data id="java-bin" value="/home/oracle/java15/bin/java"/>

You were excited and wondering about how bpel will perform with new java version.. oppps! after starting the container you will see this error message;

JDK version not supported.
The JDK version "1_5" is not supported by the OraBPEL domain runtime. Currently only JDK version 1.4 is supported.

13/08/04 16:50:47       at com.collaxa.cube.admin.adaptors.ServerAdaptorFactory.createJDKAdaptor(ServerAdaptorFactory.java:63)
13/08/04 16:50:47       at com.collaxa.cube.admin.adaptors.ServerAdaptorManager.init(ServerAdaptorManager.java:53)
13/08/04 16:50:47       at com.collaxa.cube.admin.ServerManager.__init(ServerManager.java:213)
13/08/04 16:50:47       at com.collaxa.cube.admin.ServerManager.init(ServerManager.java:101)
13/08/04 16:50:47       at com.collaxa.cube.ejb.impl.ServerBean.init(ServerBean.java:200)......


I decompiled the ServerAdaptorFactory class. Then I saw that if I put a java option then I may deceive the bpel .. Yes! it worked :)

1) Put this option to "start-parameters" in opmn.xml and leave the "java-bin" attribute with new version of java.

-Djava.specification.version=1.4


This will make your container to start up with java 1.5+ without any trouble and run your bpel instances successfully but you will not able to deploy new processes (try, you'll get errors). To overcome this new problem you should do one more little thing;

2) Link your new java 1.5+ tools.jar file to $ORACLE_HOME/jdk/lib/tools.jar.. 

Now you can run bpel 10.1.2.0.2 with java 1.5+

We are running bpel 10.1.2.0.2 on sun jdk 1.7.0_25 64bit (with 5GB heap and G1GC) without any problem. Now garbage collection takes tens of milliseconds to complete and we don't experience memory leak anymore (previously we had to restart servers once a week because heap was getting full and garbage collector was taking too much time and still could not empty old generation). With java 1.7, cpu performance is also a big achievement; we are able to process much more instances even with using less cpu resource.