I have since figured out how to solve this use case, without writing
anything new in the Thrift library itself. Beforehand, when I was
creating my server, I was using one of the constructors that took a
TProcessor. If I use the TProcessorFactory entry point, I have a way to
make everything come together.
First, I had to write a class implementing the code generated
DaemonServiceIfFactory interface. The one that I implemented created a
new server handler in getHandler, and deleted it in releaseHandler. Then,
I passed an instance of my DaemonServiceIfFactory to the
DaemonServiceProcessorFactory.
Now, everytime a client connects, I get a new instance of my IfHandler,
and when the client disconnects, my IfHandler is destroyed. This gives me
the opportunity to clean up resources associated with a particular
connection.
It doesn't actually use the TServerEventHandler, but it solves my use
case. The IfHandler's "this" pointer is all the context I need.
From: Ben Craig <ben.cr...@ni.com>
To: dev@thrift.apache.org,
Date: 01/04/2013 09:20 AM
Subject: Link a code generated server interface with a
TServerEventHandler context?
Short version of the question:
Is there any way in C++ Thrift to get the TServerEventHandler context into
a call on my server interface handler?
Long question + background:
I am running a daemon, and connecting to it with multiple applications,
all over AF_UNIX sockets. Each application has a thrift client to the
daemon, and a thrift server. The daemon has a thrift server, and one
thrift client per application.
My daemon server handler looks something like this:
service DaemonService
{
void Initialize(1: string reverseConnectionInfo),
string QueryAttribute(1: i32 id),
}
When an application connects to the daemon, it calls Initialize, with the
name of the server the application is hosting. This all works fine. The
problem is on the cleanup side. I don't know when to destroy the daemon's
"reverse connection", because I don't have any way to associate the call
to Initialize with a server context.
The closest I see as a possibility (without compiler modifications) is to
create a context in TServerEventHandler, watch for "Initialize" in a
TProcessorEventHandler, and then fail miserably, because I don't know the
contents of the "reverseConnectionInfo" string.
I am considering adding a new type in the compiler, so that I could write
my DaemonService something like this:
service DaemonService
{
void Initialize(1: string reverseConnectionInfo, ServerContext ctx),
//new ServerContext here
string QueryAttribute(1: i32 id),
}
Note that the "ServerContext" type doesn't have a number associated with
it, because it isn't ever serialized across "the wire". This wouldn't
change the client code at all, but the server interface would have an
Initialize(const std::string &reverseConnectionInfo, void *ctx) method,
instead of the current method that it has.
So... is there a way to handle cleanup triggered by client disconnection
already that I am overlooking, or should I tweak my compiler?
