You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Steven Hardy <sh...@redhat.com> on 2013/02/13 09:49:22 UTC
Understanding python-qpid map size limitations
Hi,
I'm trying to understand some differences encoding map datatypes between
qpid and rabbitmq (openstack project which needs to support both)
It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
because the map appears to be encoded as a string (write_map in codec010.py)
Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
(4294967295 - 4) octets worth of encoded entries.", so I'm trying to
understand the 65535 byte limitation I'm hitting, since we do not appear to
hit the same problem when configured to use rabbit.
Can anyone please advise - is this a bug in python-qpid, or an expected
limitation of the qpid implementation?
The versions I'm using are Fedora packages:
qpid-cpp-client-0.20-2.fc17.x86_64
python-qpid-0.20-1.fc17.noarch
qpid-cpp-server-0.20-2.fc17.x86_64
Here's an example backtrace of the error-path I'm hitting:
File "/usr/lib/python2.7/site-packages/qpid/messaging/driver.py", line
1248, in send
body = enc(msg.content)
File "/usr/lib/python2.7/site-packages/qpid/messaging/message.py", line
28, in encode
sc.write_primitive(type, x)
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 73, in
write_primitive
getattr(self, "write_%s" % type.NAME)(v)
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 257, in
write_map
sc.write(string.joinfields(map(self._write_map_elem, m.keys(),
m.values()), ""))
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 250, in
_write_map_elem
sc.write_primitive(type, v)
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 73, in
write_primitive
getattr(self, "write_%s" % type.NAME)(v)
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 190, in
write_str16
self.write_vbin16(s.encode("utf8"))
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 203, in
write_vbin16
self.write_uint16(len(b))
File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 116, in
write_uint16
raise CodecException("Cannot encode %d as uint16" % n)
CodecException: Cannot encode 69525 as uint16
Any help understanding this would be much appreciated! :)
Steve Hardy
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Wed, Feb 13, 2013 at 05:38:46PM +0000, Gordon Sim wrote:
> On 02/13/2013 08:49 AM, Steven Hardy wrote:
> >Hi,
> >
> >I'm trying to understand some differences encoding map datatypes between
> >qpid and rabbitmq (openstack project which needs to support both)
> >
> >It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
> >because the map appears to be encoded as a string (write_map in codec010.py)
> >
> >Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
> >(4294967295 - 4) octets worth of encoded entries.", so I'm trying to
> >understand the 65535 byte limitation I'm hitting, since we do not appear to
> >hit the same problem when configured to use rabbit.
> >
> >Can anyone please advise - is this a bug in python-qpid, or an expected
> >limitation of the qpid implementation?
>
> I think that is a bug in python-qpid. Do you have a simple
> reproducer you could attach to a JIRA?
Not right now, but I can reproduce the problem repeatably[1], so I'm sure I can
come up with some minimal python code which demonstrates the problem fairly
easily. If you think it is a bug, I'll try to do so and raise a JIRA report.
Thanks,
Steve
[1] : https://bugs.launchpad.net/heat/+bug/1072917
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/14/2013 10:42 AM, Steven Hardy wrote:
> On Wed, Feb 13, 2013 at 05:38:46PM +0000, Gordon Sim wrote:
>> On 02/13/2013 08:49 AM, Steven Hardy wrote:
>>> Hi,
>>>
>>> I'm trying to understand some differences encoding map datatypes between
>>> qpid and rabbitmq (openstack project which needs to support both)
>>>
>>> It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
>>> because the map appears to be encoded as a string (write_map in codec010.py)
>>>
>>> Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
>>> (4294967295 - 4) octets worth of encoded entries.", so I'm trying to
>>> understand the 65535 byte limitation I'm hitting, since we do not appear to
>>> hit the same problem when configured to use rabbit.
>>>
>>> Can anyone please advise - is this a bug in python-qpid, or an expected
>>> limitation of the qpid implementation?
>>
>> I think that is a bug in python-qpid. Do you have a simple
>> reproducer you could attach to a JIRA?
>
> I've created a minimal reproducer - after looking a bit more closely, the
> limitation is that no element of the dict/map can exceed 2^16 characters, or
> the str16 encoding fails, so the limit is not based on total map size.
I wondered if that might be the issue. A str16 does have a 2^16 limit.
There is a vbin32 type in 0-10 however that could perhaps be used
(though that is considered 'opaque binary data'.
> I don't see anything in the spec specifying limits on individual map
> elements, only the total size, and as I mentioned before, this does work
> fine with rabbitmq, so I'll raise a JIRA issue.
>
> Reproduce procedure:
>
> git clone https://gist.github.com/hardys/4951857
> cd 4951857
> python reproducer.py
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Wed, Feb 13, 2013 at 05:38:46PM +0000, Gordon Sim wrote:
> On 02/13/2013 08:49 AM, Steven Hardy wrote:
> >Hi,
> >
> >I'm trying to understand some differences encoding map datatypes between
> >qpid and rabbitmq (openstack project which needs to support both)
> >
> >It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
> >because the map appears to be encoded as a string (write_map in codec010.py)
> >
> >Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
> >(4294967295 - 4) octets worth of encoded entries.", so I'm trying to
> >understand the 65535 byte limitation I'm hitting, since we do not appear to
> >hit the same problem when configured to use rabbit.
> >
> >Can anyone please advise - is this a bug in python-qpid, or an expected
> >limitation of the qpid implementation?
>
> I think that is a bug in python-qpid. Do you have a simple
> reproducer you could attach to a JIRA?
I've created a minimal reproducer - after looking a bit more closely, the
limitation is that no element of the dict/map can exceed 2^16 characters, or
the str16 encoding fails, so the limit is not based on total map size.
I don't see anything in the spec specifying limits on individual map
elements, only the total size, and as I mentioned before, this does work
fine with rabbitmq, so I'll raise a JIRA issue.
Reproduce procedure:
git clone https://gist.github.com/hardys/4951857
cd 4951857
python reproducer.py
Thanks,
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Fri, Feb 15, 2013 at 04:52:23PM +0000, Gordon Sim wrote:
> On 02/15/2013 04:39 PM, Steven Hardy wrote:
> >Aha! I've realized that if I send the contents as a nested dict (instead of
> >a dict containing a json serialized dict) the problem does not occur.
>
> So the large value was not actually a single value but a nested map?
It is a json template, provided by a user via our API, which we need to pass
(RPC via AMQP) to our orchestration engine.
I realized after your comment and looking at the spec, that with a couple of
simple modifications we can probably deserialize that json data in the API
and pass it into the RPC call as a nested map instead of a string, which
will most-likely solve our problem :)
Thanks again for your help.
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/15/2013 04:39 PM, Steven Hardy wrote:
> Aha! I've realized that if I send the contents as a nested dict (instead of
> a dict containing a json serialized dict) the problem does not occur.
So the large value was not actually a single value but a nested map?
[...]
> I'll add a comment to the JIRA ticket so it can be closed, thanks again!
Great, thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Fri, Feb 15, 2013 at 04:48:05PM +0000, Gordon Sim wrote:
> On 02/15/2013 04:39 PM, Steven Hardy wrote:
> >I still find it interesting that we don't hit this problem on rabbitmq, but
> >I guess that may have to be a mystery that can be solved another day ;)
>
> How is the message encoded in that case? Does it use an AMQP 0-9-1
> field-table? That version defines two types of strings - short
> strings and long strings, the latter can be up to 2^32.
Sorry, I'm not really sure - all I know is all our users running qpid hit
this bug[1] and all our users running rabbit do not.
I've not personally done much testing on rabbitmq, but as you point out it
seems to provide support for a different amqp version so that may well
explain the difference we are seeing.
Our code just publishes the message, so I don't have any real visibility of
what happens under-the-hood on rabbit, although obviously I've dug into qpid
a bit trying to understand this issue.
FYI here's our code which interfaces to qpid/rabbit (common to all openstack
projects):
https://github.com/openstack/heat/blob/master/heat/openstack/common/rpc/impl_qpid.py
https://github.com/openstack/heat/blob/master/heat/openstack/common/rpc/impl_kombu.py
[1] : https://bugs.launchpad.net/heat/+bug/1072917
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/15/2013 04:39 PM, Steven Hardy wrote:
> I still find it interesting that we don't hit this problem on rabbitmq, but
> I guess that may have to be a mystery that can be solved another day ;)
How is the message encoded in that case? Does it use an AMQP 0-9-1
field-table? That version defines two types of strings - short strings
and long strings, the latter can be up to 2^32.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Fri, Feb 15, 2013 at 03:50:28PM +0000, Gordon Sim wrote:
> On 02/15/2013 03:29 PM, Steven Hardy wrote:
> >Well, no - this is only addressing half of the problem - on the receiver
> >side the binary buffer gets returned to the user as a string, but it's not
> >converted back to the original format - so the message is corrupted and we
> >have no way of knowing that conversion from binary is required.
>
> You could check the size and decode anything over 2^16... but I
> agree that is not ideal. I'll consult some more on that(!)...
>
> >See my attached revised reproducer - maybe I'm missing something, but I
> >don't see how we can detect the _context_aws_creds key has been binary
> >encoded on the receiver side.
> >
> >It seems to me that the problem here is python-qpid encoding individual
> >dict/map keys - wouldn't it be better to just dump the whole dict to a
> >string (ie json),
>
> You can certainly do that. Just set the content to the original json
> string and send it.
Aha! I've realized that if I send the contents as a nested dict (instead of
a dict containing a json serialized dict) the problem does not occur.
Thanks for helping me work through this - your comment on QPID-4583 "It is
an AMQP 0-10 encoded map" made me look at the spec again, which says "The
value is encoded according to the rules defined by the type code for that
entry" - so I can see now that any string values in the dict will need to be
< 65535 bytes long, but if I send the json template as a dict it will work.
I'll add a comment to the JIRA ticket so it can be closed, thanks again!
I still find it interesting that we don't hit this problem on rabbitmq, but
I guess that may have to be a mystery that can be solved another day ;)
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Fri, Feb 15, 2013 at 03:50:28PM +0000, Gordon Sim wrote:
> On 02/15/2013 03:29 PM, Steven Hardy wrote:
> >Well, no - this is only addressing half of the problem - on the receiver
> >side the binary buffer gets returned to the user as a string, but it's not
> >converted back to the original format - so the message is corrupted and we
> >have no way of knowing that conversion from binary is required.
>
> You could check the size and decode anything over 2^16... but I
> agree that is not ideal. I'll consult some more on that(!)...
Well it seems like you can't use a size comparison, e.g in the reproducer
example the _context_aws_creds key is 69529 bytes before the conversion to
buffer(), and 278116 bytes afterwards.
> >See my attached revised reproducer - maybe I'm missing something, but I
> >don't see how we can detect the _context_aws_creds key has been binary
> >encoded on the receiver side.
> >
> >It seems to me that the problem here is python-qpid encoding individual
> >dict/map keys - wouldn't it be better to just dump the whole dict to a
> >string (ie json),
>
> You can certainly do that. Just set the content to the original json
> string and send it.
To clarify, I was suggesting that the qpid codec write|read_map functions
should do this, I don't think the user should have to worry about this type
conversion themselves
Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/15/2013 03:29 PM, Steven Hardy wrote:
> Well, no - this is only addressing half of the problem - on the receiver
> side the binary buffer gets returned to the user as a string, but it's not
> converted back to the original format - so the message is corrupted and we
> have no way of knowing that conversion from binary is required.
You could check the size and decode anything over 2^16... but I agree
that is not ideal. I'll consult some more on that(!)...
> See my attached revised reproducer - maybe I'm missing something, but I
> don't see how we can detect the _context_aws_creds key has been binary
> encoded on the receiver side.
>
> It seems to me that the problem here is python-qpid encoding individual
> dict/map keys - wouldn't it be better to just dump the whole dict to a
> string (ie json),
You can certainly do that. Just set the content to the original json
string and send it.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/15/2013 03:29 PM, Steven Hardy wrote:
> Well, no - this is only addressing half of the problem - on the receiver
> side the binary buffer gets returned to the user as a string, but it's not
> converted back to the original format - so the message is corrupted and we
> have no way of knowing that conversion from binary is required.
>
> See my attached revised reproducer - maybe I'm missing something, but I
> don't see how we can detect the _context_aws_creds key has been binary
> encoded on the receiver side.
Actually that was my mistake in the modified reproducer. It should be:
a_map[key] = buffer(str(a_map[key]))
not
a_map[key] = buffer(a_map[key])
With that change, your amplified test does not report corruption.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
Hi Gordon,
Thanks for looking at this, response below:
On Fri, Feb 15, 2013 at 02:06:05PM +0000, Gordon Sim wrote:
> On 02/14/2013 10:58 AM, Steven Hardy wrote:
> >On Wed, Feb 13, 2013 at 05:38:46PM +0000, Gordon Sim wrote:
> >>On 02/13/2013 08:49 AM, Steven Hardy wrote:
> >>>Hi,
> >>>
> >>>I'm trying to understand some differences encoding map datatypes between
> >>>qpid and rabbitmq (openstack project which needs to support both)
> >>>
> >>>It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
> >>>because the map appears to be encoded as a string (write_map in codec010.py)
> >>>
> >>>Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
> >>>(4294967295 - 4) octets worth of encoded entries.", so I'm trying to
> >>>understand the 65535 byte limitation I'm hitting, since we do not appear to
> >>>hit the same problem when configured to use rabbit.
> >>>
> >>>Can anyone please advise - is this a bug in python-qpid, or an expected
> >>>limitation of the qpid implementation?
> >>
> >>I think that is a bug in python-qpid. Do you have a simple
> >>reproducer you could attach to a JIRA?
> >
> >JIRA raised with reproducer :
> >
> >https://issues.apache.org/jira/browse/QPID-4583
>
> It turns out you can encode larger values as binary by calling
> 'buffer()' on them. E.g. with the attached patch applied to your
> reproducer the message gets sent and received without error.
>
> My view is therefore that this is not a bug, since it is indeed true
> that a string larger than 2^16 cannot be encoded as a str16, and
> there is a reasonable simple way to indicate that the value should
> be treated as binary which can then be encoded as vbin32.
>
> Do you agree?
Well, no - this is only addressing half of the problem - on the receiver
side the binary buffer gets returned to the user as a string, but it's not
converted back to the original format - so the message is corrupted and we
have no way of knowing that conversion from binary is required.
See my attached revised reproducer - maybe I'm missing something, but I
don't see how we can detect the _context_aws_creds key has been binary
encoded on the receiver side.
It seems to me that the problem here is python-qpid encoding individual
dict/map keys - wouldn't it be better to just dump the whole dict to a
string (ie json), then send the whole thing over as vbin32?
Steve
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/14/2013 10:58 AM, Steven Hardy wrote:
> On Wed, Feb 13, 2013 at 05:38:46PM +0000, Gordon Sim wrote:
>> On 02/13/2013 08:49 AM, Steven Hardy wrote:
>>> Hi,
>>>
>>> I'm trying to understand some differences encoding map datatypes between
>>> qpid and rabbitmq (openstack project which needs to support both)
>>>
>>> It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
>>> because the map appears to be encoded as a string (write_map in codec010.py)
>>>
>>> Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
>>> (4294967295 - 4) octets worth of encoded entries.", so I'm trying to
>>> understand the 65535 byte limitation I'm hitting, since we do not appear to
>>> hit the same problem when configured to use rabbit.
>>>
>>> Can anyone please advise - is this a bug in python-qpid, or an expected
>>> limitation of the qpid implementation?
>>
>> I think that is a bug in python-qpid. Do you have a simple
>> reproducer you could attach to a JIRA?
>
> JIRA raised with reproducer :
>
> https://issues.apache.org/jira/browse/QPID-4583
It turns out you can encode larger values as binary by calling
'buffer()' on them. E.g. with the attached patch applied to your
reproducer the message gets sent and received without error.
My view is therefore that this is not a bug, since it is indeed true
that a string larger than 2^16 cannot be encoded as a str16, and there
is a reasonable simple way to indicate that the value should be treated
as binary which can then be encoded as vbin32.
Do you agree?
Re: Understanding python-qpid map size limitations
Posted by Steven Hardy <sh...@redhat.com>.
On Wed, Feb 13, 2013 at 05:38:46PM +0000, Gordon Sim wrote:
> On 02/13/2013 08:49 AM, Steven Hardy wrote:
> >Hi,
> >
> >I'm trying to understand some differences encoding map datatypes between
> >qpid and rabbitmq (openstack project which needs to support both)
> >
> >It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
> >because the map appears to be encoded as a string (write_map in codec010.py)
> >
> >Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
> >(4294967295 - 4) octets worth of encoded entries.", so I'm trying to
> >understand the 65535 byte limitation I'm hitting, since we do not appear to
> >hit the same problem when configured to use rabbit.
> >
> >Can anyone please advise - is this a bug in python-qpid, or an expected
> >limitation of the qpid implementation?
>
> I think that is a bug in python-qpid. Do you have a simple
> reproducer you could attach to a JIRA?
JIRA raised with reproducer :
https://issues.apache.org/jira/browse/QPID-4583
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Understanding python-qpid map size limitations
Posted by Gordon Sim <gs...@redhat.com>.
On 02/13/2013 08:49 AM, Steven Hardy wrote:
> Hi,
>
> I'm trying to understand some differences encoding map datatypes between
> qpid and rabbitmq (openstack project which needs to support both)
>
> It seems that we hit a limit of 2^16 bytes when encoding a map on qpid,
> because the map appears to be encoded as a string (write_map in codec010.py)
>
> Looking at the amqp 0-10 spec, it says "An encoded map may contain up to
> (4294967295 - 4) octets worth of encoded entries.", so I'm trying to
> understand the 65535 byte limitation I'm hitting, since we do not appear to
> hit the same problem when configured to use rabbit.
>
> Can anyone please advise - is this a bug in python-qpid, or an expected
> limitation of the qpid implementation?
I think that is a bug in python-qpid. Do you have a simple reproducer
you could attach to a JIRA?
> The versions I'm using are Fedora packages:
> qpid-cpp-client-0.20-2.fc17.x86_64
> python-qpid-0.20-1.fc17.noarch
> qpid-cpp-server-0.20-2.fc17.x86_64
>
> Here's an example backtrace of the error-path I'm hitting:
> File "/usr/lib/python2.7/site-packages/qpid/messaging/driver.py", line
> 1248, in send
> body = enc(msg.content)
> File "/usr/lib/python2.7/site-packages/qpid/messaging/message.py", line
> 28, in encode
> sc.write_primitive(type, x)
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 73, in
> write_primitive
> getattr(self, "write_%s" % type.NAME)(v)
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 257, in
> write_map
> sc.write(string.joinfields(map(self._write_map_elem, m.keys(),
> m.values()), ""))
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 250, in
> _write_map_elem
> sc.write_primitive(type, v)
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 73, in
> write_primitive
> getattr(self, "write_%s" % type.NAME)(v)
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 190, in
> write_str16
> self.write_vbin16(s.encode("utf8"))
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 203, in
> write_vbin16
> self.write_uint16(len(b))
> File "/usr/lib/python2.7/site-packages/qpid/codec010.py", line 116, in
> write_uint16
> raise CodecException("Cannot encode %d as uint16" % n)
> CodecException: Cannot encode 69525 as uint16
>
> Any help understanding this would be much appreciated! :)
>
> Steve Hardy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org