I've raised https://issues.apache.org/jira/browse/SOLR-6903 for this, as I consider it a bug. Attached to the JIRA is a modified test demonstrating the failure. The test fails on 5.x and 4.x.
Cheers, -Brendan On 30 December 2014 at 13:53, Brendan Humphreys <bren...@canva.com> wrote: > Thanks for the reply Shawn. > > Yes I am using 4.10.2 - I should have mentioned that in my original post. > I can confirm there are not multiple versions of solr in the classpath; Our > SolrCloud nodes are built programmatically in AWS using the download > package of a specific Solr version as a starting point. > > I should add that document adds/updates are visible on all nodes very > quickly. Its only the deletes that are problematic. Reloading the core on a > node brings into into alignment with the leader. > > I'll dig into the JIRA's you linked to see if there are any hints as to > whats going on. > > Cheers, > -Brendan > > > > On 30 December 2014 at 12:57, Shawn Heisey <apa...@elyograg.org> wrote: > >> On 12/29/2014 4:11 PM, Brendan Humphreys wrote: >> > We've noticed that when we send deletes to our SolrCloud cluster via >> curl >> > with the param commitWithin=10000 specified, the deletes are applied and >> > are visible to the leader node, but aren't replicated to other nodes. >> > >> > The problem can be worked around by issuing an explicit (hard) "commit". >> > >> > Is this expected behaviour? Can anyone shed light on what is going on >> here? >> >> Another of your messages mentions 4.10.2, which should have the fix for >> a similar problem reported with a much earlier version, fixed in 4.6.1. >> >> https://issues.apache.org/jira/browse/SOLR-5658 >> >> There's some confusion around another problem introduced by SOLR-5658 -- >> SOLR-5762 -- but if you use the latest version, that shouldn't be a >> problem. >> >> If you are running 4.10.2, perhaps SOLR-5658 has come back, or maybe you >> have multiple versions of the solr jars on your classpath? >> >> Thanks, >> Shawn >> >> >
