On 10-Sep-07, at 4:42 AM, Brian Whitman wrote:
On Sep 10, 2007, at 1:33 AM, Adrian Sutton wrote:
After a while we start getting exceptions thrown because of a
timeout in acquiring write.lock. It's quite possible that this
occurs whenever two updates are attempted at the same time - is
DirectSolrConnection intended to be thread safe?
We use DirectSolrConnection via JNI in a couple of client apps that
sometimes have 100s of thousands of new docs as fast as Solr will
have them. It would crash relentlessly if I didn't force all calls
to update or query to be on the same thread using objc's
@synchronized and a message queue. I never narrowed down if this
was a solr issue or a JNI one.
Sounds like we should put a disclaimer somewhere--I don't get the
impression that DirectSolrConnection is very polished, tested, or
documented.
The problem largely stems from Solr not being designed to be used as
search library code. I don't think any core devs use it in this mode
(except perhaps Ryan?), and so it hasn't got a lot of love.
Embedded Solr/DSC seem to be popular despite being not well-
publicized; eg.:
http://www.symphonious.net/category/apache/
I'm a little worried about Solr getting a bad rap for being buggy or
not well-documented due to people trying to use it embeddedly. It
seems that we need to do one of two things:
1. Someone lead the effort to clean up and organize the situation,
develop and test the relevant api, and document it to the standards
of the rest of Solr.
2. Remove references to embedding Solr (including out-of-date wiki
pages) if we do not have a maintainer for this functionality.
ciao,
-Mike
