Unfortunately, this is not currently possible. Every existing Thrift server implementation requires one thread per active request. We have an experimental branch internally (that I will try to open up soon) that enables the behavior you are describing, but it is only in C++, and it was a pretty significant amount of work to implement. We don't even have a nonblocking server in Java yet. There is an open bug covering this functionality:
https://issues.apache.org/jira/browse/THRIFT-1 --David Ben Maurer wrote: > Hey, > > Usually, when writing stuff for thrift, I've found it's best to create an > object that takes parameters: > > FooReturn doFoo(1: FooArgs args); > > For the return value, this is pretty critical because thrift doesn't allow > you to return multiple values. For the arguments, I've found that even > though thrift can support multiple arguments, doing this makes it easier > (eg, you can serialize args and log it). > > So for this kind of API I'd just take the args value insert it into a > queue. It does require a bit of work for each function, however, you can > also do stuff like validate the request and raise an exception if you know > the insert will fail. > > -b > > On Wed, 28 May 2008, Benjamin Reed wrote: > >> Could I get a pointer to how to deal with the following scenario: >> >> I have a Java server using thrift. There are potentially hundreds of > clients >> sending hundreds of requests at a time. The server receives a request, >> batches it up with other pending requests, processes a batch at a > time, and >> then generates the responses when the batch finishes. >> >> For example, clients A, B, and C, are each sending up records to be > inserted >> into a database. The clients are sending up 1000 requests per second. The >> server will grab some number, lets say 100 requests at a time, insert them >> into the database, issue a commit, and send back successful responses. > Doing >> batch commits of 100 requests at a time allows the server to keep up > with the >> clients. Committing each request individually would be too slow. >> >> So, in my Java server, how do I get an RPC request and then put it on a >> completion list so that I can free up the thread for the next RPC call and >> complete the RPC when I do the batch processing? >> >> thanx >> ben >> _______________________________________________ >> thrift mailing list >> [EMAIL PROTECTED] >> http://publists.facebook.com/mailman/listinfo/thrift >> >> > _______________________________________________ > thrift mailing list > [EMAIL PROTECTED] > http://publists.facebook.com/mailman/listinfo/thrift >
