Hi,
This may be related to SOLR-1711 and/or SOLR-1543, however I read the
archives and the issues and think I am running code where these issues
have been fixed.

I am running a snapshot of Solr4 at revision 1040465, which was about
Feb 2011 IIRC, and I am testing recovery of the client when the master
Solr instance in a cluster dies. The indexer uses a
StreamingUpdateSolrServer. When the master Solr instance dies the
client commits fail with a java.net.ConnectException on the commit
operation which bubbles back up the stack to the SolrJ client. The
runner threads retry several times and eventually fail, emptying the
queue.

When the master Solr instance comes back online, I see the runner
threads re-trying and I think succeeding, but the SolrJ client thread
ends up in this state (forever). There are no runner threads (in my
case pool-2-thread-x) present in the thread dump.

"IndexerQueueDispatch" daemon prio=10 tid=0x00007f87949e0000
nid=0x7f68 waiting on condition [0x00007f87928a7000]
   java.lang.Thread.State: WAITING (parking)
        at sun.misc.Unsafe.park(Native Method)
        - parking to wait for  <0x00000000b2277390> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
        at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:306)
        at org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer.request(StreamingUpdateSolrServer.java:218)
        at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105)
        at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:50)
        at org.sakaiproject.nakamura.solr.ContentEventListener.batchedEventRun(ContentEventListener.java:379)
        at org.sakaiproject.nakamura.solr.ContentEventListener.run(ContentEventListener.java:285)
        at java.lang.Thread.run(Thread.java:662)

I can reproduce with ease.

I suspect using a CommonsHttpSolrServer will fix the problem, as it
will make indexing single threaded on the client side, which I would
like to avoid if possible.

Is this something that has been seen before now?
Is there a fix in a later revision?
Thanks
Ian

(btw, since this is snapshot code I thought the dev list was the best
place to ask the question, please say if I should re-post on the users
list. Also, if its been fixed already, please just post a pointer or
something to search for and tell me to go away and read it :))
https://issues.apache.org/jira/browse/SOLR-1711
https://issues.apache.org/jira/browse/SOLR-1543

---------------------------------------------------------------------

Sorry for the noise, but I might as well answer my own question, since
I have found a solution.

The problem doesn't appear to happen after 1144174, which I think was
due to SOLR-1711 fixes, but its hard to tell as the svn history isn't
that clear.

And before that using CommonHttpSolrServer avoids the problem.

Thanks
Ian

On 11 November 2011 13:03, Ian Boston <[EMAIL PROTECTED]> wrote:
> Hi,
> This may be related to SOLR-1711 and/or SOLR-1543, however I read the
> archives and the issues and think I am running code where these issues
> have been fixed.
>
> I am running a snapshot of Solr4 at revision 1040465, which was about
> Feb 2011 IIRC, and I am testing recovery of the client when the master
> Solr instance in a cluster dies. The indexer uses a
> StreamingUpdateSolrServer. When the master Solr instance dies the
> client commits fail with a java.net.ConnectException on the commit
> operation which bubbles back up the stack to the SolrJ client. The
> runner threads retry several times and eventually fail, emptying the
> queue.
>
> When the master Solr instance comes back online, I see the runner
> threads re-trying and I think succeeding, but the SolrJ client thread
> ends up in this state (forever). There are no runner threads (in my
> case pool-2-thread-x) present in the thread dump.
>
> "IndexerQueueDispatch" daemon prio=10 tid=0x00007f87949e0000
> nid=0x7f68 waiting on condition [0x00007f87928a7000]
>   java.lang.Thread.State: WAITING (parking)
>        at sun.misc.Unsafe.park(Native Method)
>        - parking to wait for  <0x00000000b2277390> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>        at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
>        at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
>        at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:306)
>        at org.apache.solr.client.solrj.impl.StreamingUpdateSolrServer.request(StreamingUpdateSolrServer.java:218)
>        at org.apache.solr.client.solrj.request.AbstractUpdateRequest.process(AbstractUpdateRequest.java:105)
>        at org.apache.solr.client.solrj.SolrServer.add(SolrServer.java:50)
>        at org.sakaiproject.nakamura.solr.ContentEventListener.batchedEventRun(ContentEventListener.java:379)
>        at org.sakaiproject.nakamura.solr.ContentEventListener.run(ContentEventListener.java:285)
>        at java.lang.Thread.run(Thread.java:662)
>
> I can reproduce with ease.
>
> I suspect using a CommonsHttpSolrServer will fix the problem, as it
> will make indexing single threaded on the client side, which I would
> like to avoid if possible.
>
> Is this something that has been seen before now?
> Is there a fix in a later revision?
>
>
> Thanks
> Ian
>
> (btw, since this is snapshot code I thought the dev list was the best
> place to ask the question, please say if I should re-post on the users
> list. Also, if its been fixed already, please just post a pointer or
> something to search for and tell me to go away and read it :))
>
>
>
>
>
>
> https://issues.apache.org/jira/browse/SOLR-1711
> https://issues.apache.org/jira/browse/SOLR-1543
>

---------------------------------------------------------------------