qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajith Attapattu <rajit...@gmail.com>
Subject Re: Race condition in the TransportImpl in Proton-J
Date Tue, 25 Mar 2014 13:23:02 GMT
I agree with you.
I will create a JIRA and attach a patch for you to review.

It also appears the Frame Parser errors was swallowed before it made to the
application layer.
I will take a closer look and create a JIRA and patch if necessary.


On Tue, Mar 25, 2014 at 6:47 AM, Rafael Schloming <rhs@alum.mit.edu> wrote:

> On Mon, Mar 24, 2014 at 9:37 PM, Rajith Attapattu <rajith77@gmail.com
> >wrote:
> > I encountered an issue in Proton J which I believe is a race condition.
> > If the input stream is read and passed into the transport, before the
> > sasl() method of TransportImpl.java is called then the _inputProcessor
> > defaults to FrameParser instead of being wrapped by the SASL frame
> parser.
> > This causes a Frame Parsing error as it expects '0' as per the regular
> > header but instead finds '3' which is the correct format if the process
> is
> > the SASL frame parser.
> >
> > We should either test the incoming header and determine the right
> > inputProcessor
> > OR
> > clearly document that the transport needs to be ready (i.e the sasl()
> > method has to be called) before any incoming data is fed to the
> transport.
> >
> I'd say we should do the latter. In fact we should probably throw an
> exception if you attempt to configure a sasl layer after input has occurred
> since there is never anything sensible we can do if you try to configure
> the sasl layer "midstream". It all needs to be set up prior to actually
> processing any input bytes.
> --Rafael

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message