On 11/20/06 5:51 PM, "Yonik Seeley" <[EMAIL PROTECTED]> wrote: >> : If you really want to handle failure in an error response, write that >> : to a string and if that fails, send a hard-coded string. >> >> Hmmm... i could definitely get on board an idea like that. > > I took pains to make things streamable.. I'd hate to discard that. > How do other servers handle streaming back a response and hitting an error?
You found the design tradeoff! We can stream the results or we can give reliable error codes for errors that happen during result processing. We can't do both. Ultraseek does streaming, but we were generating HTML, so we could print reasonable errors in-line. Streaming is very useful for HTML pages, because it allows the first pixels to be painted as soon as possible. It isn't as important on the back end, unless someone has gone to the considerable trouble of making their entire front-end able to stream the back-end results to HTML. If we aren't calling Writer.flush occasionally, then the streaming is just filling up a buffer smoothly. The client won't see anything until TCP decides to send it. Does Lucene access fetch information from disk while we iterate through the search results? If that happens a few times, then streaming might make a difference. If it is mostly CPU-bound, then streaming probably doesn't help. wunder -- Walter Underwood Search Guru, Netflix
