Synapse
  1. Synapse
  2. SYNAPSE-584

Enhance the non-blocking HTTP/S transports to recover from possible exceptions

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: NIGHTLY
    • Fix Version/s: NIGHTLY, 3.0
    • Component/s: Transports
    • Labels:
      None

      Description

      See http://markmail.org/thread/3moet7es5bsvx2r6 for issue description and log files provided by Mike Obendorf and Daniel Moise

      Enhancing HttpComponents as per HTTPCORE-208 would allow us better control to handle failures that could be corrected at a connection level. On fatal IOReactor exceptions, Synapse could auto-restart the reactors, than filling up the log files and continuing (This was already proposed by Eric Hubert)

      As an initial step, the fix proposed by Daniel Moise seems sufficient, as we will need to wait till HttpCore 4.1-beta1 for HTTPCORE-208 when we should be able to fix this with a more robust recovery mechanism that will cover other possibilities

        Issue Links

          Activity

          Hide
          Ruwan Linton added a comment -

          Asankha, when you are properly fixing this, please have a look at the issue SYNAPSE-592 as well. The temporary fix to this issue resolve SYNAPSE-592 as well, and from my understanding proper fix will also fix that issue. Hence I am resolving the duplicated issue SYNAPSE-592.

          Show
          Ruwan Linton added a comment - Asankha, when you are properly fixing this, please have a look at the issue SYNAPSE-592 as well. The temporary fix to this issue resolve SYNAPSE-592 as well, and from my understanding proper fix will also fix that issue. Hence I am resolving the duplicated issue SYNAPSE-592 .
          Hide
          Hiranya Jayathilaka added a comment -

          I'm going to resolve this issue as fixed.

          Over the years, the error handling features of the NHTTP transport has been significantly improved and subjected to extensive testing. These improvements have been adopted by the new PTT transport as well. The HTTPCORE-208 referenced in the above description has been resolved as invalid. It seems the HC community has reached a consensus that IOSession related errors should be handled at the respective protocol handlers. And the NHTTP/PTT protocol handlers have been improved over the years to handle session specific errors appropriately. So I think this is no longer a problem. In fact, I haven't seen any infinite loops or unexpected crashes in the NHTTP/PTT transports over the last couple of years.

          I also tested the scenario outlined in the above mailing list discussion (Synapse running into an infinite loop when the request URL is malformed). But this is gracefully handled in the PTT transport. Synapse didn't throw any errors, and the client received a 400 Bad Request message:

          • Connected to localhost (::1) port 8280 (#0)
            > GET /foo bar/baz HTTP/1.1
            > User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5
            > Host: localhost:8280
            > Accept: /
            >
            < HTTP/1.1 400 Bad request
            < Connection: Close
            < Date: Thu, 08 Aug 2013 23:07:14 GMT
            < Server: Synapse-PassThrough-HTTP
            < Content-Length: 0
            <
          • Closing connection #0

          I believe this is pretty much the optimal behavior.

          Show
          Hiranya Jayathilaka added a comment - I'm going to resolve this issue as fixed. Over the years, the error handling features of the NHTTP transport has been significantly improved and subjected to extensive testing. These improvements have been adopted by the new PTT transport as well. The HTTPCORE-208 referenced in the above description has been resolved as invalid. It seems the HC community has reached a consensus that IOSession related errors should be handled at the respective protocol handlers. And the NHTTP/PTT protocol handlers have been improved over the years to handle session specific errors appropriately. So I think this is no longer a problem. In fact, I haven't seen any infinite loops or unexpected crashes in the NHTTP/PTT transports over the last couple of years. I also tested the scenario outlined in the above mailing list discussion (Synapse running into an infinite loop when the request URL is malformed). But this is gracefully handled in the PTT transport. Synapse didn't throw any errors, and the client received a 400 Bad Request message: Connected to localhost (::1) port 8280 (#0) > GET /foo bar/baz HTTP/1.1 > User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8r zlib/1.2.5 > Host: localhost:8280 > Accept: / > < HTTP/1.1 400 Bad request < Connection: Close < Date: Thu, 08 Aug 2013 23:07:14 GMT < Server: Synapse-PassThrough-HTTP < Content-Length: 0 < Closing connection #0 I believe this is pretty much the optimal behavior.
          Hide
          Hiranya Jayathilaka added a comment -

          Resolving since the current behavior is correct. Feel free to reopen if anybody encounters a situation where the HTTP transport goes into infinite loop or just crashes unexpectedly.

          Show
          Hiranya Jayathilaka added a comment - Resolving since the current behavior is correct. Feel free to reopen if anybody encounters a situation where the HTTP transport goes into infinite loop or just crashes unexpectedly.

            People

            • Assignee:
              Hiranya Jayathilaka
              Reporter:
              Asankha C. Perera
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development