Re: Use of AMQShortString in client side code

Hmm, actually those numbers don't seem right.. 12GBytes/s = 3G 32 bit words/s = 750 M 32 bit words/RAM cycle (DDR ram) My laptop should only be able to do about around 2.5 to 3G/s.. On 26/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > Interestingly, I re-ran these tests, on Linux (2.6 kern

Re: Use of AMQShortString in client side code

I think I slipped a 0 somewhere, and it is 1.2G/s per second for buffer access, and 2.5G/s for byte[] access. On 26/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > > Hmm, actually those numbers don't seem right.. > > 12GBytes/s = 3G 32 bit words/s = 750 M 32 bit words/RAM cycle (DDR ram) > > My

Re: Use of AMQShortString in client side code

Interestingly, I re-ran these tests, on Linux (2.6 kernel) on a 1.5 and 1.6jvm, on my 800Mhz laptop. On 1.5, the indexed, and relative put(byte b), methods for reading and writing to byte buffers were maybe 4 times as slow as byte[] access. Reading/writing to the array directly (or in the case of

Re: Use of AMQShortString in client side code

I am planning on doing some micro-benchmarking. Its my current project for the train ride to work ;) I did do a little bit of benchmarking on this before and found that direct buffers are slower, when you call them with the indexed access methods: *put

Re: Use of AMQShortString in client side code

On 25/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > Current situation. > > Messages -> heap buffer. > JVM takes data into a temp direct buffer (behind the scenes, this is how it > does it more or less), copies into heap buffer (of fixed size). > > Solution 1: > Messages -> direct buffer. > Wo

Re: Use of AMQShortString in client side code

On 25/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > > Sorry I don't follow. Why is this useful? Surely this introduces extra > copying in some cases? > Current situation. Messages -> heap buffer. JVM takes data into a temp direct buffer (behind the scenes, this is how it does it more or less

Re: Use of AMQShortString in client side code

On 25/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > One problem with the current M2 Java broker, is that it can be extremely > wasteful of memory. It uses (by default) 32K buffers. So if I send small > messages, I can waste up to 32K per message, because I will never fill the > buffers. I thi

Re: Use of AMQShortString in client side code

On 25/09/2007, Rupert Smith <[EMAIL PROTECTED]> wrote: > On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > > > This analysis gets a little more complicated in 0-10. In 0-10 a frame > > boundary can appear anywhere, so it isn't possible to simply wrap the > > bytes read in off the wire

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > This analysis gets a little more complicated in 0-10. In 0-10 a frame > boundary can appear anywhere, so it isn't possible to simply wrap the > bytes read in off the wire in an AMQShortString object and pass that up. > You either need t

Re: Use of AMQShortString in client side code

On 24/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > the routing key. For the headers exchange the encoding is relevant for > example. Sorry I'm talking nonsense, the headers exchange doesn't care about the encoding. RG

Re: Use of AMQShortString in client side code

On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > Surely we should be pushing to modify the protocol? > > I'm not yet convinced there is sufficient reason to modify the protocol. > Nothing in the protocol forces a *broker* to perform unicode character > conversion on the exchange nam

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: Seriously though, if we actually need to operate on chars then there is no point in casting. Short of modifying the protocol to redefine shortstr as ASCII only, that will not result in the character that the client i

Re: Use of AMQShortString in client side code

On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Seriously though, if we actually need to operate on chars then there is > no point in casting. Short of modifying the protocol to redefine > shortstr as ASCII only, that will not result in the character that the > client intended to send

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: I do mean lazily decode, however not like the AMQShortString implementation does. It currently just casts from byte to char. This only works if the string consists entirely of non extended ASCII. I was thinking more

Re: Use of AMQShortString in client side code

On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > I do mean lazily decode, however not like the AMQShortString > implementation does. It currently just casts from byte to char. This > only works if the string consists entirely of non extended ASCII. I was > thinking more along the lines

Re: Use of AMQShortString in client side code

Rafael, Thanks for those links. I see your point. On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > Rafael Schloming wrote: > > Rupert Smith wrote: > >> On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > >>> So if we were to fix AMQShortString to just use bulk put/get > ope

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: My understanding is that the two proven factors in decoding shortstrs are (1) unicode character conversion, and (2) copy via iteration rather than bulk put/get. And as far as I can see the only correct solution to (1

Re: Use of AMQShortString in client side code

Rafael Schloming wrote: Rupert Smith wrote: On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: So if we were to fix AMQShortString to just use bulk put/get operations all the time then the only issue is whether it is possible to implement an aggregating ByteBuffer with efficient bulk pu

Re: Use of AMQShortString in client side code

On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > My understanding is that the two proven factors in decoding shortstrs > are (1) unicode character conversion, and (2) copy via iteration rather > than bulk put/get. And as far as I can see the only correct solution to > (1) is a CharSequ

Re: Use of AMQShortString in client side code

Rupert Smith wrote: On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: So if we were to fix AMQShortString to just use bulk put/get operations all the time then the only issue is whether it is possible to implement an aggregating ByteBuffer with efficient bulk put/get operations, and the

Re: Use of AMQShortString in client side code

On 24/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > So if we were to fix AMQShortString to just use bulk put/get operations > all the time then the only issue is whether it is possible to implement > an aggregating ByteBuffer with efficient bulk put/get operations, and > the answer to th

Re: Use of AMQShortString in client side code

Rupert Smith wrote: Rafael, Thanks for those thoughts on the subject. On 20/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: Also, performance-wise an aggregating ByteBuffer probably wouldn't do so well since you'd have to return false/null from hasArray()/array(), and so you'd nullify the

Re: Use of AMQShortString in client side code

Rafael, Thanks for those thoughts on the subject. On 20/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > Also, performance-wise an aggregating ByteBuffer probably wouldn't do so > well since you'd have to return false/null from hasArray()/array(), and > so you'd nullify the benefit from b

Re: Use of AMQShortString in client side code

Robert Godfrey wrote: Perhaps I didn't understand your suggestion. It sounds to me like it is the same thing as doing nothing at all. The generated API would use String and there would be no copying on encode, however that still leaves the overhead of copying and unicode character conversion on d

Re: Use of AMQShortString in client side code

On 20/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Perhaps I didn't understand your suggestion. OK, now I am confused I think... > It sounds to me like it is > the same thing as doing nothing at all. No, I meant enhance the current implementation of AMQShortString to correct the weakn

Re: Use of AMQShortString in client side code

Rupert Smith wrote: Rafael, Is there much difference between your decoder that works on multiple byte buffers, and a decoder that works on a byte buffer but that could be passed a special aggregating byte buffer that pulls together several byte buffers and presents them as if they are one buffer

Re: Use of AMQShortString in client side code

> > Perhaps I didn't understand your suggestion. It sounds to me like it is > the same thing as doing nothing at all. The generated API would use > String and there would be no copying on encode, however that still > leaves the overhead of copying and unicode character conversion on > decode. It is

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 20/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: Robert Greig wrote: That depends on the details of how tokenizing would work. It's not 100% clear to me how you'd apply a generalized tokenizing scheme to AMQP as some shortstrs are intended for the broker to interpr

Re: Use of AMQShortString in client side code

Rafael, Is there much difference between your decoder that works on multiple byte buffers, and a decoder that works on a byte buffer but that could be passed a special aggregating byte buffer that pulls together several byte buffers and presents them as if they are one buffer? That is, do you thin

Re: Use of AMQShortString in client side code

On 20/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Robert Greig wrote: > That depends on the details of how tokenizing would work. It's not 100% > clear to me how you'd apply a generalized tokenizing scheme to AMQP as > some shortstrs are intended for the broker to interpret, and some > s

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: One of the previously discussed improvements for 0-11 is to define a fixed width destination or address type that can be used to efficiently represent the exchange name + routing-key (i.e. something akin to an IP add

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > One of the previously discussed improvements for 0-11 is to define a > fixed width destination or address type that can be used to efficiently > represent the exchange name + routing-key (i.e. something akin to an IP > address). I suspec

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: This is what is in the spec. I think it's the same as 0-8: Short strings, stored as an 8-bit unsigned integer length followed by zero or more octets of data. Short strings can carry up to 255 octets

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > This is what is in the spec. I think it's the same as 0-8: > > Short strings, stored as an 8-bit unsigned integer length > followed by zero or more octets of data. Short strings can > carry up to 255 octets of UTF-8 data

Re: Use of AMQShortString in client side code

Robert Godfrey wrote: On 19/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: Yes, except 0-10 adds another level of this since frames are the unit you read off of the wire, and those can't be directly parsed without aggregating them.

Re: Use of AMQShortString in client side code

On 19/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > > On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > > > Yes, except 0-10 adds another level of this since frames are the unit > > you read off of the wire, and those can't be directly parsed without > > aggregating them. > > Presum

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Yes, except 0-10 adds another level of this since frames are the unit > you read off of the wire, and those can't be directly parsed without > aggregating them. Presumably there is a size so you can pull in all the chunks before startin

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: At a minimum it would be nice if FieldTable implemented the Map interface and had a copy constructor that took a regular Map. In fact FieldTable used to be a subclass of HashMap (or AbstractMap or something like th

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > At a minimum it would be nice if FieldTable implemented the Map > interface and had a copy constructor that took a regular Map. In fact FieldTable used to be a subclass of HashMap (or AbstractMap or something like that). I cannot rememb

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > Sorry, my question really is, given that AMQShortString already > implements CharSequence, why do we need to use AMQShortString all over > the code rather than the CharSequence interface? I'm not sure. I'm inclined to say we could use C

Re: Use of AMQShortString in client side code

Robert Godfrey wrote: OK - let's try to examine this in detail... The objection to using AMQShortString is, I presume, as much aesthetic as anything else. We want to provide through the Java API a type which is natural to the Java programmer. [As an aside, I presume therefor that where the arg

Re: Use of AMQShortString in client side code

On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: > That is what I meant by converting to a String "on demand." It was the use of conditional tense that threw me since that is what we do already. RG

Re: Use of AMQShortString in client side code

Robert Greig wrote: On 19/09/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote: That is what I meant by converting to a String "on demand." It was the use of conditional tense that threw me since that is what we do already. Sorry, my question really is, given that AMQShortString already imp

Re: Use of AMQShortString in client side code

Also, consider the example of the low-level back to back client, that moves messages between brokers. It wants to do as little decoding as possible. Good reason to have lazy decoding at least at the low-level API. Rupert On 19/09/2007, Robert Greig <[EMAIL PROTECTED]> wrote: > > > >> I believe wh

Re: Use of AMQShortString in client side code

Robert Greig wrote: I believe what would be optimal is to use the CharSequence interface everywhere. This way String values passed to us by an application could be directly passed all the way down the stack and encoded directly onto the wire without an additional copy, and incoming data could be

Re: Use of AMQShortString in client side code

Yes, but if you have a new string, that may match an existing token you still have to match it? e.g. Queue queue1 = session.createQueue("test"); Queue queue2 = session.createQueue("test"); need to match "test" against the token set, to see if it has already been tokenized. (ok in this case the c

Re: Use of AMQShortString in client side code

> >> I believe what would be optimal is to use the CharSequence interface > >> everywhere. This way String values passed to us by an application could > >> be directly passed all the way down the stack and encoded directly onto > >> the wire without an additional copy, and incoming data could be >

Re: Use of AMQShortString in client side code

The idea of tokenization is to not do String matching. It is something we may try to do at AMQP... e.g. client says "From now on we should refer to the Short String 'very-very-very-very-long-in-fact-ridiculously-long-routing-key-name' as Token 1" Then, whenever it publishes a message with this

Re: Use of AMQShortString in client side code

Just for the record, when short string was introduced, there was a performance boost. I like the idea of a string mapping down onto a byte buffer, its more like how things would be done in C. That is the incoming data would not be lifted out of its frame, the string would just be a pointer into th

Re: Use of AMQShortString in client side code

OK - let's try to examine this in detail... The objection to using AMQShortString is, I presume, as much aesthetic as anything else. We want to provide through the Java API a type which is natural to the Java programmer. [As an aside, I presume therefor that where the argument is a Field Table y

Re: Use of AMQShortString in client side code

Its also a space optimisation on the wire for when we cared about that... for high volume messaging esp with TCP/IP and serial unicast those bytes start to matter. As for Tokenising, to support the notion of trivial clients the idea was to let the client assert which short strings were tokenized;

Re: Use of AMQShortString in client side code

John O'Hara wrote: I agree with Rob that the lower levels of the stack should be implemented in AMQPShortString *where it occurs in the protocol* for the following reasons: 1) It provides the opportunity to validate the semantics; just because we're not checking length today doesn't mean we shou

Re: Use of AMQShortString in client side code

I agree with Rob that the lower levels of the stack should be implemented in AMQPShortString *where it occurs in the protocol* for the following reasons: 1) It provides the opportunity to validate the semantics; just because we're not checking length today doesn't mean we shouldn't 2) We may intro

Re: Use of AMQShortString in client side code

>As the common case on the client side is dealing with Strings, I'm not at all convinced that ubiquitous use of AMQShortString > is a net win for the client. It is exactly my point. Also as I mentioned we sometimes do the asString() method in logging etc which does the String encoding every time.

Re: Use of AMQShortString in client side code

Robert Godfrey wrote: On 13/09/2007, Rajith Attapattu <[EMAIL PROTECTED]> wrote: I am wondering why we are using AMQShortString indiscriminately all over the client side code? There is no performance benefit of using AMQShortString (based on the way it is used) on the client side and is purely u

Re: Use of AMQShortString in client side code

Hello Robert, On 9/14/07, Robert Godfrey <[EMAIL PROTECTED]> wrote: > > On 13/09/2007, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > > > I am wondering why we are using AMQShortString indiscriminately all over > > the > > client side code? > > There is no performance benefit of using AMQShortStr

Re: Use of AMQShortString in client side code

On 13/09/2007, Rajith Attapattu <[EMAIL PROTECTED]> wrote: > > I am wondering why we are using AMQShortString indiscriminately all over > the > client side code? > There is no performance benefit of using AMQShortString (based on the way > it > is used) on the client side and is purely used for enc