Re: [java] Message codec improvements

2015-02-20 Thread Robbie Gemmell
On 20 February 2015 at 03:57, Rajith Muditha Attapattu rajit...@gmail.com wrote: Most of the things I'd consider most awkward about about the current codebase have little to do with the Message, but rather all the stuff you need before you get that far. Changing or improving Message or any of

Re: [java] Message codec improvements

2015-02-19 Thread Robbie Gemmell
On 19 February 2015 at 04:22, Rafael Schloming r...@alum.mit.edu wrote: On Wed, Feb 18, 2015 at 3:58 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Setting the message body for an o.a.q.proton.message.Message is slightly awkward. You have to create a AmqpValue. AmqpSequence or a

Re: [java] Message codec improvements

2015-02-19 Thread Rajith Muditha Attapattu
Most of the things I'd consider most awkward about about the current codebase have little to do with the Message, but rather all the stuff you need before you get that far. Changing or improving Message or any of the public API's is not the focus for me. But while working on the type handling

Re: [java] Message codec improvements

2015-02-19 Thread Rajith Muditha Attapattu
On Thu, Feb 19, 2015 at 5:41 AM, Robbie Gemmell robbie.gemm...@gmail.com wrote: On 19 February 2015 at 04:22, Rafael Schloming r...@alum.mit.edu wrote: On Wed, Feb 18, 2015 at 3:58 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Setting the message body for an

Re: [java] Message codec improvements

2015-02-18 Thread Rajith Muditha Attapattu
Setting the message body for an o.a.q.proton.message.Message is slightly awkward. You have to create a AmqpValue. AmqpSequence or a Data object that encapsulates the underlying data type. Given that one of our goals is to expose an API that works with standard Java types instead of AMQP defined

Re: [java] Message codec improvements

2015-02-18 Thread Rafael Schloming
On Wed, Feb 18, 2015 at 3:58 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Setting the message body for an o.a.q.proton.message.Message is slightly awkward. You have to create a AmqpValue. AmqpSequence or a Data object that encapsulates the underlying data type. Given that one of

Re: [java] Message codec improvements

2015-02-02 Thread Rafael Schloming
Overall I think this is a good direction. I made a bunch of more detailed comments on the patch. --Rafael On Mon, Feb 2, 2015 at 1:42 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, further to our discussion I have posted a patch to illustrate the approach we plan to take. This

Re: [java] Message codec improvements

2015-02-02 Thread Rajith Muditha Attapattu
Rafi, further to our discussion I have posted a patch to illustrate the approach we plan to take. This should enable me to make progress until you get a chance to make further changes on the Decoder side. Regards, Rajith On Thu, Jan 29, 2015 at 3:59 PM, Rajith Muditha Attapattu

Re: [java] Message codec improvements

2015-01-29 Thread Rajith Muditha Attapattu
Rafi could u pls answer the two questions I had in the code? 1. Your uint method only takes an int .. shouldn't it take a long? Bcos it could contain a value larger than a java int? 2. What should I use for boolean? there is no getBoolean .. or an equivalent method Regards, Rajith On Wed, Jan

Re: [java] Message codec improvements

2015-01-29 Thread Rafael Schloming
On Thu, Jan 29, 2015 at 12:28 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi could u pls answer the two questions I had in the code? 1. Your uint method only takes an int .. shouldn't it take a long? Bcos it could contain a value larger than a java int? To be honest I don't

Re: [java] Message codec improvements

2015-01-29 Thread Rajith Muditha Attapattu
More questions. For all the maps we return should we restrict them to String, Object or should it be Object, Object ? Technically one could use a Number (int, long) etc as a key.. Any opinion here? ;) On Thu, Jan 29, 2015 at 12:48 PM, Rafael Schloming r...@alum.mit.edu wrote: On Thu, Jan 29,

Re: [java] Message codec improvements

2015-01-28 Thread Rajith Muditha Attapattu
Rafi, I just checked in some skeleton code to explore a particular approach. It avoids the intermediate objects we have in proton now (Ex FlowType.java) Instead the Flow class is directly used by the encoding/decoding layer. The Flow class uses java types as opposed to AMQP specific types, which

Re: [java] Message codec improvements

2015-01-28 Thread Rafael Schloming
On Wed, Jan 28, 2015 at 2:01 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, I just checked in some skeleton code to explore a particular approach. It avoids the intermediate objects we have in proton now (Ex FlowType.java) Instead the Flow class is directly used by the

Re: [java] Message codec improvements

2015-01-27 Thread Rafael Schloming
My inclination here would be to keep things simple. One of the more annoying aspects of working on the Java code is dealing with the fact that all the AMQP performatives use an entirely different type system. I would start out with developing a plain and simple POJO representation for all the

Re: [java] Message codec improvements

2015-01-23 Thread Rajith Muditha Attapattu
Given the existing encorder was not put behind any sort of interface (the impl is directly used), it's proving to be a PIA to track down all the different types and changing them to use the new codec. Look at the public static void register(Decoder decoder, EncoderImpl encoder) method of any of

Re: [java] Message codec improvements

2015-01-19 Thread Rajith Muditha Attapattu
Rafi, Could you please explaining your approach to using the AbstractEncoder with respect to starting and ending a frame. Looking at the code it wasn't immediately clear to me on how you intended to use this. A quick code example will be quite useful. Regards, Rajith On Thu, Jan 15, 2015 at

Re: [java] Message codec improvements

2015-01-15 Thread Rajith Muditha Attapattu
Rafi, Do you have a JIRA for this work? Regards, Rajith On Wed, Jan 14, 2015 at 6:35 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, I had a closer look at the code, put it on trunk and ran your benchmark. I see quite an improvement with respect to writing lists, maps and

Re: [java] Message codec improvements

2015-01-15 Thread Rafael Schloming
I don't believe there is an existing one. --Rafael On Thu, Jan 15, 2015 at 3:10 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, Do you have a JIRA for this work? Regards, Rajith On Wed, Jan 14, 2015 at 6:35 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi,

Re: [java] Message codec improvements

2015-01-14 Thread Rajith Muditha Attapattu
Rafi, I had a closer look at the code, put it on trunk and ran your benchmark. I see quite an improvement with respect to writing lists, maps and strings. Simply put the writeList and writeMap methods in the old encorder is about ~10 times slower than the new encorder. If I run with a

Re: [java] Message codec improvements

2015-01-06 Thread Rajith Muditha Attapattu
Thanks Rafi, for the link. I agree that any work should use this as a basis. I plan to take a closer look at this in the next week or so. Rajith On Wed, Dec 17, 2014 at 1:24 PM, Rafael Schloming r...@alum.mit.edu wrote: A while back I implemented a relatively complete standalone codec here:

Re: [java] Message codec improvements

2014-12-17 Thread Rafael Schloming
A while back I implemented a relatively complete standalone codec here: https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 It's quite a bit faster than the existing codec. I believe any new codec work should probably be based on this. It's

[java] Message codec improvements

2014-12-15 Thread Rajith Muditha Attapattu
I'm starting to look at improving this areas as I was told a few folks have noted some concerns. I would appreciate some input on these concerns and hope to have a discussion to figure out how best to proceed. Regards, Rajith

Re: [java] Message codec improvements

2014-12-15 Thread Clebert Suconic
I will need to recover my old-branch to give you some pointers about it… I - A lot of the codecs are creating plenty of intermediate objects… Pseudo-Example on the messageCodec: List… decodedProperties… Message message = new Message(list.get(0), list.get(1)… ); it could be something done