Proof is below. The main summary is that DateTimeFieldType.java has NO
hashCode method so returns different hashcodes in different JVMs
L.....and AbstractPartialDate's hashCode calls that hashCode which
varies from JVM to JVM so two dates that are equal become unequal. It
works in a single JVM since there is only one instance of
DateTimeFieldType in a JVM. First bug I hit in joda time after using it
for about 2 years(still way better than the jdk time api ;) ).
I have the following code to log what the LocalDate(or rather
AbstractPartialDate) is doing in it's hashCode method
It turns out the hashcode of the dt.getFieldType(i)(year, monthOfYear
and date are all different) returns different values on the different
servers!!!! Ouch!!!!
This email is html color coded from eclipse copy so not sure if you can
read it???.....
log.info("Resolver: saving rdbms key=" + overallKey
+ " hash1=" + pk.getAccountId().hashCode() + " hash2="
+ pk.getMarketvalueDt().hashCode());
LocalDate dt = pk.getMarketvalueDt();
for (int i = 0; i < dt.size(); i++) {
int val = dt.getValue(i);
int typeHash = dt.getFieldType(i).hashCode();
log.info("type=" + dt.getFieldType(i) + " hashVal=" + val
+ " hashType=" + typeHash);
}
log.info("hash=" + dt.getChronology().hashCode());
Log from server 1....
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingR
esolution
: Resolver: saving rdbms key=RdbmsKey
[rdbmsClass=com.broadridge.papr.olddb.marketvalue.ETLMvAccountDbo,
rdbmsKey=MvAccountPK [accountId=18487, marketvalueDt=2011-01-12]]
hash1=18487 hash2=-77876543
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: type=year hashVal=2011 hashType=20028211
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: type=monthOfYear hashVal=1 hashType=1235672037
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: type=dayOfMonth hashVal=12 hashType=1773059369
2011-04-29 13:41:53,209 INFO [Function Execution Processor1]
c.b.p.p.KeyMappingResolution
: hash=885211
Log from server 2
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: Resolver: saving rdbms key=RdbmsKey
[rdbmsClass=com.broadridge.papr.olddb.marketvalue.ETLMvAccountDbo,
rdbmsKey=MvAccountPK [accountId=18487, marketvalueDt=2011-01-12]]
hash1=18487 hash2=-1292312838
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: type=year hashVal=2011 hashType=1905251818
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: type=monthOfYear hashVal=1 hashType=438644709
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: type=dayOfMonth hashVal=12 hashType=2137747659
2011-04-29 13:41:53,210 INFO [PartitionedRegion Message Processor1]
c.b.p.p.KeyMappingResolution
: hash=885211
From: Hiller, Dean (Contractor)
Sent: Friday, April 29, 2011 1:32 PM
To: 'joda-interest@lists.sourceforge.net'
Subject: hashCode on LocalDate failed in this instance
We are using a nosql platform in which we shipped a LocalDate to another
server. The hashCode of LocalDate on the other server was different than
the one on my local server. I am still not why. The toString spit out
the exact same date AND on my local server when I serialize/deserialize,
the hashCode was still the same. It was only when I serialized the
LocalDate to another server and called hashcode that I received a
different result even though the toString is the exact same date on both
nodes.
Is LocalDate grabbing some different timezone from the local computer
instead of serializing and sending that date. All of this comes from
simple new LocalDate().plusOrMinusXXX(int x) calls. We don't use any
timezone stuff at this point though.
Thanks,
Dean
This message and any attachments are intended only for the use of the addressee
and
may contain information that is privileged and confidential. If the reader of
the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Joda-interest mailing list
Joda-interest@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/joda-interest
