| Author |
Message
|
| sharons |
 Posted: Fri Mar 10, 2006 9:26 am Post subject: mqcmit does not seem to be working with .net client app |
 |
|
Newbie
Joined: 10 Mar 2006
Posts: 4
|
| I'm a mq support specialist and not a .net programmer. I'm trying to help a .net programmer who is seeing several problems that seem to be related to an mqcmit he is issuing not working. He is opening several queues (2 input, 2 output) and using the gmo/pmo options for syncpoint. He issues the commit and doesn't see any errors afterword. What happens though is if he reaches the max uncommitted messages in the queue manager (10,000) or stops the .net application all the messages that have been processed get rolled back onto the input queue. I saw the 10000 come off and 10000 go back on last night myself. I've looked at his code and see the mqget, mqput and mqcmit commands and they seem to be in the right places. Any suggestions? By the way we are at 5.3 fp11 and he's tried installing fp12 to see if it would help but the results were the same. |
|
| Back to top |
|
 |
| wschutz |
| Posted: Fri Mar 10, 2006 9:45 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Is this a client or server binding? I think you could run a API or channel comm trace to see what MQ thinks is happening under the covers (I say "I think" because I've never dealt with .net)
_________________
-wayne |
|
| Back to top |
|
|
| sharons |
| Posted: Fri Mar 10, 2006 10:05 am Post subject: |
|
|
Newbie
Joined: 10 Mar 2006
Posts: 4
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 10, 2006 11:23 am Post subject: Re: mqcmit does not seem to be working with .net client app |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| sharons wrote: |
| I've looked at his code and see the mqget, mqput and mqcmit commands and they seem to be in the right places. Any suggestions? |
Look again and verify that he actually captures the return code from the mqcmit calls (Try Catch block). Sounds to me like the mqcmit did not really work, or he doing the gets via on QM object, but issuing the mqcmit on another QM object.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| sharons |
| Posted: Fri Mar 10, 2006 11:52 am Post subject: |
|
|
Newbie
Joined: 10 Mar 2006
Posts: 4
|
| Peter, does he have to issue a separate mqcmit for each of the queues (objects) he has open? I believe he is only issuing a single commit. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Mar 10, 2006 11:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
u connect to a QM (create a QM object), and under that thingie, you open one or more queues. When you issue a commit, its done on the QM object, so all its queues are committed together.
Make sure the commit actually worked, and if he create multiple QM objects, make sure each gets its own commit.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| wschutz |
| Posted: Fri Mar 10, 2006 12:50 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
Often, a developer will swear "up and down" that they are (not) doing a certain thing. Since you have an MQ client there, running a trace in the client machine (strmqtrc) should "prove" what's happening. (again, the caveat about .net applies, but I think it should work...)
_________________
-wayne |
|
| Back to top |
|
|
| sharons |
| Posted: Fri Mar 10, 2006 3:21 pm Post subject: |
|
|
Newbie
Joined: 10 Mar 2006
Posts: 4
|
| We found the problem in one of the applications. The programmer was checking the IsOpen property of the MQManagedObject class rather than the IsConnected property of the MQQueueManager class. According to the manual MQQueueManager extends MQManagedObject. The programmer feels it is a deficiency in the library that the IsOpen property shouldn't be visible since it's not valid for MQQueueManager. I can't say because my OO programming background is very limited. They changed the code to check for OpenStatus rather than IsOpen. OpenStatus is not documented in the manual but seems to work. I recommended they go back and change the IsOpen to IsConnected to ensure that an "undocumented feature" that is removed in a later release doesn't catch them off guard. |
|
| Back to top |
|
|
| questro |
| Posted: Mon Mar 13, 2006 1:02 am Post subject: |
|
|
Newbie
Joined: 07 Mar 2006
Posts: 9
Location: Magic Land
|
The OpenStatus method will work, as things stand, but you are right in saying that this is an undocumented feature, and shouldn't be relied upon.
MQQueueManager's IsConnected is the right thing to use to determine whether the queue manager is connected or not. Perhaps the use of 'IsOpen' in the application is in some generic function which doesn't know what type of MQManagedObject it is dealing with and so downcasting it to an MQQueueManager would not be possible?
In short, I think IsOpen should only have been exposed on MQQueue, not MQManagedObject - it is one of those occassions where changing the interface would break existing applications - those that rely on being able to call 'IsOpen' on MQManagedObject (but which also rely on the MQManagedObject objects they are dealing with always being MQQueues). |
|
| Back to top |
|
|
|
|
