On Thu, 05 Jun 2014 15:09:57 GMT, David Nadlinger wrote:
I'm not sure if I agree with your rationale for creating one service instance per connection. In the Thrift universe, a service is semantically something stateful which clients can invoke methods on via a stateless Connection
...
Now, of course, in some cases, keeping the connections entirely stateless is just not enough. You mentioned one of them, authentication.
...
For this reason the vanilla Thrift implementation, if conceptually geared towards a stateless model, offers an opportunity to attach contextual information to a connection, either by writing a custom TProcessorFactory to create a processor instance per connection, or by using a TProcessorEventHandler.
I'm almost certain that it is possible to find a more natural, less "Java-ish" design for this in the context of the Vibe.d I/O model. However, it will need to address the question of how to share state somehow.
Well, it is precisely this shared state that I want to avoid. As long as it's transparent for the service clients, we do not have to follow the vanilla Thrift server implementations. In a non-blocking, potentially multi-threaded environment, shared state is pain. I am a fan of the actor model, where every entity that has state, is encapsulated in an actor instance, that may execute code (process messages) only serially, but in parallel with any other actors. I see a (multi)service processor as such an actor entity, the method invocations are (literally) messages passed to it, and their processing is done serially. Each client connection is represented by one processor instance, may have some state, and being tcp-connection bound, the messages/method-calls arrive and are dispatched serially. The processor may communicate with the outer-system using the async I/O, either with the database (async with vibe.d sockets: ddb, mysql-native), or with other Thrift services, or with HTTP (REST) servers. A service that is representing global domain state, should not be available directly on the public network, and will have nothing to do in an vibed async environment. Such a (multi)service would be in a different process/thread/machine, hosted in a vanilla Thrift server (although, there should be some change too, right now a connection takes over the server/processor and the client requests are not processed fifo-wise)