| Author |
Message
|
| fjb_saper |
 Posted: Tue Jul 27, 2010 7:49 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You need to check channel defaults in V7. I believe the new default is sharing up to 10 connections. This might give you those side effects. 
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jul 27, 2010 8:36 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| You need to check channel defaults in V7. I believe the new default is sharing up to 10 connections. This might give you those side effects. |
I had considered that, but let's make sure that channel connections are being established in the first place...  |
|
| Back to top |
|
|
| kumoyuki |
| Posted: Wed Jul 28, 2010 12:10 am Post subject: |
|
|
Newbie
Joined: 26 Jul 2010
Posts: 8
|
So I changed the channel "sharing conversations" value from 10 down to zero and it had no effect. I am still getting that lovely "6" for the MQHCONN returned from MQCONNX; the completion code and the reason code are always 0. I then ran the requested DISPLAY CONN and DISPLAY CHSTATUS queries (with sharing conversations set to 0 and after the second connection is established in the program) and got :
| Code: |
5724-H72 (C) Copyright IBM Corp. 1994, 2008. ALL RIGHTS RESERVED.
Starting MQSC for queue manager peer.
dis conn(*)
1 : dis conn(*)
AMQ8276: Display Connection details.
CONN(101F484C20000001)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C20000501)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C20000601)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C20000C01)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C20000D01)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C20001201)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C2063C102)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
AMQ8276: Display Connection details.
CONN(101F484C2063DE02)
EXTCONN(414D5143706565722020202020202020)
TYPE(CONN)
dis chstatus(SYSTEM.ADMIN.SVRCONN)
2 : dis chstatus(SYSTEM.ADMIN.SVRCONN)
AMQ8417: Display Channel Status details.
CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
CONNAME(192.168.107.177) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
|
The EXTCONN fields all contain the text "AMQCpeer ", for those of you that do not wish to decode the ascii.
I am back to stumped.[/code] |
|
| Back to top |
|
|
| markt |
| Posted: Wed Jul 28, 2010 12:14 am Post subject: |
|
|
Knight
Joined: 14 May 2002
Posts: 508
|
| The hconn value returned to your application code is unique within that process. If you did a second connect, then you'd get a different number. But there are no guarantees about uniqueness across processes. Any "uniqueness" is handled internally, not exposed to the application. At one time, the hconn was a pointer value. But that's not always true - it's often an index to internal arrays. |
|
| Back to top |
|
|
| kumoyuki |
| Posted: Wed Jul 28, 2010 12:41 am Post subject: |
|
|
Newbie
Joined: 26 Jul 2010
Posts: 8
|
I have to correct my assertion that I am always getting MQCC_OK/MQRC_NONE back from the MQCONNX call. I don;t know what has been fogging my mind, but I note now that on the second and subsequent calls I get MQCC_WARNING/MQRC_ALREADY_CONNECTED, so I have in fact been told by the API that it is re-using the connection.
At this point I consider it a bug in MQ that the API does not reference count the connection if it is re-using the handle. Really, that's just wrong, and really easy to fix on MQ's side.
...proceeding to finish implementing my own reference counting scheme... |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Jul 28, 2010 4:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kumoyuki wrote: |
| At this point I consider it a bug in MQ that the API does not reference count the connection if it is re-using the handle. Really, that's just wrong, and really easy to fix on MQ's side. |
Time for a PMR. Make the world a better place for future generations (and save yourself some code if it's really a quick & easy fix!).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mvic |
| Posted: Sat Jul 31, 2010 2:29 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| kumoyuki wrote: |
| At this point I consider it a bug in MQ that the API does not reference count the connection if it is re-using the handle. Really, that's just wrong, and really easy to fix on MQ's side. |
MQ does not need to reference count the HConn in this example because there is still only one reference. Your rc of MQRC_ALREADY_CONNECTED indicates you already have a connection to the named queue manager, and the HConn is returned to you. You only need to call MQDISC once to disconnect that HConn - this is another proof that there is no reference counting needed, either by your code or by MQ code.
Will shared HConns help you out here? See http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/topic/com.ibm.mq.csqzal.doc/fg12070_.htm |
|
| Back to top |
|
|
|
|
