Mark, Here is the https://issues.apache.org/jira/browse/SOLR-3284 ConcurrentUpdateSolrServer queues updates on the SolrJ side, not the server ones. Solr server processes number of updates simultaneously, e.g. if your servlet containers threads are unlimited it can potentially lead to OOM.
On Wed, Jan 16, 2013 at 3:09 AM, Shawn Heisey <s...@elyograg.org> wrote: > On 1/15/2013 2:10 PM, Mark Bennett wrote: > >> First off, just reporting this: >> >> I wound up with approx 58% few documents having submitted via >> ConcurrentUpdateSolrServer. I went back and changed the code to use >> HttpSolrServer and had 100% >> >> This was a long running test, approx 12 hours, with gigabytes of data, so >> conveniently shared / reproducible, but I at least wanted to email around, >> in part to get it "on the record", and second to see if anybody else has >> seen this? I didn't see anything in JIRA. >> >> I realize that Concurrent update is asynchronous and I'm giving up the >> ability to monitor things, but since it works using the old server, >> there's >> nothing glaringly wrong at least. >> > > You're not only giving up the ability to monitor things, you're also > giving up the ability to detect errors. All exceptions that get thrown by > the internals of ConcurrentUpdateSolrServer are swallowed, your code will > never know they happened. The client log (slf4j with whatever binding & > config you chose) may have such errors logged, but they are completely > undetectable by the code. Make sure you're actually logging someplace with > your solrj app at a minimum level of INFO, then check that log. > > It might be a case of errors being silently swallowed, or it might be a > bug. > > Thanks, > Shawn > > -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics <http://www.griddynamics.com> <mkhlud...@griddynamics.com>
