[
https://issues.apache.org/jira/browse/SOLR-13599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-13599:
----------------------------
Attachment: thetaphi_Lucene-Solr-master-Windows_8025.log.txt
Status: Open (was: Open)
Details of Uwe's jenkins updates...
*
http://mail-archives.apache.org/mod_mbox/lucene-dev/201906.mbox/%[email protected]%3E
*
http://mail-archives.apache.org/mod_mbox/lucene-dev/201907.mbox/%[email protected]%3E
*
http://mail-archives.apache.org/mod_mbox/lucene-dev/201907.mbox/raw/%[email protected]%3E/4
----
I'm attaching thetaphi_Lucene-Solr-master-Windows_8025.log.txt as an
illustrative example of the failure, here are some key snippets and the
associated lines from the test class...
{noformat}
# Previously: test individual adds, delById, and delByyQ using...
# ... rf=3 with all replicas connected,
# ... rf=2 when one replica's proxy is closed,
# ... rf=1 when both replica's proxies are closed
# Lines # 314-320 - "heal" the cluster (re-enable all proxies)
...
[junit4] 2> 555732 INFO
(TEST-ReplicationFactorTest.test-seed#[C415B4F186C6C69D]) [ ]
o.a.s.c.AbstractFullDistribZkTestBase Found 3 replicas and leader on
127.0.0.1:59004_ for shard1 in repfacttest_c8n_1x3
[junit4] 2> 555732 INFO
(TEST-ReplicationFactorTest.test-seed#[C415B4F186C6C69D]) [ ]
o.a.s.c.AbstractFullDistribZkTestBase Took 7107.0 ms to see all replicas become
active.
...
# Lines # 322-326 - checks that (individual) add, delById & delByQ all get rf=3
# Lines # 328-341 - checks that (batched) add, delById & delByQ all get rf=3
# Line # 344 - close a proxy port (59108) again ...
[junit4] 2> 556060 WARN
(TEST-ReplicationFactorTest.test-seed#[C415B4F186C6C69D]) [ ]
o.a.s.c.s.c.SocketProxy Closing 1 connections to: http://127.0.0.1:59108/,
target: http://127.0.0.1:59109/
{noformat}
At this point, the next thing in the test is to add a batch of documents
(ids#15-29) while one replica is partitioned -- but I should point out that
it's not immediately obvious to me if the {{(updateExecutor-1924-thread-4}}
logging from the leader below (complaining about {{Connection refused:}} to
port 59108 is *because* of the update sent my the client, or independently
because of the HTTP2 connection management detecting that the proxy was
closed...
{noformat}
# Lines # 346-355 - send our first "batch" (id#15-29) when cluster isn't
"healed"
[junit4] 2> 558074 ERROR
(updateExecutor-1924-thread-4-processing-x:repfacttest_c8n_1x3_shard1_replica_n2
r:core_node5 null n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1)
[n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1 r:core_node5
x:repfacttest_c8n_1x3_shard1_replica_n2 ]
o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
SolrCmdDistributor$Req: cmd=add{,id=(null)}; node=StdNode:
http://127.0.0.1:59108/repfacttest_c8n_1x3_shard1_replica_n3/ to
http://127.0.0.1:59108/repfacttest_c8n_1x3_shard1_replica_n3/
[junit4] 2> => java.io.IOException: java.net.ConnectException:
Connection refused: no further information
...
# ...there are more details about supressed exceptions
# ...this ERROR repeats many times - evidently as the leader tries to
reconnect...
...
[junit4] 2> 560193 ERROR
(updateExecutor-1924-thread-4-processing-x:repfacttest_c8n_1x3_shard1_replica_n2
r:core_node5 null n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1)
[n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1 r:core_node5
x:repfacttest_c8n_1x3_shard1_replica_n2 ]
o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
SolrCmdDistributor$Req: cmd=add{,id=(null)}; node=StdNode:
http://127.0.0.1:59108/repfacttest_c8n_1x3_shard1_replica_n3/ to
http://127.0.0.1:59108/repfacttest_c8n_1x3_shard1_replica_n3/
[junit4] 2> => java.io.IOException: java.net.ConnectException:
Connection refused: no further information
...
# ... brief bit of path=/admin/metrics logging from both n:127.0.0.1:59004_ and
n:127.0.0.1:59084_
# ... and some other MetricsHistoryHandler logging (from overseer?) about
failing to talk to 127.0.0.1:59108
# ... but mostly lots of logging from the leader about not being able to
connect to 127.0.0.1:59108
# live replica (port 59060) logs that it's added the 15 docs FROMLEADER, ...
BUT!!!!...
# ... same thread then logs jetty EofException: Reset cancel_stream_error
# ... so aparently it added the docs but had a problem communicating that back
to the leader
# ... evidently because it took 30 seconds (QTime = 30013) and leader gave up
(see below)
[junit4] 2> 591364 INFO (qtp1520091886-5884) [n:127.0.0.1:59060_
c:repfacttest_c8n_1x3 s:shard1 r:core_node4
x:repfacttest_c8n_1x3_shard1_replica_n1 ] o.a.s.u.p.LogUpdateProcessorFactory
[repfacttest_c8n_1x3_shard1_replica_n1] webapp= path=/update
params={update.distrib=FROMLEADER&distrib.from=http://127.0.0.1:59004/repfacttest_c8n_1x3_shard1_replica_n2/&wt=javabin&version=2}{add=[15
(1637713552307388416), 16 (1637713552307388417), 17 (1637713552307388418), 18
(1637713552308436992), 19 (1637713552308436993), 20 (1637713552308436994), 21
(1637713552308436995), 22 (1637713552308436996), 23 (1637713552308436997), 24
(1637713552308436998), ... (15 adds)]} 0 30013
[junit4] 2> 591367 ERROR (qtp1520091886-5884) [n:127.0.0.1:59060_
c:repfacttest_c8n_1x3 s:shard1 r:core_node4
x:repfacttest_c8n_1x3_shard1_replica_n1 ] o.a.s.h.RequestHandlerBase
org.eclipse.jetty.io.EofException: Reset cancel_stream_error
[junit4] 2> at
org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory$HTTPServerSessionListener.onReset(HTTP2ServerConnectionFactory.java:157)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Stream.notifyReset(HTTP2Stream.java:574)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Stream.onReset(HTTP2Stream.java:343)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Stream.process(HTTP2Stream.java:252)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Session.onReset(HTTP2Session.java:294)
[junit4] 2> at
org.eclipse.jetty.http2.parser.Parser$Listener$Wrapper.onReset(Parser.java:368)
[junit4] 2> at
org.eclipse.jetty.http2.parser.BodyParser.notifyReset(BodyParser.java:139)
[junit4] 2> at
org.eclipse.jetty.http2.parser.ResetBodyParser.onReset(ResetBodyParser.java:97)
[junit4] 2> at
org.eclipse.jetty.http2.parser.ResetBodyParser.parse(ResetBodyParser.java:66)
[junit4] 2> at
org.eclipse.jetty.http2.parser.Parser.parseBody(Parser.java:194)
[junit4] 2> at
org.eclipse.jetty.http2.parser.Parser.parse(Parser.java:123)
[junit4] 2> at
org.eclipse.jetty.http2.parser.ServerParser.parse(ServerParser.java:115)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection$HTTP2Producer.produce(HTTP2Connection.java:248)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:357)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:181)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:170)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:125)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:348)
[junit4] 2> at
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[junit4] 2> at
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
[junit4] 2> at
org.eclipse.jetty.util.thread.Invocable.invokeNonBlocking(Invocable.java:68)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.invokeTask(EatWhatYouKill.java:345)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:300)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)
[junit4] 2> at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
[junit4] 2> at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
[junit4] 2> at java.base/java.lang.Thread.run(Thread.java:830)
[junit4] 2> Suppressed: java.lang.Throwable: HttpInput failure
[junit4] 2> at
org.eclipse.jetty.server.HttpInput.failed(HttpInput.java:831)
[junit4] 2> at
org.eclipse.jetty.http2.server.HttpChannelOverHTTP2.onFailure(HttpChannelOverHTTP2.java:323)
[junit4] 2> at
org.eclipse.jetty.http2.server.HTTP2ServerConnection.onStreamFailure(HTTP2ServerConnection.java:219)
[junit4] 2> ... 30 more
[junit4] 2>
# FYI: same request thread on port 59060 also logs same exception from
o.a.s.s.HttpSolrCall ...
[junit4] 2> 591367 ERROR (qtp1520091886-5884) [n:127.0.0.1:59060_
c:repfacttest_c8n_1x3 s:shard1 r:core_node4
x:repfacttest_c8n_1x3_shard1_replica_n1 ] o.a.s.s.HttpSolrCall
null:org.eclipse.jetty.io.EofException: Reset cancel_stream_error
[junit4] 2> at
org.eclipse.jetty.http2.server.HTTP2ServerConnectionFactory$HTTPServerSessionListener.onReset(HTTP2ServerConnectionFactory.java:157)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Stream.notifyReset(HTTP2Stream.java:574)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Stream.onReset(HTTP2Stream.java:343)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Stream.process(HTTP2Stream.java:252)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Session.onReset(HTTP2Session.java:294)
[junit4] 2> at
org.eclipse.jetty.http2.parser.Parser$Listener$Wrapper.onReset(Parser.java:368)
[junit4] 2> at
org.eclipse.jetty.http2.parser.BodyParser.notifyReset(BodyParser.java:139)
[junit4] 2> at
org.eclipse.jetty.http2.parser.ResetBodyParser.onReset(ResetBodyParser.java:97)
[junit4] 2> at
org.eclipse.jetty.http2.parser.ResetBodyParser.parse(ResetBodyParser.java:66)
[junit4] 2> at
org.eclipse.jetty.http2.parser.Parser.parseBody(Parser.java:194)
[junit4] 2> at
org.eclipse.jetty.http2.parser.Parser.parse(Parser.java:123)
[junit4] 2> at
org.eclipse.jetty.http2.parser.ServerParser.parse(ServerParser.java:115)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection$HTTP2Producer.produce(HTTP2Connection.java:248)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produceTask(EatWhatYouKill.java:357)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:181)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection.produce(HTTP2Connection.java:170)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection.onFillable(HTTP2Connection.java:125)
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection$FillableCallback.succeeded(HTTP2Connection.java:348)
[junit4] 2> at
org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103)
[junit4] 2> at
org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117)
[junit4] 2> at
org.eclipse.jetty.util.thread.Invocable.invokeNonBlocking(Invocable.java:68)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.invokeTask(EatWhatYouKill.java:345)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:300)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:168)
[junit4] 2> at
org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.produce(EatWhatYouKill.java:132)
[junit4] 2> at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:781)
[junit4] 2> at
org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:917)
[junit4] 2> at java.base/java.lang.Thread.run(Thread.java:830)
[junit4] 2> Suppressed: java.lang.Throwable: HttpInput failure
[junit4] 2> at
org.eclipse.jetty.server.HttpInput.failed(HttpInput.java:831)
[junit4] 2> at
org.eclipse.jetty.http2.server.HttpChannelOverHTTP2.onFailure(HttpChannelOverHTTP2.java:323)
[junit4] 2> at
org.eclipse.jetty.http2.server.HTTP2ServerConnection.onStreamFailure(HTTP2ServerConnection.java:219)
[junit4] 2> ... 30 more
# leader's updateExecutor-1924-thread-4 complains many more times that it isn't
able to update
# (the still down) 127.0.0.1:59108 ...
[junit4] 2> 591661 ERROR
(updateExecutor-1924-thread-4-processing-x:repfacttest_c8n_1x3_shard1_replica_n2
r:core_node5 null n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1)
[n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1 r:core_node5
x:repfacttest_c8n_1x3_shard1_replica_n2 ]
o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
SolrCmdDistributor$Req: cmd=add{,id=(null)}; node=StdNode: http://127.0.0.1:59
108/repfacttest_c8n_1x3_shard1_replica_n3/ to
http://127.0.0.1:59108/repfacttest_c8n_1x3_shard1_replica_n3/
[junit4] 2> => java.io.IOException: java.net.ConnectException:
Connection refused: no further information
[junit4] 2> at
org.eclipse.jetty.client.util.DeferredContentProvider.flush(DeferredContentProvider.java:193)
...
# Eventually (a different) updateExecutor-1924-thread-2 on the leader also
complains it
# couldn't send the update to port 59060 because of a "TimeoutException:
idle_timeout"
# (which is either a cause or effect of 59060's "EofException: Reset
cancel_stream_error" above)
[junit4] 2> 591661 ERROR
(updateExecutor-1924-thread-2-processing-x:repfacttest_c8n_1x3_shard1_replica_n2
r:core_node5 null n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1)
[n:127.0.0.1:59004_ c:repfacttest_c8n_1x3 s:shard1 r:core_node5
x:repfacttest_c8n_1x3_shard1_replica_n2 ]
o.a.s.u.ErrorReportingConcurrentUpdateSolrClient Error when calling
SolrCmdDistributor$Req: cmd=add{,id=(null)}; node=StdNode:
http://127.0.0.1:59060/repfacttest_c8n_1x3_shard1_replica_n1/ to
http://127.0.0.1:59060/repfacttest_c8n_1x3_shard1_replica_n1/
[junit4] 2> => java.util.concurrent.ExecutionException:
java.util.concurrent.TimeoutException: idle_timeout
[junit4] 2> at
org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:221)
[junit4] 2> java.util.concurrent.ExecutionException:
java.util.concurrent.TimeoutException: idle_timeout
[junit4] 2> at
org.eclipse.jetty.client.util.InputStreamResponseListener.get(InputStreamResponseListener.java:221)
~[jetty-client-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.sendUpdateStream(ConcurrentUpdateHttp2SolrClient.java:240)
~[java/:?]
[junit4] 2> at
org.apache.solr.client.solrj.impl.ConcurrentUpdateHttp2SolrClient$Runner.run(ConcurrentUpdateHttp2SolrClient.java:176)
~[java/:?]
[junit4] 2> at
com.codahale.metrics.InstrumentedExecutorService$InstrumentedRunnable.run(InstrumentedExecutorService.java:181)
~[metrics-core-4.0.5.jar:4.0.5]
[junit4] 2> at
org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor.lambda$execute$0(ExecutorUtil.java:209)
~[java/:?]
[junit4] 2> at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
~[?:?]
[junit4] 2> at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
~[?:?]
[junit4] 2> at java.lang.Thread.run(Thread.java:830) [?:?]
[junit4] 2> Caused by: java.util.concurrent.TimeoutException: idle_timeout
[junit4] 2> at
org.eclipse.jetty.http2.client.http.HttpConnectionOverHTTP2.onIdleTimeout(HttpConnectionOverHTTP2.java:137)
~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.http2.client.http.HttpClientTransportOverHTTP2$SessionListenerPromise.onIdleTimeout(HttpClientTransportOverHTTP2.java:243)
~[http2-http-client-transport-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Session.notifyIdleTimeout(HTTP2Session.java:1165)
~[http2-common-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Session.onIdleTimeout(HTTP2Session.java:1003)
~[http2-common-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.http2.HTTP2Connection.onIdleExpired(HTTP2Connection.java:150)
~[http2-common-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.io.AbstractEndPoint.onIdleExpired(AbstractEndPoint.java:401)
~[jetty-io-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:171)
~[jetty-io-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
org.eclipse.jetty.io.IdleTimeout.idleCheck(IdleTimeout.java:113)
~[jetty-io-9.4.19.v20190610.jar:9.4.19.v20190610]
[junit4] 2> at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
[junit4] 2> at
java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
[junit4] 2> at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
~[?:?]
[junit4] 2> ... 3 more
# lots more logging from the leader about being unable to talk to the (down)
127.0.0.1:59108
{noformat}
> ReplicationFactorTest high failure rate on Windows jenkins VMs after
> 2019-06-22 OS/java upgrades
> ------------------------------------------------------------------------------------------------
>
> Key: SOLR-13599
> URL: https://issues.apache.org/jira/browse/SOLR-13599
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Priority: Major
> Attachments: thetaphi_Lucene-Solr-master-Windows_8025.log.txt
>
>
> We've started seeing some weirdly consistent (but not reliably reproducible)
> failures from ReplicationFactorTest when running on Uwe's Windows jenkins
> machines.
> The failures all seem to have started on June 22 -- when Uwe upgraded his
> Windows VMs to upgrade the Java version, but happen across all versions of
> java tested, and on both the master and branch_8x.
> While this test failed a total of 5 times, in different ways, on various
> jenkins boxes between 2019-01-01 and 2019-06-21, it seems to have failed on
> all but 1 or 2 of Uwe's "Windows" jenkins builds since that 2019-06-22, and
> when it fails the {{reproduceJenkinsFailures.py}} logic used in Uwe's jenkins
> builds frequently fails anywhere from 1-4 additional times.
> All of these failures occur in the exact same place, with the exact same
> assertion: that the expected replicationFactor of 2 was not achieved, and an
> rf=1 (ie: only the master) was returned, when sending a _batch_ of documents
> to a collection with 1 shard, 3 replicas; while 1 of the replicas was
> partitioned off due to a closed proxy.
> In the handful of logs I've examined closely, the 2nd "live" replica does in
> fact log that it recieved & processed the update, but with a QTime of over 30
> seconds, and it then it immediately logs an
> {{org.eclipse.jetty.io.EofException: Reset cancel_stream_error}} Exception --
> meanwhile, the leader has one ({{updateExecutor}} thread logging copious
> amount of {{java.net.ConnectException: Connection refused: no further
> information}} regarding the replica that was partitioned off, before a second
> {{updateExecutor}} thread ultimately logs
> {{java.util.concurrent.ExecutionException:
> java.util.concurrent.TimeoutException: idle_timeout}} regarding the "live"
> replica.
> ----
> What makes this perplexing is that this is not the first time in the test
> that documents were added to this collection while one replica was
> partitioned off, but it is the first time that all 3 of the following are
> true _at the same time_:
> # the collection has recovered after some replicas were partitioned and
> re-connected
> # a batch of multiple documents is being added
> # one replica has been "re" partitioned.
> ...prior to the point when this failure happens, only individual document
> adds were tested while replicas where partitioned. Batches of adds were only
> tested when all 3 replicas were "live" after the proxies were re-opened and
> the collection had fully recovered. The failure also comes from the first
> update to happen after a replica's proxy port has been "closed" for the
> _second_ time.
> While this conflagration of events might concievible trigger some weird bug,
> what makes these failures _particularly_ perplexing is that:
> * the failures only happen on Windows
> * the failures only started after the Windows VM update on June-22.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
