Re: Race condition in the TransportImpl in Proton-J
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. Rajith On Tue, Mar 25, 2014 at 6:47 AM, Rafael Schloming wrote: > On Mon, Mar 24, 2014 at 9:37 PM, Rajith Attapattu >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 >
Re: Race condition in the TransportImpl in Proton-J
On Mon, Mar 24, 2014 at 9:37 PM, Rajith Attapattu 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
Race condition in the TransportImpl in Proton-J
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. Rajith
