Wait ACKs for all messages posted by bmqtool

[syuzvinsky]

Instead of waiting for Ctrl+C in auto-posting mode, bmqtool will be counting ACKs and terminate after all posted messages are acknowledged.

[678098]

I propose to use 64 bit integer type instead for both counters, because it is possible to have int32 overflow here, especially during soak testing.

With achievable rate of 100k messages/second it will take approx 6 hours ((2**31) / 100000 / 3600 ~= 5.965) to overflow. If you reduce this stress rate by a multiple of 10 for soak testing (10k/s), it will take 60 hours to overflow which is still achievable.

Even the signed bsls::Types::Int64 should be enough here, because in practise overflow will not be achievable (almost 3 million years to overflow with signed int64 type).

[syuzvinsky]

Good catch in general!
Changing to bsl::uint64_t though, because:

1. I don't plan to store negative values there, so unsigned type is chosen;
2. ::uint64_t did not seem to be supported by C++03;
3. bsls::Types::UInt64 is a legacy type.

[678098]

I think bsl::uint64_t is a good choice, if you don't want to add a special meaning for negative values here.

Note that for bmqbrkr and related libs we preferred to use bsls::Types::... at least while we support AIX/Solaris, using bsl::uint64_t in bmqtool should be fine though

[678098]

I think it's worth to change these params types to xs:long in xsd, so the product here is less prone to overflow with "seemingly not too big" param values.

[678098]

At the same time, I am not sure if we should add more constraints for param values, like:

BSLS_ASSERT(eventsCount() >= 0);
BSLS_ASSERT(eventsCount() <= 2^31);
BSLS_ASSERT(eventSize() >= 1);
BSLS_ASSERT(eventSize() <= 2^31);

Another way, these constraints might be introduced in xsd if possible.

[dorjesinpo]

some questions

[dorjesinpo]

Why is this 'posted'? It looks like an ACK counter, regardless of what is posted. Or does it correlate GUIDs to make sure it is a valid ACK?

[syuzvinsky]

No, it does not correlate ACKs, but is there anything which can be ACKed other than posted messages?

[dorjesinpo]

There is nothing. So, the "posted' part does not carry much meaning, does it. It is just a bit confusing because one can think we have posted ACKs.
Very minor

[dorjesinpo]

Could you verify the use of shutdownGrace now? Do we still need it?

[syuzvinsky]

I will double check this with Jean-Louis and update the response after that.

[syuzvinsky]

Discussed this with Julien Bibollet.
The conclusion was that shutdownGrace was designed, and is still needed in consuming mode: some integration tests imply running several instances of the consumer, and there is some nondeterminism in how many messages each particular instance should receive, only the total number of messages is defined.
So, the test code will be waiting for a publisher to complete, and after that it will be waiting until each client stops receiving messages and terminate.
In the mean time, using shutdownGrace in a publisher thread looks rather like a hack, and counting ACKs is a better way to make sure that all messages have reached the cluster.