| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Writing a browser application and running it parallely. |
« View previous topic :: View next topic » |
| Author |
Message
|
| Vitor |
 Posted: Wed Nov 26, 2008 2:27 am Post subject: Re: The whole picture |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| hilla wrote: |
| The rates of the messages can get to 30 msgs per second at the peak and our cics system programer would like to have the means to run more than one semi-ckbr (browser application) for the times the TOR won't gave enought resources to deal with the msgs. |
Taking this into account, and messages greater than 32K, I'd stand by my design. It'll give your sys prog more control, visability and options for scaling.
Which is not to say there are not other methods. But for your situation I still prefer mine. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Nov 26, 2008 6:45 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| 30 msgs per second at the peak |
Unless your system is incredibly overloaded (CPU, I/O, central storage), I'd be surprised that a peak of 30 msgs per second would be noticed.
What performance/throughput issues is your cics sysprog seeing now that demands an application redesign?
If you want to spread the workload across a parallel sysplex, have the inbound messages arrive at a shared-queue on the CF; let your AORs pull the transactions.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Nov 26, 2008 11:22 am Post subject: Re: The whole picture |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| hilla wrote: |
Hey,
I'm about to give you the whole story so hold tight
The thing is that We wrote an alternative for the IBM DPL bridge.
We wanted the alternative code to be as similar to the native one, but to add more features: The ability to run it in a TOR+AORs system and route transaction dynamicly by CICSPLEX, add more logging possibilities, support more than 32K.
All messages arive to the same queue and each message is supposed to be read by a different transaction, that why we need the system application to browse the messages for the CIH header and start the transaction written there.
The way we implemented it, is that the transaction is connected to application program (Which was re-written to support this) which calls a number of system routines that gets the msg, builds the reply, send the msg. |
Bad design. Go back the drawing board. Have the system program call the application program/transaction and pass the information in shared storage.
| hilla wrote: |
The rates of the messages can get to 30 msgs per second at the peak and our cics system programer would like to have the means to run more than one semi-ckbr (browser application) for the times the TOR won't gave enought resources to deal with the msgs.
That's the whole story.... |
And you are having MQ do double duty. First by browsing than by reading.
If you want a faster way try following. Have MQ read the message, copy it to a different queue and pass the message identifier as you already do to the processing program. You still read twice but you have some advantages... like only 2 queues, no browsing.
Ideally refer to the dispatcher as mentioned above passing the message info in shared memory. However you need some special attention to make this thread safe and allow you to process / dispatch to multiple threads. Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bob_buxton |
| Posted: Sat Nov 29, 2008 6:26 am Post subject: |
|
|
Master
Joined: 23 Aug 2001
Posts: 266
Location: England
|
The Browse with mark function in MQ version 7 was specifically designed to allow for this type of content based dispatching.
Each dispatcher can browse the queue using the options MQGMO_BROWSE_FIRST +
MQGMO_UNMARKED_BROWSE_MSG +
MQGMO_MARK_BROWSE_CO_OP +
MQGMO_ACCEPT_TRUNCATED_MSG +
MQGMO_WAIT +
MQGMO_FAIL_IF_QUIESCING +
MQGMO_CONVERT
to get a message that hasn't been seen by any other dispatcher.
It can then start the appropriate transaction passing the unique message token of the message to the transaction which can then do a MQGET with MQMO_MATCH_MSG_TOKEN.
If for any reason the transaction backs out or does not run within the Mark Interval the mark will be released and the dispatcher will see the message again.
An alternative to using the Browse with Mark function is for the dispatcher to destructively get the message and pass it to the transaction in a CICS channel Container which avoids the overheads of two MQGETs but this approach may not be suitable for persistent messages since you would need to think about message loss in failure scenarios.
_________________
Bob Buxton
Ex-Websphere MQ Development |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Nov 29, 2008 7:31 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9471
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The rates of the messages can get to 30 msgs per second at the peak and our cics system programer would like to have the means to run more than one semi-ckbr (browser application) for the times the TOR won't gave enought resources to deal with the msgs. |
What leads you to believe that your TOR and AOR can't keep up with 30 messages per second? Are you missing SLAs now? What tuning efforts have your CICS and MVS sysprogs performed? What were the results? How were the results evaluated?
Additional layers of home-grown software to workload-balance seems to me to be an overreaction.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
