Author |
Message
|
tekn0wledg |
Posted: Wed Jun 25, 2003 10:22 am Post subject: never too late! |
|
|
Novice
Joined: 15 Jan 2003 Posts: 16
|
hmm, interesting.
i've managed to get around the problem myself, but rather makeshiftly. basically what i did was just pull about 30 messages at a time, and then close the connection, wait a few seconds, and resume.
it's not as efficient as i would hope, but.... it works. |
|
Back to top |
|
 |
rwa |
Posted: Thu Jun 26, 2003 1:16 am Post subject: |
|
|
Voyager
Joined: 22 Jan 2002 Posts: 76 Location: Duesseldorf/Germany
|
I also had problems with 2058 when I often did MQCONN/MQDISC calls. I could also see lots of abandon Socket-Connections waiting at the same time on the Queue Manager socket. So I assume that it takes longer for the Queue Manager to do his part of MQDISC then for the client. Also the MQDISC call does not wait for the Queue Manager to finish. If there are lots of MQCONN/MQDISC the Queue Manager is not able to answer all MQCONN calls. Therefore I got 2058's.
This is my personal experience doing a black box test on this issue.
Can somebody proof me wrong or right? |
|
Back to top |
|
 |
tekn0wledg |
Posted: Thu Jun 26, 2003 3:19 am Post subject: exactly! |
|
|
Novice
Joined: 15 Jan 2003 Posts: 16
|
i believe that is exactly what was occuring on my end as well. that is why i put the delay timers in there after x amount of messages had processed.
your reply helps to confirm my theory on that.
would it prove more beneficial to open the queue and grab x amount of messages in one call instead of using multiple MQGET statements? if so, how would i go about doing that?
ideally i could connect, grab 200 messages if they are available, disconnect and process the stored messages before going back to the queue to grab the remainder. is that feasible? |
|
Back to top |
|
 |
rwa |
Posted: Thu Jun 26, 2003 3:40 am Post subject: |
|
|
Voyager
Joined: 22 Jan 2002 Posts: 76 Location: Duesseldorf/Germany
|
Question 1)
I have not seen a MQI call for fetching multiple messages per call.
Question 2)
General rule: A program should open/close an channel ones. A program should only reconnect if the channel had gone down.
WSMQ is a message oriented middleware and designed to handle each message independently. A program should adopt this design when using the WSMQ API.
Example:
If you grab and commit 200 messages and your program failes to process them the messages are lost.
If you grab one message at a time process it and commit only if processing did not fail no messages gets lost. |
|
Back to top |
|
 |
tekn0wledg |
Posted: Thu Jun 26, 2003 4:00 am Post subject: |
|
|
Novice
Joined: 15 Jan 2003 Posts: 16
|
that is true unless you store those messages in a database, or archive file of some sort, which we do for compliance purposes.
but i still agree with what you are saying.
the problem is after a certain amount of requests, the channel returns the 2058 message. thus i close the channel after x amount of messages and re-establish the connection. it runs fine via this method, the problem is i can sometimes receive a backup of messages due to pausing here and there. |
|
Back to top |
|
 |
rwa |
Posted: Thu Jun 26, 2003 4:07 am Post subject: |
|
|
Voyager
Joined: 22 Jan 2002 Posts: 76 Location: Duesseldorf/Germany
|
A message can only be retrieved twice if the commit did not work (no matter if MQPUT autocommits or an explicit MQCMIT call is made) (also assuming no use of browse). Your program has to evalute the returncode of MQPUT/MQCMIT call be able to handle this situation properly. |
|
Back to top |
|
 |
|