This closes #1924
This commit is contained in:
commit
f97d0e0014
|
@ -479,12 +479,12 @@ In the above cluster connection all parameters have been explicitly
|
|||
specified. The following shows all the available configuration options
|
||||
|
||||
- `address` Each cluster connection only applies to addresses that
|
||||
match the specified address field. An address is matched on the
|
||||
match the specified `address` field. An address is matched on the
|
||||
cluster connection when it begins with the string specified in this
|
||||
field. The address field on a cluster connection also supports comma
|
||||
separated lists and an exclude syntax '!'. To prevent an address
|
||||
field. The `address` field on a cluster connection also supports comma
|
||||
separated lists and an exclude syntax `!`. To prevent an address
|
||||
from being matched on this cluster connection, prepend a cluster
|
||||
connection address string with '!'.
|
||||
connection address string with `!`.
|
||||
|
||||
In the case shown above the cluster connection will load balance
|
||||
messages sent to all addresses (since it's empty).
|
||||
|
@ -522,8 +522,6 @@ specified. The following shows all the available configuration options
|
|||
- Address matching on cluster connections does not support
|
||||
wild-card matching.
|
||||
|
||||
This parameter is mandatory.
|
||||
|
||||
- `connector-ref`. This is the connector which will be sent to other
|
||||
nodes in the cluster so they have the correct cluster topology.
|
||||
|
||||
|
|
|
@ -99,13 +99,8 @@ have its own grouping handler and when a messages is sent with a group
|
|||
id assigned, the handlers will decide between them which route the
|
||||
message should take.
|
||||
|
||||
There are 2 types of handlers; Local and Remote. Each cluster should
|
||||
choose 1 node to have a local grouping handler and all the other nodes
|
||||
should have remote handlers- it's the local handler that actually makes
|
||||
the decision as to what route should be used, all the other remote
|
||||
handlers converse with this. Here is a sample config for both types of
|
||||
handler, this should be configured in the *broker.xml*
|
||||
file.
|
||||
Here is a sample config for each type of handler. This should be
|
||||
configured in `broker.xml`.
|
||||
|
||||
<grouping-handler name="my-grouping-handler">
|
||||
<type>LOCAL</type>
|
||||
|
@ -118,12 +113,20 @@ file.
|
|||
<address>jms</address>
|
||||
<timeout>5000</timeout>
|
||||
</grouping-handler>
|
||||
|
||||
- `type` two types of handlers are supported - `LOCAL` and `REMOTE`.
|
||||
Each cluster should choose 1 node to have a `LOCAL` grouping handler
|
||||
and all the other nodes should have `REMOTE` handlers. It's the `LOCAL`
|
||||
handler that actually makes the decision as to what route should be
|
||||
used, all the other `REMOTE` handlers converse with this.
|
||||
|
||||
The *address* attribute refers to a [cluster connection and the address
|
||||
it uses](clusters.md#configuring-cluster-connections), refer to the clustering section on how to
|
||||
configure clusters. The *timeout* attribute referees to how long to wait
|
||||
for a decision to be made, an exception will be thrown during the send
|
||||
if this timeout is reached, this ensures that strict ordering is kept.
|
||||
- `address` refers to a [cluster connection and the address
|
||||
it uses](clusters.md#configuring-cluster-connections). Refer to the
|
||||
clustering section on how to configure clusters.
|
||||
|
||||
- `timeout` how long to wait for a decision to be made. An exception
|
||||
will be thrown during the send if this timeout is reached, this
|
||||
ensures that strict ordering is kept.
|
||||
|
||||
The decision as to where a message should be routed to is initially
|
||||
proposed by the node that receives the message. The node will pick a
|
||||
|
|
Loading…
Reference in New Issue