| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| AMQ9519 due to mismatched properties |
« View previous topic :: View next topic » |
| Author |
Message
|
| Techy |
 Posted: Tue Dec 07, 2004 7:11 am Post subject: AMQ9519 due to mismatched properties |
 |
|
Newbie
Joined: 29 Oct 2002
Posts: 5
|
AMQ9519 is repeatedly filling up the /var/mqm/qmgrs/xxxx/errors/AMQERR*.LOG files on one of 4 QMGRs running on a UNIX-based host. Using an MQ trace, I can see that the MQ client (probably Java) has specified the QMGR name, host and port of one QMGR on the box, but named the channel of another QMGR on the box. This matches the AMQ9519 error message. Since the MQCONN is never successful, there is no TCP/IP address information available about the client, which is most certainly failing repeatedly, though no one seems to notice or complain. I didn't find any source IP information in the trace either -- only the target QMGR address and port.
The application appears to be executed intermittently, and usually tries several times (generating multiple AMQ9519's) with each sequence of attempts. Developers have reportedly checked their .ini and properties files, but found nothing.
I tried defining the "wrong" channel name to the apparent target QMGR, hoping it would connect and give me something to look at with "display chs(*)" or "display qs(*) type(handle) all". (But of course, there's a mismatch there too, because SRVCONN points at the target QMGR, but CLNTCONN still points at the IP address and port of the "wrong" QMGR). The AMQ9519 messages stop when I do this, but there's nothing useful shows up in displays from either QMGR (neither the apparent target, nor the QMGR associated with the misdirected channel). Haven't been able to trace the AMQ9519 activity in that configuration.
Does anyone have any idea how I can identify the source of the error?
Thank you.
_________________
Cheers,
Techy |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Dec 07, 2004 7:48 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
netstat should show you the ip address of the client while the client is trying to connect...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Techy |
| Posted: Tue Dec 07, 2004 7:54 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2002
Posts: 5
|
I thought about that too. But I can't predict when the client will try again, and when it does it happens so fast, I can't capture netstat before it's already gone.
Any other ideas?
_________________
Cheers,
Techy |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 07, 2004 7:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Install the BlockIP2 exit, and block all IP addresses. Unblock until you get an error occuring... or do the same with a firewall/iptables.
Run netstat in a continuous mode, writing stuff to a log file...
Change the port the listener is on, and make every application change it's configuration. If the application causing the problem is found during this process, your issue is solved. If the application is not found, it will be failing to connect for a different reason, and might be more noticable because of it.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Techy |
| Posted: Tue Dec 07, 2004 8:33 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2002
Posts: 5
|
Thanks for your suggestions Jeff.
What is a BlockIP2 exit? I couldn't find it documented anywhere on the IBM site. Can you differentiate between ports or can you only block the host IP address (which is NOT an option on this host).
I can try netstat in continuous mode, but I'm not sure how I'd differentiate the IP address of the client that's about to connect legitimately from the one that's not, as both would be using the same target IP address and port. Developers can and do connect to both QMGRs, so even the source address is likely to be unremarkable unless it can be paired with a simultaneous AMQ9519 error or matches the host address of an unexpected test server.
Changing the listener port is not an option. The target queue manager is heavily used (lots of Java and non-Java clients on other hosts, QMGR connections, etc). It is a mid-level instance between test and production.
Maybe I can buddy-up with one of the network wizards and have them put a sniffer on it.
Thank you.
_________________
Cheers,
Techy |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 07, 2004 8:40 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
BlockIP is discussed here http://www.mqseries.net/phpBB2/viewtopic.php?t=12747
I believe it goes on a queue manager, so it would only be for the listener port that QM is using, not the entire IP address or network adapter.
A network sniffer wouldn't be a bad idea... assuming you can identify the channel name from the network traffic...
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Techy |
| Posted: Tue Dec 07, 2004 9:07 am Post subject: |
|
|
Newbie
Joined: 29 Oct 2002
Posts: 5
|
BlockIP looks pretty interesting. Thanks for the tip. I'll have to check that out in more detail, as the z/OS port is something I have a use for in the near future!
In the meantime, I think I'll try the sniffer approach and see what I can turn up that way. Thanks again for your suggestions.
_________________
Cheers,
Techy |
|
| 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
|
|
|
|
