I was asked an interesting question.
If your messaging engine is in a cluster and it fails over from one node to the next, how to my clients know which node is now hosting the Messaging Engine?
I haven’t run this scenario myself so I don’t know. I do know that the datapower allow you to specify transport chains, bootstrap ports and the like. Does anyone know of documentation of describes SIBus High Availability? The only time I’ve dealt with a bootstrap messaging port was when trying to perform a remote JMS lookup. Is there where I would specify info?
Is this for internal or external JMS. Internal JMS just works because the WPS server knows where the destination is, even after failover, due to the HA components.
For external, use a “floating” ip address which can be pointed at the relevant node when the failover occurs. This is normally controlled by something like VCS, AIX HACMP etc.
The other solution is to use a hardware solution which can detect which server is listening and divert requests to the appropriate one. Again, a single IP address (or DNS) would be used.
Not sure I agree with all of Chris’ response. If the client is running inside the same cell then, yes, it all just works as the location of the messaging engines is propagated to every server. If the client is external to the cell then it needs to bootstrap to a server with the SIBService enabled (this is enabled by default when a server or its cluster is added as a member of a bus). The connection factory lets you define a list of bootstrap servers (the provider endpoints) so that you don’t get a single point of failure. The bootstrap server then tells the client where it can find a messaging engine, if necessary, redirecting it to another server. Typically you’d just list all of the cluster members in which the messaging engine can run as the provider endpoints.
Oddly enough, this is actually all documented rather well in the InfoCenter:
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websphere.pmc.nd.doc/tasks/tjn0033_.html
Thanks for the update. I have not seen that document but it will definitely help in the future.
Regards
Chris
Hi Guys,
First off, thanks for addressing my question.
David,
Ok seriously, how would I ever find that information in the infocenter. “Configuring a connection to a non-default bootstrap server” isn’t exactly the search term on my mind ;-). That really is a very good link and I admit I’m surprised that it’s described so well in the doc.
The part that kind of sucks is needed to re-describe the potential server list in the connection factory. I can understand why but I hate duplcating information that can quickly get old.
It always me how long it takes me to find something in the InfoCenter even when I know it’s there and what it says! A connection factory could just contain the name of the bus so I’m not sure what information you are duplicating in the provider endpoints? Agreed, it would be nice if the connection factory was automatically populated with details of the server it was looked up from but that would break the admin model where you can define resources at scopes other than server scope (although perhaps it should be automatically populated with all of the servers at that scope).
I just haven’t put my own hands on this issue, so until then things aren’t baked in.. so I may ask for stuff that makes no sense 🙂
We did look at doing something like this when it was developed but we we’re hoping to do something clever at lookup time. Unfortunately there are really no hooks on the server side when a remote lookup takes place. We could have moved the clever logic to bind time but then you start to run the risk of data becoming out of date again. The provider endpoints also cover the case when you didn’t go to the server JNDI at all and are just programmatically constructing the connection factory.