I think this is fixed in svn. I'm on holiday and cannot check...
Stephen
On 29/04/2011, Hiller, Dean (Contractor) <dean.hil...@broadridge.com> wrote:
> 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
