Possible connection/context leak in CreateContextWithSessionMode

[manheckxx]

Greetings,

we use your library in our project for communicating with queue managers and are currently experiencing some issues with error code 2391 (MQRC_SSL_ALREADY_INITIALIZED).

We have logic to attempt a reconnect when encountering certain errors and noticed that while we tried to close the connections, the connections still seemed to pile up.

I think this might be due to the way non-OK return codes are handled by this library.

As I understand, code 2391 signifies that a connection has successfully been established, albeit ignoring the provided SSL/TLS settings, re-using the configuration of an existing connection instead.

Looking at the upstream library, mq-golang, shows that

https://github.com/ibm-messaging/mq-golang/blob/2a31ece25fbfa7a78a1bb49ce4968a6eda35e68d/ibmmq/mqi.go#L259-L262

seems to possibly return both a connection and an error on a non-OK return code, but here in mq-golang-jms20

mq-golang-jms20/mqjms/ConnectionFactoryImpl.go

Lines 147 to 177 in b349e76

	if err == nil {
	// Initialize the countInc value to 1 so that if CheckCount is enabled (>0)
	// then an error check will be made after the first message - to catch any
	// failures quickly.
	countInc := new(int)
	*countInc = 1
	// Connection was created successfully, so we wrap the MQI object into
	// a new ContextImpl and return it to the caller.
	ctx = ContextImpl{
	qMgr: qMgr,
	ctxLock: &sync.Mutex{},
	sessionMode: sessionMode,
	receiveBufferSize: cf.ReceiveBufferSize,
	sendCheckCount: cf.SendCheckCount,
	sendCheckCountInc: countInc,
	}
	} else {
	// The underlying MQI call returned an error, so extract the relevant
	// details and pass it back to the caller as a JMSException
	rcInt := int(err.(*ibmmq.MQReturn).MQRC)
	errCode := strconv.Itoa(rcInt)
	reason := ibmmq.MQItoString("RC", rcInt)
	retErr = jms20subset.CreateJMSException(reason, errCode, err)
	}
	return ctx, retErr

a connection context is only returned if the return code says no errors occurred.

In my opinion, this prevents both using or closing the connection, causing a connection leak in this case.

Any thoughts on this?

[matrober-uk]

Hi @manheckxx - thanks for raising this issue, and for investigating the code behaviour that caused it 👍

I've made the necessary code update, and validated with a new testcase that reproduces the scenario you described under #73, which is now also packaged as release v1.13.0 of this library.

Please feel free to re-open this issue if you find the fix doesn't work for you.
Regards, Matt.