[tahoe-dev] [tahoe-lafs] #653: introducer client: connection count is wrong, !VersionedRemoteReference needs EQ
tahoe-lafs
trac at allmydata.org
Wed Mar 4 14:53:00 PST 2009
#653: introducer client: connection count is wrong, !VersionedRemoteReference
needs EQ
--------------------------+-------------------------------------------------
Reporter: warner | Owner:
Type: defect | Status: new
Priority: major | Milestone: undecided
Component: code-network | Version: 1.3.0
Keywords: | Launchpad_bug:
--------------------------+-------------------------------------------------
Zandr noticed that the prodnet webapi nodes are reporting 111 known
servers (which is correct) and 135 connected servers (which is not). The
root problem is that the !IntroducerClient uses object-identity
(specifically !RemoteReference identity) to manage the set of current
connections. Specifically {{{IntroducerClient._connections}}} is a set of
(peerid, service_name, rref) tuples, and the insertion/removal code
assumes that 'rref' values are comparable (it uses _connections.add() and
assumes that duplicates will be removed by the set class).
Unfortunately, the recent introduction of !VersionedRemoteReference
wrappers breaks this. The 135-111 extra ghost servers are actually two
different !VersionedRemoteReference objects which wrap the same original
!RemoteReference instance.
I'm not quite sure how to fix this. My first inclination is to stop using
!VersionedRemoteReference wrappers, and instead assign {{{.versions}}}
attributes to the regular !RemoteReference instances to achieve the
versioning functionality. However, I believe that
!VersionedRemoteReference also serves another purpose, which is to
transform all remote exceptions (everything returned by callRemote,
incidentally including local schema Violations) into a special form which
is easily recognizable. This is not as simple to achieve without a
wrapper.
Another approach would be to modify {{{__eq__}}} and {{{__hash__}}} (and
also {{{__ne__}}}? I'm never sure..) on !VersionedRemoteReference to pass
through to the original. A third approach would be to maintain a singleton
weak dict of some sort, which would help us make sure that we have at most
one !VersionedRemoteReference per !RemoteReference.
I prefer the first (no-wrapper) approach, but it may take some doing.
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/653>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list