100 beast runs and no failures so this looks fixed by Alan's latest
SOLR-9906 push.
On Mon, Jan 16, 2017 at 9:17 AM, Erick Erickson wrote:
> This is probably SOLR-9906 right? I'll go start my beasting from
> yesterday on a new pull.
>
> On Sun, Jan 15, 2017 at 8:11 PM,
This is probably SOLR-9906 right? I'll go start my beasting from
yesterday on a new pull.
On Sun, Jan 15, 2017 at 8:11 PM, Erick Erickson wrote:
> Pushkar:
>
> Yes, PeerSynchReplicationTest. I'm getting 21/100 failures when
> beasting on 6x so it's not a trunk-only
Pushkar:
Yes, PeerSynchReplicationTest. I'm getting 21/100 failures when
beasting on 6x so it's not a trunk-only issue. The script I was using
is Mark Miller's "The best Lucene / Solr beasting script in the world.
TM." here: https://gist.github.com/markrmiller/dbdb792216dc98b018ad
Here's the
Thanks Uwe, I didn't _think_ what I was seeing was possible.
I was using Mark's beast script with the option set that's supposed to
do a clean-and-compie first when I saw that error, so I don't quite
know what was up with that.
But with a manual clean that error went away so I'm on to others.
Erick,
Is this PeerSyncTest or PeerSyncReplicationTest?
Can you send me link to Jenkins build logs(if this is happening on
Jenkins).
I recently sent a patch to improve the validation check (in the
PeerSyncReplicationTest) made in order to figure out if node successfully
recovered via
Hi,
Are you sure that you ran ant clean on top level? It is impossible that this
error occurs if compilation was fine.
Uwe
Am 15. Januar 2017 22:10:27 MEZ schrieb Erick Erickson
:
>I was wondering about the failures and tried to beast it on my Pro on
>trunk which