Red Hat Application Server: JOnAS User Guide | ||
---|---|---|
Prev | Chapter 33. JOnAS and JORAM: Distributed Message Beans | Next |
Here we provide examples of the relevant portions of the configuration for our system, to provide completely specific detail. Our application uses only queues (at the moment).
<?xml version="1.0"?> <config> <domain name="D1"/> <server id="0" name="S0" hostname="server1"> <network domain="D1" port="16301"/> <service class="fr.dyade.aaa.ns.NameService"/> <service class="fr.dyade.aaa.mom.dest.AdminTopic"/> <service class="fr.dyade.aaa.mom.proxies.tcp.ConnectionFactory" args="16010 root root"/> </server> <server id="1" name="S1" hostname="server2"> <network domain="D1" port="16302"/> <service class="fr.dyade.aaa.mom.dest.AdminTopic"/> <service class="fr.dyade.aaa.mom.proxies.tcp.ConnectionFactory" args="16011 root root"/> </server> <server id="2" name="S2" hostname="server3"> <network domain="D1" port="16303"/> <service class="fr.dyade.aaa.mom.dest.AdminTopic"/> <service class="fr.dyade.aaa.mom.proxies.tcp.ConnectionFactory" args="16012 root root"/> </server> </config> |
The "export" is required for the script to work with the bash shell that we use on our Linux machines.
server 1:
export JAVA_OPTS="$JAVA_OPTS -DTransaction=fr.dyade.aaa.util.ATransaction -Dfr.dyade.aaa.agent.A3CONF_DIR=$JONAS_BASE/conf" jclient -cp "$JONAS_ROOT/lib/jonas.jar:$JONAS_ROOT/lib/common/xml/xerces.jar" fr.dyade.aaa.agent.AgentServer 0 ./s0 "$@" |
server 2:
export JAVA_OPTS="$JAVA_OPTS -DTransaction=fr.dyade.aaa.util.ATransaction -Dfr.dyade.aaa.agent.A3CONF_DIR=$JONAS_BASE/conf" jclient -cp "$JONAS_ROOT/lib/jonas.jar:$JONAS_ROOT/lib/common/xml/xerces.jar" fr.dyade.aaa.agent.AgentServer 1 ./s1 "$@" |
server 3:
export JAVA_OPTS="$JAVA_OPTS -DTransaction=fr.dyade.aaa.util.ATransaction -Dfr.dyade.aaa.agent.A3CONF_DIR=$JONAS_BASE/conf" jclient -cp "$JONAS_ROOT/lib/jonas.jar:$JONAS_ROOT/lib/common/xml/xerces.jar" fr.dyade.aaa.agent.AgentServer 2 ./s2 "$@" |
The Transaction argument specifies the persistence mode of the started JORAM server. The fr.dyade.aaa.util.ATransaction mode provides persistence, when starting a server (server "s1" for example) a persistence root (./s1) is created. If re-starting s1 after a crash, the info contained in this directory is used to retrieve the pre-crash state. For starting a bright new platform, all servers' persistence roots should be removed.
For starting non-persistent servers (which provided better performance), the mode to set is fr.dyade.aaa.util.NullTransaction.
We show only the portions that vary from the default:
server 1:
jonas.services registry,jmx,jtm,dbm,security,jms,resource,joramdist,ejb,web,ear jonas.service.joramdist.class com.nimblefish.sdk.jonas.JoramDistributionService jonas.service.jms.collocated false jonas.service.jms.url joram://localhost:16010 jonas.service.jms.topics jonas.service.jms.queues ApplicationQueue1,ApplicationQueue2,ApplicationQueue3 |
server 2:
jonas.services registry,jmx,jtm,dbm,security,jms,resource,joramdist,ejb,web,ear jonas.service.joramdist.class com.nimblefish.sdk.jonas.JoramDistributionService jonas.service.jms.collocated false jonas.service.jms.url joram://localhost:16011 #jonas.service.jms.topics #jonas.service.jms.queues |
server 3:
jonas.services registry,jmx,jtm,dbm,security,jms,resource,joramdist,ejb,web,ear jonas.service.joramdist.class com.nimblefish.sdk.jonas.JoramDistributionService jonas.service.jms.collocated false jonas.service.jms.url joram://localhost:16012 #jonas.service.jms.topics #jonas.service.jms.queues |
server 1:
joram.createanonuser=false joram.port=16010 joram.bindremotehost=localhost joram.bindremotequeues=WorkManagerQueue,StatusManagerQueue, InternalWorkQueue,ExternalWorkQueue |
server 2:
joram.createanonuser=true joram.port=16011 joram.bindremotehost=server1 joram.bindremotequeues=WorkManagerQueue,StatusManagerQueue, InternalWorkQueue,ExternalWorkQueue |
server 3:
joram.createanonuser=true joram.port=16012 joram.bindremotehost=server1 joram.bindremotequeues=WorkManagerQueue,StatusManagerQueue, InternalWorkQueue,ExternalWorkQueue |
It is a bit odd that server 1, which hosts the queues locally, has a "bindremotequeues" property. In practice, the code that reads "bindremotequeues" actually also sets permissions, and then only binds the queues locally if bindremotehost is other than "localhost". In other words, the code was originally written before the permissions issue came to light, and so the names are a bit stale.