Uploaded image for project: 'JGroups'
  1. JGroups
  2. JGRP-682

TUNNEL: reconnector thread is not started in certain scenarios

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 2.6.2, 2.7
    • None
    • None
    • Workaround Exists
    • Hide

      Start the GossipRouter first (may not be feasible all the time)

      Show
      Start the GossipRouter first (may not be feasible all the time)

      This is in TUNNEL.StubConnectionListener:

      public void connectionStatusChange(int newState) {
      if(currentState == RouterStub.STATUS_CONNECTED && newState == RouterStub.STATUS_CONNECTION_LOST)

      { startReconnecting(); }

      else if(currentState != RouterStub.STATUS_CONNECTED && newState == RouterStub.STATUS_CONNECTED)

      { stopReconnecting(); Thread receiver = new Thread(Util.getGlobalThreadGroup(), new TunnelReceiver(), "TUNNEL receiver"); receiver.setDaemon(true); receiver.start(); }

      currentState = newState;
      }

      1. 1: why do we need 3 states ? Why not just CONNECTED and DISCONNECTED ?

      #2: the logic above is incorrect, as it doesn't handle all state transitions ! For example, if we go from DISCONNECTED to CONNECTION_LOST, we will not start the reconnector thread !

      We can reproduce #2 through the following steps:

      • Start node A (channel with with tunnel.xml) (GossipRouter is not running)
      • Start node B (start GossipRouter then channel with tunnel.xml)
        ==> The nodes will not merge. Reason: there is never a CONNECT from node A, only REGISTER calls. If there is no CONNECT, we never set the GossipRouter$AddressEntry.output field and therefore can never send anything !

              vblagoje Vladimir Blagojevic (Inactive)
              rhn-engineering-bban Bela Ban
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

                Created:
                Updated:
                Resolved: