You are viewing a plain text version of this content. The canonical link for it is here.
Posted to proton@qpid.apache.org by Rajith Muditha Attapattu <ra...@gmail.com> on 2015/05/13 18:58:18 UTC
[Proton-J] Improving the engine impl.
If you look at the engine impl, you would see TransportLink and a LinkImpl
(ditto for Session, Delivery etc..)
1. Is this separation necessary? Could we not collapse the two into one?
2. The extra copying of data btw the two layers could possibly be a
performance issue.
Regards,
Rajith
Re: [Proton-J] Improving the engine impl.
Posted by Rajith Muditha Attapattu <ra...@gmail.com>.
Sure, just wanted to pose the question to what your thoughts were.
Having said that, this maybe one of the areas to look at after the codec
work is done.
Another area is the FrameParser and FrameWrite :p ... but one thing at a
time.
Regards,
Rajith
On Wed, May 13, 2015 at 2:07 PM, Rafael Schloming <rh...@alum.mit.edu> wrote:
> On Wed, May 13, 2015 at 12:58 PM, Rajith Muditha Attapattu <
> rajith77@gmail.com> wrote:
>
> > If you look at the engine impl, you would see TransportLink and a
> LinkImpl
> > (ditto for Session, Delivery etc..)
> >
> > 1. Is this separation necessary? Could we not collapse the two into one?
> >
> > 2. The extra copying of data btw the two layers could possibly be a
> > performance issue.
> >
>
> Logically it is good to keep them distinct since the TransportLink state is
> only valid when the Link is bound to a connection and needs to be
> cleared/reinitialized on unbind/rebind. I doubt there is much overhead to
> it so I'd leave it be for now.
>
> --Rafael
>
Re: [Proton-J] Improving the engine impl.
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Wed, May 13, 2015 at 12:58 PM, Rajith Muditha Attapattu <
rajith77@gmail.com> wrote:
> If you look at the engine impl, you would see TransportLink and a LinkImpl
> (ditto for Session, Delivery etc..)
>
> 1. Is this separation necessary? Could we not collapse the two into one?
>
> 2. The extra copying of data btw the two layers could possibly be a
> performance issue.
>
Logically it is good to keep them distinct since the TransportLink state is
only valid when the Link is bound to a connection and needs to be
cleared/reinitialized on unbind/rebind. I doubt there is much overhead to
it so I'd leave it be for now.
--Rafael