DocsAndPositionsEnum.getPayload() is allowed to re-use the returned BytesRef under the hood.
So, if you want to hold a copy of the payload across two or more calls to .getPayload you'll have to make a deep copy of (BytesRef.deepCopyOf) the returned BytesRef yourself. Mike McCandless http://blog.mikemccandless.com On Wed, Jan 22, 2014 at 3:12 AM, Steven Schlansker <ste...@likeness.com> wrote: > On Wed, 22 Jan 2014 07:14:59 +0100 > Yann-Erwan Perio <ye.pe...@gmail.com> wrote: > >> On Tue, Jan 21, 2014 at 7:54 PM, Steven Schlansker >> <ste...@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-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
