Services can inherit from one another. Would it make sense for you to
have one meta-service inherit from all the separate services, and
just serve the meta-service?
By the way, multiple invocations can happen in the same connection.
You don't need to create a new connection every time, though there is
risk of fairness issues if you keep persistent connections. This is
something we've solved with NonblockingServer in Ruby, and will be
solving similarly in Java soon.
-Bryan
On Jun 19, 2008, at 11:34 AM, Johan Stuyts wrote:
Hi,
Is anyone interested in writing a specification for a multiplexed,
poolable transport?
My use case is this: I separate my applications in a server tier
containing all the business logic, validation and security, and one
or more presentation tiers. All functionality of the application is
exposed using multiple Thrift services. The current implementation
requires opening a new server socket for each service. When the
number of services grows this becomes very cumbersome. Also a
connection to the server can be used for only one invocation which
makes invocations expensive because the TCP handshake has to be
performed each time.
What I am proposing is similar to database connections. The client
pools a number of connections to the server. When a request has to
be made, a connection is retrieved from the pool, a function of an
arbitrary service is invoked and the connection is returned to the
pool.
The advantages are:
- more friendly to firewalls. Only one socket per application needs
to be opened.
- better performance because connections are kept open indefinitely
so the expensive TCP handshake can be omitted.
I have no experience writing protocols so I will need help to write
the specification.
--
Kind regards,
Johan Stuyts
