Deprecated. A HornetQ server is clustered if it has at least one cluster-connection. Whether the server will use the file based journal for persistence. Maximum number of threads to use for the scheduled thread pool Maximum number of threads to use for the thread pool The security domain to use to verify user and role information Whether security is enabled How long (in ms) to wait before invalidating the security cache. Whether the HornetQ server will override security credentials for in-vm connections (true by default). Whether the server supports wild card routing. Address to send management messages to. The name of the address that consumers bind to to receive management notifications. The user used by cluster connections to communicate between the clustered nodes. The password used by cluster connections to communicate between the clustered nodes. Whether HornetQ should expose its internal management API via JMX. This is not recommended, as accessing these MBeans can lead to inconsistent configuration. The JMX domain used to register internal HornetQ MBeans in the MBeanServer. Whether gathering of statistics such as message counters are enabled. Deprecated. Use statistics-enabled. The sample period (in ms) to use for message counters. How many days to keep message counter history. If set, this will override how long (in ms) to keep a connection alive without receiving a ping. Whether incoming packets on the server should be handed off to a thread from the thread pool for processing. False if they should be handled on the remoting thread. How long (in ms) before a transaction can be removed from the resource manager after create time. How often (in ms) to scan for timeout transactions. How often (in ms) to scan for expired messages. The priority of the thread expiring messages. The size of the cache for pre-creating message IDs. Whether IDs are persisted to the journal. Deprecated. Use remoting-incoming-interceptors instead The list of incoming interceptor classes used by this server. The list of outgoing interceptor classes used by this server. Whether this server is a backup server. Whether this server will automatically shutdown if the original live server comes back up. How long to wait before failback occurs on live server restart. Whether this backup server (if it is a backup server) should come live on a normal server shutdown. Whether this server is using a shared store for failover. Whether the delivery count is persisted before delivery. False means that this only happens after a message has been cancelled. Deprecated. The maximum number of concurrent reads allowed on paging Whether the server should create the bindings directory on start up. Whether the server should create the journal directory on start up. The type of journal to use. The timeout (in nanoseconds) used to flush internal buffers on the journal. The size of the internal buffer on the journal. Whether to wait for transaction data to be synchronized to the journal before returning a response to the client. Whether to wait for non transaction data to be synced to the journal before returning a response to the client. Whether to periodically log the journal's write rate and flush rate. The size (in bytes) of each journal file. How many journal files to pre-create. The percentage of live data on which we consider compacting the journal. The minimal number of journal data files before we can start compacting. The maximum number of write requests that can be in the AIO queue at any one time. The maximum number of backup journals to keep after failback occurs. Whether on startup to perform a diagnostic test on how fast your disk can sync. Useful when determining performance issues. How often to dump basic runtime information to the server log. A value less than 1 disables this feature. Percentage of available memory which if exceeded results in a warning log Frequency to sample JVM memory in ms (or -1 to disable memory sampling) If a replicated live server should check the current cluster to see if there is already a live server with the same node id The name of a set of live/backups that should replicate with each other The name of the cluster connection to replicate from if more than one cluster connection is configured The name to use for this HornetQ Server. Must be unique across all "hornetq-server" elements in the subsystem. So, this attribute is optional with a default value, but if more than one "hornetq-server" element exists, only one can leave this attribute unspecified. Deprecated. Deprecated. Deprecated. Deprecated. The period in milliseconds between consecutive broadcasts. Period, in ms, to wait for an initial broadcast to give us at least one node in the cluster. The name of a stack defined in the org.jboss.as.clustering.jgroups subsystem. The name used by a JGroups channel to join a cluster. The broadcast group socket binding. Deprecated. use socket-binding attribute instead to specify the local bind address. Deprecated. use socket-binding attribute instead to specify the local bind port. Deprecated. use socket-binding attribute instead to specify the group address. Deprecated. use socket-binding attribute instead to specify the group port. Specifies the names of connectors that will be broadcast. The name of the broadcast group The name of a stack defined in the org.jboss.as.clustering.jgroups subsystem. The name used by a JGroups channel to join a cluster. The discovery group socket binding. Deprecated. use socket-binding attribute instead to specify the local bind address. Deprecated. use socket-binding attribute instead to specify the group address. Deprecated. use socket-binding attribute instead to specify the group port. Period the discovery group waits after receiving the last broadcast from a particular server before removing that server's connector pair entry from its list. Period, in ms, to wait for an initial broadcast to give us at least one node in the cluster. The name of the discovery group The class name of the remoting incoming interceptor. The class name of the remoting outgoing interceptor. The key of the parameter The value of the parameter The socket binding reference. The connector server ID. Class name of the factory class that can instantiate the connector. The socket binding reference. The name of the connector The socket binding reference. The server id. Class name of the factory class that can instantiate the acceptor. The socket binding that the acceptor will use to accept connections. The name of the acceptor The unique name of the local queue that the bridge consumes from. The address on the target server that the message will be forwarded to. If a forwarding address is not specified then the original destination of the message will be retained. Whether or not this bridge should support high availability. True means it will connect to any available server in a cluster and support failover. An optional filter string. If specified then only messages which match the filter expression specified will be forwarded. The filter string follows the HornetQ filter expression syntax described in the HornetQ documentation. The minimum size (in bytes) for a message before it is considered as a large message. The period (in milliseconds) between client failure check. The maximum time (in milliseconds) for which the connections used by the bridges are considered alive (in the absence of heartbeat). The period in milliseconds between subsequent reconnection attempts, if the connection to the target server has failed. A multiplier to apply to the time since the last retry to compute the time to the next retry. This allows you to implement an exponential backoff between retry attempts. The maximum interval of time used to retry connections The number of attempts to connect initially with this bridge. The total number of reconnect attempts the bridge will make before giving up and shutting down. A value of -1 signifies an unlimited number of attempts. The total number of reconnect attempts on the same node the bridge will make before giving up and shutting down. A value of -1 signifies an unlimited number of attempts. Deprecated. the failover-on-server-shutdown attribute is no longer taken into account when configuring a connector-ref. Whether the bridge will automatically insert a duplicate id property into each message that it forwards. The confirmation-window-size to use for the connection used to forward messages to the target node. The user name to use when creating the bridge connection to the remote server. If it is not specified the default cluster user specified by the cluster-user attribute in the root messaging subsystem resource will be used. The password to use when creating the bridge connection to the remote server. If it is not specified the default cluster password specified by the cluster-password attribute in the root messaging subsystem resource will be used. A list of names of statically defined connectors used by this bridge. Must be undefined (null) if 'discovery-group-name' is defined. The name of the bridge Each cluster connection only applies to messages sent to an address that starts with this value. The name of connector to use for live connection The period (in milliseconds) between client failure check. The maximum time (in milliseconds) for which the connections used by the cluster connections are considered alive (in the absence of heartbeat). The minimum size (in bytes) for a message before it is considered as a large message. The timeout (in ms) for remote calls made by the cluster connection. The timeout to use when fail over is in process (in ms) for remote calls made by the cluster connection. The period in milliseconds between subsequent attempts to reconnect to a target server, if the connection to the target server has failed. A multiplier to apply to the time since the last retry to compute the time to the next retry. This allows you to implement an exponential backoff between retry attempts. The maximum interval of time used to retry connections The number of attempts to connect initially with this cluster connection. The total number of reconnect attempts the bridge will make before giving up and shutting down. A value of -1 signifies an unlimited number of attempts. Whether the bridge will automatically insert a duplicate id property into each message that it forwards. Whether messages will be distributed round robin between other nodes of the cluster irrespective of whether there are matching or indeed any consumers on other nodes. If this is set to false (the default) then HornetQ will only forward messages to other nodes of the cluster if the address to which they are being forwarded has queues which have consumers, and if those consumers have message filters (selectors) at least one of those selectors must match the message. The maximum number of times a message can be forwarded. HornetQ can be configured to also load balance messages to nodes which might be connected to it only indirectly with other HornetQ servers as intermediates in a chain. The confirmation-window-size to use for the connection used to forward messages to a target node. How many times the cluster connection will broadcast itself How often the cluster connection will broadcast itself Whether, if a node learns of the existence of a node that is more than 1 hop away, we do not create a bridge for direct cluster connection. Only relevant if 'static-connectors' is defined. The name of the discovery group Routing name of the divert Address to divert from Address to divert to An optional filter string. If specified then only messages which match the filter expression specified will be diverted. The filter string follows the HornetQ filter expression syntax described in the HornetQ documentation. The name of a class used to transform the message's body or properties before it is diverted. Whether the divert is exclusive, meaning that the message is diverted to the new address, and does not go to the old address at all. A reference to a cluster connection and the address it uses. How long to wait for a handling decision to be made; an exception will be thrown during the send if this timeout is reached, ensuring that strict ordering is kept. How long a group binding will be used, -1 means for ever. Bindings are removed after this wait elapses (only valid for LOCAL handlers). How often the reaper will be run to check for timed out group bindings (only valid for LOCAL handlers). The name of the grouping handler. Whether the handler is the single "Local" handler for the cluster, which makes handling decisions, or a "Remote" handler which converses with the local handler. Expression matched against a queue address. The dead letter address Defines where to send a message that has expired. Defines the expiration time that will be used for messages using the default expiration time Defines how long to wait before attempting redelivery of a cancelled message Multiplier to apply to the redelivery-delay parameter Defines how many time a cancelled message can be redelivered before sending to the dead-letter-address Maximum value for the redelivery-delay (in ms). The max bytes size. The paging size. The number of page files to keep in memory to optimize IO during paging navigation. Determines what happens when an address where max-size-bytes is specified becomes full. (PAGE, DROP or BLOCK) Day limit for the message counter history. Defines whether a queue only uses last values or not Defines how long to wait when the last consumer is closed on a queue before redistributing any messages If this parameter is set to true for that address, if the message is not routed to any queues it will instead be sent to the dead letter address (DLA) for that address, if it exists. How often (in minutes) to check for slow consumers on a particular queue. Determine what happens when a slow consumer is identified (accepted values: KILL, NOTIFY). The minimum rate of message consumption allowed before a consumer is considered slow. The name of the address setting. The queue address defines what address is used for routing messages. A queue message filter definition. An undefined or empty filter will match all messages. Defines whether the queue is durable. The name of the queue. Class name of the factory class that can instantiate the connector service. The name of the connector service. Whether the connection factory supports High Availability. The client failure check period. The connection ttl. The call time out. The timeout to use when fail over is in process (in ms). The consumer window size. The consumer max rate. The confirmation window size. The producer window size. The producer max rate. Whether large messages should be compressed. True to cache large messages. The min large message size. The client id. The dups ok batch size. The transaction batch size. True to set block on acknowledge. True to set block on non durable send. True to set block on durable send. Whether or not message grouping is automatically used True to pre-acknowledge. The retry interval. The retry interval multiplier. The max retry interval. The reconnect attempts. True to fail over on initial connection. Deprecated. the failover-on-server-shutdown attribute is no longer taken into account when configuring a connector-ref. Name of a class implementing a client-side load balancing policy that a client can use to load balance sessions across different nodes in a cluster. True to use global pools. The scheduled thread pool max size. The thread pool max size. The group id. The name of the connection factory. Use JNDI to locate the destination for incoming connections The JNDI params to use for locating the destination for incoming connections. Use a local transaction for incoming sessions The number of times to set up an MDB endpoint The interval between attempts at setting up an MDB endpoint. The type of transaction. The default username to use with this connection factory. This is only needed when pointing the connection factory to a remote host. The default password to use with this connection factory. This is only needed when pointing the connection factory to a remote host. The minimum size for the pool The maximum size for the pool True to use auto recovery. The initial size of messages created through this factory. The number of attempts to connect initially with this factory. The discovery group name. Whether the connection factory supports High Availability. The client failure check period. The connection ttl. The call time out. The timeout to use when fail over is in process (in ms). Whether large messages should be compressed. The consumer window size. The consumer max rate. The confirmation window size. The producer window size. The producer max rate. True to cache large messages. The min large message size. The client id. The dups ok batch size. The transaction batch size. True to set block on acknowledge. True to set block on non durable send. True to set block on durable send. The autogroup. True to pre-acknowledge. The retry interval. The retry interval multiplier. The max retry interval. The reconnect attempts. By default, a pooled connection factory will try to reconnect infinitely to the messaging server(s). True to fail over on initial connection. Deprecated. the failover-on-server-shutdown attribute is no longer taken into account when configuring a connector-ref. Name of a class implementing a client-side load balancing policy that a client can use to load balance sessions across different nodes in a cluster. True to use global pools. The scheduled thread pool max size. The thread pool max size. The group id. The name of the pooled connection factory. The name of the connector. Deprecated. the backup-connector-name attribute is no longer taken into account when configuring a connector-ref. The name of the JNDI entry. The name of the discovery group. The queue selector. Whether the queue is durable or not. The name of the JMS queue. The name of the JMS Topic. Use XA transaction. Use local transaction. Do not use transaction. The source of the JMS bridge. The target of the JMS bridge. The desired quality of service mode (AT_MOST_ONCE, DUPLICATES_OK or ONCE_AND_ONLY_ONCE). The amount of time in milliseconds to wait between trying to recreate connections to the source or target servers when the bridge has detected they have failed. The number of times to attempt to recreate connections to the source or target servers when the bridge has detected they have failed. The bridge will give up after trying this number of times. -1 represents 'try forever'. The maximum number of messages to consume from the source destination before sending them in a batch to the target destination. Its value must >= 1. The maximum number of milliseconds to wait before sending a batch to target, even if the number of messages consumed has not reached max-batch-size. Its value must be -1 to represent 'wait forever', or >= 1 to specify an actual time. The name of the subscription if it is durable and the source destination is a topic. The JMS client ID to use when creating/looking up the subscription if it is durable and the source destination is a topic. If true, then the original message's message ID will be appended in the message sent to the destination in the header HORNETQ_BRIDGE_MSG_ID_LIST. If the message is bridged more than once, each message ID will be appended. The name to use for this JMS bridge. Must be unique across all "jms-bridge" elements in the subsystem. So, this attribute is optional with a default value, but if more than one "jms-bridge" element exists, only one can leave this attribute unspecified. The name of the module that contains resources required to lookup source or target JMS resources from another messaging broker than AS7. This does not need to be specified if the bridge uses AS7 instances for both source and target. The JNDI name to lookup the connection factory. The JNDI name to lookup the destination. The name of the user for creating the connection. The password of the user for creating the connection. A message selector. Deprecated. use createNonDurableQueue instead. Deprecated. use deleteNonDurableQueue instead. The properties set on the JNDI Context used to lookup the JMS bridge resources. In the absence of a context element, the JMS bridge will lookup resources locally on its own AS7 instance.