Confirms stop working if you send > 2^63-1 msgs

[rabbitmq]

Confirms stop working if you send > 2^63-1 msgs

[michaelklishin]

Thanks for reporting. This is a limitation in both JDK and the protocol. We'll mention it in the Java client doc guide.

[rade]

I cannot fathom why you'd want to document this. At 1MHz, which is way faster than a single channel can operate, even on exotic hardware, it would take 292 thousand years to reach 2^63-1. So this is of no relevance to any user, and hence should not appear in the documentation.

[beeftornado]

This is probably what they said about Y2K, and 32 bit numbers. Although I agree that this situation is very unlikely to ever appear, if someone found a way to exploit someone's messaging APIs and flood it with messages just to overflow that long, they could cause confirms to stop working. And in the future, as processor speeds increase, it will become more realistic to hit that number. And I follow the belief that all unexpected behavior should be documented.

On May 6, 2015, at 12:46 AM, rade [email protected] wrote:

I cannot fathom why you'd want to document this. At 1MHz, which is way faster than a single channel can operate, even on exotic hardware, it would take 292 thousand years to reach 2^63-1. So this is of no relevance to any user, and hence should not appear in the documentation.

—
Reply to this email directly or view it on GitHub.

[michaelklishin]

I don't mind documenting this as an FYI and looking into handling wrap-arounds as time permits. Thank you for bringing this up, @beeftornado: no edge case is too small to report.

[michaelklishin]

The doc part of this is done (in the website repo, which is not yet open source).

[michaelklishin]

I haven't seen this issue reported elsewhere in over 1 year, so closing as not a high enough priority, at least for now.