| Author |
Message
|
| Vitor |
 Posted: Wed Jan 10, 2007 2:57 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lex wrote: |
| (we have a script for quickly rebuilding the broker). |
Do you need to do it quite often then?
I'm also going to ask again where the cluster comes into the deploy process and what's being done to fix the stuck messages on the cluster xmitq.
Because the most likely cause of this (as has been stated) is a failure in the deploy messages getting to their target. So a known message sticking problem does sound like a good place to start. Even for a newbie. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| Lex |
| Posted: Wed Jan 10, 2007 3:00 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
I just run runmqsc command on the AIX server side, and then typed the following commands:
DISPLAY QLOCAL(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
5 : DISPLAY QLOCAL(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
AMQ8409: Display Queue details.
DESCR(MQSeries Cluster Repository Queue)
PROCESS( ) BOQNAME( )
INITQ( ) TRIGDATA( )
CLUSTER( ) CLUSNL( )
QUEUE(SYSTEM.CLUSTER.REPOSITORY.QUEUE)
CRDATE(2007-01-10) CRTIME(11.30.06)
ALTDATE(2007-01-10) ALTTIME(11.30.06)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(640000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(NORMAL) NOTRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(1)
OPPROCS(1) CURDEPTH(24)
DISPLAY QLOCAL(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
3 : DISPLAY QLOCAL(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
AMQ8409: Display Queue details.
DESCR(MQSeries Cluster Transmission Queue)
PROCESS( ) BOQNAME( )
INITQ( ) TRIGDATA( )
CLUSTER( ) CLUSNL( )
QUEUE(SYSTEM.CLUSTER.TRANSMIT.QUEUE) CRDATE(2007-01-10)
CRTIME(11.30.06) ALTDATE(2007-01-10)
ALTTIME(11.40.14) GET(ENABLED)
PUT(ENABLED) DEFPRTY(0)
DEFPSIST(NO) MAXDEPTH(640000)
MAXMSGL(4194304) BOTHRESH(0)
SHARE DEFSOPT(SHARED)
HARDENBO MSGDLVSQ(PRIORITY)
RETINTVL(999999999) USAGE(XMITQ)
TRIGGER TRIGTYPE(FIRST)
TRIGDPTH(1) TRIGMPRI(0)
QDEPTHHI(80) QDEPTHLO(20)
QDPMAXEV(ENABLED) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QSVCINT(999999999)
QSVCIEV(NONE) DISTL(NO)
DEFTYPE(PREDEFINED) TYPE(QLOCAL)
SCOPE(QMGR) DEFBIND(OPEN)
IPPROCS(1) OPPROCS(1)
CURDEPTH(49)
Is it normal that these queues are not associated with a Cluster? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 10, 2007 3:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lex wrote: |
| Is it normal that these queues are not associated with a Cluster? |
Um - no.
I think you need to get a better handle on your setup.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lex |
| Posted: Wed Jan 10, 2007 3:08 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
| Well we have scripts for the setup of both broker and config manager, and these worked fine since a few days, they have not been changed (except for adding some queue definition in the script that creates the QM on the AIX side). The queue definition i added is exactly the same as the other which were already inside the script, and these queues are used for the message flows. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 10, 2007 3:12 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lex wrote: |
| Well we have scripts for the setup of both broker and config manager, and these worked fine since a few days, they have not been changed (except for adding some queue definition in the script that creates the QM on the AIX side). The queue definition i added is exactly the same as the other which were already inside the script, and these queues are used for the message flows. |
And this has what to do with the existence or not of a cluster and/or the channel settings? 
Or the existence or not of a cluster?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Jan 10, 2007 3:13 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I think it is normal that SYSTEM.CLUSTER.TRANSMIT.QUEUE and SYSTEM.CLUSTER.REPOSITORY.QUEUE will not be shared in a cluster (which is what the CLUSTER() attribute means).
IGNORE THE QUEUES. FOCUS ON THE CHANNELS!
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Lex |
| Posted: Wed Jan 10, 2007 3:19 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
| Vitor wrote: |
And this has what to do with the existence or not of a cluster and/or the channel settings?
Or the existence or not of a cluster? |
Because in the scripts that create the QM, we have a li,e like that:
ALTER QMGR REPOS (CLUSTER_NAME)
and then
DEFINE CHANNEL CLUSTER (CLUSTER_NAME) (I didn't write the whole instruction)
And i didn't see any other place during the installation where i can see the cluster name. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 10, 2007 3:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
So, for what feels like the umpteenth time, what status do the channels have? It can be assumed from messages stuck in the cluster xmitq not all of them are working so which ones are not?
And are the config mngr & broker queue managers in this cluster? You've not confirmed this. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lex |
| Posted: Wed Jan 10, 2007 4:55 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
Yes the broker and configmgr QMs' are on this cluster.
What do you call xmitq? |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 10, 2007 5:02 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lex wrote: |
Yes the broker and configmgr QMs' are on this cluster.
What do you call xmitq? |
SYSTEM.CLUSTER.TRANSMIT.QUEUE 
Now if the two queue managers concerned with a deploy are on this cluster and messages are not getting delivered I think we may have taken a step closer to why your deploy is not happening.
As a wise PooBah has already said more than once:
| jefflowrey wrote: |
| Fix the cluster! |
and
| jefflowrey wrote: |
| IGNORE THE QUEUES. FOCUS ON THE CHANNELS! |
Even I keep asking about channel status and you never tell me...
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lex |
| Posted: Wed Jan 10, 2007 6:01 am Post subject: |
|
|
Acolyte
Joined: 14 Nov 2006
Posts: 73
|
Ok, here is what display chstatus returns on each computer:
AIX:
display chstatus(*)
3 : display chstatus(*)
AMQ8417: Display Channel Status details.
CHANNEL(TO.QM_EAI_2_DEV) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
CONNAME(siprog_sv10(1416)) CURRENT
CHLTYPE(CLUSSDR) STATUS(RETRYING)
AMQ8417: Display Channel Status details.
CHANNEL(SYSTEM.ADMIN.SVRCONN) XMITQ( )
CONNAME(20.3.192.5) CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
AMQ8417: Display Channel Status details.
CHANNEL(SYSTEM.ADMIN.SVRCONN) XMITQ( )
CONNAME(20.3.192.5) CURRENT
CHLTYPE(SVRCONN) STATUS(RUNNING)
end
NT:
DISPLAY CHSTATUS(*)
3 : DISPLAY CHSTATUS(*)
AMQ8420: Etat du canal introuvable.
end
4 : end
Apparently there is a problem on the NT side... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 10, 2007 6:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
There does appear to be an issue - a status of RETRYING is never good.
Note that the lack of status on NT just proves the channel's not been active recently, not that there's a problem with the channel per se
Fix this, with reference to your network people I expect, and then see if the deploys still fail.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| pathipati |
| Posted: Wed Jan 10, 2007 7:28 am Post subject: |
|
|
Master
Joined: 03 Mar 2006
Posts: 296
|
| Lex wrote: |
| Apparently there is a problem on the NT side... |
Fix this.
and
| jefflowrey wrote: |
| IGNORE THE QUEUES. FOCUS ON THE CHANNELS! |
|
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jan 10, 2007 7:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| pathipati wrote: |
| Lex wrote: |
| Apparently there is a problem on the NT side... |
Fix this.
and
| jefflowrey wrote: |
| IGNORE THE QUEUES. FOCUS ON THE CHANNELS! |
|
I think we've already said that..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Jan 10, 2007 8:03 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| Lex wrote: |
CONNAME(siprog_sv10(1416)) CURRENT
CHLTYPE(CLUSSDR) STATUS(RETRYING) |
Do you have a listener running on siprog_sv10 (which I assume is your NT bos) listening on port 1416? If not, that would explain the RETRYING status. |
|
| Back to top |
|
|
|
|
