Non-Message callbacks not routed correctly

[louissobel]

There's a few issues with how callbacks are routed from the single MQCALLBACK_Go entrypoint to the user-specified go callback function:

• if any connection-wide "Event Handler" callback is registered, it will get called for an event (like, say, MQRC_CONNECTION_BROKEN) once for each queue-specific callback that's also registered
• if any connection-wide "Event Handler" callback is registered, all callback-specific events requested via MQCBDO_ (like MQCBDO_START) will get routed to it rather than to the specific registered callbacks
• if no connection-wide "Event Hander" callback is registered, then all the other events (MQCBDO_START etc) get dropped.
• MQCBDO_REGISTER events could be dropped completely, as items aren't added to the cbMap structure until after the underlying CB call

The root of most of these is that the cbMap is indexed by hConn, hObj, but calltypes other than MESSAGE_REMOVED seem to omit the hObj, so the key that gets computed (https://github.com/ibm-messaging/mq-golang/blob/master/ibmmq/mqicb.go#L101) sometimes points at the wrong callback, or sometimes the fallback branch is taken when it should not be (https://github.com/ibm-messaging/mq-golang/blob/master/ibmmq/mqicb.go#L111).

One possible fix for this would be to instead index the cbMap by some opaque pointer that can be passed through the C MQCBD structure. Proof of concept here: master...louissobel:mq-golang:louis-fix-callbacks

[ibmmqmet]

I've finally had a chance to look at this. Thanks for raising it.

I believe that the underlying problem is that the MQ C client code passes events like "qmgr stopping" with the wrong hObj value of 0.

When using local bindings, the hObj is set as you'd expect. It's the real value when the callback was registered with the hObj, or 0 when the callback has been registered as a qmgr-wide function.

I suspect this is a bug in the client library, and I'll see if I can get an internal defect opened to fix it in the future. But we have to cope anyway with the currently-available library.

I think I've got a working fix now for this package. It's not the same as your PoC, but it does get the "correct" hObj passed around for both local and client connections. I'll make the fix available as part of the next release.