Getting MQRC_HCONN_ASYNC_ACTIVE in response logic in request / response code.

[chughts]

• mq-mqi-nodejs version(s) that are affected by this issue. bump from 1.0.5 to 2.0.3

We are migrating our code from ibmmq 1.0.5 to 2.0.3 and have hit a problem relating to a request / response application.

The problem is in the response application.

Its flow is:

mq.Connx
mq.Open
mq.Get with callback
mq.Ctl with MQC.MQOP_START
wait for a termination signal (no more messages or fatal error)

This kick-starts the async callback which starts processing the requests. All good so far.

The interesting behaviour is when responding to a request.

We got 2500 (MQRC_HCONN_ASYNC_ACTIVE) errors when opening the reply to queue, it's a temporary queue so can only be opened when processing the request. To overcome this we added in a

mq.Ctl with MQC.MQOP.SUSPEND before the open, but still got the 2500 error. Experimenting we found:

	With suspend	No suspend
Open	2500	2500
OpenSync	2500	OK

The connection is only successful if we haven't suspended the callback async callback and connect synchronously.

Then the mq.Put starting throwing a 2500, until we added in the suspend / resume around it. ie.

mq.Ctl with MQC.MQOP_SUSPEND
mq.Put
mq.Ctl with MQC.MQOP_RESUME

We did try mq.PutSync without the suspend, but still got the 2500. ie.

	With suspend	No suspend
Put	OK	2500
PutSync	OK	2500

We seem to have traversed this obstacle course, but I am not sure that we have done it right. Are these behaviours consistent with mq.Ctl ?

[ibmmqmet]

Thanks for raising this.

I've think I've got some fixes to improve the situation. So you shouldn't need to do any explicit SUSPEND/RESUME in the getCB function. In my testing, I could generate async_active problems but not on every attempt. It typically failed within a few minutes of a test run. But with the fixed version, I've had it running for a couple of hours and no issues seen.

Assuming it continues to pass tests, I'll release a 2.0.4 soon - probably next week.