Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Connect Frequency

Status
Not open for further replies.

smpaul

Programmer
Nov 13, 2002
7
GB
Please forgive my ignorance on this as I am a complete novice to MQSeries and we have not had a chance to test out it's capabilities, this is for design considerations at this stage.

We have an application that needs to send messages to our customers MQ server. I was going to introduce a server process in our application that would cycle every 45 seconds or so to gather any messages and send them to the MQ server.

Is it advisable for me to make a connection on every 45 second cycle? Would there be timing issues of the connect?

To further complicate the issue I cannot directly use the MQSeries libraries as we have to use our application wrapped libraries which only have basic connect, write, etc functionality and no method of checking the connection.

If we can simply re-connect every 45 seconds or so without causing any MQ problems we could go ahead with this idea, I understand that it's not a good solution but in the time we have remaining it would at least give us a solution.

Thanks for listening.
 
Connect and disconnect is very costly. If you dont have many api calls that you can make from within your app as you mentioned, then why dont you just connect, get, and wait for 45 seconds and then again get in a loop to get all the messages. This would be more reasonable approach.

There are other ways too. You could for instance trigger.

But all other approaches in your particular case may not be good enough to not cause performance bottlenecks. Sicne you have to read the queue every 45 seconds which is very small.

But again. If you are not really concerned about the overhead of connect, you can do this. I meant if the additional second or so is not a problem, then you can do this. From your requirement it doesn't seem to be.

So, its your call.



Cheers
KK
 
Wow, thanks for the quick response!

Maybe should have mentioned also that our server is only ever writing to MQ, never reading in a send and forget style.

I was thinking of making an initial connection, then looping for as long as my sends are successful (including the 45 second sleep period), if I ever fail to send then I'll destroy my current MQ object and attempt to create another forcing the reconnect. Obviously I'd only attempt to send once I've established a connection.

Sound feasible?

Thanks
Steve.
 
I did notice in one of your earlier statments that you "gather" any messages after the 45 sec time period and then put them to a queue, presumably. Where do you "get" the messages from. Does this mean you are doing a conn, open, get, put, close and disc in your mq app???

If you are, then you can very well do a get and put in a loop until all messages are put. Then do a waited get until you get more messages and put again. This would not require you to code an explicit wait of 45 seconds and the messages would be put to the required queue as soon as a message arrives onto another queue(get) presumably.

But if your scenario is differnt than this, then you could just "gather" all messages put and then wait for as long as you wish and then repeat it all over again. I wouldnt do a close and disc all the time.

Since you think there could be a failure condition, i would recommend you do a put with syncpoint, so that in case of a failure situation the messages are either put or not, and you do not end up putting the same message twice or loosing one.

Hope this helps.



Cheers
KK
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top