Session management in Thrift

Question

I can't seem to find any documentation on how session management is supposed to be done in Thrift's RPC framework.

I know I can do a

TServer.setServerEventHandler(myEventHandler);

and observe calls to createContext (called when a connection is established) and processContext (called before every method call). Still, I have to get whatever session state I maintain in those message into the handler itself.

So how can I access session information in my handlers?

Answer 1

Not sure if there isn't also a way to use the ServerEventHandler approach mentioned in my question, but here's how I was able to create one handler per connection.

Rather than providing a singleton processor instance, containing a handler instance, once, like this:

XProcessor<XHandler> processor = new X.Processor<XHandler>(new XHandler());
TServer server = new TSimpleServer(new TServer.Args(serverTransport)
    .processor(processor));

I instead create and provide a TProcessorFactory:

TProcessorFactory processorFactory = new TProcessorFactory(null)
{
    public TProcessor getProcessor(TTransport trans)
    {
        return new X.Processor<XHandler>(new XHandler());
    }
};
TServer server = new TSimpleServer(new TServer.Args(serverTransport)
    .processorFactory(processorFactory));

Answer 2

There is no such thing as an built-in session management with Thrift. Remember, Thrift is supposed to be a lightweight RPC and serialization framework. Managing sessions it considered outside the scope, located at least one layer on top of Thrift.

I'm not so sure, if the events approach will work, but maybe it does - I never tried it that way.

My recommendation would be to include the session ID (or whatever equivalent you use) into each call. That's how we do it, and it works quite well.

Altough quite handy, the "one handler per connection" model does not scale very far by design (same is true for the "Threaded" servers, btw). Imagine any multiple of your choice of 1000 connections hammering your service in parallel. If there is the slightest chance of that scenario becoming reality, you should think of a different solution, because most likely the approach you are about to use will not scale.

_{Actually, there are some plans to integrate kind of "header" data, but that stuff is not in the Apache Thrift code base yet.}