Here is a patch to add streaming. It adds this top level function to solrServer:

  QueryResponse queryAndStreamResponse( SolrParams params, StreamingResponseCallback callback ) 

public interface StreamingResponseCallback {
  public void documentRead( SolrDocument doc );
  public void documentListInfo( long numFound, long start, Float maxScore );
}

This is implemented by hacking the BinaryResponseWriter (embedded) and JavaBinCodec (http) to send events rather then write/read documents.

this patch has better comments and includes some missing files

I would like to commit this soon (just to /trunk) unless there are objections

Can StreamingResponseCallback be an abstract class for easier back compat?
I imagine we could want to stream other stuff in the future (output from terms component, facet component, term vector component, etc).

ah yes, good point.

Here is an updated patch using:

public abstract class StreamingResponseCallback {
  /*
   * Called for each SolrDocument in the response
   */
  public abstract void streamSolrDocument( SolrDocument doc );

  /*
   * Called at the beginning of each DocList (and SolrDocumentList)
   */
  public abstract void streamDocListInfo( long numFound, long start, Float maxScore );
}

added in r996693

I'm not sure what the 3.x release schedule looks like... so i'm not sure if back porting makes sense. I think keeping it on /trunk for a while makes sense till we know this is the API we want.

fwiw,
server side streaming is out-of scope of this issue. Some time ago I did a hack to allow streaming response during collecting results, if somebody need it, feel free to raise an issue. there is the code https://github.com/m-khl/solr-patches/compare/streaming

Mikhail Khludnev - are you using it somewhere? Does it work well? Is it "contributable"?

I don't run it, just played with it a year ago up to passing distributed search test, see github. I'm ready to collaborate if anyone is interested. The most questionable thing is the overall design. To discuss it we need to have two separate issues, I suppose, for core ability and distributed support.
IIRC there is a special component, which injects own delegating collector which writes into ServletResponse while search is going. It needs to require sort=docid&rows=0 (to avoid buffering results).
Then for distributed search index should be presorted to keep internal and external ids monotonic. I didn't cover index sorting.
But passing all these traps we've got yet another one MapReduce platform! Sounds cool isn't it!