|
Migration |
This document provides a brief overview of the configuration changes in Pramati Server 4.1 compared to Pramati Server 3.5 SP6. The configuration changes involved in each of the Server XML file is highlighted in this document.
<connection-factory name="CLOUDSCAPE_CF1" description="CloudscapeCF" classname="COM.cloudscape.core.JDBCDriver" url="jdbc:cloudscape:../sample_db" authorized-by="Container">
Server 4.1
<connection-factory name="CLOUDSCAPE_CF1" description="CloudscapeCF" classname="COM.cloudscape.core.JDBCDriver" url="jdbc:cloudscape:$SAMPLES_DIR/sample_db" authorized-by="Con- tainer">
The $SAMPLES_DIR constant is introduced to handle cases when the server is not started from the bin directory.
Automigration - No. Behavior is as 3.5.
Automigration - No. A default value is programmatically used. The XML is not
updated by adding the tag.
<property name="orr-row-exists-check" value="true"/> <property name="ro-refreshinterval-millis" value="0"/>--> <property name="sfsb-allow-transactional-remove" value="false"/>
Automigration - Not relevant since the tag is not read. The XML is not updated by removing the tag.
Added new tag:
<compilation-server> <options> <property name="initial-heap-size-megabytes" value="120" /> <property name="maximum-heap-size-megabytes" value="200" /> <property name="idle-timeout-minutes" value="5" /> <property name="number-of-trials" value="5" /> </options> </compilation-server-->
Automigration - No. If not present will have Server 3.5 default behavior.
This tag was moved from the web-config.xml
Automigration - No. If not present, will have default value [false].
No Change
Revamped. Not backward compatible.
No Change
New in Server 4.1
New in Server 4.1
New in Server 4.1
It also contains the configuration of CRL, including the URL from which it will be downloaded, location where it is kept and time after which a new version of CRL will be checked.
Note: All these changes are backward compatible and so an old node with 3.5 configuration can be used in 4.1
Note: For all 3.5 applications, the deploy service does the migration automatically.
Added new tag:
This tag enables error message logging while adding non-serializable attribute object into HTTP Session. This tag is optional. In case of missing tag or previous configuration, this will have default value [false].
The child tags under the root tag <jms-service> in Server 3.5
is changed in Server 4.1 to:
This tag specifies spec compliance and spec leniancy. Strict spec compliance can be enabled using this tag. If this tag is set, all the features will run under spec compliance regardless of what is specified in the inner tags for each feature.
If the user wants to capitalize on specific features under spec compliance, he can set this value to false and specify the featured tag strict-compliance to true. The following are the spec-compliance tags supported by pramati JMS server. This feature is supported from 3.5 SP6.
enable-multiple-receivers : will allow queues to have multiple receivers, and the messages will be delivered to each receiver in a round-robin way.
The following tags are used for allowing or disallowing overriding of message attributes for each destination
strict-compliance true: will not allow administrator to override the message attributes
strict-compliance false: will be overridden by the value of the override tags under each destination.
<override-message-priority strict-compliance="false"/> <override-message-timetolive-millis strict-compliance="false"/> <override-message-delivery-mode strict-compliance="false"/>
This will allow or disallow defining default message attributes for the connection factories. When a new message is created, and the user does not set these message attributes, these values should be the default values.
strict-compliance true: default values will be as specified in the JMS specification
strict-compliance false: administrator will be allowed to specify the default values for these attributes:
<default-message-priority strict-compliance="false"/> <default-message-timetolive strict-compliance="false"/> <default-message-delivery-mode strict-compliance="false"/>
timed-message: A long property "com.pramati.jms.message.deliverytime" that can be set on the message, which does not make the message visible on the destination until that time specified in the property.
strict-compliance true: ignore this property even if it is set on the message
strict-compliance false: Honor this property
The spec does not say anything about the size of a particular message. In Pramati Message Server, administrator can specify the max message size that can be sent to the Server.
strict-compliance true: accept messages of all sizes
strict-compliance false: if message exceed the configured size, take corrective action according to the policy
Pramati Message Server allows administrators to disable persistence. When persistence is disabled, and the delivery mode on the message is persistent, it is treated as a non-persistent message.
strict-compliance true: throw an exception to the sender
strict-compliance false: action depends on the configured policy
Pramati JMS allows administrator to configure the number of retries and the delay between two retries for redelivering a message when the client does not accept a message
strict-compliance true: unlimited number of retries
strict-compliance false: number of attempts depended on configuration.
Pramati JMS allows administrator to configure the number of messages that should be kept in cache for each destination separately.
strict-compliance true: unlimited number of messages should be kept in cache
strict-compliance false: limits the number of messages kept in cache
Allows multiple communication protocols between client and sever.
default-transport-protocol="tcp": uses TCP Sockets for communication
default-transport-protocol="rmi": uses RMI for communication
max-concurrent-threads: Number of threads that are created in the transport layer to dispatch the messages arriving in the transport layer, to the parent layer. A value of -1 means that a new thread would be created for each message dispatch to the upper layer. This in itself could be costly as thread are important resources to the system and should be re-used.
This should be configured according to the requirements. An ideal thread count would be double the value of (Number of receiver JMS connection + Number of sender JMS Connection).
Note: If high number of clients(>60) are expected, the value needs to be increased appropriately.
method-timeout-seconds: This gives a time-out value to the method call on the transport layer.
The method call is deemed as not executed on the server side if there is no response from the server until the timeout. The value must not be changed (Especially for the receiver VM's) as it might lead to some problems as in the method getting executed multiple times on the server.
wire-protocol
there could be multiple wire protocol implementations available
socket-pool-size: Defines the size of the socket pool that is used to send the data across the network.
If the CPU consumption is not a bottleneck then increasing the size might result in better results.
socket-timeout-seconds:
Enable/disable SO_TIMEOUT with the specified timeout, in milliseconds. With this option set to a non-zero timeout, a read() call on the Input Stream associated with this Socket will block for only this amount of time. A timeout of zero is interpreted as an infinite timeout.
send-buffer-bytes/receive-buffer-bytes:
Sets the SO_SNDBUF/SO_RCVBUF option to the specified value for this Socket. The SO_SNDBUF/SO_RCVBUF option is used by the platform's networking code as a hint for the size to set the underlying network I/O buffers. Increasing buffer size can increase the performance of network I/O for high-volume connection, while decreasing it can help reduce the backlog of incoming data.
socket-connect-retrials:
Number of retries that should be made to establish a connection to the destination before assuming the unavailability of the destination.
data-send-retrials:
Number of retries that should be made to send data to the destination before assuming the unavailability of the destination.
<client-socket-properties socket-timeout-seconds="0" send-buffer-bytes="0" receive-buffer-bytes="0" socket-connect-retrials="0" data-send-retrials="2"/>
accept-backlog: It specifies the TCP layer to buffer these many connection request between subsequent requests from the user process to accept the connection.
Default packet transformations to enable compression and aggregation These will be useful transformation based on network bandwidth. The tags look like:
custom interceptors:
To extend the behavior and transform the communication packets.
<custom-interceptors> <interceptor name="priority.aggregator" type="aggregation" class-name=""> <interceptor-property name="destination" value="JMSQueue"/> </interceptor>
Server 3.5 admin-params consists of
Server 4.1 admin-params consists of
expiration-policy
messages can have a timetolive set on them. If there are no clients for the messages and the message exceeds the time to live. The action taken will depend on this policy
add-to-dead-message-queue: redirects the message to the dead message queue
discard-message: (default) the message is dropped and not delivered to the client
< connection-timeout-millis> equal to <ping-timeout> in Server 3.5
On the server side the client proxies are discarded if there is no ping/heartbeat from the client until this time. This is needed to guard against improper close from JMS client
If true, it delivers a message for a topic to all J2EE nodes on which the MDB for the topic is deployed.
This tag is optional, used only in clustering and the value is false.
If true, then the server backups the non persistent messages, so, they wont be lost on failover of the node. This tag is optional, valid only in clustered jms server and default value is false.
This is the wait time till the server has to wait on a failover from the last client, for the missed client. This tag is optional and only valid in clustered jms server, and default value is 3 min(180000 milli
seconds).
When a new destination is created, it will have theses properties unless overridden. All the attributes are optional, and only those attribute that needs to be overridden can be specified for each destination
The runtime/in-memory size of the destination in terms of the number of messages. (in future versions this can also be based on the memory size). Value of -1 implies there is no limit set. The server could go out of memory in this case.
cache-overflow-policy:
This determines, what action to take when there are more messages sent than configured in max-messages-in-cache handle-with-persistence(default): messages are not kept in memory but persisted in persistence store
throw-exception: send call throws exception
block-sender: send call will block
<cache-overflow-policy>throw-exception</cache-overflow-policy> max-message-size-kb max size of each message that will be kept in memory. <max-message-size-kb>50</max-message-size-kb>
message-size-overflow-policy: action that will be taken based when the message size exceeds max-message-size-kb
message-size-overflow-policy:
handle-with-persistence(default),
throw-exception
enable-multiple-receivers: For Queues,
false: All receivers will receive messages according to round robin fashion
true: exception while registering the second receiver
redelivery-delay-millis :
This is the delay in redelivering the message which is rolled back by a transaction or client failure.
This is the limit that a message should be redelivered only these many times, after that it should not be delivered to any client.
redelivery-count-overflow-policy:
This specifies what action should be taken when a message crosses its redelivery limit.
add-to-dead-message-queue(default),
discard-message
This will override the properties of the message. The value of -1 indicates that the value should not be overridden.
<override-message-priority>-1</override-message-priority> <over-ride-message-timetolive -1 implied do not override>
over-ride-message-delivery-mode
-1 implied do not override. 1 - Non persistent 2 - Persistent
block-sender-wait-time-millis :
if the cache-overflow-policy is selected as block-sender, then this time denotes how much time the sender should be blocked when the queue is full and after the time out he will be thrown by the exception indicating that the queue is full. This tag is optional and valid only if the cache-overflow-policy is block-sender.
The value "0" , blocks the sender until the message is sent to the server.
<block-sender-wait-time-millis></block-sender-wait-time-millis> <default-connection-factory-properties>
These values will be taken by new connection factories unless overridden. Each property can be separately overridden
transport-type:
Each connection factory can create connection with certain type of transfer for client-server communication pramati-transport(default) :
Uses TCP Sockets. The transport configuration will is specified under pramati-transport tag
rmi-transport : Use RMI for client-server communication
naming-provider-url :
This property not required for stand alone JMS. In case of clusters, it can be configured to specify the order of fail overs. It is a comma separated list of urls
is-secure: determines whether or not to use secure sockets.
false(default)
enable-compression:
compress the message at the client side before sending it to the server this is CPU intensive and network friendly.
compression-trigger-size-kb:
compress is effective only after a certain min size
Number of messages that can accumulate at the client proxy without acknowledgments. increasing this number increases the throughput, but will require higher memory at runtime.
These many unack messages will be kept for each client proxy on the server. It is a memory vs perf trade off. In case of queues, these are the number of messages in the client VM. In case of topics it is maximum number of messages accumulated at the client proxy on the server side. These are messages which have still not gone to the client side. Maximum messages on the client side in case of topics is specified by client-message-cache-size.
This parameter is valid only for topics. Client Message cache size has been introduced for topic flow control. Here we control the flow at three levels. Client can have a maximum number of messages which is approximately equal to client-message-cache-size. After this no further messages can be accepted unless number of messages in the client goes down.
Second level of flow control is on the data structure of client on the server side(client proxy). For this user must tune the value of max-unacknowledged-messages.
Third level of control is at message cache at the destination. This is specified as max-messages-in-cache under the destination tag. If there are large number of clients in a VM, client-message-cache-size must have a low value.
In cases the acknowledgment mode is AUTO_ACKNOWLEDGEMENT, assume that the client has received the message if the checkForNewMessage does not throw any exception. (It is equivalent of NO_ACK in WebLogic).
false : higher performance
true : higher reliability (client sends the ack)
Accumulate the messages at the client end until the bulk-send-rate number of messages. Then send all the messages in one shot. Enable this when network traffic is heavy.
These tags specifies the default values that should be taken when the sender does not provide them. The value of -1 indicates that there is no default value provided, so, it uses the spec default values.
<default-message-priority>-1</default-message-priority> <default-message-timetolive>-1</default-message-timetolive> <default-message-delivery-mode>-1</default-message-delivery-mode>
Changes in DB Parameters
db-params in Server 3.5:
db-params is replaced with persistent-store in 4.1 with the following properties:
In 4.1 one can explicitly disable the persistence using <persistence-enabled> to true or false.
persistence-enabled : If this is disabled, the server will not access any persistence store. If messages are sent with PERSISTENT delivery mode, the handling is decided by the persistence-disabled-policy:
persistence-disabled-policy :
throw-exception : send message throws an exception
override-message-delivery-mode(default) : messages are treated as non-persistent messages
persistence-type: There are two implementations of persistence store.
file-store(default) : Faster and does not have external dependencies
db-store : more reliable and needs to be configured in the resource-service
messages-dir :
should specify is absolute path or use prefix $NODES_DIR/ to make the store relative to nodes dir or use prefix $INSTALL_DIR/ to make the store relative to install dir
max-file-size-mb :
New file is created after the max file size is reached. If one file is too big, it reduces performance
purge-interval-sec :
The interval for purging deleted messages from the file store
<purge-interval-sec> <db-store> data-source-name : as defined in the resource-config.xml <data-source-name>
jms-table-name-prefix : All tables created by jms will have this as prefix.
The child tags under administered-objects are <destinations> and <connection-factories> . Under <destinations> we have <queue> and <topic> in 3.5 server.
In 4.1 one more child tag is added to <destinations> that is <dead-message-queue>. The occurrences of this (dead-message-queue) tag is atmost once.
All the tags under destinations can have tags specified in the <default-destination-properties>, and all the tags under connection-factories can have the tags specified in the <default-connection-factory-properties> for overriding the default values specified for each destination and connection-factory.
For more information on Server configuration refer to the Pramati Server 4.1 Installation and Configuration Guide.
Pramati Technologies © Copyright |
Migration |