jersey
  1. jersey
  2. JERSEY-2058

Make Jersey's async client truly asynchronous

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 2.2
    • Fix Version/s: 2.3
    • Component/s: None
    • Labels:
      None

      Description

      Currently, AsyncInvoker simply submits a runnable to a thread-pool, where a regular blocking IO operation is performed. While not blocking the submitting thread, the asynchronous operation still occupies a thread, and does not raise the limitation on the maximum number of concurrent requests, thereby making the entire feature only marginally useful (as it would not have been much harder to manually submit a synchronous call to a thread pool).

      Jersey's async client should employ asynchronous or selectable IO to bring AsyncInvoker to its full potential, and let clients enjoy the feature's real purpose of supporting a large number of concurrent requests.

        Issue Links

          Activity

          Hide
          Marek Potociar added a comment -

          What EXACTLY do you suggest? Do you have a concrete idea of what should be done? An example perhaps?

          Show
          Marek Potociar added a comment - What EXACTLY do you suggest? Do you have a concrete idea of what should be done? An example perhaps?
          Hide
          pron added a comment -

          Sure. A connector based on https://github.com/AsyncHttpClient/async-http-client, or a similar solution, would do the job.

          Asynchronous APIs are usually, as in this case, more complicated than synchronous ones. Their advantage, and their main purpose, is to allow for greater concurrency. As it stands, Jersey's async API doesn't provide any benefit. In fact, using Jersey's synchronous API in a Runnable submitted to an ExecutorService is both simpler, easier to understand, and performs just as well as using the async API in its current form.

          Of the few async http clients I've examined, the one mentioned actually performs as advertised: a request does not consume a thread (internally the library uses Netty, which, in turn, uses NIO selectors rather than thread-blocking IO calls (Jersey's default connector uses Java's URLConnection, that does a simple thread-blocking IO call). It allows making far more concurrent requests while consuming less system resources.

          Show
          pron added a comment - Sure. A connector based on https://github.com/AsyncHttpClient/async-http-client , or a similar solution, would do the job. Asynchronous APIs are usually, as in this case, more complicated than synchronous ones. Their advantage, and their main purpose, is to allow for greater concurrency. As it stands, Jersey's async API doesn't provide any benefit. In fact, using Jersey's synchronous API in a Runnable submitted to an ExecutorService is both simpler, easier to understand, and performs just as well as using the async API in its current form. Of the few async http clients I've examined, the one mentioned actually performs as advertised: a request does not consume a thread (internally the library uses Netty, which, in turn, uses NIO selectors rather than thread-blocking IO calls (Jersey's default connector uses Java's URLConnection, that does a simple thread-blocking IO call). It allows making far more concurrent requests while consuming less system resources.
          Hide
          Marek Potociar added a comment -

          I see, thanks for providing more details.

          Please have a look at [https://github.com/jersey/jersey/tree/master/connectors/grizzly-connector|Jersey Grizzly Connector]. It is actually using the AsyncHttpClient (1.7.15) that delegates to Grizzly provider for async I/O.

          IMO that connector will provide what you're asking for (once JERSEY-2070 is fixed - planned for this release). Closing as duplicate of JERSEY-2070.

          Show
          Marek Potociar added a comment - I see, thanks for providing more details. Please have a look at [https://github.com/jersey/jersey/tree/master/connectors/grizzly-connector|Jersey Grizzly Connector] . It is actually using the AsyncHttpClient (1.7.15) that delegates to Grizzly provider for async I/O. IMO that connector will provide what you're asking for (once JERSEY-2070 is fixed - planned for this release). Closing as duplicate of JERSEY-2070 .
          Hide
          pron added a comment -

          Yep. That should do it, though perhaps it should feature more prominently in the documentation (if not made default). After all, the async API is a major feature in JAX-RS 2.0, but is rendered all but useless with the default connector.

          Show
          pron added a comment - Yep. That should do it, though perhaps it should feature more prominently in the documentation (if not made default). After all, the async API is a major feature in JAX-RS 2.0, but is rendered all but useless with the default connector.

            People

            • Assignee:
              Marek Potociar
              Reporter:
              pron
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: