| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Cluster transmission Q |
« View previous topic :: View next topic » |
| Author |
Message
|
| techno freak |
 Posted: Sat Jul 24, 2010 6:49 am Post subject: Cluster transmission Q |
 |
|
Newbie
Joined: 24 Jul 2010
Posts: 1
|
Hey Guys,
Applications must not write directly to the cluster transmission queue. They write to named queues that resolve to the cluster transmission queue.
whats a reason behind it. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Sat Jul 24, 2010 8:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Becuase if you grant permission to the S.C.T.Q for an application, then the application can choose to write to SYSTEM.ADMIN.COMMAND.QUEUE on any machine in the cluster, and thus you have lost all of your MQ security entirely.
This is Bad. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 24, 2010 12:09 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Applications must not write directly to the cluster transmission queue. They write to named queues that resolve to the cluster transmission queue. |
To be more technically accurate, end-user apps should not be able to open transmission queues; rather, they should open an application queue name - most often a QRemote definition - that resolves to an xmit queue as its real local queue.
Similarly, an application should open an application cluster queue definition, and not the SCTQ.
_________________
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. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Aug 07, 2010 11:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
And yes, this is a problem when the apps are replying to dynamic queue names in a cluster. By running all the Cluster Receivers with an MCAUSER that does not have access to the SYSTEM.ADMIN.COMMAND.QUEUE you can prevent remote administration if you must still allow access to the S.C.T.Q.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Aug 11, 2010 7:10 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
"Cluster" has multiple meanings.
Briefly, an MQ cluster is a group of queue managers that host the same queue.
_________________
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. |
|
| Back to top |
|
|
| Mr Butcher |
| Posted: Wed Aug 11, 2010 9:57 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
applications should not write to the transmission quees because, if they do, they have to provide a tramsmission header (XQH). If that header is missing or if it is not accurate to the sending MCA, then you message will be put to the local dead letter queue.
this is why there are remotequeues. they hold the information that enables mqseries to create a proper transmission header for you, and you do not have to care about all that technical stuff that is in the transmission header.
especially for the S:C:T:Q, there is the cluster workload algoritm that is passed to pick a channel to the target queue. the channel is then placed in the correlid (i hope i am correct here) of the message that is put in S.C.T.Q to be picked up by the proper mca. now, if youj put to the S.C.T.Q directly, you pass the cluster workload algorithm and have to pick up a channel of your choice by your own.
applications should not care about all that technical stuff. thats up to MQ or the MQ administration.
_________________
Regards, Butcher |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
