ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Best way to wait in MQSI

Post new topic  Reply to topic
 Best way to wait in MQSI « View previous topic :: View next topic » 
Author Message
WBI_user
PostPosted: Mon Aug 13, 2001 6:33 pm    Post subject: Reply with quote

Partisan

Joined: 07 Aug 2001
Posts: 386

I am using the MQGET plug-in to get messages to merge with the original one which starts the flow. The orignal message told me the number of messages I have to get from the MQGET plugin. However there is also a time limit waiting for those messages. For example I have to get 5 messages within 2 seconds. I cannot use MQ GET Wait in the MQGET plug-in ( I was thinkimg of modifying the code) because it can results in a 10 second total wait time for 5 messages.
I am now using a compute node and a filter node to spin for 2 seconds if the MQGET plugin results in no message. I have concern about CPU cycles and stability by doing such a tight spin. The wait time can be as long as 10 seconds.
I am looking for best practice or any other suggestion on how this wait can be accomplished.


[ This Message was edited by: Kelvin Yung on 2001-08-13 19:34 ]
Back to top
View user's profile Send private message
kolban
PostPosted: Mon Aug 13, 2001 8:37 pm    Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

The MQGET plug-in node doesn't permit a get with wait by design. The idea behind MQSI is that it is stateless and non-blocking. It is an engine that responds to individual messages and should process and externalize the results as quickly as possible. Blocking within a message flow results in further messages which may arrive on the MQInput node from being processed.

From your description, it sounds very much like you could benefit from the
IA72 Aggregtaor plugin. Suggest strongly that you review the docs on that and see if it meets your needs.
Back to top
View user's profile Send private message
WBI_user
PostPosted: Wed Aug 15, 2001 9:06 pm    Post subject: Reply with quote

Partisan

Joined: 07 Aug 2001
Posts: 386

I looked at the aggregator supportPac. But the condition that I don't know how many message I have to wait for until I got the first one makes it difficult for me to use it.
I am doing a POC for an insurance company. A message containing just the policy number is used to drive a backend CICS transaction which can then start multiple CICS transactions to produce multiple messages representing the status of that policy. Such as the number of drivers, the number of vehicles, if there has been any claim....
So there is an undetermined number of messages return to a single reply to queue.
That's why I am using the MQGET node to get those replies until I timed out or got all the messages indicated by a control message being out on a separate queue.
Since messages are generated by multiple CICS transactions, The control message may come before or behind the actual reply messgaes and there is no way to assure that all reply messages will be there.
I agree with you 100% that we should not wait in MQSI. But this is a very valid requirement for this application.
Back to top
View user's profile Send private message
kolban
PostPosted: Thu Aug 16, 2001 3:38 am    Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

The classic solution for this kind of problem is to "stash" each of the response messages as a row in a database table until all the expected messages have been retrieved. When the last one has been obtained, you can then retrieve all the rows from the table and aggregate yourself. I am assuming that the control message, which I understand may arrive pre or post the last data record contains some count of the number of expected messages ...
Back to top
View user's profile Send private message
WBI_user
PostPosted: Fri Aug 17, 2001 11:04 am    Post subject: Reply with quote

Partisan

Joined: 07 Aug 2001
Posts: 386

Customer prefer not to use data base if they don't have to. I made the DB suggestion before and was reject because they feel that ODBC is slow.
Back to top
View user's profile Send private message
kolban
PostPosted: Fri Aug 17, 2001 12:33 pm    Post subject: Reply with quote

Grand Master

Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA

I used to think database stashing was too slow too but after running some low level performance tests, I was VERY pleasently surprised at just how good it is.

Lets review.... databases have been around, what, 10+ years. They are software servers optimized for efficient storage and retrieval of data. MQSI comes with a database.

Why would we neglect the use of a database without "knowing" its too slow.
Back to top
View user's profile Send private message
Mike Brady
PostPosted: Wed Sep 05, 2001 4:44 pm    Post subject: Reply with quote

Newbie

Joined: 04 Jul 2001
Posts: 8

A new timer plug-in node has just been made available as a SupportPac. This will enable you to implement a much more efficient event driven model, rather than using a Compute node in a spin as a psuedo-timer.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » Best way to wait in MQSI
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.