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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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,
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
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:
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
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
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
23 matches
Mail list logo