OC4J (Oracle Containers 4 Java) and PRM

[Raf_L]

Hello Team,


Proces:
[s51uf32:/root]# ps -exf | grep -ie oc4j | more
oraase 9342 1 0 May 26 ? 28:26 /opt/java1.5/bin/IA64N/java -server -mx256M -ms256M -XX:MaxPermSize=128M
-XX:AppendRatio=3 -Dstdstream.filesize=2.5 -Dstdstream.filenumber=10 -Djava.security.policy=/opt/oracle/ASPREPROD1013/j
2ee/OC4J_EMD/config/java2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -XX:NewSize=128m -XX:MaxNewSize=256
m -Doracle.ons.oraclehome=/opt/oracle/ASPREPROD1013 -Doracle.home=/opt/oracle/ASPREPROD1013 -Doracle.ons.oracleconfighom
e=/opt/oracle/ASPREPROD1013 -Doracle.ons.clustername=default -Doracle.ons.instancename=ASPREPROD1013.s51uf32 -Dopmn.comp
atible=904 -Doracle.ons.indexid=OC4J_EMD.default_group.1 -Doracle.ons.numprocs=1 -Doracle.ons.uid=7 -Doracle.oc4j.groupn
ame=EMD -Doracle.oc4j.instancename=OC4J_EMD -Doracle.oc4j.islandname=default_group -Doracle.opmn.routingid=g_rt_id -DOPM
N=true -jar oc4j.jar -config /opt/oracle/ASPREPROD1013/j2ee/OC4J_EMD/config/server.xml -properties -out /opt/oracle/ASPR
EPROD1013/opmn/logs/oc4j.out -err /opt/oracle/ASPREPROD1013/opmn/logs/oc4j.err -ports default-web-site:ajp:1

Task: I'm trying to put this proces in a PRM group.

PRM Manual:
Launching a Java program under PRM
To always run a Java program in a specific PRM group, use an
application record. In this record, specify the full path of the Java binary
as the application. Also, give the classname as an alternate name.
(Specifically, the alternate name you specify should match the first
argument to the Java binary that is not preceded by a dash ( - ) in the
COMMAND column of the ps -ef output.)
The full path of the Java binary used must appear in either the file
/etc/shells or the file /opt/prm/shells.

Question:
In my case, there is no class loaded, i.e. there is no argument after "java" in "ps -ef" which does not start with a "-".
How can I tell PRM in this case that this OC4J Container as above shouyld be in PRM group A and another OC4J container in group B ?

[Scott Rhine]

There are two easy ways to handle this.
1) put a "prmrun -g GROUP command" in the script file that starts this java instance.

2) PRM has the ability to handle arbitrary argument strings.
APPLICATION::::GROUP[,{ALTERNATE_NAME[, ...]|'REGEXP'}]

Find some arg in the list that differentiates this instance and use it
/opt/java1.5/bin/IA64N/java::::mygroup:'*instancename=OCJ4_EMD *'

I believe that /opt/java1.5/bin/IA64N/java goes into /opt/prm/shells.

[Raf_L]

Hi Scott,


is this known to be working - because I don't succeed in gettoing it to work ?

Question 1: is PRM using "ps -ef" to decide, or is it using "ps -efx" ? It's only in the latter case that I'm fully able to differentiate between some containers.
Question 2: the manual says
"Specifically, the alternate name you specify should match the first
argument to the Java binary that is not preceded by a dash ( - ) in the
COMMAND column of the ps -ef output."; In our case, there is no argument like this, so it looks like your suggested REGEXP does not work

best regards,


Raf

PS: yes indeed, the prmrun command during startup is the alternative I was considering.

[Duncan Edmonstone]

Raf,

Well I see an argument in your ps output there that isn't preceeded by a dash.

-jar oc4j.jar

I doubt the text/string/regexp intepreter in PRM is clever enough to know that oc4j.jar is an argument to the -jar option...

So I'd try:

/opt/java1.5/bin/IA64N/java::::mygroup:oc4j.jar

if that's a unique enough string to identify your process by...

HTH

Duncan

[Raf_L]

Hi all,

again to no success:
here is my /etc/prmconf entry:

/opt/java1.5/bin/IA64N/java::::MYGROUP,'oc4j.jar'

1/ it does not move any process at all to MYGROUP
2/ even if it would work, it would not be specific enough to filter my different containers

As the manual states that "java" is treated as a shell interpreter, it looks hard to let PRM do something with java not-out-of-the-box.
I'm afraid prmrun is still the best option.

brgds,


Raf

[Scott Rhine · Accepted solution]

the "-" restriction is only for the altname. You're not using any altname.
If anything, there may be a length limitation to the size of the command line
being parsed. I vaguely recall 256 characters at one time and this command is nearly 600. I will look into this further.

[Scott Rhine]

As the same code must be binary compatible with all 11.x platforms, the smallest of which has a kernel bottleneck (pstat constant PST_LEN) of 64 bytes, this must be our "command size" limit. I'm guessing that the interesting part happens after that point.
I will take out a PRM issue for this impracticality.

[Raf_L]

Got feedback from HP support; indeed as stated above, the P_stat limit of 63 chars is killing this example.

Enhancemnet request QXCR1001017550 has been submitted.

Explained to customer that this is a known limitation of 63 characters in the commandline that can be checked by PRM.
We talked about possible workarounds of using prmmove etc.