qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Significant Headers Exchange interoperability issues noticed - was Re: JMS client skips string message properties
Date Mon, 19 Sep 2011 18:53:14 GMT
On 09/16/2011 07:08 PM, Fraser Adams wrote:
> Thanks for your support in this Gordon. I really do hope that there's an
> elegant way to make interoperability the default position. Sorry if I
> seem to be a broken record on this subject :-)

Not at all, taking the time to keep making that point is appreciated 
even if we haven't quite kept pace with the feedback!

>>> Is there any way that I can force the address string in C++/perl to be
>>> treated as Unicode in
>>> Receiver receiver = session.createReceiver(address);
> I had a look at the jira you raised, so I guess that the answer to the
> above then is no. Looks pretty down in the guts of Address string
> parsing if it's being treated as a binary. I suspect I might be getting
> away with it by the use of qpid::client in my organisation, perhaps I'll
> have to back off my pressuring to move to qpid::messaging for now -
> that's a real shame.

The only way to do this would be to directly manipulate the Address 
object and not rely on the parsing of the stringified form at least for 
those arguments.

> On the subject of Address string parsing we spoke a little while about
> maximum queue sizes and the miscellany of uint32, int32 etc. (and
> Integer in the Java AddressParser) that have caused it to be difficult
> to consistently have queue sizes larger than between 2GB or 4GB
> depending on language and where queues are created. I know 0.12 has
> fixed a lot of the broker side issues but the issue still exists in the
> Java AddressParser, do you know what the position is for the C++ and
> Python AddressParsers.

In python I don't believe there is an issue as it does not have the 
concept of different types of integer based on their size in memory. In 
c++ the values will be converted to int64 if possible. That does 
restrict the size a little over a uint64, but certainly it is not as big 
an issue as using a int/uint32.

We probably need to enhance the syntax to allow specific constructors or 
descriptors to be used to control the exact types (e.g. my_value = 
uint64(11) or my_value = 11LL etc).

>> Yes, I agree it is vital. I apologise for the frustration. I really
>> appreciate all your contributions on the list and certainly don't want
>> to drive you nuts! :-)
> No need to apologise, life would be boring if everything was easy :-D I
> wish I'd tried more of this sooner, it was looking into Jiri's problem
> that prompted me to check this out.
> Thanks again for your support and kind words about my contributions.
> *hopefully* I'll be in a position to make a proper contribution over the
> next few weeks. My Java implementation of the QMF2 API is coming along
> nicely, the core features are done and I'm at the stage of finishing off
> some of the "shinier" features such as Query subscriptions. I'd hoped to
> have it finished by now, but I only get a chance to do development at
> weekends and I've had a load going on over the last few weeks.

Look forward to it!

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org

View raw message