Uploaded image for project: 'Couchbase Lite'
  1. Couchbase Lite
  2. CBL-1812

p2p : Replicator is disconnecting when server is down

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Not a Bug
    • None
    • 3.0
    • LiteCore
    • Security Level: Public
    • None
    • 0
    • Critical

    Description

      • CBL : 3.0.0-112
      • Steps to Reproduce:

      1. Create docs on client & Server.
      2. Start the server.
      3. Start replication from client.
      4. Restart the server
      5. Verify replication is completed.
      6. Verify all docs got replicated on server

      • Actual Result:
        After the server restart replicator is throwing errors
      • Expected Result:'
        After the server restart replicator should reconnect
      • What is the last build this test passed: new test

      Attachments

        Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

            when server connect and disconnect multiple time In retry logic we need to verify whether retry values are resetting or not.

            manasa.ghanta Manasa Ghanta (Inactive) added a comment - when server connect and disconnect multiple time In retry logic we need to verify whether retry values are resetting or not.

            We do have couple of tests where we restart the SG , and verifies the replicator is connected successfully and document are replicated.

            Do you mean the test passed with SG but not the listener?

            pasin Pasin Suriyentrakorn added a comment - We do have couple of tests where we restart the SG , and verifies the replicator is connected successfully and document are replicated. Do you mean the test passed with SG but not the listener?

            Functionally,

            For p2p

            A stop on the p2p websockets listener should be considered a graceful shutdown and the replicator should not retry. Otherwise, ideally, replicator should retry.

            If we cannot distinguish distinguish between a "temporary" shutdown (and restart) and permanent shutdown (eg stop()), then it makes more sense that replicator just not retry in either case. Didn't we add the bug fix related to this in 2.8.4 ? https://issues.couchbase.com/browse/CBSE-9615

             

             

            For SGW sync

            That isn't quite the case for Sync Gateway.  There are many cases where a sync gateway may be temporarily down (upgrades, config/sync function changes, resource issues like OOM causing a restart ...) and not permanently go away. I don't think all the connected client should be disconnected and forced to restart a replication.  

            I think in case of SGW, it is more often than not that the SGW "going away" event is a temporary event so the client should continually retry subject to the retry parameters,

            priya.rajagopal Priya Rajagopal added a comment - Functionally, For p2p A stop on the p2p websockets listener should be considered a graceful shutdown and the replicator should not retry. Otherwise, ideally, replicator should retry. If we cannot distinguish distinguish between a "temporary" shutdown (and restart) and permanent shutdown (eg stop()), then it makes more sense that replicator just not retry in either case. Didn't we add the bug fix related to this in 2.8.4 ? https://issues.couchbase.com/browse/CBSE-9615     For SGW sync That isn't quite the case for Sync Gateway.  There are many cases where a sync gateway may be temporarily down (upgrades, config/sync function changes, resource issues like OOM causing a restart ...) and not permanently go away. I don't think all the connected client should be disconnected and forced to restart a replication.   I think in case of SGW, it is more often than not that the SGW "going away" event is a temporary event so the client should continually retry subject to the retry parameters,
            jimb Jim Borden added a comment -

            That CBSE is regarding something else. There is a large difference in the way that Sync Gateway functions in constrast to P2P. Sync Gateway is a cloud based function and is not expected to ever really be "stopped". It can go offline, crash, or the connection could be cut and all of these would be temporary situations. There is no equivalent in Sync Gateway to the P2P stop method. P2P is meant to be a mesh of connected devices that can come and go as they please. When they go, assuming they announce their departure via stop, this means that they won't come back. If the connection is severed, or they crash then this should be a temporary situation if possible (it will really depend on if the error received is significantly different than one that is considered permanent), but stop means that host is finished and it won't come back again for a significant amount of time.

            jimb Jim Borden added a comment - That CBSE is regarding something else. There is a large difference in the way that Sync Gateway functions in constrast to P2P. Sync Gateway is a cloud based function and is not expected to ever really be "stopped". It can go offline, crash, or the connection could be cut and all of these would be temporary situations. There is no equivalent in Sync Gateway to the P2P stop method. P2P is meant to be a mesh of connected devices that can come and go as they please. When they go, assuming they announce their departure via stop, this means that they won't come back. If the connection is severed, or they crash then this should be a temporary situation if possible (it will really depend on if the error received is significantly different than one that is considered permanent), but stop means that host is finished and it won't come back again for a significant amount of time.

            As discussed in the meeting SG will reconnect.In peer to peer , if server peer is stopped replicator also stops.

            manasa.ghanta Manasa Ghanta (Inactive) added a comment - As discussed in the meeting SG will reconnect.In peer to peer , if server peer is stopped replicator also stops.

            People

              manasa.ghanta Manasa Ghanta (Inactive)
              manasa.ghanta Manasa Ghanta (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes

                  PagerDuty