Hi Shawn, from your answer I see that you are obviously not using ConcurrentUpdateSolrClient. I didn't say that I use ConcurrentUpdateSolrClient in multiple threads. I say that ConcurrentUpdateSolrClient.Builder has a method to set "withThreadCount", to empty the Clients queue with multiple threads. This is useful for bulk loading huge data volumes or replay backup into index.
As I can see at the indexer with infostream, there are _no_ indexing errors. I tried now with one thread several times and everything was fine. The newer docs replaced the older docs (wich were marked deleted) in the index. With more than 1 "threadCount" for emtying the queue there are problems with ConcurrentUpdateSolrClient. This will nerver pass a Jepsen test and I call it _NOT_ thread safe. I haven't looked into the code yet, to see if the queue is FIFO, otherwise this would be stupid. Regards Bernd Am 11.01.2018 um 02:27 schrieb Shawn Heisey: > On 1/10/2018 8:33 AM, Bernd Fehling wrote: >> after some strange search results I was trying to locate the problem >> and it turned out that it starts with bulk loading with SolrJ >> and ConcurrentUpdateSolrClient.Builder with several threads. >> >> I assume that ConcurrentUpdateSolrClient.Builder is _NOT_ thread safe >> according the docs send to the indexer? > > Why would you need the Builder to be threadsafe? > > The actual client object (ConcurrentUpdateSolrClient) should be perfectly > threadsafe, but the Builder probably isn't, and I can't think of any > reason to try and use it with multiple threads. In a well-constructed > program, you will use the Builder exactly once, in an initialization > thread, and then have all the indexing threads use the client object that the > Builder creates. > > I hope you're aware that the concurrent client swallows all indexing errors > and does not tell your program about them. > > Thanks, > Shawn >
