Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-6364

Powering down the server host holding the .META. table causes HBase Client to take excessively long to recover and connect to reassigned .META. table

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 0.90.6, 0.92.1, 0.94.0
    • Fix Version/s: 0.94.2
    • Component/s: Client
    • Labels:
    • Hadoop Flags:
      Reviewed
    • Release Note:
      Hide
      The client (ipc.HBaseClient) now keeps a list of the failed connection attempts. It does not retry to connect before 2 seconds after a failure. This can be configured by setting "hbase.ipc.client.failed.servers.expiry": number of milliseconds before retrying the same server. Note that some clients retry multiple times to allow transient errors. If this parameter is set to a large value, these clients will fail without the server being actually retried.
      Show
      The client (ipc.HBaseClient) now keeps a list of the failed connection attempts. It does not retry to connect before 2 seconds after a failure. This can be configured by setting "hbase.ipc.client.failed.servers.expiry": number of milliseconds before retrying the same server. Note that some clients retry multiple times to allow transient errors. If this parameter is set to a large value, these clients will fail without the server being actually retried.
    • Tags:
      client, connection, timeout

      Description

      When a server host with a Region Server holding the .META. table is powered down on a live cluster, while the HBase cluster itself detects and reassigns the .META. table, connected HBase Client's take an excessively long time to detect this and re-discover the reassigned .META.

      Workaround: Decrease the ipc.socket.timeout on HBase Client side to a low value (default is 20s leading to 35 minute recovery time; we were able to get acceptable results with 100ms getting a 3 minute recovery)

      This was found during some hardware failure testing scenarios.

      Test Case:
      1) Apply load via client app on HBase cluster for several minutes
      2) Power down the region server holding the .META. server (i.e. power off ... and keep it off)
      3) Measure how long it takes for cluster to reassign META table and for client threads to re-lookup and re-orient to the lesser cluster (minus the RS and DN on that host).

      Observation:
      1) Client threads spike up to maxThreads size ... and take over 35 mins to recover (i.e. for the thread count to go back to normal) - no client calls are serviced - they just back up on a synchronized method (see #2 below)

      2) All the client app threads queue up behind the oahh.ipc.HBaseClient#setupIOStreams method http://tinyurl.com/7js53dj

      After taking several thread dumps we found that the thread within this synchronized method was blocked on NetUtils.connect(this.socket, remoteId.getAddress(), getSocketTimeout(conf));

      The client thread that gets the synchronized lock would try to connect to the dead RS (till socket times out after 20s), retries, and then the next thread gets in and so forth in a serial manner.

      Workaround:
      -------------------
      Default ipc.socket.timeout is set to 20s. We dropped this to a low number (1000 ms, 100 ms, etc) on the client side hbase-site.xml. With this setting, the client threads recovered in a couple of minutes by failing fast and re-discovering the .META. table on a reassigned RS.

      Assumption: This ipc.socket.timeout is only ever used during the initial "HConnection" setup via the NetUtils.connect and should only ever be used when connectivity to a region server is lost and needs to be re-established. i.e it does not affect the normal "RPC" actiivity as this is just the connect timeout.
      During RS GC periods, any new clients trying to connect will fail and will require .META. table re-lookups.

      This above timeout workaround is only for the HBase client side.

        Attachments

        1. 6364.94.v2.nolargetest.patch
          13 kB
          Nicolas Liochon
        2. 6364.94.v2.nolargetest.security-addendum.patch
          2 kB
          Nicolas Liochon
        3. 6364.v1.patch
          2 kB
          Nicolas Liochon
        4. 6364.v1.patch
          2 kB
          Nicolas Liochon
        5. 6364.v11.nolargetest.patch
          33 kB
          Nicolas Liochon
        6. 6364.v2.patch
          3 kB
          Nicolas Liochon
        7. 6364.v3.patch
          3 kB
          Nicolas Liochon
        8. 6364.v3.patch
          3 kB
          Nicolas Liochon
        9. 6364.v5.patch
          7 kB
          Nicolas Liochon
        10. 6364.v5.withtests.patch
          26 kB
          Nicolas Liochon
        11. 6364.v6.patch
          12 kB
          Nicolas Liochon
        12. 6364.v6.withtests.patch
          33 kB
          Nicolas Liochon
        13. 6364.v7.withtests.patch
          39 kB
          Nicolas Liochon
        14. 6364.v8.withtests.patch
          39 kB
          Nicolas Liochon
        15. 6364.v9.patch
          17 kB
          Nicolas Liochon
        16. 6364-host-serving-META.v1.patch
          2 kB
          Ted Yu
        17. stacktrace.txt
          16 kB
          Suraj Varma

          Issue Links

            Activity

              People

              • Assignee:
                nkeywal Nicolas Liochon
                Reporter:
                svarma Suraj Varma
              • Votes:
                1 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: