On a side note, even with the non-blocking server is use, Thrift 0.9.0 did not have an async server implementation so the server side really couldn't take advantage of the non-blocking server anyway.
Aaron On Wed, Nov 23, 2016 at 12:22 AM, Ravikumar Govindarajan < [email protected]> wrote: > Thanks for the clarification... > > Our concurrency overhead is quite low. Guess we can safely switch over to > the new model > > On Mon, Nov 21, 2016 at 6:38 PM, Aaron McCurry <[email protected]> wrote: > > > If I remember correctly the biggest reason at the time (not sure if it's > > still true or not) was the non-blocking server didn't support the sasl > > authentication. Perhaps with newer versions of Thrift this is no longer > > the case. > > > > Aaron > > > > On Mon, Nov 21, 2016 at 4:18 AM, Ravikumar Govindarajan < > > [email protected]> wrote: > > > > > I just saw this commit > > > https://git1-us-west.apache.org/repos/asf?p=incubator- > > > blur.git;a=commitdiff;h=5853d86e > > > where non-blocking server is removed and threaded-server model is > used... > > > > > > Are there any particular reasons for this change? > > > > > > The reason why I am asking is, we use non-blocking server mode as of > > today > > > & frequently see responses from controller side (After collating all > > query > > > data from shard-servers etc...) not getting through to the calling VM > > (Our > > > app-servers) > > > > > > We suspect AbstractNonBlockingServer.responseReady() method to be the > > > culprit but not entirely sure. > > > > > > May be changing to threaded-thrift servers will do the trick for us. > > > Anyways, its good to know the actual reason(s) for the change > > > > > > -- > > > Ravi > > > > > >
