MQSeries.net :: View topic - Changing default clustering behavior

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » Clustering » Changing default clustering behavior

Goto page Previous 1, 2, 3, 4, 5 Next

Changing default clustering behavior

« View previous topic :: View next topic »

Author

Message

yalmasri

Posted: Wed May 05, 2010 6:51 am Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

Finally got the time to do that.

I could see neigher under Options, so I grabbed this relevant part to check it yourself:

Code:

15:50:06.720469 13795.1 MQOPEN >>
15:50:06.720472 13795.1 Hconn:
15:50:06.720475 13795.1 0x0000: 00000001 |.... |
15:50:06.720478 13795.1 Objdesc:
15:50:06.720481 13795.1 0x0000: 4f442020 00000001 00000001 4d4f4249 |OD ........SERV|
15:50:06.720481 13795.1 0x0010: 4c592e46 554e432e 534d5344 53505443 |ICE.FUNC.SMSDSPC|
15:50:06.720481 13795.1 0x0020: 48522e53 532e434f 4d4d4f4e 00000000 |HR.SS.COMMON....|
15:50:06.720481 13795.1 0x0030: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x0040: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x0050: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x0060: 00000000 00000000 00000000 414d512e |............AMQ.|
15:50:06.720481 13795.1 0x0070: 2a000000 00000000 00000000 00000000 |*...............|
15:50:06.720481 13795.1 0x0080: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x0090: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x00a0: 00000000 00000000 00000000 00030800 |................|
15:50:06.720481 13795.1 0x00b0: 00031138 00000001 01000000 00031138 |...8...........8|
15:50:06.720481 13795.1 0x00c0: 00031514 00000020 00000000 00000000 |....... ........|
15:50:06.720481 13795.1 0x00d0: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x00e0: 00000000 00000000 00000000 00000000 |................|
15:50:06.720481 13795.1 0x00f0: 000000d6 fe57f130 fee087f0 00030800 |.....W.0........|
15:50:06.720481 13795.1 0x0100: 00000000 00031138 00031140 0000000c |.......8...@... |
15:50:06.720481 13795.1 0x0110: fe0771c0 fe07185c 00030914 fe57f290 |..q....\.. ..W..|
15:50:06.720481 13795.1 0x0120: 00000ab8 fe0723c8 fe071910 fe57f3b4 |.. ...#......W..|
15:50:06.720481 13795.1 0x0130: fe071874 fe57f568 fe57f254 001d844c |...t.W.h.W.T...L|
15:50:06.720481 13795.1 0x0140: 00000000 fe57f180 fe05d8cc 00000004 |.....W..........|
15:50:06.720485 13795.1 Options:
15:50:06.720487 13795.1 0x0000: 000020a9 |.. . |
15:50:06.720490 13795.1 Hobj : Output Parm
15:50:06.720494 13795.1 Compcode : Output Parm
15:50:06.720497 13795.1 Reason : Output Parm
15:50:06.720787 13795.1 __________
15:50:06.720791 13795.1 MQOPEN <<
15:50:06.720794 13795.1 Hconn : Input Parm
15:50:06.720797 13795.1 Objdesc:
15:50:06.720800 13795.1 0x0000: 4f442020 00000001 00000001 4d4f4249 |OD ........SERV|
15:50:06.720800 13795.1 0x0010: 4c592e46 554e432e 534d5344 53505443 |ICE.FUNC.SMSDSPC|
15:50:06.720800 13795.1 0x0020: 48522e53 532e434f 4d4d4f4e 00000000 |HR.SS.COMMON....|
15:50:06.720800 13795.1 0x0030: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x0040: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x0050: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x0060: 00000000 00000000 00000000 414d512e |............AMQ.|
15:50:06.720800 13795.1 0x0070: 2a000000 00000000 00000000 00000000 |*...............|
15:50:06.720800 13795.1 0x0080: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x0090: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x00a0: 00000000 00000000 00000000 00000001 |................|
15:50:06.720800 13795.1 0x00b0: 00000000 00000000 01000000 00031138 |...............8|
15:50:06.720800 13795.1 0x00c0: 00031514 00000020 00000000 00000000 |....... ........|
15:50:06.720800 13795.1 0x00d0: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x00e0: 00000000 00000000 00000000 00000000 |................|
15:50:06.720800 13795.1 0x00f0: 4d4f4249 4c592e46 554e432e 534d5344 |SERVICE.FUNC.SMS|
15:50:06.720800 13795.1 0x0100: 53505443 48522e53 532e434f 4d4d4f4e |DSPTCHR.SS.COMMO|
15:50:06.720800 13795.1 0x0110: 20202020 20202020 20202020 20202020 |N |
15:50:06.720800 13795.1 0x0120: 4545534f 37383150 20202020 20202020 |EKSO712C |
15:50:06.720800 13795.1 0x0130: 20202020 20202020 20202020 20202020 | |
15:50:06.720800 13795.1 0x0140: 20202020 20202020 20202020 20202020 | |
15:50:06.720803 13795.1 Options : Input Parm
15:50:06.720806 13795.1 Hobj:
15:50:06.720809 13795.1 0x0000: 00000004 |.... |
15:50:06.720812 13795.1 Compcode:
15:50:06.720815 13795.1 0x0000: 00000000 |.... |
15:50:06.720818 13795.1 Reason:
15:50:06.720821 13795.1 0x0000: 00000000 |.... |

fjb_saper

Posted: Wed May 05, 2010 7:06 am Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

Code:

15:50:06.720485 13795.1 Options:
15:50:06.720487 13795.1 0x0000: 000020a9 |.. . |

Now all you need to do is compare this value Bit wise with the corresponding bind option... should be a breeze right?

_________________
MQ & Broker admin

mvic

Posted: Wed May 05, 2010 7:13 am Post subject:

Jedi

Joined: 09 Mar 2004
Posts: 2080

fjp_saper is right, but I couldn't resist making a post of my own with the answer..

0x000020a9 contains neither 0x00008000 nor 0x00004000.

So this MQOPEN will use MQOO_BIND_AS_Q_DEF (which is 0x00000000).

So, what does your queue definition look like?

yalmasri

Posted: Wed May 05, 2010 11:25 am Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

mvic wrote:

0x000020a9 contains neither 0x00008000 nor 0x00004000.

So this MQOPEN will use MQOO_BIND_AS_Q_DEF (which is 0x00000000).

Dude, we're back to square 1

But at least we know now that Destination is by default MQOO_BIND_AS_Q_DEF.

mvic wrote:

So, what does your queue definition look like?

Both queues are CLWLUSEQ(ANY), DEFBIND(NOTFIXED), I'm sending from local machine but messages all go to remote one

yalmasri

Posted: Wed May 05, 2010 11:31 am Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

fjb_saper wrote:

Code:

15:50:06.720485 13795.1 Options:
15:50:06.720487 13795.1 0x0000: 000020a9 |.. . |

Now all you need to do is compare this value Bit wise with the corresponding bind option... should be a breeze right?

What could I know from this other than what mvic said?

mqjeff

Posted: Wed May 05, 2010 11:34 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

It's a long and winding thread, so apologies if this has been covered...

Try specifying a name for the qmgr in the destination, as well as a name for the queue.

Then create a qremote in the local qmgr that has the same name as the one you specified in the qmgr in the destination. And set the RQMNAME of the QREMOTE to blank.

bruce2359

Posted: Wed May 05, 2010 11:49 am Post subject:

Poobah

Joined: 05 Jan 2008
Posts: 9472
Location: US: west coast, almost. Otherwise, enroute.

Quote:

But at least we know now that Destination is by default MQOO_BIND_AS_Q_DEF.

No, no, no, NO, NO!

It is not a default. It is an initial value of the queue bind attribute. The application will pick BIND_FIXED or BIND_NOT_FIXED or BIND_AS_Q_DEF.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live.

Last edited by bruce2359 on Thu May 06, 2010 5:55 am; edited 1 time in total

yalmasri

Posted: Wed May 05, 2010 12:35 pm Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

mqjeff wrote:

What're you trying to do here?

mqjeff

Posted: Wed May 05, 2010 6:09 pm Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

yalmasri wrote:

mqjeff wrote:

What're you trying to do here?

It's a cluster alias that will cause new name resolution when messages are sent to the destination.

It should prevent messages from being sent to a specific qmgr, and allow them to be balanced across all instances of the cluster queue.

fjb_saper

Posted: Wed May 05, 2010 7:32 pm Post subject:

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY

yalmasri wrote:

Both queues are CLWLUSEQ(ANY), DEFBIND(NOTFIXED), I'm sending from local machine but messages all go to remote one

So did you verify that the local queue was not put inhibited??
DEFBIND(NOTFIXED) only makes it choose (round robing fashion) between ELIGIBLE destinations. A put inhibited destination is not eligible.

_________________
MQ & Broker admin

yalmasri

Posted: Thu May 06, 2010 1:26 am Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

mqjeff wrote:

Try specifying a name for the qmgr in the destination, as well as a name for the queue.

So if I have QM1 & QM2 and QM1 is local to me then I should specify QM1 as qmanager for destination? But it's already the default for empty qmanager property, isn't it?

mqjeff wrote:

Then create a qremote in the local qmgr that has the same name as the one you specified in the qmgr in the destination. And set the RQMNAME of the QREMOTE to blank.

This way I'll be having two queues with same name and with one is local. How queue manager is going to pick between them for local sends?

mqjeff wrote:

It should prevent messages from being sent to a specific qmgr, and allow them to be balanced across all instances of the cluster queue.

So can I suggest that even though I have CLWLUSEQ(ANY), DEFBIND(NOTFIXED) for my queues, I will not experience even load distribution and I'll have to do that "trick" to get around it?

yalmasri

Posted: Thu May 06, 2010 1:35 am Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

fjb_saper wrote:

yalmasri wrote:

Both queues are CLWLUSEQ(ANY), DEFBIND(NOTFIXED), I'm sending from local machine but messages all go to remote one

I'm really admiring your "out of the box" way of thinking!

The answer is yes, because when I do it the other way around, i.e., sending on the other machine, the messages just go to the remote queue (some sort of stickiness is created some how with the other queue)

mvic

Posted: Thu May 06, 2010 1:36 am Post subject:

Jedi

Joined: 09 Mar 2004
Posts: 2080

We've been assuming that your cluster is properly set up, and you have fixes for all known issues. It might not be properly set up, and/or you might not have all fixes (did you apply 6.0.2.8 after it was mentioned earlier? 6.0.2.9 would be a better choice seeing as it's been available for a while now)

Have you called IBM to work through this? If your cluster were OK, I would not expect the workload mechanisms to avoid any queue of the correct name, whose channel was up and running.

We are not really getting very far after 4 pages of mqseries.net discussions, and just wanted to suggest trying something else.. Just IMHO. Hope you get it fixed

yalmasri

Posted: Thu May 06, 2010 1:48 am Post subject:

Centurion

Joined: 18 Jun 2008
Posts: 110

mvic wrote:

I agree. I guess I'll stop here and get IBM to check this. I'll post the solution once verified by them.

Thanks for all of you guys for your insightful contributions.

exerk

Posted: Thu May 06, 2010 2:21 am Post subject:

Jedi Council

Joined: 02 Nov 2006
Posts: 6339

One additional thought...

Were all the queues set to NOTFIXED before the application(s) connected, and have the application(s) been stopped/started since, or released their OPEN on the queue?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Display posts from previous:

Goto page Previous 1, 2, 3, 4, 5 Next

Page 4 of 5

MQSeries.net Forum Index » Clustering » Changing default clustering behavior

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Protected by Anti-Spam ACP