| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Randomly ReasonCode 2059 with ActiveX API in Navision |
« View previous topic :: View next topic » |
| Author |
Message
|
| feri |
 Posted: Wed Nov 15, 2006 8:07 am Post subject: Randomly ReasonCode 2059 with ActiveX API in Navision |
 |
|
Newbie
Joined: 27 Mar 2006
Posts: 5
Location: Austria, Vlbg, Dornbirn
|
Hi,
first of all, we already use the MQ ActiveX API in Navision to read and write messages for some months. As the current tasks are not critical of the time, we start the job, that reads / writes the messages, just all 15 minutes. This works pretty good. 
Now we should cover a new task, where it is important, to send response messages as fast as possible.
I already created that new program and run a few tests. In principle it works, but if I start a stress test (send 1message all 10 seconds and reply immediately) I constantly get all ~10-20 messages these 2 errors in the event viewer.
| Code: |
The program could not bind to a TCP/IP socket.
The attempt to bind to socket '0' failed with return code 10048. The failing TCP/IP call was 'bind'. The most likely cause of this problem is incorrect configuration of the TCP/IP local address or incorrect start and end port parameters.
Contact the system administrator. If the problem persists contact your IBM support center.
|
| Code: |
The call to member AccessQueueManager failed. mqax200 returned the following message:
MQAX200.MQSession::AccessQueueManager CompletionCode = 2, ReasonCode = 2059, ReasonName = MQRC_Q_MGR_NOT_AVAILABLE |
Between those errors it works just fine. I don't have to restart anything.
These versions are installed:
MQManager: 5.3
MQClient: 5.3
Any suggestions? Maybe I can convince our system admin to upgrade to the newest version if that helps  .
Best Regards
feri |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Nov 15, 2006 8:19 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You may be using up all the available connections on the queue manager during your stress test, if you are running many copies of the same program that all connect and disconnect.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 15, 2006 3:43 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
For the server side try doing a receive with a time out of say 15 seconds(get with wait). You will still be serving the messages as fast as they come but not need to start a new thread / open and close the qmgr if another message is available within the wait interval...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| feri |
| Posted: Thu Nov 16, 2006 6:41 am Post subject: |
|
|
Newbie
Joined: 27 Mar 2006
Posts: 5
Location: Austria, Vlbg, Dornbirn
|
Hi,
thanks for the answers.
| Quote: |
You may be using up all the available connections on the queue manager during your stress test, if you are running many copies of the same program that all connect and disconnect.
|
There is just on program, that is running in an infinite loop, but it connects / disconnets on each loop.
I changed the program as suggested. Now there is just one connect at the beginning of the loop. Then it is connected, until someone is stopping the job.
The TCP/IP Error is gone now! 
| Quote: |
For the server side try doing a receive with a time out of say 15 seconds(get with wait). You will still be serving the messages as fast as they come but not need to start a new thread / open and close the qmgr if another message is available within the wait interval...
|
I already used a get with a wait (10 seconds).
There is a new error in the event viewer on the server. Usually it occurs all ~70 minutes. The job, that is receiving/sending the messages is setup as a windows service. Maybe it has something to do with the ram. At the start it takes ~5mb of ram. During the stress test it sometimes eats up most of the available ram  . I use commit / backout on both, reading and writing messages.
| Quote: |
The call to member CorrelationId failed. mqax200 returned the following message:
MQAX200.MQMessage::SetCorrelationId CompletionCode = 2, ReasonCode = 6111, ReasonName = MQRC_BINARY_DATA_LENGTH_ERROR
|
Regarding the documentation the length of the binary data is inconsistent. 
Best Regards
feri |
|
| Back to top |
|
|
| feri |
| Posted: Fri Nov 17, 2006 1:04 am Post subject: |
|
|
Newbie
Joined: 27 Mar 2006
Posts: 5
Location: Austria, Vlbg, Dornbirn
|
Hi,
the memory bug wasn't caused by the MQ API. As the program is setup as a service, and the loop should run as long, as the service runs, I use a external dll, to determine, if the status of the service has changed.
If the status is = 4 (Running), then it should stay in the loop, otherwise it should exit.
I check the status in each loop and this call takes always more ram. 
So it's no more MQ issue.
Thanks & Best Regards
feri |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
