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

[Java][2.8.4] test_no_conflicts_update_with_revs_limit failed due to unexpected exception

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.8.4
    • Component/s: Java
    • Security Level: Public
    • Labels:
      None
    • Story Points:
      1

      Description

      Mandatory:

      CBL / SG Version: cbs 6.6.1-9213, SG 2.8.1-13

      Steps to Reproduce:

      1. Have sg config with allow conflicts with some revs_limit        
      2. Create docs in CBL        
      3. Start a continous Replicator to have SG load all the docs. Verify if the no. of docs are same in both SG and CBL.        
      4. Update docs in CBL and also update docs through SG with number of times more than revs_limit. check the docs after replication become idle        
      5. Change the revs_limit less than actual revs limit        
      6. Restart sg        
      7. update doc 1 more time and let replication become idle        
      8. Verify revs limit is maintained with new modified revs_limit 

      Actual Result:

      after step 6, replicator stopped, got unexpected exception, calling for replicator status doesn't get smooth response.

      Expected Result:

      no unexpected exception, receive replicator stopped message or smooth message to keep test run to the end

      Logs : attached

      Github link for the code: 

      https://github.com/couchbaselabs/mobile-testkit/blob/master/testsuites/CBLTester/CBL_Functional_tests/TestSetup_FunctionalTests/test_no_conflicts_cbl.py#L202

      Jenkins job failure link: 

      http://uberjenkins.sc.couchbase.com:8080/job/CBLITE_Java-centos7-desktop-Functional-XATTRS-DELTA-SYNC-tests/110/testReport/testsuites.CBLTester.CBL_Functional_tests.TestSetup_FunctionalTests/test_no_conflicts_cbl/test_no_conflicts_update_with_revs_limit_sync_gateway_revs_conflict_configurable_10_25_/

      Pytest Command 

      pytest -s -rsx --timeout 1800 --liteserv-version=2.8.4-6 --liteserv-host=localhost --liteserv-port=8080 --no-conflicts --enable-file-logging --delta-sync --sg-ssl --sync-gateway-version=2.8.1-13 --mode=cc --server-version=6.6.1-9213 --liteserv-platform=java-macosx --create-db-per-test=cbl-test testsuites/CBLTester/CBL_Functional_tests/TestSetup_FunctionalTests -k test_no_conflicts_update_with_revs_limit[sync_gateway_revs_conflict_configurable-10-25] --use-local-testserver --skip-provisioning 

      What is the last build this test passed: 2.8.3-1 (java) 2.8.4-7 (android)

        Attachments

        1. 2.8.4-10-java-fixed.txt
          1.83 MB
        2. 2.8.4-8 java.zip
          190 kB
        3. 2.8.4-8-java-ws.txt
          1024 kB
        4. sg-restart-all.zip
          432 kB
        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

          Activity

          Hide
          blake.meike Blake Meike added a comment -

          Fixed in RC5

          Show
          blake.meike Blake Meike added a comment - Fixed in RC5
          Hide
          blake.meike Blake Meike added a comment - - edited

          Ian Bridge: I don't think there is any change in the doc here. Perhaps confirm with Priya etc.

          FWIW, the behavior is as follows:
          Any successful connection resets the backoff
          If, after a successful connection, the remote disconnects (closes the connection, a backhoe finds the wires, etc) Core will close the connection and retry after 2 seconds. If it cannot get a connection, it will retry with backoff.
          If it can get a connection, and the connection is broken again, it will, again, retry after 2 sec (the retry count was reset).
          If this connect and fail thing keeps happening, Core will give up after 3 retries (4 tries total)

          Show
          blake.meike Blake Meike added a comment - - edited Ian Bridge : I don't think there is any change in the doc here. Perhaps confirm with Priya etc. FWIW, the behavior is as follows: Any successful connection resets the backoff If, after a successful connection, the remote disconnects (closes the connection, a backhoe finds the wires, etc) Core will close the connection and retry after 2 seconds. If it cannot get a connection, it will retry with backoff. If it can get a connection, and the connection is broken again, it will, again, retry after 2 sec (the retry count was reset). If this connect and fail thing keeps happening, Core will give up after 3 retries (4 tries total)
          Hide
          eunice.huang Eunice Huang added a comment -

          still seeing issues with 2.8.4-8, logs attached. tested with java desktop and java webservice

          Show
          eunice.huang Eunice Huang added a comment - still seeing issues with 2.8.4-8, logs attached. tested with java desktop and java webservice
          Hide
          blake.meike Blake Meike added a comment -

          FIxed in 2.8.4-10, RC#6

          Show
          blake.meike Blake Meike added a comment - FIxed in 2.8.4-10, RC#6
          Hide
          eunice.huang Eunice Huang added a comment -

          run locally test passed. jenkins job still has some issue to pass, but it's not product related issue anymore. close this ticket.

          Show
          eunice.huang Eunice Huang added a comment - run locally test passed. jenkins job still has some issue to pass, but it's not product related issue anymore. close this ticket.

            People

            Assignee:
            blake.meike Blake Meike
            Reporter:
            eunice.huang Eunice Huang
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 6h
                6h

                  Gerrit Reviews

                  There are no open Gerrit changes

                    PagerDuty