[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