lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Schlansker <ste...@likeness.com>
Subject Re: BytesRef equals() method
Date Wed, 22 Jan 2014 08:12:24 GMT
On Wed, 22 Jan 2014 07:14:59 +0100
Yann-Erwan Perio <ye.perio@gmail.com> wrote:

> On Tue, Jan 21, 2014 at 7:54 PM, Steven Schlansker
> <steven@likeness.com> wrote:
> 
> Certainly, but my problem still persists if I do not do it. I spent
> the whole night debugging the code, to no avail. As a matter of fact,
> when I run a series of tests on my application, the following happens
> about once out of ten times (this is the resulting log of some sysout
> calls):
> 
> Payload: toString=Nc6, bytes=[4e 63 36], offset=3, length=3,
> hashcode=78081 map.keySet()=[[4e 63 36]]
> Now testing map.contains(payload)
> map.contains(payload)==false
> Now testing map.isEmpty()
> map.isEmpty()==false
> Map is not empty. Manually iterating keys.
> Key n°1: toString=Nc6, bytes=[4e 63 36], offset=3, length=3,
> hashcode=78081 Verifying key.equals(payload)==true
> Verifying map.containsKey(payload)==false
> Verifying map.containsKey(key)==false
> 
> As you can see, the map provides the key I am looking for, but it
> cannot identify it back! Going through the HashMap data structure, it
> was indeed assigned a different hashCode (73787).
> 
> I do not understand how this could happen. I thought that there was
> maybe a concurrency issue with the payload itself - as if it were
> reused in concurrent scoring processes (I use the payload sent back by
> DefaultSimilarity) - but the faulty hashCode, as far as I can see,
> should not be generated by my test data set.
> 
> I'll try looking again at the code with fresh eyes, but in the
> meanwhile, do not hesitate to tell me if this makes sense to you.

It sounds like you've already considered this somewhat, but I'd guess
that by far the most likely cause here is modification of either the
byte[] or the offset/length somewhere behind your back.  Perhaps the
BytesRef itself is unexpectedly shared such that two different
processes use it for their own purposes.

If you can't find that, perhaps try to pare down a self-contained test
case.

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message