Yeah, this sounds reasonable to me. I can see some reasonable use cases for this for processes that need to do both internal (i.e. non-Thrift) and server-invoked work (Thrift). A single executor service might give you better control over resource utilization if you want the same policy to apply to all tasks.
Cheers, Mark -----Original Message----- From: Bryan Duxbury [mailto:[email protected]] Sent: Monday, January 05, 2009 9:24 AM To: [email protected] Subject: Re: ExecutorService as a constructor parameter for TServer I suspect it would be pretty simple, though the "correct" route is probably to make a TExecutorServiceServer and have TThreadPoolServer extend that at some point. Why do you want to use a centralized ExecutorService? It seems like that detail of how the server works is something that should remain concealed. If you'd like, you can create a ticket for it in the JIRA (https://issues.apache.org/jira/browse/ THRIFT), and can of course supply us with a patch. -Bryan On Jan 3, 2009, at 7:00 PM, [email protected] wrote: > Hi: > > Would you consider adding a constructor parameter to the TServer > (TThreadPoolServer) > class in order to pass a reference to an existing ExecutorService ? > I am using a Java server program that manages a centralized > ExecutorService (as other implementation I > suspect) so it would be a nice feature to have. > > Regards, >
