Keyed queues are a reasonable alternative, absolutely.
The primary reason we prefer vanilla data queues is that is the way we have
always done it. Seriously. In the beginning, data queues were not near as
robust as they are now, and would reach "full" even when they had been
"relieved" of records. While the one incoming for the "service" program
must be a known name - hence limited to one - we could at least break up the
return traffic through many return queues. There was also a large speed
penalty as the number of jobs sitting on the keyed queue increased. So the
initial approach in 1993 was to use brute force and avoid features in which
we had little faith - at the time. In 1993 the design was for credit card
transaction processing, not web pages, of course - was that OS/400 V2R2??
The other issue we considered was that the MAIN "service" program was
monitored, and if it died, we would know it and it would restart. So, it's
queue filling up (however unlikely) would be a handled exception.
However, if the requester thread died or did not retrieve its record from
the ONE single return queue (keyed model), its records would become orphans,
and sit in the queue. Enough of those requesting threads die, and the queue
can fill up - certainly in the early days with small max size, and bring
down the whole process. This way, when the requester job/thread dies and
leaves the record in the queue, it has zero effect on anything. The queue
broker is smart enough to monitor the total time issued, and if a max value
is exceeded, it checks the queue back in. This way orphaned queues are not
lost for too long.
We do use keyed queues and Sender ID now in a lot of places, but still are
more comfortable with brute force for the high volume operations where we
have many hundreds of txns per minute. The overhead of the queue broker
dispatch/checkout process is about 3ms overall, since the clearing of the
queues is actually performed by another job. The dispatcher itself does not
waste time with that.
The original performance of keyed queues was marginal, and that has improved
greatly over the years.
Ira Chandler
Curbstone Corporation
Technical Services - 888-844-8533
https://curbstone.com/email_disclaimer
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Don
Brown
Sent: Wednesday, December 28, 2016 8:05 PM
To: Midrange Systems Technical Discussion
Subject: RE: Are data queues reliable?
Just curious why you could not just use two DQ's one for IN and one for OUT
and have them keyed.
With each PHP thread using a unique key portion.
Why would this not work ?
Cheers
Don Brown
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
Please contact support@xxxxxxxxxxxx for any subscription related questions.
Help support midrange.com by shopping at amazon.com with our affiliate link:
http://amzn.to/2dEadiD
midrange.com
