Thanks Anne. Like I said, I'm pretty sure what's going on. But it seems
very unlikely that we could add a fix for this in Sentry, since the error
occurs in the thrift communication between SentryService and
SentryGenericServiceClientDefultImpl. To me, this seemed like a good
candidate for some FAQs section we there is one on wiki - so its at least
discoverable when someone does a search for this error with Sentry.

-
Bhooshan

On Thu, Apr 21, 2016 at 10:27 AM, Anne Yu <ann...@cloudera.com> wrote:

> Hi Bhooshan,
>
> Thanks for reporting this issue. If you have clear idea of what's going on,
> since you've spent time debugging the code, please feel free to create a
> jira (https://issues.apache.org/jira/browse/SENTRY/) then post a fix.
> Committers will be very happy to do the code review.
>
> Best,
> Anne
>
> On Wed, Apr 20, 2016 at 9:17 PM, Bhooshan Mogal <bhooshan.mo...@gmail.com>
> wrote:
>
> > Hi folks,
> >
> > I suddenly started seeing the following error in the Sentry Service today
> > and ended up debugging it for a long time across Sentry, Thrift and my
> own
> > code.
> >
> > 16/04/21 02:15:51 ERROR server.TThreadPoolServer: Thrift error occurred
> > during processing of message.
> > org.apache.thrift.protocol.TProtocolException: Missing version in
> > readMessageBegin, old client?
> > at
> >
> >
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:228)
> > at
> >
> >
> org.apache.thrift.TMultiplexedProcessor.process(TMultiplexedProcessor.java:92)
> > at
> >
> >
> org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:285)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> > at
> >
> >
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:745)
> >
> >
> >
> > It turns out that my (Sentry) client had sentry.service.security.mode set
> > to *kerberos* while the (Sentry) server had it set to *none. *But the
> error
> > message threw me off completely.
> >
> > I tried to see if there was a way we could catch this scenario and throw
> a
> > better error, but its difficult because as either the client or server,
> its
> > not possible to know what the other is configured as. However, is there
> an
> > FAQs section where such issues can be documented?
> >
> >
> > Best,
> > Bhooshan
> >
> >
> >
> > --
> > Bhooshan
> >
>
>
>
> --
> Anne
>



-- 
Bhooshan

Reply via email to