On 25/03/13 20:38, Rob Godfrey wrote:
We should definitely try to address the cases where queue arguments simply
have different names. Things like ring queues are a little odd. In the
C++ broker they make a lot of sense because of the design of the persistent
store in use.
I'm not sure that it's just because of the design of the persistent
store where ring queues make sense. I'm responsible for a large
federated topology of C++ brokers and we use ring queues pretty much
everywhere (without persistence).
We need a bounded buffer architecture so we erm rejected reject policy
and are running at very high throughput so want to avoid the performance
hit of persistence and our producers are real time components so we
certainly don't want to use flow control to "push back" on the producers.
It might be a fairly "specialised" set of requirements, but I've
certainly found ring queues to be really useful indeed in our system and
would have balked (ha ha) had I not had the option of using them.
Because the design of the store in the Java Broker is so
different it makes less sense to implement them in the same way... but
having some sort of size bounded queue would make sense... and we should
aim to provide a single name for this so they can be created consistently
across the two implementations.
The impression that I got about the Java broker queues is that it wasn't
possible to specify a queue size per se but to implement "bounded"
behaviour by the use of flow control, so when the number of
messages/bytes hits a given limit the producer gets throttled. The C++
broker has added flow control from I think 0.12 - though I think the
parameters for that are messages but the Java broker limits are in bytes
(aaaarrrrggghhh).
None of this is really insurmountable, but getting the little things
right I think will ultimately make a big difference.
From a user perspective some of this comes across rather as "black
magic" the confluence wiki page that you put together describing some of
the differences isn't exactly easy to find (I found it by accident and
bookmarked it :-))
There's a bit of a common theme in my rambles isn't there :-)
Cheers,
Frase
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
