[Bugs] #3326 UNSP: Telepathy signals connected twice when connecting to jabber

Sugar Labs Bugs bugtracker-noreply at sugarlabs.org
Tue Feb 14 10:03:14 EST 2012


#3326: Telepathy signals connected twice when connecting to jabber
------------------------------------------+---------------------------------
    Reporter:  dsd                        |          Owner:                             
        Type:  defect                     |         Status:  new                        
    Priority:  Unspecified by Maintainer  |      Milestone:  Unspecified by Release Team
   Component:  sugar                      |        Version:  Unspecified                
    Severity:  Unspecified                |       Keywords:                             
Distribution:  Unspecified                |   Status_field:  Unconfirmed                
------------------------------------------+---------------------------------
 When connecting to jabber, some telepathy signals are connected twice in
 the _Account class (model/neighborhood.py). Here's what happens:

  * The first connection attempt always tries to register to the server as
 well as connect
  * _Account.start_listening() is called, which connects to
 !__account_property_changed_cb on
 http://telepathy.freedesktop.org/spec/Account.html
  * The connection is initiated by telepathy, and
 !__account_property_changed_cb is called notifying this - providing a
 Connection object which is in state "Connecting".
    * As we previously didn't have a Connection object,
 !__account_property_changed_cb calls _prepare_connection
  * _prepare_connection instantiates the telepathy-client Connection
 interface on the object we just received, connecting a ready handler which
 will be fired once the initial status of the Connection is known
  * The server rejects our connection because we were already registered.
  * !__account_property_changed_cb is fired with a connection of "/" and a
 connection error of "org.freedesktop.Telepathy.Error.RegistrationExists"
    * so we hit this code in !__account_property_changed_cb :
 {{{
         if properties['Connection'] == '/':
             self._check_registration_error()
             self._connection = None
 }}}

  * note how that the _connection object here is "forgotten", however it
 still resides in memory and is still activating itself and will fire its
 ready handler later
  * _check_registration_error updates the account to try and login without
 registering and the connection is restarted
  * The connection is restarted by telepathy, and
 !__account_property_changed_cb is called notifying this - providing a
 Connection object which is in state "Connecting".
    * As self._connection is None, !__account_property_changed_cb calls
 _prepare_connection
  * _prepare_connection instantiates '''ANOTHER''' telepathy-client
 Connection interface on the object we just received, connecting a ready
 handler which will be fired once the initial status of the Connection is
 known
    * We now have two active Connection objects for the same telepathy
 connection
  * The ready handlers of both Connection objects fire, and
 !__connection_ready_cb hence fires twice
  * From here on, all signal handlers are connected in duplicate due to us
 having two Connection objects tracking the same connection

 One way to fix this would be to remove the "self._connection = None"
 assignment from the code block pasted above. However, I'm not sure if it
 is 100% correct and I think I can envision a better design for this code:

 The Account interface (http://telepathy.freedesktop.org/spec/Account.html)
 conveniently provides properties which duplicate properties from the
 Connection (ConnectionStatus, etc). We should look at these property
 values (and the AccountPropertyChanged signal which conveniently notifies
 us of updates), and we should only call _prepare_connection when the
 Account interface has told us that we have a Connection and that the
 connection is actually connected.

-- 
Ticket URL: <http://bugs.sugarlabs.org/ticket/3326>
Sugar Labs <http://sugarlabs.org/>
Sugar Labs bug tracking system


More information about the Bugs mailing list