Rajith, could you please look into fixing that in a future release? BTW
I totally agree with your comment "
Btw I think it's quite ugly to have a user specify queue sizes in
large numbers. We should allow it to be specified in bytes, MB's and
GB.
Ex qpid.max_size=13334553 (treat it as bytes)
qpid.max_size=100MB
qpid.max_size=2GB
"
Re "We should modify the parser to try to parse it into a long if it
gets a number format exception when parsing it into an integer." I
don't know the code terribly well, but is there a good reason not to
simply parse it into a Long and be done with it? I'm not sure that
trying to parse into an Integer, catching an exception then parsing into
a Long feels all that neat. It's not really an "exceptional" case per
se, I'd have though exception handling should be reserved for
unexpected/unpredictable behaviours - IMHO of course.
Gordon, Re "No, its not a different part of the code. Also I should have
been a little more clear - the broker side bug treated the size as an
unsigned 32 bit int, rather than signed so the limit was not 2GB but
4GB. ". So does this mean that until the fix you put into 0.12 the
maximum possible size of a queue, however created, was 4GB so if I set a
limit of 6GB it was silently truncated to 4GB. Gosh I'm surprised nobody
noticed :-)
Your colleague is certainly right. All though we don't verify the
parameters, the address parse does treat it as an integer rather than
a long.
So the maximum you can specify is Integer.MAX which ~ 2GB.
Rajith
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscr...@qpid.apache.org
