5.2. ServerPeer attributes
This section discusses the
ServerPeer
managed bean attributes.
- ServerPeerID
- The unique identifier of the
ServerPeer
. Each node deployed must have a unique identifier, whether the nodes form a cluster or are linked by a message bridge. The identifier must be a valid integer. - DefaultQueueJNDIContext
- The default JNDI context to be used when binding queues. The default value is
/queue
. - DefaultTopicJNDIContext
- The default JNDI context to be used when binding topics. The default value is
/topic
. - PostOffice
- The post office used by the
ServerPeer
. You will not normally need to edit this attribute. The post office routes messages to queues and maintains the mapping between queues and addresses. - DefaultDLQ
- The default DLQ (Dead Letter Queue) that the server uses for destinations. You can override the DLQ on a per-destination basis. For more information, see Section 5.7, “Configuring Destinations”. A DLQ is a destination for messages that the server has failed to deliver more than a certain number of times. If the DLQ is not specified, the message will be removed after the maximum number of delivery attempts. You can specify a global default for the maximum number of delivery attempts with the
DefaultMaxDeliveryAttempts
attribute, or set the maximum individually on a per-destination basis. - DefaultMaxDeliveryAttempts
- The global default for the maximum number of times delivery will be attempted for a message before the message is removed or sent to the DLQ, if configured. The default value is
10
. You can override this value on a per-destination basis. - DefaultExpiryQueue
- The default expiry queue that the
ServerPeer
will use for destinations. You can override this value on a per-destination basis, as seen in the section on destination managed bean configuration. An expiry queue holds messages that have expired. Message expiry is determined by the value ofMessage::getJMSExpiration()
. If the expiry queue is not specified, the message will be deleted when it expires. - DefaultRedeliveryDelay
- This attribute lets you delay a redelivery attempt, which helps to prevent thrashing delivery-failure. The default value is
0
(that is, no delay). You can override this value on a per-destination basis. - MessageCounterSamplePeriod
- This attribute defines the period of time between the server's queries to the queue for queue statistics. The default value is
5000
milliseconds. - FailoverStartTimeout
- The longest period (in milliseconds) that the client will wait for failover to begin on the server side when a problem is detected. The default value is
60000
(one minute). - FailoverCompleteTimeout
- The longest period (in milliseconds) that the client will wait for failover to complete on the server side once failover has been initiated. The default value is
300000
(five minutes). - DefaultMessageCounterHistoryDayLimit
- JBoss Messaging provides a message counter history, which shows the number of messages arriving on each queue over a certain number of days. This attribute represents the maximum number of days for which to store message counter history. You can override this value on a per-destination.
- ClusterPullConnectionFactoryName
- The connection factory used to pull, or suck, messages between queues. You can omit this attribute to disable message sucking while retaining failover.
- DefaultPreserveOrdering
- When
true
, JMS ordering is preserved in the cluster. See Chapter 6, Clustering Notes for more detail. The default value isfalse
. - RecoverDeliveriesTimeout
- When failover occurs, messages that have been delivered will be stored while the clients reconnect. If the clients do not reconnect (for example, if the client is dead), these messages will eventually time out and be added to the queue. This attribute sets the period before timeout in milliseconds. The default value is
300000
(five minutes). - EnableMessageCounters
- When set to
true
, enables message counters upon server start. - SuckerPassword
- JBoss Messaging internally creates connections between nodes to redistribute messages between clustered destinations. These connections are created with a special, reserved username. This attribute defines the password to use when creating these connections.For versions of JBoss Messaging later than 1.4.1.GA, you must define the
SuckerPassword
on theSecurityMetadataStore
.Warning
TheSuckerPassword
must be changed at install time, or the default password will be used, giving any user who knows the default password access to any destination on the server. - SuckerConnectionRetryTimes
- This is the maximum number of times a sucker's connection is permitted to retry in the event of a failure. The default value is
-1
which represents "retry indefinitely". - SuckerConnectionRetryInterval
- This is the interval in milliseconds between each retry of the failed sucker's connection. The default value is
5000
. - StrictTck
- To enable strict JMS Technology Compatibility Kit (TCK) semantics, set this attribute to
true
. - Destinations
- Returns a list of the destinations (queues and topics) currently deployed.
- MessageCounters
- A message counter for a particular queue.
- MessageStatistics
- Statistics about each message counter for each queue.
- SupportsFailover
- When this attribute is
false
, server-side failover does not occur when a node crashes in a cluster. - PersistenceManager
- The persistence manager used by the
ServerPeer
. (You will not normally need to change this attribute.) - JMSUserManager
- The JMS user manager used by the
ServerPeer
. (You will not normally need to change this attribute.) - SecurityStore
- The pluggable
SecurityStore
. If you redefine this attribute, remember that you will need to authenticate theMessageSucker
user (JBM.SUCKER
) with all special permissions required by clustering. - SupportsTxAge
- Specifies whether the transaction creation time is stored in the transaction record. If set to
true
, the transaction record is stored. The default isfalse
.
5.2.1. ServerPeer methods
The following methods are available for the ServerPeer managed bean:
- deployQueue
- Used to programmatically deploy a queue. If the queue exists but is undeployed, it will be deployed. Otherwise, it is created and deployed.The
name
parameter matches a destination to deploy.The optionaljndiName
parameter represents the full JNDI name of the location to which a destination will be bound. If this is not specified, the destination will be bound in<DefaultQueueJNDIContext>/<name>
.There are two overloaded versions of this operation. The first deploys the destination with default paging parameters. The second deploys the destination with the paging parameters specified. For more information about paging parameters, see Section 5.7, “Configuring Destinations”. - undeployQueue
- Used to programmatically undeploy a queue. Queues are not removed from persistent storage. This operation returns
true
if the queue is successfully undeployed. Otherwise, it returnsfalse
. - destroyQueue
- Used to programmatically destroy a queue. Queues are undeployed and all of their data is removed from the database and destroyed.
Warning
Exercise caution when using this method, since it will delete all data for the queue.This operation returnstrue
if the queue was destroyed successfully. Otherwise, it returnsfalse
. - deployTopic
- Used to programmatically deploy a topic. There are two overloaded versions of this operation. The first deploys already existing topics with the default paging parameters. The second creates and deploys topics with specified paging parameters. See Section 5.7, “Configuring Destinations” for more information.The
name
parameter represents the name of the destination to deploy.ThejndiName
represents the full JNDI name of the location to which the destination will be bound. If this is not specified, the destination will be bound in<DefaultTopicJNDIContext>/<name>
. - undeployTopic
- Used to programmatically undeploy a topic. Topics are undeployed, but not removed from persistent storage. This operation returns
true
if the topic is undeployed successfully. Otherwise,false
is returned. - destroyTopic
- Used to programmatically destroy a topic. Topics are undeployed and all data is removed from the database and destroyed. This operation returns
true
if the topic is successfully destroyed. Otherwise, it returnsfalse
.Warning
Exercise caution when using this method: it will delete all data for the topic. - listMessageCountersHTML
- Returns message counters in a simply-displayed HTML format.
- resetAllMesageCounters
- Resets all message counters to zero.
- enableMessageCounters
- Enables all message counters for all destinations. Message counters are disabled by default.
- disableMessageCounters
- Disables all message counters for all destinations. Message counters are disabled by default.
- retrievePreparedTransactions
- Retrieves a list of the XIDs for all transactions currently in a prepared state on the node.
- showPreparedTransactions
- Retrieves a list of the XIDs for all transactions currently in a prepared state on the node in an easily-displayed HTML format.
- listAllPreparedTransactions
- Displays the details of all prepared transactions.
- listPreparedTransactions
- Displays the details of all prepared transactions where the transaction ages are equal to or older than a specified time.
- showMessageDetails
- Displays the details of a message. The message ID is used to specify the message to display.
- commitPreparedTransaction
- Manually commit a prepared transaction. The transaction ID is used to specify the transaction to commit.
- rollbackPreparedTransaction
- Manually roll-back a prepared transaction. The transaction ID is used to specify the transaction to roll-back.