RASTCMS is the JCA 1.5 connector through which application servers can connect to STCMS, both for inbound and outbound. RASTCMS is part of the JMSJCA "family" of JMS connectors, i.e. a JMS connector for 4.5.3, a JMS connector for NSJMS, and
a generic JMS connector based on JNDI.
RASTCMS is shipped as rastcms.rar. It contains the connector code and the complete runtime client for STCMS.
RASTCMS uses a generic connectionURL string to specify options, including connectivity information to the STCMS server. This single URL is used instead of specifying three or more different parameters in ra.xml and in the activation spec.
The format is for non-SSL use:
stcms://server:port
when using SSL, specify
stcmss://server:port
When no port is specified, the port number will be looked up in the system properties. This will work in the Java CAPS application server and will return the port number of the embedded STCMS JMS server. When no server is specified, the server localhost will be used. The default value for the ConnectionURL is stcms://.
The ConnectionURL can optionally contain a query string. This can be used to specify parameters for the STCMS connection factory or the JMSJCA adapter.
For example, to turn make the client validate the SSL certificate that it receives from the server, one can specify server authentication as follows: stcmss://?com.stc.jms.ssl.authenticationmode=Authenticate.
The STCMS client provides producer pooling at a low level. The JMSJCA connector also provides producer pooling; this functionality
was added for JMS providers that don't provide this functionality in the JMS client runtime. The ProducerPooling parameter controls
the producer pooling setting in the connector; by default the producer pooling setting in STCMS client is turned off.
JMSJCA.Strict: if set to true, the adapter will behave as close to the J2EE spec as possible. With STCMS the only effect will be that it will set the connection factory property com.stc.jms.strictPersistence so that the persistence attribute on received messages is identical to how it was sent to when the message was sent.
To prevent deadlocks in the case of all MDBs rolling back, FIFO mode should ONLY be run in sync-mode. This concurrency mode can be specified in the activation spec, as an option in the ra.xml or ejb-jar.xml or the connection URL using the key JMSJCA.concurrencymode. Example for the connection URL:
stcms://?JMSJCA.concurrencymode=sync
Another example:
stcms://server:18007?JMSJCA.concurrencymode=sync
Run in cc-mode will cause deadlock in the case of any MDB rolling back. This can be fixed either in the client side or the server side. A better solution will be addessed
later.