You the threaded and threadpool guys are here: https://github.com/apache/thrift/tree/master/lib/csharp/src/Server
On Wed, May 28, 2014 at 1:54 AM, Myles McDonnell < [email protected]> wrote: > I'm going to have a look at this too. As well as being sub-optimal in > terms of performance it's a pain when debugging a C# server. > > what repo. is this code in? > > > > On 28 May 2014 08:04, Jens Geyer <[email protected]> wrote: > > > +1 but it is not only the C# code. This pattern is used elsewhere too. > > That doesn't make it better. > > ________________________________ > > Von: Randy Abernethy > > Gesendet: 28.05.2014 06:58 > > An: [email protected] > > Betreff: Re: Unnecessary Exceptions > > > > Hi Craig, > > > > I agree with your assessment of exceptions in normal control flow. If you > > can provide a patch that improves on the C# server solution we'll > certainly > > review it! > > > > Best, > > Randy > > > > > > On Tue, May 27, 2014 at 12:58 PM, Craig Peterson <[email protected] > > >wrote: > > > > > I am looking through the C# server code, and was surprised at the > > > try/catch mechanisms being used. The Server does a while > > > (processor.Process(inputProtocol, outputProtocol)) loop to process all > > > requests on a given connection. The processor in turn calls > > > ReadMessageBegin and catches IOExceptions (which do not appear to be > > > throwing for me). What is happening on every request is that the > protocol > > > is throwing a TTransport exception when the stream is closed, and the > > > server is catching it. > > > > > > Everything technically works correctly, but I am not so comfortable > with > > > Exceptions being thrown and caught on EVERY request to my server. I > don't > > > have hard numbers on the performance impact of throwing and catching > > > exceptions in .net, but I do know that exceptions have a real cost, and > > > should be avoided for control-flow type scenarios. > > > > > > Is there a better way to detect if there is another request on the > stream > > > than trying to read it and letting it throw if there is nothing there, > or > > > if the socket is closed? I tried playing around with reading > > > transport.IsOpen in various places, but that does not seem to be > reliable > > > enough to act as a signal. > > > > > > In my case I know that no client will make multiple requests on a > socket, > > > so I can even make my own server that doesn't loop over the processor, > > but > > > I am not so happy about that either. > > > > > > > > >
