Mailing-List: contact dev-help@curator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@curator.apache.org
From: Jordan Zimmerman <jordan@jordanzimmerman.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_BA4C62E6-639A-4B78-BC52-402A541F3CE8"
Message-Id: <8C219932-05A7-49B4-99F7-732D431FC784@jordanzimmerman.com>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Subject: Re: NamespaceWatcher hashCode and equals still bugging me
Date: Wed, 10 Feb 2016 08:48:27 -0500
References: 
 <CALuNCpipa4Fy58erHEG2=n_9wTXZSytL_-c5R8Tg2XuEXVfV1Q@mail.gmail.com>
 <82086D54-9F8D-43DF-90B8-A84B5789EE3D@jordanzimmerman.com>
 <CALuNCphxRvY3OtKyinVWvx9XGzjv=NAP+FxqwmcaP41QMYM8Xg@mail.gmail.com>
To: Scott Blum <dragonsinth@gmail.com>,
 dev@curator.apache.org
In-Reply-To: 
 <CALuNCphxRvY3OtKyinVWvx9XGzjv=NAP+FxqwmcaP41QMYM8Xg@mail.gmail.com>

--Apple-Mail=_BA4C62E6-639A-4B78-BC52-402A541F3CE8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Scott - are you OK with a release or should I wait for more discussion =
on this issue?

-Jordan

> On Feb 9, 2016, at 1:50 PM, Scott Blum <dragonsinth@gmail.com> wrote:
>=20
> Sounds like a job for weak hash map. Will follow up later with more
>=20
> On Feb 9, 2016 12:01 PM, "Jordan Zimmerman" =
<jordan@jordanzimmerman.com <mailto:jordan@jordanzimmerman.com>> wrote:
> > So.... taking a step back, what was underlying motivation for the =
hashCode / equality changes?  IE, what's the bigger problem we were =
trying to solve?
>=20
> Before this change, we were maintaining a map from Watcher to =
NamespaceWatcher so that we could track/remove the wrapped watcher. This =
is necessary due to this guarantee of ZooKeeper:
>=20
> =
http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#sc_WatchGu=
arantees =
<http://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#sc_WatchG=
uarantees>
>=20
> "if the same watch object is registered for an exists and a getData =
call for the same file and that file is then deleted, the watch object =
would only be invoked once with the deletion notification for the =
file.=E2=80=9D
>=20
> Given that NamespaceWatcher is an internal wrapper, Curator needs to =
generate the same NamespaceWatcher for a given client=E2=80=99s =
Watcher/CuratorWatcher. The map handled this. In the past, this was =
difficult to manage and had potential memory leaks if the map wasn=E2=80=99=
t managed correctly. It occurred to me that the map isn=E2=80=99t needed =
if NamespaceWatcher could have equality/hash values the same as the =
Watcher that it wraps. My testing proved this.
>=20
> Thoughts?
>=20
> -Jordan
>=20
>=20
> > On Feb 9, 2016, at 11:49 AM, Scott Blum <dragonsinth@gmail.com =
<mailto:dragonsinth@gmail.com>> wrote:
> >
> > Hi guys,
> >
> > I'm a practical guy, not a purist, but the 3.0 implementations of =
NamespaceWatcher.hashCode() and equals() are bothering me.  The reason I =
care is that I want to avoid subtle bugs cropping up.
> >
> > So here's the problem.
> >
> > 1) equals() is not reflexive between NamespaceWatcher and Watcher
> >
> > Assuming you have a NamespaceWatcher nw wrapping a Watcher w, the =
following code might or might not work:
> >
> > container.add(nw)
> > container.remove(w)
> >
> > It depends on whether the underlying container ultimately does =
"nw.equals(w)" or "w.equals(nw)".  Set.contains() would have the same =
problem.
> >
> > 2) hashCode() and equals() inconsistent with each other
> >
> > Because nw.hashCode() !=3D w.hashCode(), lookups in a hashSet or =
hashMap will practically never work except by luck.
> >
> > hashSet.put(nw)
> > hashSet.contains(w)
> >
> > Most of the time this will return false, except in the exact case =
where nw and w happen to have hashCodes that map into the same bucket, =
and the equality check is done the "right" order.
> >
> >
> > So.... taking a step back, what was underlying motivation for the =
hashCode / equality changes?  IE, what's the bigger problem we were =
trying to solve?
> >
> > Scott
> >
>=20


--Apple-Mail=_BA4C62E6-639A-4B78-BC52-402A541F3CE8--