Author |
Message
|
rammer |
Posted: Fri Aug 13, 2004 5:52 am Post subject: .NET and Clustering |
|
|
Partisan
Joined: 02 May 2002 Posts: 359 Location: England
|
Hi I have a question regarding using the MQ .NET API's.
The installation is going to be MQ Client 5.3 CSD7. I am wanting this server to be able to put to any of 4 MQ Servers running MQ5.3 CSD7, which all host a clustered queue. For the Get it will be exactly the same with 4 servers hosting clustered queues.
Reading the .NET manual on page 15 it states:
Using .NET as a client it is similar to the MQ C Client except:
It does not support connection tables
Information that would be stored in a channel definition and in environment variables is stored in a call called Environment. Alternatively this information can be passed as parameters when the connection is made.
What I am asking is it possible then to get the application server to choose any of the 4 servers and not be tied to the same one each time?
I am only used to using Client with connection tables.
Thanks in advance |
|
Back to top |
|
 |
bduncan |
Posted: Fri Aug 13, 2004 9:15 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
That isn't clustering the MQ sense. MQ Clustering simply allows the flow of messages to arbitrary queue managers which host the same clustered queue. Having a client connect to an arbitrary queue manager is a completely different problem. Perhaps you could provide some more detail about your message flow / architecture, because it seems like you might be able to alter it somewhat so that you don't need your clients to connect to different queue managers... _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri Aug 13, 2004 3:54 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Quote: |
I am wanting this server to be able to put to any of 4 MQ Servers running MQ5.3 CSD7, which all host a clustered queue. For the Get it will be exactly the same with 4 servers hosting clustered queues.
|
If you want to choose 1 of the four QMs to connect to to put/get, then code the MQEnvironment class with that QMs connection info prior to connecting.
If you want random connections, you could.......wait....why do you want that?
Like Brandon said, what are you trying to do? Then we can help you decide how to do it. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
rammer |
Posted: Sun Aug 15, 2004 11:51 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002 Posts: 359 Location: England
|
Thanks for the reply,
What I am trying to do is be able to offer the project a server that is always available to for putting the message.
So for example Application Server needs to put to Queue 1, and this is clustered on 4 MQ Servers. If Server 1 is down for any reason, it can then try server 2 etc.
Since being asked to provide this solution last week, I have found out that the messages are going to be carried out under transaction (if thats the correct word), and there is a very short window for these message having to be processed. With this in mind (and if clustering was able to work) I was worried that messages could get stuck on a queue manager that was suddenly to fail, thus causing a backlog in processing.
Instead of using clustering I have asked the project team if they would rather spec up a system that made use of Microsoft Clustering as an alternative which would give hardware failover, so instead of there being 4 MQ Servers, there would just be 1 virtual one.
Not sure if this is the correct way to go with this so I would still be interested in your thoughts.
I won't be able to reply for 2 weeks as I am just about to head of to the airport for 2 weeks in Spain.
Thanks in advance |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Aug 16, 2004 3:52 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If stranded messages are a concern, then the only solution is to employ hardware failover and persistent messages (or if you were on the MF, shared queues). Clustering from an application perspective is only for workload balancing. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
rammer |
Posted: Wed Sep 01, 2004 2:41 am Post subject: |
|
|
Partisan
Joined: 02 May 2002 Posts: 359 Location: England
|
I believe stranded message are the concern which is why I have suggested using Microsoft Cluster Servers as there solution is going to be Microsoft based, but since passing the costs onto the project it has all gone very quiet so we will just have to wait and see.
Thanks for the replies.
Rammer |
|
Back to top |
|
 |
|