Ok, I was preparing to do a long bisecting session, but I started with the 
commit you highlighted below (4271d573d60f39564c458e2d3fb7c14afb82d4d8) and 
the commit before that one (6481a2fde858520988f2ce28c02a15be3fe108e4). And 
as it turns out, it is the breaking commit.

If I build the commit of yours from December 3 it fails my test suite.
If I build the commit of Nik from Januari 6 it still passes my test.

I also tried reverting your commit on the v1.0.0.RC1 tag, but it gave me 
all kinds of conflicts so I could not test RC1 without your commit.

If you would like I can still do a full bisect, but I suspect I end up at 
your commit since I tested that one, and the one before.

Would it be possible for you to send a .patch without the unsafe stuff, so 
I can apply that to a commit and make a build?

Thanks in advance,

On Wednesday, February 5, 2014 6:10:35 PM UTC+1, Adrien Grand wrote:
>
>
> On Wed, Feb 5, 2014 at 6:01 PM, Nils Dijk <[email protected] <javascript:>>wrote:
>>
>> I was trying to find out if I could disable this unsafe 
>> string comparisons, but could not really find where that should be 
>> disabled. Is there an easy way for me to switch back that change? Do you 
>> know on what commit this was changed so I can revert that commit in my 
>> local clone of the repo, do a build to see if the problem is solved that 
>> way?
>>
>
> Sure, this was changed in 4271d573d60f39564c458e2d3fb7c14afb82d4d8 However 
> I also just read that you can't reproduce the issue with one shard although 
> this shouldn't be relevant.
>  
>
>> For reproducing I do not really see what could impact this besides from 
>> the OS and java version. And the other OSX machine was a different version 
>> of OS AND java, and still having the same results.
>>
>> I am however a bit more relaxed with the issue not showing up on our 
>> production machines, that would have killed the ES migration we are 
>> currently doing. Although it is unfortunate that we can not test our stuff 
>> on our developement machines (all showing the issue here).
>>
>> Do you have any thoughts on what could be different between our setups 
>> that we are having the issue, and you don't?
>>
>
> I wish I had ideas! :-)
>
> Since the issue seems to reproduce consistently for you, something that 
> would be super helpful would be to git bisect in order to find the commit 
> that broke aggregations in your setup (Beta2 commit is 296cfbe3 and rc1 
> commit is 2c8ee3fb).
>  
>
>> To make sure, you use my scripts to load it in? Since Jörg seemed to load 
>> the data on a different way (different shardcount and different mapping) 
>> which did not show the issues here.
>>
>
> Yes, I used your scripts, exactly as described in the README.
>  
> -- 
> Adrien Grand
>  

-- 
You received this message because you are subscribed to the Google Groups 
"elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/elasticsearch/ab8f000d-d0ee-4be8-aaa5-46d0718c56e8%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to