Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 3.2 M1
    • Fix Version/s: 3.2 GA
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      In the mean time see series of blog posts.

      Specific items:

      • Global config options via MVC namespace and Java config
      • Per request configuration overrides (timeout and task executor)
      • New controller return types DeferredResult, Callable, and AsyncTask
      • AsyncHandlerInterceptor as well Filter-related considerations

        Activity

        Hide
        Rossen Stoyanchev added a comment -

        Verify and document case where TCP connection times out before the AsyncContext timeout is reached.

        Show
        Rossen Stoyanchev added a comment - Verify and document case where TCP connection times out before the AsyncContext timeout is reached.
        Hide
        DOAN Duy Hai added a comment -

        The probleam is broader than just TCP timeout.

        There are many questions on StackOverflow (http://stackoverflow.com/questions/7124508/how-to-properly-detect-a-client-disconnect-in-servlet-spec-3) about situations when the client is disconnected (force close of browser) before the timeout on AsyncContext is reached. In this case the behavior of containers is somehow hectic. Sometimes an IOException is thrown sometimes not.

        The client disconnection and client timeout handling by the container is crucial.

        Suppose I set a ConcurrentMap on server side to wait for events and notify the client of changes. If the servlet code is unable to detect client disconnection, there is a risk that the map keeps some object longer than necessary (until next AsyncContext timeout) and that the Runnable code flushes data to the response without knowing that the socket is closed

        Show
        DOAN Duy Hai added a comment - The probleam is broader than just TCP timeout. There are many questions on StackOverflow ( http://stackoverflow.com/questions/7124508/how-to-properly-detect-a-client-disconnect-in-servlet-spec-3 ) about situations when the client is disconnected (force close of browser) before the timeout on AsyncContext is reached. In this case the behavior of containers is somehow hectic. Sometimes an IOException is thrown sometimes not. The client disconnection and client timeout handling by the container is crucial. Suppose I set a ConcurrentMap on server side to wait for events and notify the client of changes. If the servlet code is unable to detect client disconnection, there is a risk that the map keeps some object longer than necessary (until next AsyncContext timeout) and that the Runnable code flushes data to the response without knowing that the socket is closed
        Hide
        sridhar kondoji added a comment - - edited

        Freeing servlet threads will only help to handle more http connections. But you will still be limited on async thread pool. What if all the threads in async thread pool are long running. What will happen to the newest http connection that wants to access async controller? Will that request behave synchronously causing the servlet thread to wait as long as it takes response to finish?
        Thanks

        Show
        sridhar kondoji added a comment - - edited Freeing servlet threads will only help to handle more http connections. But you will still be limited on async thread pool. What if all the threads in async thread pool are long running. What will happen to the newest http connection that wants to access async controller? Will that request behave synchronously causing the servlet thread to wait as long as it takes response to finish? Thanks
        Hide
        Rossen Stoyanchev added a comment - - edited

        Unfortunately with the Servlet 3 async feature (based on blocking IO) there is no good way to detect when a client has gone away.

        Suppose I set a ConcurrentMap on server side to wait for events and notify the client of changes. If the servlet code is unable to detect client disconnection, there is a risk that the map keeps some object longer than necessary

        That's correct although the overhead of storing an AsyncContext is a lot smaller than using a thread. Also since the server timeout will typically be configured to one or two minutes, or under five anyway, every so often you can proactively set DeferredResult instances even if there are no new events and purge them from the ConcurrentMap.

        Show
        Rossen Stoyanchev added a comment - - edited Unfortunately with the Servlet 3 async feature (based on blocking IO) there is no good way to detect when a client has gone away. Suppose I set a ConcurrentMap on server side to wait for events and notify the client of changes. If the servlet code is unable to detect client disconnection, there is a risk that the map keeps some object longer than necessary That's correct although the overhead of storing an AsyncContext is a lot smaller than using a thread. Also since the server timeout will typically be configured to one or two minutes, or under five anyway, every so often you can proactively set DeferredResult instances even if there are no new events and purge them from the ConcurrentMap.
        Hide
        Rossen Stoyanchev added a comment -

        DeferredResult now has a isSetOrExpired method that can be used to check if the instance is still usable.

        Show
        Rossen Stoyanchev added a comment - DeferredResult now has a isSetOrExpired method that can be used to check if the instance is still usable.

          People

          • Assignee:
            Rossen Stoyanchev
            Reporter:
            Rossen Stoyanchev
            Last updater:
            Rossen Stoyanchev
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Days since last comment:
              1 year, 35 weeks, 4 days ago