2. The SolrJ library handling of content streams is "pull", not "push". That is, you give it a reader and it pulls content when it feels like it. If your software to feed the connection wants to write the data, you have to either buffer the whole thing or do a dual-thread writer/reader pair.
The easiest way to pull stuff from SVN is to use one of the web server apps. Solr takes a "stream.url" parameter. (Also stream.file.) Note that there is no outbound authentication supported; your web server has to be open (at least to the Solr instance). On Sun, Oct 31, 2010 at 4:06 PM, getagrip <getag...@web.de> wrote: > Hi, > > I've got some basic usage / design questions. > > 1. The SolrJ wiki proposes to use the same CommonsHttpSolrServer > instance for all requests to avoid connection leaks. > So if I create a Singleton instance upon application-startup I can > securely use this instance for ALL queries/updates throughout my > application without running into performance issues? > > 2. My System's documents are stored in a Subversion repository. > For fast searchresults I want to periodically index new documents > from the repository. > > What I get from the repository is a ByteArrayOutputStream. How can I > pass this Stream to Solr? > > I only see possibilities to pass Files but in my case it does not > make sense to write the ByteArrayOutputStream to disk again as this > would cause performance issues apart from making no sense anyway. > > 3. Are there any disadvantages using Solrj over some other HTTP based > solution e.g. creating & sending my own HTTP requests? Do I even > have to use HTTP? > I see the EmbeddedSolrServer exists. Any drawbacks using that? > > Any hints are welcome, Thanks! > -- Lance Norskog goks...@gmail.com
