2

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?

Evgeniy Berezovsky
  • 18,571
  • 13
  • 82
  • 156
  • @JensG answered in one of the answers that this cannot be done right now. I think the key here is THttpClient, which can save headers data. What remains is to create the server. I was hoping of creating an http server using thrift, but can't find examples/info for this. – AlikElzin-kilaka Feb 02 '15 at 23:54

2 Answers2

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));
Evgeniy Berezovsky
  • 18,571
  • 13
  • 82
  • 156
  • I don't get it. How does the client set the session onto the server? – AlikElzin-kilaka Jan 08 '15 at 14:48
  • @AlikElzin-kilaka The client just connects. At connect time, the server instantiates a new `XHandler`. That XHandler instance is tied to that one connection, it *is* the session. The client doesn't have to set anything. As long as the connection is alive, that session is alive, too. A disconnect will kill the session. This is not sufficient if you need your sessions to survive disconnects. And I'm not sure if/how this works in case you use an HTTP transport. – Evgeniy Berezovsky Jan 08 '15 at 23:01
  • 1
    For simplicity, lets talk about a java client. How do you set the sessionid/auth-token on the client side so the server could read it? – AlikElzin-kilaka Jan 08 '15 at 23:12
1

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.

JensG
  • 13,148
  • 4
  • 45
  • 55
  • 2
    Yep, adding another parameter to every method (interested in session data) would be a somewhat cumbersome, "non-AOP" way of doing it. I was trying to avoid the boilerplate. Do you have a link to the "header data" delveopments you mentioned? – Evgeniy Berezovsky Apr 01 '14 at 01:38
  • Here's the [THeader ticket](https://issues.apache.org/jira/browse/THRIFT-2423). By AOP you mean aspect-oriented? Where can I find that in the Thrift docs? ;-) – JensG Apr 01 '14 at 10:24
  • Aspect-oriented, that's right. I'm not talking about the concept, not an AOP framework. I don't want to have to spread that one aspect, namely providing a session id with every call, over each and every method. – Evgeniy Berezovsky Apr 02 '14 at 02:17
  • Thanks JensG, the ticket doesn't reveal a lot, but the keyword `THeader` led to a [high-level description](https://code.facebook.com/posts/1468950976659943/under-the-hood-building-and-open-sourcing-fbthrift/) and from there it was only one step to [fbthrift](https://github.com/facebook/fbthrift/) which I'll check out. – Evgeniy Berezovsky Apr 02 '14 at 04:58
  • Well, it does. We are in the process of merging the fbthrift changes into Apache Thrift, hence the ticket(s). Regarding AOP: you can't make any component (including Thrift but not limited to) liable for not being AOP, when it was not a design goal. If you want to do AOP, that's your choice. – JensG Apr 02 '14 at 09:38
  • I don't believe there's still no header like mechanism in Thrift :( – AlikElzin-kilaka Feb 02 '15 at 19:23
  • @AlikElzin-kilaka: Not yet, but [there is some movement](http://comments.gmane.org/gmane.comp.lib.thrift.devel/21257). And belief does not bring us forward. After all, Thrift is Open Source, so these are the options: **1)** have patience and wait passively, relying on others **2)** [contribute actively, push it and make it happen faster](http://thrift.apache.org/docs/HowToContribute) **3)** Work around the problem in another way. Clearly, either one of these options come with advantages and disadvantages. The choice is yours. – JensG Feb 02 '15 at 20:57