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 will address one of your main concerns. The code is checked into the "rajith-codec" branch. The classes to look at Flow.java in the o/a/q/p/transport2 package TransportTypesEncoder and TransportTypesDecoder in o/a/q/p/codec2 package. I've also put some question marks in the code .. pls answer them. But more importantly pls provide feedback on the direction taken. I'm keen to settle down on the direction/approach first and then will start implementing the rest. Regards, Rajith On Tue, Jan 27, 2015 at 8:13 AM, Rafael Schloming <r...@alum.mit.edu> wrote: > 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 performatives defined by the protocol. > > By POJO, I mean for example a Flow class where getCredit() actually returns > a standard java type (probably a long) rather than an > org.apache.qpid.proton.amqp.UnsignedInteger which I then need to convert > into a long in order to do anything useful with. > > You could use some code generation here, but I wouldn't sacrifice the > naturalness of the API just to allow it to be code generated, and I > wouldn't think of this as an internal API just for the engine to use. We > should have something here that anyone could use to easily decode/encode > raw AMQP performatives in a natural way. > > Once you have those classes, it should be straightforward to write a > DataHandler that will use the fast codec to produce them. > > --Rafael > > > On Fri, Jan 23, 2015 at 12:09 PM, Rajith Muditha Attapattu < > rajit...@gmail.com> wrote: > > > 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 the XXXType classes to get a sense of what I'm > > describing. > > > > We should take this opportunity to review the current approach and see if > > we could come up with a better alternative. > > If anybody has any suggestions, I would be happy to discuss them with you > > on the list. > > > > Regards, > > > > Rajith > > > > > > > > > > On Thu, Jan 15, 2015 at 3:15 PM, Rafael Schloming <r...@alum.mit.edu> > > wrote: > > > > > 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, > > > > > > > > > > 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 sufficiently large set of strings, the old encorder > > is > > > > > about ~2 times slower than the new encorder. > > > > > > > > > > I'm now focusing on hooking it up with the engine. > > > > > > > > > > Once that is done we can look at tweaking it further. But as it is, > > the > > > > > new codec is a real improvement over the existing one. > > > > > Great job Rafi! > > > > > > > > > > Rajith > > > > > > > > > > On Tue, Jan 6, 2015 at 10:28 AM, Rajith Muditha Attapattu < > > > > > rajit...@gmail.com> wrote: > > > > > > > > > >> 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: > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > > > > > > > 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 relatively > standalone, > > so > > > > >>> should be easy to import into the tree, and then it's just a > matter > > > of > > > > >>> modifying the rest of the engine to use it. Note that my > > > > qpid-proton-old > > > > >>> repo is a clone of the pre-migration repo. > > > > >>> > > > > >>> --Rafael > > > > >>> > > > > >>> > > > > >>> On Mon, Dec 15, 2014 at 2:17 PM, Rajith Muditha Attapattu < > > > > >>> rajit...@gmail.com> wrote: > > > > >>> > > > > > >>> > 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 > > > > >>> > > > > > >>> > > > > >> > > > > >> > > > > > > > > > > > > > > >
