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

Fabric8 gateway does not close client connections even when the target container has crashed

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • None
    • jboss-fuse-6.3
    • Fabric8 v1
    • None
    • % %
    • Hide

      1. Set up three child containers – one with gateway-http, and two with a CXF endpoint (e.g., the REST quickstart example).
      2. Making HTTP requests on the gateway port for the CXF endpoints using, e.g., curl
      3. Note from the container logs that the client requests are directed alternately to the service containers
      4. Execute kill -9 on one of the service containers
      5. Attempt to make multiple requests on the gateway from the HTTP client
      6. Note that half of these requests appear to hang – the gateway never disconnects the clients, even after it knows that the target container is down. So new requests might be serviced correctly, while old requests cannot be re-tried until the client itself times out

      Show
      1. Set up three child containers – one with gateway-http, and two with a CXF endpoint (e.g., the REST quickstart example). 2. Making HTTP requests on the gateway port for the CXF endpoints using, e.g., curl 3. Note from the container logs that the client requests are directed alternately to the service containers 4. Execute kill -9 on one of the service containers 5. Attempt to make multiple requests on the gateway from the HTTP client 6. Note that half of these requests appear to hang – the gateway never disconnects the clients, even after it knows that the target container is down. So new requests might be serviced correctly, while old requests cannot be re-tried until the client itself times out

    Description

      When HTTP clients use the Fabric8 gateway for sharing requests for HTTP services among containers, it takes a surprisingly long time for a client of the gateway to respond to a situation where one of the service containers fails.

      The first problem, which might be unavoidable, is the time it takes for the gateway to realise that one of its target containers has crashed. It responds a lot more quickly to a orderly shut-down because, I presume, the container that is shutting down is able to close its ZK session properly. However, responding to a crash relies, I think, on ZK heartbeats and timeouts.

      The second problem, though, is that the gateway maintains a client connection even after it has learned that the container it is trying to communicate on behalf of that client with is no longer available. At a time at which new requests on the gateway might be handled correctly, by being directed to one of the surviving containers, old requests are stuck, waiting for the client to time out.

      When the gateway realizes that one of its service endpoints is no longer available, for whatever reason, any client connections to the gateway ought to be closed immediately, so that clients can respond to a failure more promptly.

      Attachments

        Issue Links

          is related to

          Feature Request - Feature requests from customers and/or users ENTESB-7648 HTTP gateway to allow http request timeout to be set

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          relates to

          Bug - A problem that impairs or prevents the functions of the product. ENTESB-11978 Gateway not closing connections on node

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Done

          Activity

            People

              atarocch@redhat.com Andrea Tarocchi (Inactive)
              rhn-support-kboone Kevin Boone
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: