It is pretty old concept and I tried earlier couple of times but this time I had much more time to do through analysis of Oracle Application Server with multi
JVM container and see how it works out with
SOA and
AIA in general.
Configuration of multi
JVM is fairly straight forward. All you need to do is change number of
JVM for container from EM or change
numprocs from
opmn.
xml for a particular container. You can get more information from
http://mike-lehmann.blogspot.com/2006/09/scaling-oracleas-with-multiple-jvms.html(Note: Although you can not change number of
JVM for the container where EM is running, so if you install basic
SOA suite, adding
JVM would cause problem with EM.)
So we added 2
JVM to
OC4J_
SOA container and tried couple of test cases:
1) Test case: Make sure load is distributed evenlyI believe it is due to mod_
oc4j
config or default option, but load was distributed in exactly round robin fashion as per log file.
2) Functionality testingWell, I was not involved much into functional stuff, but seems like functional stuff worked like a charm. We didn't see any issue with
BPEL or
ESB communication.
At this point we were pretty satisfied with results and about to move forward and then we thought of checking couple of configuration and deployment stuff for
AIA and things started looking pretty disappointing:
3) AIA Configuration changeTest case: Changing
AIA configuration file and using
AIA console to reload the configuration. Expected output would be to have new configuration in both
JVM.
Result: Only one
JVM loads the
AIA Configuration. I tried loading multiple times using
UI, it still loads only on one
JVM. May be http connection had some static stuff with
OC4J. Removing caching or trying from different machine might fix this issue but I would still consider it as failure scenario.
Note: Restarting server certainly forces both
JVM to load new
AIA configuration file.
4) BPEL Configuration change Test case: Changing
BPEL configuration (e.g. audit level or logging level) from
BPEL console. Expected output would be to have new configuration in both
JVM.
Result: Only one
JVM loads the
BPEL configuration.
Note: Restarting server certainly forces both
JVM to load new
BPEL configuration
5) BPEL deployment Test case: Redeploying
BPEL process with same version with minor code change. Expected output would be to have new
BPEL code in both
JVM.
Result: Only one
JVM picks up new
BPEL deployed
suitcase. Second
JVM was still running with old
BPEL code.
Note: Restarting server forces both
JVM to load latest version of
BPEL suitcase.
6) ESB Configuration and Deployment testing.I was really hoping this test to work smooth due to
ESB-
DT and
ESB-RT concept. So as long as
ESB-
DT is in
separate container with only one
JVM and
ESB RT (may be in
OC4J_
SOA) can have multiple
JVM and deployment and configuration change would still work fine. Unfortunately I didn't have access to correct environment where
ESBDT and
ESBRT were database persisted, and
ESBDT in
separate container.
With
ESB-RT and
ESB-
DT in same container (
oc4j_
soa) and having them in-memory topics caused the similar effect as
BPEL during configuration
chagne and deployment.
In future, I might publish results on
ESB with DB persisted topics and some
interesting stuff I saw on Java based application (
webapp and
webservices).