ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » Resolved ->MQRC_MSG_TOO_BIG_FOR_Q

Post new topic  Reply to topic Goto page 1, 2  Next
 Resolved ->MQRC_MSG_TOO_BIG_FOR_Q « View previous topic :: View next topic » 
Author Message
csmith28
PostPosted: Thu Sep 23, 2004 12:55 pm    Post subject: Resolved ->MQRC_MSG_TOO_BIG_FOR_Q Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

OK here goes, I set up this new application that wants to send messages as larges as 10meg to my MQManager running on AIX5.1.0.0, WMQ5.3.0.6. So I set everything up to have a MAXMSGL(12582912) in other words 12meg.

I modified the MQManager, the SYSTEM.DEAD.LETTER.QUEUE. I created a two new SVRCONN Channel for them, two new Local Queue's, a new Queue Remote, a new XMITQ and a new SDR/RCVR channel pair. All of these Objects have been created with MAXMSGL(12582912). I have verified this multiple times.

The plan is Application A places the 10meg message on Local Queue A.

Application B gets the message from that Queue then massages the Data places the message back on the Queue Remote destined for remote MQManager (AS/400 MQ5.2).

We have tested the functionality with a simple java program running off the Developers WorkStation and it works but every time they try to run this transaction from the actual WepSphere 4 Application Server it fails with the following error in the stdout.log for that application.

[9/23/04 9:32:07:617 PDT] 740a954b SystemOut U [2004/09/23 09:32:07,617] [ERROR] [ORB.thread.pool:2] [com.wellsfargo.mortgage.transport.jms.JMSWrapper] Linked Exception com.ibm.mq.MQException: MQJE001: Completion Code 2, Reason 2030

The only thing I can figure is the Actual Application is referencing the Wrong JMS Objects in it's property files but these Developers are beating me over the head with this 2030 MQ return code even after I have sent them the output from dis chl, dis ql, dis qmgr on all the objects they are supposed to be using proving that the MAXMSGL is set to 12 meg.

I looked through the MQSeries Using Java Manual and I couldn't find anything that indicated there were any Message Size Limitations in JMS. I don't know what else to do.

Any Idea's?
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.


Last edited by csmith28 on Fri Oct 01, 2004 7:18 am; edited 1 time in total
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Thu Sep 23, 2004 2:14 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Hi,

There are 4 steps that need to be done to allow 12MB messages :
Code:
ALTER QMGR MAXMSGL(12582912)
ALTER CHL(TESTQM_SVR.CH01) CHLTYPE(SVRCONN) MAXMSGL(12582912)
ALTER Q(APPL_TEST1) MAXMSGL(12582912)
ALTER Q(SYSTEM.DEAD.LETTER.QUEUE) MAXMSGL(12582912)

Done. Now your client application can connect to the 'TESTQM_SVR.CH01' SVRCONN channl and put messages up to 12MB in size.

Note: You ONLY need to do alter the attribute of the Dead Letter Queue if the message is coming from another queue manager (but then you would also need to do the sender & receiver channels).

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
csmith28
PostPosted: Thu Sep 23, 2004 2:31 pm    Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

RogerLacroix wrote:
Hi,

There are 4 steps that need to be done to allow 12MB messages :
Code:
ALTER QMGR MAXMSGL(12582912)
ALTER CHL(TESTQM_SVR.CH01) CHLTYPE(SVRCONN) MAXMSGL(12582912)
ALTER Q(APPL_TEST1) MAXMSGL(12582912)
ALTER Q(SYSTEM.DEAD.LETTER.QUEUE) MAXMSGL(12582912)

Done. Now your client application can connect to the 'TESTQM_SVR.CH01' SVRCONN channl and put messages up to 12MB in size.

Note: You ONLY need to do alter the attribute of the Dead Letter Queue if the message is coming from another queue manager (but then you would also need to do the sender & receiver channels).

Regards,
Roger Lacroix


<sighs> Okay like I said "I modified the MQManager, the SYSTEM.DEAD.LETTER.QUEUE."

and

"I created a two new SVRCONN Channels for them, two new Local Queue's, a new Queue Remote, a new XMITQ and a new SDR/RCVR channel pair. All of these Objects have been created with MAXMSGL(12582912). I have verified this multiple times."

I even modified the SYSTEM.DEFAULT.MODEL.QUEUE that the QCF points to as the TEMPMODEL value.

We are still getting the 2030 error.

But thanks for playing.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
RogerLacroix
PostPosted: Thu Sep 23, 2004 3:09 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada

Well, if you are absolutely sure that you altered everything correctly (that the MQ JNDI points to) then it is time for some live monitoring (since there is nothing in the MQ JNDI about message size).

First, make sure nobody is using that special svrconn channel.

Second, have the WAS app start up and have the MDB / EJB connect to the queue manager on that special channel without sending any messages. Now via either MQ Explorer or runmqsc display the channel status.

If the minimum value for the pool is set to 10 then you should see exactly 10 connections from WAS on that SVRCONN channel.

Now, have the WAS app attempt to put the large message. Watch carefully, if the ANY svrconn connections are created.

My guess is that they are connecting on a different channel. Quite possiblely, using QCF_A on startup and QCF_B when putting the large message to the queue.

Is the application using an external JNDI tree or dynamically creating it? (Yes, you can dynamically create a QCF in the Java code!!!) If the app is using an external JNDI then delete all QCFs but one then verify the channel in the QCF and restart the WAS app and see what happens.

Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter
Back to top
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Thu Sep 23, 2004 5:03 pm    Post subject: Reply with quote

Grand High Poobah

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

Is the application doing a 2 phase commit i.e. connecting in bindings mode and not in client connection mode?
Read up on using java if there is a limitation on size in bindings mode that is independent on the qmgr max msg length.

Also make sure the apps in WAS is using jndi lookup to get hold of the queue and not doing something like:
Code:
myqueue =session.createqueue("queuename");
Because if that is the case they need to cast it to MQQueue and change the parms on the queue before putting the message.
Using the session to create the queue will give it all the default attributes i.e. a maxmsglength of 4 MB.

best way =
Code:
myqueue = (Queue) ctx.lookup("myqueuename");

You will see the difference in the queue setup when you do
Code:
myqueue.getName();
as the uri contains a number of queue modifying attributes...
Enjoy
Back to top
View user's profile Send private message Send e-mail
csmith28
PostPosted: Fri Sep 24, 2004 12:21 pm    Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

RogerLacroix wrote:
Well, if you are absolutely sure that you altered everything correctly (that the MQ JNDI points to) then it is time for some live monitoring (since there is nothing in the MQ JNDI about message size).


I am sure, I have the number memorized now, I have nightmares about 12582912.

Quote:
First, make sure nobody is using that special svrconn channel.

Second, have the WAS app start up and have the MDB / EJB connect to the queue manager on that special channel without sending any messages. Now via either MQ Explorer or runmqsc display the channel status.

Can't do that. It is a shared channel.

Quote:
If the minimum value for the pool is set to 10 then you should see exactly 10 connections from WAS on that SVRCONN channel.

Now, have the WAS app attempt to put the large message. Watch carefully, if the ANY svrconn connections are created.


Usually when we test there are three instances of the SVRCONN Channel running.

Quote:
My guess is that they are connecting on a different channel. Quite possiblely, using QCF_A on startup and QCF_B when putting the large message to the queue.

There are multiple QCF entries in their Framework.xml.
Code:
 
<?xml version="1.0" encoding="UTF-8"?>^M
<configuration>^M
        <asynclistener switch="false" pool="1" ejbid="AsyncServiceFacade" messagetype="request">^M
                <jms providerurl="IIOP://Server.domain.com:8991" queue="mortgage/middleware/cs/services/mq/Q_ASYNC_REQ" connectionfactory="mortgage/middleware/cs/services/mq/QCF_CS_SERVICES"/>^M
        </asynclistener>^M
        <asynclistener switch="false" pool="1" ejbid="AsyncServiceFacade" messagetype="status">^M
                <jms providerurl="IIOP://Server.domain.com:8991" queue="mortgage/middleware/cs/services/mq/Q_ASYNCSTATUS_REQ" connectionfactory="mortgage/middleware/cs/services/mq/QCF_CS_SERVICES"/>^M
        </asynclistener>^M
        <asynclistener switch="false" pool="1" ejbid="AsyncServiceFacade" messagetype="result">^M
                <jms providerurl="IIOP://Server.domain.com:8991" queue="mortgage/middleware/cs/services/mq/Q_ASYNCRESULTS_REQ" connectionfactory="mortgage/middleware/cs/services/mq/QCF_CS_SERVICES"/>^M
        </asynclistener>^M
        ^M
        <synclistener switch="true" pool="1" ejbid="SyncServiceFacade">^M
                <jms providerurl="IIOP://Server.domain.com:8991" queue="mortgage/middleware/cs/services/mq/Q_CS_SYNC_REQ" connectionfactory="mortgage/middleware/cs/services/mq/QCF_CS_SERVICES"/>^M
        </synclistener>^M
        ^M
        <service id="USOB" ejbid="USOB" secure="false" non-secure="true">^M
                <component name="authentication" onrequest="false"/>^M
                <component name="authorization" onrequest="false"/>^M
                <component name="encryption" onrequest="false" onresponse="false"/>^M
                <component name="transformation" onrequest="false" onresponse="false"/>^M
                ^M
                <listener switch="true" pool="1" ejbid="USOB">^M
                        <jms queue="mortgage/middleware/cs/coreservices/mq/Q_UPLOAD_SOB_REQ" connectionfactory="mortgage/middleware/cs/services/mq/QCF_CS_SERVICES"/>^M
                </listener>^M
                ^M
                <properties type="static"/>^M
        </service>^M
        ^M
        <service id="CDU" secure="false" non-secure="true">^M
                <component name="authentication" onrequest="false"/>^M
                <component name="authorization" onrequest="false"/>^M
                <component name="transformation" onrequest="false" onresponse="false"/>^M
                <component name="encryption" onrequest="false" onresponse="false"/>^M
                <component name="messagepersistence" onrequest="false" onresponse="false"/>^M
                ^M
                <listener switch="true" pool="1" ejbid="CDU">^M
                        <jms queue="mortgage/middleware/cs/coreservices/mq/Q_UPLOAD_CDU_REQ" connectionfactory="mortgage/middleware/cs/coreservices/mq/QCF_CS_CORESERVICES"/>^M
                </listener>^M
^M
                <properties type="static"/>^M
        </service>^M
        ^M
        <service id="BPC" secure="false" non-secure="true">^M
                <component name="authentication" onrequest="false"/>^M
                <component name="authorization" onrequest="false"/>^M
                <component name="transformation" onrequest="true" onresponse="true"/>^M
                <component name="encryption" onrequest="false" onresponse="false"/>^M
                <component name="messagepersistence" onrequest="false" onresponse="false"/>^M
        ^M
                <reply-tos>^M
                        <reply-to client="LPS" queue="mortgage/middleware/cs/services/mq/Q_CS_LPS_REPLY"/>^M
                </reply-tos>^M
                ^M
                <properties type="static"/>^M
        </service>^M
</configuration>


the entries of concern are the CDU and those entries do exist in the appropriate CTX.


Quote:
Is the application using an external JNDI tree or dynamically creating it? (Yes, you can dynamically create a QCF in the Java code!!!) If the app is using an external JNDI then delete all QCFs but one then verify the channel in the QCF and restart the WAS app and see what happens.


external JMS/JNDI server but I can't get away with deleting the other only other QCF in that CTX, other people are using it.

Regards,
Roger Lacroix[/quote]
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.


Last edited by csmith28 on Fri Sep 24, 2004 12:39 pm; edited 2 times in total
Back to top
View user's profile Send private message
csmith28
PostPosted: Fri Sep 24, 2004 12:34 pm    Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

fjb_saper wrote:
Is the application doing a 2 phase commit i.e. connecting in bindings mode and not in client connection mode?
Read up on using java if there is a limitation on size in bindings mode that is independent on the qmgr max msg length.

Also make sure the apps in WAS is using jndi lookup to get hold of the queue and not doing something like:
Code:
myqueue =session.createqueue("queuename");
Because if that is the case they need to cast it to MQQueue and change the parms on the queue before putting the message.
Using the session to create the queue will give it all the default attributes i.e. a maxmsglength of 4 MB.

best way =
Code:
myqueue = (Queue) ctx.lookup("myqueuename");


You will see the difference in the queue setup when you do
Code:
myqueue.getName();
as the uri contains a number of queue modifying attributes...
Enjoy


The Application is connecting from a remote Server as a Client WebSphere 4.0.6. See code in post above.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Sep 24, 2004 12:40 pm    Post subject: Reply with quote

Grand High Poobah

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

To find out exactly what the properties of your qcf are, you can do following: from my poor memory
Code:
import com.ibm.mq.jms.*;
mqqcf = (MQQueueConnectionFactory) qcf;
Channel = mqqcf.getChannel();
bindings = mqqcf.getTrpType();
qmgrname = mqqcf.getQueueManager();
mqqueue = (MQQueue)queue;
maxmsglen = mqqueue.getMaxMsgLength();

etc... well you get the drift... and log the information somewhere.
Then when your transaction fails check that you had what you expected.

Enjoy
Back to top
View user's profile Send private message Send e-mail
csmith28
PostPosted: Fri Sep 24, 2004 1:14 pm    Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

fjb_saper wrote:
To find out exactly what the properties of your qcf are, you can do following: from my poor memory
Code:
import com.ibm.mq.jms.*;
mqqcf = (MQQueueConnectionFactory) qcf;
Channel = mqqcf.getChannel();
bindings = mqqcf.getTrpType();
qmgrname = mqqcf.getQueueManager();
mqqueue = (MQQueue)queue;
maxmsglen = mqqueue.getMaxMsgLength();

etc... well you get the drift... and log the information somewhere.
Then when your transaction fails check that you had what you expected.

Enjoy


Forgive my ignorance, I am not sure what you mean... I am learning this Java Stuff as I go along. Do you want me to add these entries in the above xml file or...
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Sep 24, 2004 1:59 pm    Post subject: Reply with quote

Grand High Poobah

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

No this is additional coding that should allow you to check exactly what objects are being returned by your JNDI.

I realize it applies more to the sending side than to an MDB but the spirit is the same.

If it fails and it does you need to inspect the object. Can't do it in debug mode but have to log (WAS). This is how you do it.

Make sure you use the right jndi lookups for the queue you put the MDB on...

Have fun
Back to top
View user's profile Send private message Send e-mail
csmith28
PostPosted: Fri Sep 24, 2004 2:52 pm    Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

fjb_saper wrote:
No this is additional coding that should allow you to check exactly what objects are being returned by your JNDI.

I realize it applies more to the sending side than to an MDB but the spirit is the same.

If it fails and it does you need to inspect the object. Can't do it in debug mode but have to log (WAS). This is how you do it.

Make sure you use the right jndi lookups for the queue you put the MDB on...

Have fun


Once again, I am not sure what you mean or what you are trying to say. Where does this coding go?

Here are the JMS Objects I created and they all point to MQObjects that have been Modified to accept 12meg messages.
Code:

InitCtx/mortgage/middleware/cs/coreservices/mq>

QCF(QCF_CS_CORESERVICES)
    FAILIFQUIESCE(YES)
    HOSTNAME(server.domain.com)
    PORT(1414)
    QMANAGER(TEST01)
    USECONNPOOLING(YES)
    CCSID(819)
    TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
    MSGBATCHSZ(10)
    TRANSPORT(CLIENT)
    SYNCPOINTALLGETS(NO)
    TEMPQPREFIX()
    MSGRETENTION(YES)
    RESCANINT(5000)
    POLLINGINT(5000)
    LOCALADDRESS()
    VERSION(2)
    CHANNEL(MR.TEST01.CSCS.CL01)
This is the channel that the application is initiall supposed to place the 10meg message on.  It's MAXMSGL is 12582912

Q(Q_UPLOAD_CDU_REQ)
    FAILIFQUIESCE(YES)
    QUEUE(MR.UPLOADCDUSERVICE.REQ.WH.QA01)
    QMANAGER(TEST01)
    PERSISTENCE(APP)
    CCSID(1208)
    TARGCLIENT(JMS)
    ENCODING(NATIVE)
    PRIORITY(APP)
    EXPIRY(APP)
    VERSION(1)
This object points to the QA that points to a QL on TEST01 where the message waits to be picked up by the second application.  MAXMSGL(12592912)

QCF(QCF_AS400CDU_BACKEND)
    FAILIFQUIESCE(YES)
    HOSTNAME(server.domain.com)
    PORT(1414)
    QMANAGER(TEST01)
    USECONNPOOLING(YES)
    CCSID(819)
    TEMPMODEL(SYSTEM.DEFAULT.MODEL.QUEUE)
    MSGBATCHSZ(10)
    TRANSPORT(CLIENT)
    SYNCPOINTALLGETS(NO)
    TEMPQPREFIX()
    MSGRETENTION(YES)
    RESCANINT(5000)
    POLLINGINT(5000)
    LOCALADDRESS()
    VERSION(2)
    CHANNEL(MR.TEST01.CDU.CL01)
This QCF points to the channel the second application is supposed to use to get the message from the QL that Q_UPLOAD_CDU_REQ point too.  This channel is then used to put the message on the following Q.

Q(Q_AS400CDU_REQUEST)
    FAILIFQUIESCE(YES)
    QUEUE(MR.AS400CDU.REQUEST.WH.QA01)
    QMANAGER(TEST01)
    PERSISTENCE(APP)
    CCSID(1208)
    TARGCLIENT(JMS)
    ENCODING(NATIVE)
    PRIORITY(APP)
    EXPIRY(APP)
    VERSION(1)
This Q points to a QA with a QR Target that sends the message to the remote MQManager on the AS/400 via a dedicated XMITQ SDR/RCVR channel pair.  Once again all of these objects have MAXMSGL(12582912)

Q(Q_AS400CDU_REPLY)
    FAILIFQUIESCE(YES)
    QUEUE(MR.AS400CDU.REPLY.WH.QA01)
    QMANAGER(TEST01)
    PERSISTENCE(APP)
    CCSID(1208)
    TARGCLIENT(JMS)
    ENCODING(NATIVE)
    PRIORITY(APP)
    EXPIRY(APP)
    VERSION(1)
The application uses this Q targets a QA that points to a QL and is used along with Q_UPLOAD_CDU_REQ to get the reply message from the remote AS/400 MQManager.  MAXMSGL(12582912)

It has also been confirmed that the MQObjects on the AS/400 have also been modified to accept 12meg messages.

NOTE: MQManager Name and Hostnames have been modified to preserve security.

_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Fri Sep 24, 2004 3:51 pm    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7722

I hesitate to mention this, bucause I doubt you are the first person in the world trying to put a big message in JMS, but, if F.J. suggestion turn up nothing, and since you have tried everything else...

In the 5.3 CSD05 version of the .NET classes, I found a bug that limited the size of the message to 4 MEG. I was going round and round, just like you, trying to convince anyone that would listen that all the MQ properties were set to 10 MEG, and it turned out to be a bug. Is it possible that you have found something similar in your particular verion of JMS?

One more thing. You did double check that you have 12582912 everywhere, right. And not 1258912 or something inadvertantly in one of the properties? Probably not, but it sounds like you got 12582912 burned into your contact admin, and maybe you missed the missing digit in one spot?

I feel your pain. Like you don't have anything better to do than debug a developer's JMS app....
_________________
Peter Potkay
Keep Calm and MQ On
Back to top
View user's profile Send private message
csmith28
PostPosted: Fri Sep 24, 2004 4:47 pm    Post subject: Reply with quote

Grand Master

Joined: 15 Jul 2003
Posts: 1196
Location: Arizona

@PeterPotkay

Both the MQJava Client Server and the Server that hosts the MQManager are running 5.3.0.6 but then, it could still be a Bug.

Quote:
You did double check that you have 12582912 everywhere, right. And not 1258912 or something inadvertantly in one of the properties?


Yes, over and over and over and over and over..... Note I do not have access to the Remote MQManager on the AS/400 but my understanding is that if my MQManager is configured properly and the Remote Destination MQManager is not then the large message would end up on my SYSTEM.DEAD.LETTER.QUEUE.

But just so you can see:

Quote:

$ uname -a
AIX servername 1 5 000FB12F4C00

# dspmq
QMNAME(TEST01) STATUS(Running)

# mqver
Name: WebSphere MQ
Version: 530.6 CSD06
CMVC level: p530-06-L040211
BuildType: IKAP - (Production)

1 : dis qmgr MAXMSGL
AMQ8408: Display Queue Manager details.
QMNAME(TEST01) MAXMSGL(12582912)

1 : dis ql(system.dead.letter.queue) MAXMSGL
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEAD.LETTER.QUEUE) MAXMSGL(12582912)

1 : dis qmodel(system.default.model.queue) MAXMSGL
AMQ8409: Display Queue details.
QUEUE(SYSTEM.DEFAULT.MODEL.QUEUE) MAXMSGL(12582912)

1 : dis chl(SYSTEM.DEF.SVRCONN) MAXMSGL
AMQ8414: Display Channel details.
CHANNEL(SYSTEM.DEF.SVRCONN) MAXMSGL(12582912)

1 : dis ql(MR.TEST.TEST01.UPLOADCDUSERVICE.REQ.WH.QL01) MAXMSGL
AMQ8409: Display Queue details.
QUEUE(MR.TEST.TEST01.UPLOADCDUSERVICE.REQ.WH.QL01)
MAXMSGL(12582912)

1 : dis chl(MR.TEST01.CSCS.CL01) MAXMSGL
AMQ8414: Display Channel details.
CHANNEL(MR.TEST01.CSCS.CL01) MAXMSGL(12582912)

1 : dis chl(MR.TEST01.CDU.CL01) MAXMSGL
AMQ8414: Display Channel details.
CHANNEL(MR.TEST01.CDU.CL01) MAXMSGL(12582912)

1 : dis ql(MR.TEST.TEST01.TO.REMOTE_AS/400_MQManager.WH.QX02) MAXMSGL
AMQ8409: Display Queue details.
QUEUE(MR.TEST.TEST01.TO.REMOTE_AS/400_MQManager.WH.QX02) MAXMSGL(12582912)

1 : dis ql(MR.TEST.TEST01.AS400CDU.REPLY.WH.QL01) MAXMSGL
AMQ8409: Display Queue details.
QUEUE(MR.TEST.TEST01.AS400CDU.REPLY.WH.QL01)
MAXMSGL(12582912)

: dis chl(MR.TEST01.REMOTE_AS/400_MQManager.CH02) MAXMSGL
AMQ8414: Display Channel details.
CHANNEL(MR.TEST01.REMOTE_AS/400_MQManager.CH02) MAXMSGL(12582912)

1 : dis chl(MR.REMOTE_AS/400_MQManager.TEST01.CH02) MAXMSGL
AMQ8414: Display Channel details.
CHANNEL(MR.REMOTE_AS/400_MQManager.TEST01.CH02) MAXMSGL(12582912)


MQManager names have been changed for security reasons.

At this point I do not believe that there is anything I can do as an MQSeries Admin to further facilitate this applications ability to place a message larger than 4meg on my MQManager. It has to be an issue on the Client Server, the application properties or...... I don't know.

I have forwarded all suggestions posted here to the application group and I am grateful for the input. It is their problem now...
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Sat Sep 25, 2004 1:13 pm    Post subject: Reply with quote

Grand High Poobah

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

csmith28:

I see you only sharing setup stuff. However there is no way to know whether or not this is implemented correctly at runtime. Could be something as easy as pointing to the wrong .bindings file....

The only way to know for sure what is happening at runtime is:
a) inspect the code of the app / WAS setup to make sure the right stuff is being looked at...
b) create some kind of servlet that will give you some answers, hence the code I posted above. Running that servlet should then allow you to inspect a number of attributes at runtime and see if you are really getting what you expect.

Like I said some java/JMS apps are creating a queue using :
Code:
String queuename = "myqueue";
myqueue = session.createQueue(queuename);
instead of
Code:
myqueue=(Queue)context.lookup(queuename);

I believe that using the session.createQueue method you get a queue handle but all the caracteristics for that queue are default. Not exactly what you are looking for ... right ?

Also I seem to remember reading somewhere that a bindings connection would not handle the size of message you are trying to use. You'd possibly have to use a client connection. Now If I could just remember where I read it.... No matter from your setup info you are using a client connection anyway...

Finally the assumption is that the file system and log will be able to handle a message this big...

This pain is still a long way from fading...
Back to top
View user's profile Send private message Send e-mail
siliconfish
PostPosted: Sat Sep 25, 2004 9:15 pm    Post subject: Reply with quote

Master

Joined: 12 Aug 2002
Posts: 203
Location: USA

I am not sure if this helps but u can try this

If you are using the embedded JMS pubsub engine (WEMPS) which comes with WebSphere Application Server

ALTER CHANNEL(WAS.JMS.SVRCONN) CHLTYPE(SVRCONN) MAXMSGL(12582912)
ALTER QL(SYSTEM.BROKER.DEFAULT.STREAM) MAXMSGL(12582912)
ALTER QL(SYSTEM.JMS.ND.SUBSCRIBER.QUEUE) MAXMSGL(12582912) ALTER QL(SYSTEM.JMS.ND.CC.SUBSCRIBER.QUEUE)MAXMSGL(12582912)
ALTER QMODEL(SYSTEM.JMS.MODEL.QUEUE)MAXMSGL(12582912)
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » General IBM MQ Support » Resolved ->MQRC_MSG_TOO_BIG_FOR_Q
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
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.