|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
1300 character Message not transmitted |
« View previous topic :: View next topic » |
Author |
Message
|
flsb |
Posted: Wed Oct 16, 2019 1:10 am Post subject: |
|
|
Apprentice
Joined: 01 Apr 2010 Posts: 43
|
HubertKleinmanns wrote: |
When you split the message:
- Which size did these spitted messages have?
- Did it work when they where sent within one batch (e. g. 130 b and BATCHSZ 100)?
- Could you sent the bulk of splitted messages again and deliver the output of the following command before and after the transfer:
Code: |
dis chs(<your Sender channel>) all |
Some further questions:
- Does 'xxx' stand for an IP address or a host name?
- What's about the log size at your parties side? The content of "qm.ini" of your parties would be helpful.
- What's about the load on the parties side?
In Addition: I don't think, that DNS use used on a runnung channel. I assume, the DNS resolution only occurs when the channel starts. |
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size..
well, it worked in my older AIX MQ v5.3.. only stopped working after we have migrated to RHEL MQ 9.1.
here is the sender channel status
AMQ8417I: Display Channel Status details.
CHANNEL(xxx.CHANNEL) CHLTYPE(SVR)
BATCHES(706) BATCHSZ(1)
BUFSRCVD(993) BUFSSENT(993)
BYTSRCVD(28044) BYTSSENT(855449)
CHSTADA(2019-10-15) CHSTATI(16.47.36)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(xxx(1414)) CURLUWID(5F37A35DC35F6E10)
CURMSGS(0) CURRENT
CURSEQNO(2388) EXITTIME(0,0)
HBINT(300) INDOUBT(NO)
JOBNAME(0000A50A00000001) LOCLADDR(xxx(44674))
LONGRTS(999999999) LSTLUWID(5F37A35DC25F6E10)
LSTMSGDA(2019-10-16) LSTMSGTI(17.05.55)
LSTSEQNO(2388) MCASTAT(RUNNING)
MONCHL(OFF) MSGS(706)
NETTIME(0,0) NPMSPEED(FAST)
RQMNAME(qmgrxxx) SHORTRTS(10)
SECPROT(NONE) SSLCERTI( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(RUNNING) STOPREQ(NO)
SUBSTATE(MQGET) XBATCHSZ(0,0)
XMITQ(xxx.TRAN.QUEUE) XQTIME(0,0)
RVERSION(08000004) RPRODUCT(MQMM)
the XXX in conname is the IP address, not hostname.
the log size should be default at receiver's end.
we are sending only plaintext in all our messages to the parties.. the load should be low.. |
|
Back to top |
|
|
hughson |
Posted: Wed Oct 16, 2019 1:13 am Post subject: |
|
|
Padawan
Joined: 09 May 2013 Posts: 1919 Location: Bay of Plenty, New Zealand
|
flsb wrote: |
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size.. |
Isn't message length the same thing as message size? Please explain what the difference is in this context?
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
|
HubertKleinmanns |
Posted: Wed Oct 16, 2019 3:32 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
flsb wrote: |
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size.. |
The value of BYTSSENT is 855449 and the value of MSGS is 706. This means, your average message size is: 855449 / 706 = 1211.68... about 1.3 k .
flsb wrote: |
well, it worked in my older AIX MQ v5.3.. only stopped working after we have migrated to RHEL MQ 9.1. |
Should not be the difference .
flsb wrote: |
the XXX in conname is the IP address, not hostname. |
So it doesn't look like a DNS issue.
flsb wrote: |
the log size should be default at receiver's end. |
Normally these are the log defaults:
Code: |
LogDefaults:
LogPrimaryFiles=3
LogSecondaryFiles=2
LogFilePages=4096 |
This means the primary log size is: 3 * 4069 * 4k = 49152 k = 48 M
If you would send 50 messages per batch (default) with 1.3 k you would need a log space of: 50 * 1.3k = 65 k - so the log would be sufficient for these messages.
These are the minimum values (on Windows, on Linux LogFilePages is at least 64):
Code: |
LogDefaults:
LogPrimaryFiles=1
LogSecondaryFiles=1
LogFilePages=32 |
This means the minimum primary log size would be: 32 * 4k = 128 k - still enough for your messages.
flsb wrote: |
the load should be low.. |
Then I would expect no big messages on the side of the parties, which could fill the log.
You wrote, that only two parties have this problem and the others run fine. So I assume, there is somthing different on the side of the parties.
You also wrote, the log size should be default and the load should be low. Could you please verify this?
And in addition, could you please verify the values of MAXMSGL for QMgr channel and queue at the side of the parties?
Do they have an exit in place? _________________ Regards
Hubert |
|
Back to top |
|
|
HubertKleinmanns |
Posted: Wed Oct 16, 2019 3:38 am Post subject: |
|
|
Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
hughson wrote: |
flsb wrote: |
ya.. 1.3k is not really large.. but it is 1300 characters long.. im suspecting the length not the size of it.. but there is no param on message length, only on message size.. |
Isn't message length the same thing as message size? Please explain what the difference is in this context?
Cheers,
Morag |
Hmm, what's about two-byte character sets?
And what's about sending a 1300 character text as XML file?
I'm not pretty sure what "1300 characters Long" really means.
I would say:
- message length: No. of characters
- message size: No. of bytes
But according to the channel statistics - in this case - "message length" and "message size" seems to be the same. _________________ Regards
Hubert |
|
Back to top |
|
|
bruce2359 |
Posted: Wed Oct 16, 2019 7:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9409 Location: US: west coast, almost. Otherwise, enroute.
|
HubertKleinmanns wrote: |
Hmm, what's about two-byte character sets? |
"Character" is from legacy mainframe days when a byte was exactly equal to a character. There was/is a chart that depicts the hex byte 00-FF and the character that the hex represented. A x'40' is/was a blank character, for example. See Appendix I EBCDIC and Other Codes in z/Architecture Principles of Operation https://www-01.ibm.com/support/docview.wss?aid=1&uid=isg26480faec85f44e2385256d5200627dee
Decades later IBM implemented double-byte character set (DBCS) to accommodate a broader range of iconic/graphical characters.
MaxMsgLength is defined at the queue/qmgr/channel in bytes. _________________ 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 |
|
|
gbaddeley |
Posted: Wed Oct 16, 2019 3:55 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003 Posts: 2502 Location: Melbourne, Australia
|
flsb wrote: |
it is just plain text..
total 1300 characters...
default MAXMSGL is 4Mb... i don't think the message can exceed 4Mb even with headers and encryption etc..
we have tried increasing to 10mb on Qmgr, channel and queue level.. and still fail to send..
The batchsz for both channel is set to 50... we tried to set as 1 but still failed to send.. |
Message lengths and batch sizes are irrelevant. They might be contributing to the frequency of the issue, but it is not root cause. Can we move on please. _________________ Glenn |
|
Back to top |
|
|
bruce2359 |
Posted: Wed Oct 16, 2019 4:44 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008 Posts: 9409 Location: US: west coast, almost. Otherwise, enroute.
|
What channel pair type? SVR-RCVR? or SVR-RQSTR?
What starts the channel?
Please display and post the receiving end channel definition. Display and post channel-status at the receiving end. _________________ 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 |
|
|
flsb |
Posted: Wed Oct 16, 2019 6:16 pm Post subject: |
|
|
Apprentice
Joined: 01 Apr 2010 Posts: 43
|
What channel pair type?
SVR-RCVR and we even tried SDR-RCVR
Receiving end should be the default definition settings:
CHANNEL(xxx) CHLTYPE(RCVR)
ALTDATE(2019-10-01) ALTTIME(11.48.49)
BATCHSZ(50) CERTLABL( )
COMPHDR(NONE) COMPMSG(NONE)
DESCR( ) HBINT(300)
KAINT(AUTO) MAXMSGL(4194304)
MCAUSER( ) MONCHL(QMGR)
MRDATA( ) MREXIT( )
MRRTY(10) MRTMR(1000)
MSGDATA( ) MSGEXIT( )
NPMSPEED(FAST) PUTAUT(DEF)
RCVDATA( ) RCVEXIT( )
RESETSEQ(NO) SCYDATA( )
SCYEXIT( ) SENDDATA( )
SENDEXIT( ) SEQWRAP(999999999)
SSLCAUTH(REQUIRED) SSLCIPH( )
SSLPEER( ) STATCHL(QMGR)
TRPTYPE(TCP) USEDLQ(YES) |
|
Back to top |
|
|
flsb |
Posted: Wed Oct 16, 2019 6:24 pm Post subject: |
|
|
Apprentice
Joined: 01 Apr 2010 Posts: 43
|
HubertKleinmanns wrote: |
You wrote, that only two parties have this problem and the others run fine. So I assume, there is somthing different on the side of the parties.
You also wrote, the log size should be default and the load should be low. Could you please verify this?
And in addition, could you please verify the values of MAXMSGL for QMgr channel and queue at the side of the parties?
Do they have an exit in place? |
1 thing I noticed from these 2 parties are that they do NAT on their network to the MQ server.
Example,
A -> B (conname 192.168.0.1) -> NAT 192.168.0.1 to B local IP
B -> A (conname 20.20.20.1) -> NAT 20.20.20.1 to A destination IP -> A
Other parties will point to A destination IP in the conname to A
And A will point to B NAT ip and then to B local IP
But in these 2 parties, messages with shorter message length can go through in other channels
==========
No exit in place at both end and the MAXMSGL is the default value..
we have tried changing to 10Mb but still couldnt transmit through.. |
|
Back to top |
|
|
flsb |
Posted: Wed Oct 16, 2019 6:27 pm Post subject: |
|
|
Apprentice
Joined: 01 Apr 2010 Posts: 43
|
gbaddeley wrote: |
Message lengths and batch sizes are irrelevant. They might be contributing to the frequency of the issue, but it is not root cause. Can we move on please. |
i know it looks like it is pointing to a network problem instead of an MQ problem but a few factors are contradicting with one another..
1) other shorted messages can go through via other channels
2) the affected channel message can send through after splitting the message to shorted message and alter batchsz to 1
3) Wireshark and firewall logs show packets sent through
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM)
And this happened before in one of my other MQ server version 7.5 as well and that we have to route the channel to AIXMQ5.3 to go through. |
|
Back to top |
|
|
hughson |
Posted: Wed Oct 16, 2019 7:01 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013 Posts: 1919 Location: Bay of Plenty, New Zealand
|
flsb wrote: |
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM) |
I find the word "only" used in this sentence rather amusing. You have presumably changed hardware, physcial vs virtual machine, O/S type (and therefore O/S level), MQ level, and also firewall settings, network settings, and goodness knows what else.
Perhaps another way to ask this is, what haven't you changed?
My previous post on this thread suggested this is likely to be a firewall issue - have you looked into that further?
Cheers,
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
|
flsb |
Posted: Wed Oct 16, 2019 7:51 pm Post subject: |
|
|
Apprentice
Joined: 01 Apr 2010 Posts: 43
|
hughson wrote: |
flsb wrote: |
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM) |
I find the word "only" used in this sentence rather amusing. You have presumably changed hardware, physcial vs virtual machine, O/S type (and therefore O/S level), MQ level, and also firewall settings, network settings, and goodness knows what else.
Perhaps another way to ask this is, what haven't you changed?
My previous post on this thread suggested this is likely to be a firewall issue - have you looked into that further?
Cheers,
Morag |
i think the quote from AIX MQv5.3 (physical) to RHEL MQv9.1(vm) pretty much covers the changed in hardware, physical to VM, OS and MQ level.
On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out.
That is why i am pointing out the only changes done for this. |
|
Back to top |
|
|
fjb_saper |
Posted: Wed Oct 16, 2019 8:29 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003 Posts: 20702 Location: LI,NY
|
flsb wrote: |
hughson wrote: |
flsb wrote: |
The only changes from this is upgrading from AIX MQ5.3 (physical server) to RHEL MQ 9.1 (VM) |
I find the word "only" used in this sentence rather amusing. You have presumably changed hardware, physcial vs virtual machine, O/S type (and therefore O/S level), MQ level, and also firewall settings, network settings, and goodness knows what else.
Perhaps another way to ask this is, what haven't you changed?
My previous post on this thread suggested this is likely to be a firewall issue - have you looked into that further?
Cheers,
Morag |
i think the quote from AIX MQv5.3 (physical) to RHEL MQv9.1(vm) pretty much covers the changed in hardware, physical to VM, OS and MQ level.
On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out.
That is why i am pointing out the only changes done for this. |
If you haven't already done it, make sure the firewall has been opened for the correct zone at the linux/RHEL level. _________________ MQ & Broker admin |
|
Back to top |
|
|
hughson |
Posted: Wed Oct 16, 2019 9:14 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013 Posts: 1919 Location: Bay of Plenty, New Zealand
|
flsb wrote: |
On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out. |
So how have you ensured that the firewall is the same in these two completely different environments? _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
|
flsb |
Posted: Thu Oct 17, 2019 12:09 am Post subject: |
|
|
Apprentice
Joined: 01 Apr 2010 Posts: 43
|
hughson wrote: |
flsb wrote: |
On firewall side, we only change the object from the physical IP address to the VM ip address as we are changing the IP address to go out. |
So how have you ensured that the firewall is the same in these two completely different environments? |
as i've mentioned earlier..
the firewall only change on the object
example,
object MQserver from IP 192.168.0.1 (AIX MQ) to 192.168.0.2 (new RHEL MQ)
all firewall rules remain intact.. |
|
Back to top |
|
|
|
|
|
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
|
|
|
|