0

I am trying to put messages on a REMOTE queue using XMS versoin 9.1. The MQ server was upgraded to 9.1 as well, but my messages aren't making it to the remote server.

var cf = factoryFactory.CreateConnectionFactory();
cf.SetIntProperty(XMSC.WMQ_CONNECTION_MODE, XMSC.WMQ_CM_CLIENT);
cf.SetStringProperty(XMSC.WMQ_HOST_NAME, _host);
cf.SetIntProperty(XMSC.WMQ_PORT, _port);
cf.SetStringProperty(XMSC.WMQ_CHANNEL, _channel);
cf.SetIntProperty(XMSC.WMQ_CLIENT_RECONNECT_OPTIONS, XMSC.WMQ_CLIENT_RECONNECT_Q_MGR);
cf.SetStringProperty(XMSC.WMQ_QUEUE_MANAGER, _managerName);

_connection = cf.CreateConnection();
_session = _connection.CreateSession(false, AcknowledgeMode.AutoAcknowledge);

in a different method...

var queue = _session.CreateQueue(queueName);
var producer = _session.CreateProducer(queue);

var msg = _session.CreateTextMessage(message);
producer.Send(msg);

I have been unable to find many examples. Is there a property on the producer that has to be set in order to write to remote queues?

Thanks in advance.

JoshMc
  • 10,239
  • 2
  • 19
  • 38
cderrick
  • 76
  • 7
  • What error do you receive? – JoshMc Dec 19 '19 at 20:14
  • None. That’s the main problem. I can see the message being sent to the server in WireShark. And if I drop the same message on the queue manually, it makes it to the forwarding server. But writing them on the queue in code doesn’t. – cderrick Dec 19 '19 at 20:57
  • Are you using try/catch to get exceptions. See this sample for example: https://github.com/ibm-messaging/mq-dev-patterns/blob/master/dotnet/dotNetPut.cs – JoshMc Dec 19 '19 at 21:19
  • Are you doing `_connection.Start()` in your code? – JoshMc Dec 19 '19 at 21:29
  • Yes to both of those. I am catching any exception and starting the connection. Like I mentioned above, I see the message going to server A in WireShark. – cderrick Dec 19 '19 at 23:24
  • Can you explain what the forwarding server is? You put it to `queueName` what ever that resolves to, is this a `QLOCAL` on the queue manager? What does `DIS QLOCAL(queueName) MONQ` show? If it shows `QMGR` then what does `DIS QMGR MONQ` show? It does not cause any further CPU usage to turn this on. All the values `HIGH`, `MEDIUM`, and `LOW` are equal and in current versions of MQ just turn on queue monitoring. With this on you can look at for example `DIS QS(queueName) TYPE(QUEUE) LPUTDATE LPUTTIME LGETDATE LGETTIME` to see the last put and get times of the actual queue. – JoshMc Dec 19 '19 at 23:33
  • My nomenclature may be incorrect, but something like this SeverA/QueueMgr/QueueA->QueueB/QueueMgrB/ServerB. The QueueType is REMOTE not LOCAL. I am trying to put messages on ServerA/QueueA and they should end up on ServerB/QueueB. – cderrick Dec 20 '19 at 00:08
  • Which queue is this "if I drop the same message on the queue manually, it makes it to the forwarding server." Do you mean if you put to the remote queue 'QueueA' it gets to the local queue 'QueueB' on the other server? – JoshMc Dec 20 '19 at 00:14
  • Yes. If I use MQ Explorer and put a message on QueueA it gets to ServerB/QueueB, but when I use the above code to write to QueueA, ServerB/QueueB never receives the message. – cderrick Dec 20 '19 at 00:16
  • Have you configured DLQ on Queue Manager A (on server A)? If yes, check if any of your messages are ending up there. – Shashi Dec 20 '19 at 00:28
  • @Shashi There is a DLQ and the messages are not going to it. – cderrick Dec 20 '19 at 00:34
  • What is the response from the qmgr to the MQPUT as shown in wireshark? 20xx type error is common. – JoshMc Dec 20 '19 at 01:07
  • Did this used to work at a version of dll or MQ less than 9.1. What was the full version number of both new 9.1.x.x and old. – JoshMc Dec 20 '19 at 01:25
  • There isn't a response error that I can find. Yes. using MQ.net and opening the queue with `MQC.MQOO_OUTPUT + MQC.MQOO_FAIL_IF_QUIESCING` it worked on version 9.0. Client and server are both at version 9.1.4 now. – cderrick Dec 20 '19 at 01:47
  • What specific 9.0.x.x version was in use before? Do you see a put date and time on the xmit queue associated with the remote queue? – JoshMc Dec 20 '19 at 02:01
  • I believe the previous version was 9.0.0, both server and client. – cderrick Dec 20 '19 at 02:04
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/204586/discussion-between-joshmc-and-cderrick). – JoshMc Dec 20 '19 at 02:05
  • Are your messages making it onto the transmission queue? For example, if you stop the sender channel, and run your program, do you see a non-zero `CURDEPTH` on the transmission queue? If yes, then start the channel, do you see any error messages in the `SENDER` end `AMQERR01.LOG`? If not, do you see any error messages in the `RCVR` end `AMQERR01.LOG`? If no messages on the transmission queue, then you should have received a non-zero reason code on your put call. – Morag Hughson Dec 20 '19 at 02:59
  • @MoragHughson Stopping the sender channel caused the queue depth to increase on the the transmission queue and there were no errors in the log. I don't have access to the receiver, it's a different company and their help is that my connection is dead. But obviously that's not possibly since manually PUTting a message gets there. – cderrick Dec 20 '19 at 19:03
  • @cderrick - that's good news to hear that the messages are at least making it to the transmission queue. So that's why you don't get a non-zero reason code since the put worked. So the problem of why it doesn't arrive on the receiver end should be reported in the receiver queue manager error log. If you are not able to ask them to tell you what that says, then you could compare the difference between the message on the XmitQ when your app puts it versus the message on the XmitQ when you put it 'manually'. Perhaps different lengths, extra headers etc. – Morag Hughson Dec 21 '19 at 06:33

1 Answers1

0

In my case the fix was to set the WMQ_TARGET_CLIENT:

queue.SetIntProperty(XMSC.WMQ_TARGET_CLIENT, XMSC.WMQ_TARGET_DEST_MQ);
cderrick
  • 76
  • 7
  • That is interesting, the messages were being received, they just had RFH2 headers which broke the receiver. I wonder why at XMS with v9.0 dlls that you were using were not sending RFH2 headers. I believe sending RFH2 headers is always the default unless you turn it off pragmatically or if you had a QALIAS with PROPCTL(NONE) pointed to your QREMOTE, or the QLOCAL had it set to NONE on the receiving side, or the SDR channel had PROPCTL(NONE). – JoshMc Dec 20 '19 at 22:49
  • When you mentioned that the queue manager you connect to was also upgraded, was it really a new queue manager where similar objects were defined? The above queue/channel properties should not be lost if the actually existing qmgr was upgraded. – JoshMc Dec 20 '19 at 22:53
  • No, it was upgraded. But I think it was working previously because we were using the MQ.net client, not the XMS client. I am guessing this `props.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_MANAGED);` set the headers correctly? – cderrick Dec 20 '19 at 23:01
  • Regular .net API does not send RFH2 headers without extra effort. RFH2 headers are default with JMS and XMS APIs. Providing the detail that the application changed as well and how would have been helpful to provide suggestions. – JoshMc Dec 20 '19 at 23:30