Thrift knows when the application -> daemon connection goes bad. I can even get those notifications with TServerEventHandler::deleteContext. So I can identify my clients with the "reverseConnectionInfo", and with the context I create in createContext. I don't have any way to associate the two identifiers though. I want to tie the garbage connection cleanup to initialize calls, I just don't see a way to right now.
So, for example, someone connects to my daemon's server. I create a context for that (context 0x1234). The client calls Initialize with reverseConnectionInfo="abcd". I can detect that context 0x1234 has been destroyed, but there is nothing associating context 0x1234 with reverseConnectionInfo "abcd". I'm looking for a way to make that connection so that my implementation of deleteContext can cleanup resources. From: "Troyanker, Vlad" <[email protected]> To: "[email protected]" <[email protected]>, Date: 01/04/2013 01:31 PM Subject: Re: Link a code generated server interface with a TServerEventHandler context? I may have misunderstood your question. But to me your problem has very little to do with thrift. The issue of safely recycling and/or destroying connections has to be addressed in design. Thrift cannot solve connection lifecycle issues. If all your clients are anonymous instances of the same app, then you may have to do some sort of garbage collection in the daemon. Alternatively if clients are identifiable, then tie garbage connection cleanup to a each Initialize() call. On 1/4/13 11:02 AM, "Ben Craig" <[email protected]> wrote: >If the applications were reliable, then that would work. They are not >though. > >The applications in question are often in development, and they are >killed >frequently. I don't want unexpected application death to manifest as a >memory leak in the daemon. > > > >From: "Troyanker, Vlad" <[email protected]> >To: "[email protected]" <[email protected]>, >Date: 01/04/2013 12:47 PM >Subject: Re: Link a code generated server interface with a >TServerEventHandler context? > > > >Add Destroy() call to your server interface. That way full lifecycle of >reverse connection is under client control. > >void Destroy(1: string reverseConnectionInfo) > > >On 1/4/13 7:19 AM, "Ben Craig" <[email protected]> wrote: > >>void Initialize(1: string reverseConnectionInfo), > >
