Uploaded image for project: 'Red Hat Fuse'
  1. Red Hat Fuse
  2. ENTESB-9543

Git Read/Write lock contention caused by "watch" commands

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • fuse-6.x-GA
    • jboss-fuse-6.3
    • Fabric8 v1
    • None
    • % %
    • Hide

      No workaround identified

      Show
      No workaround identified
    • Hide

      Steps for a local reproducer are as follows:

      • Create fabric, 6.3.0 R7, host name = "host1" with ssh containers "sshhost2" and "sshhost3", user/password for host1=admin/admin
      • start reproducer (attached reproducer-single.sh), please adjust FUSE_HOME variable to your env
      • open karaf client in local, issue command "watch profile-display test1"
      • open another karaf client in local, issue command "watch container-list"
      • While reproducing is sending karaf commands (You see "setting value...), you may Ctrl+c the "watch container-list" command, and there should appear a "Git read lock" error on local log

      The steps to reproduce it on customer env were:

      • Log into the container and start a "watch" command that would hit the datastore, like "container-info"
      • Log into the container from a new session and run another watch command that involves the git datastore
      • Now, try to perform some profile edits or profile creation commands from a third session

      When we did this, we started seeing the read lock / write lock errors.

      Show
      Steps for a local reproducer are as follows: Create fabric, 6.3.0 R7, host name = "host1" with ssh containers "sshhost2" and "sshhost3", user/password for host1=admin/admin start reproducer (attached reproducer-single.sh), please adjust FUSE_HOME variable to your env open karaf client in local, issue command "watch profile-display test1" open another karaf client in local, issue command "watch container-list" While reproducing is sending karaf commands (You see "setting value...), you may Ctrl+c the "watch container-list" command, and there should appear a "Git read lock" error on local log The steps to reproduce it on customer env were: Log into the container and start a "watch" command that would hit the datastore, like "container-info" Log into the container from a new session and run another watch command that involves the git datastore Now, try to perform some profile edits or profile creation commands from a third session When we did this, we started seeing the read lock / write lock errors.

      Threads executing commands requiring git datastore access grab the git lock and hold onto it for a time.

              ggrzybek Grzegorz Grzybek
              rhn-support-anarvaez Alfredo Narvaez
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: