However for a pinned service we have to make sure that the server instance to which
the service is pinned should be up, otherwise the service will cease to serve.
For the sample (refer to the previous figure) we will make use of both clustered
and pinned services. As shown in figure, receiver3 is a clustered service since it is
deployed in both the instances of the cluster. receiver1 and receiver2 are pinned
services since they are deployed to managed1 and managed2 instances alone,
respectively. The external JMS client will target the messages to all the above three
services. We can see that for messages targeted to receiver1 and receiver2, they are
always routed to managed1 and managed2 server instances respectively. However,
for messages targeted to receiver3 the cluster will load balance the requests to any
of the servers in the cluster. If by any chance we bring down any of the managed
servers, then the pinned services in that instance will no longer be available, but all
the subsequent requests for the clustered service will then onwards be routed to the
other instance(s) of the server in the cluster alone.
Pages:
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509