| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Q size and memory allocation for MQ v5.3 CSD10 (AIX) |
« View previous topic :: View next topic » |
| Author |
Message
|
| aahmad8 |
 Posted: Mon Apr 30, 2007 12:03 am Post subject: Q size and memory allocation for MQ v5.3 CSD10 (AIX) |
 |
|
Apprentice
Joined: 12 Sep 2005
Posts: 27
Location: Malaysia
|
Recently our application using MQ having a situation where application with MQ trigger enabled stop picking up message from local q. Our temporary solution is by saving all messages from local q to a text files using amqsbcg utility, clear messages from local q and restart the trigger monitor by using "nohup runmqtrm -m MLEP11 -q GCIF.ELIXIR.TRIGGER.ALL.01 &"
Below are the qlocal settings:
DESCR( ) PROCESS(GCIF.ELIXIR.PRQ.UPD.PR.D1)
BOQNAME( ) INITQ(GCIF.ELIXIR.TRIGGER.ALL.01)
TRIGDATA( ) CLUSTER( )
CLUSNL( ) QUEUE(GCIF.ELIXIR.PRQ.UPD.01)
CRDATE(2005-08-18) CRTIME(17.15.14)
ALTDATE(2005-09-27) ALTTIME(15.44.32)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(YES)
MAXDEPTH(25000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(NORMAL) TRIGGER
TRIGTYPE(EVERY) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(ENABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(NO) NPMCLASS(NORMAL)
DEFTYPE(PREDEFINED) TYPE(QLOCAL)
SCOPE(QMGR) DEFBIND(OPEN)
IPPROCS(0) OPPROCS(1)
CURDEPTH(0)
Application owner asked the following questions:
1. Allocate queue size.
2. Allocate memory for certain queue.
3. Set priority for critical queue.
Below are my answer to those questions.
1.a Size will be predetermined by defining the message length (MAXMSGL) and message depth (MAXDEPTH) subject to disk space availibility. It's not control outside of MQ. Under normal circumtances default settings is sufficient to service the message load.
2.a MQ memory allocation handle internally which doesn't require MQ administrator to manage it. As far as I know this possibly handle by server administrator.
3.a MQ do not offer any priority setting for a certain queue. Again this might be possible for certain application with the help of server administrator.
Please advise if I do not answer them correctly as they insist on the method to handle their request.
1.q There must be a way to allocate queue size?
2.q Should be able to allocate more memory as and when required?
3.q They would like to set queues high priority setting for their online application?
4.q Will CSD13 solves this problem?
Then I also inspect the nohup.out file which sized about 184MB. Once I manage to open the text file I discovered the followings:
/gcifprod/prodexec/prprod/preqprod 'TMC 2GCIF.ELIXIR.PRQ.UPD.02 GCIF.ELIXIR.PRQ.UPD.PRT.02 /gcifprod/prodexec/prprod/preqprod /gcifprod/common/ini/ MLEP11 '
exec(): 0509-036 Cannot load program elixir because of the following errors:
0509-150 Dependent module /lib/libmqic.a(mqic.o) could not be loaded.
0509-103 The module has an invalid magic number.
End of application trigger.
exec(): 0509-036 Cannot load program exec(): 0509-036 Cannot load program elixirelixir because of the following errors:
because of the following errors:
0509-150 Dependent module 0509-150 Dependent module /lib/libmqic.a(mqic.o)/lib/libmqic.a(mqic.o) could not be loaded.
could not be loaded.
0509-103 The module has an invalid magic number.
0509-103 The module has an invalid magic number.
End of application trigger.
and also
/gcifprod/prodexec/prprod/preqprod 'TMC 2GCIF.ELIXIR.PRQ.UPD.01 GCIF.ELIXIR.PRQ.UPD.PR.D1 /gcifprod/prodexec/prprod/preqprod /gcifprod/common/ini/ MLEP11 '
called via trig Mon
got the errolog path from pra.ini file as[/gcifprod/preqerr/]
error log is been called
Printing GCIF Message Header
Message Version Number: 00000001
Source Logical ID: 100
Message Reference Number:GCF20070419018545582
User Logon ID: M0106A7
GCIF Key Prim Ac Number :010834036
Transaction Code: CIFP0002
Destination Logical ID: 004001
Record Length: 1718
Number of Record: 000001
Transaction Date: 20070419
Transaction Time: 0185455
Destn Qmgr:
Dest Queue:
Application Res Code:
System Status: 000
Error Message: Performing Resource Cleanup...
Closing the log..
End of application trigger.
Based on the info from the nohup.out file could it be derived from application program instead of the MQ trigger itself?
Thank you. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Apr 30, 2007 12:25 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's always the application, not MQ.
It looks like the program nees to be recompiled for a pure 32bit or pure 64bit environment. (Magic numbers have to do with trying to load the 32bit stuff into 64bit environments or vice versa).
Did you upgrade to v6 without recompiling application?
Also, if you need to cause a new trigger to occur, you can alter the queue twice - once to disable the trigger and once to enable the trigger.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| aahmad8 |
| Posted: Mon Apr 30, 2007 1:04 am Post subject: |
|
|
Apprentice
Joined: 12 Sep 2005
Posts: 27
Location: Malaysia
|
We're still in MQ v5.3 CSD10 for AIX i.e still in 32-bit and planning to upgrade to V6 before September, 2007. Once I upgrade all applications need to recompile? Can it remains as 32-bit application or suggest to convert to 64-bit instead for better performance etc.?
I did sometimes to initiate new trigger as your suggestion. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Apr 30, 2007 11:10 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're right, the subject said 5.3 - sorry about that.
Magic number errors still have to do with 32-bit versus 64-bit. It's not clear how you would have this issue on a v5.3 machine, unless the app team was trying to run a 64-bit app against the 32-bit MQ libraries.
You will be able to run 32-bit applications against MQ v6, you will just have to build them as 32-bit apps and use the 32-bit versions of the MQ libraries.
It's better to recompile the apps for v6, although it might not be 100% necessary.
_________________
I am *not* the model of the modern major general. |
|
| 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
|
|
|
|
