Details

    • Type: Feature Request Feature Request
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: 3.1.0.ALPHA4
    • Component/s: Handler
    • Labels:
      None
    • Similar Issues:
      None

      Description

      Netty core doesn't detect an idle channel at all. There should be a ChannelHandler which triggers some action when a connection becomes idle. For example, a connection which didn't send a certain message for a certain amount of time could be closed automatically. To fulfill this requirement,

      1) A user should be able to define what an 'idle' channel is. (sensible default would be 'no communication for 10 seconds' for example)
      2) A user should be able to define what action should be performed when a channel becomes idle. (sensible default would be disconnection for example)
      3) A user should be able to add multiple instances of this handler so that one can enforce multiple rules.

        Issue Links

          Activity

          Hide
          Christian Migowski
          added a comment -

          I must admit that I am not terribly familiar with Nettty (yet), and there do not seem to be jUnit tests for this now, could you please give a brief example of how to setup the bootstrap (and constructing instances of the *TimeoutHandler classes, this is what I didn't get right now) to be able to both receive read and write timeouts?

          Show
          Christian Migowski
          added a comment - I must admit that I am not terribly familiar with Nettty (yet), and there do not seem to be jUnit tests for this now, could you please give a brief example of how to setup the bootstrap (and constructing instances of the *TimeoutHandler classes, this is what I didn't get right now) to be able to both receive read and write timeouts?
          Hide
          Trustin Lee
          added a comment -

          In your ChannelPipelineFactory, you can add ReadTimeoutHandler and WriteTimeoutHandler. For example:

          public class MyChannelPipelineFactory implements ChannelPipelineFactory {
          // You need to call timer.stop() when shutting down the application.
          private final Timer timer = new HashedWheelTimer(...);

          public ChannelPipeline getPipeline()

          { ChannelPipeline p = Channels.pipeline(); p.addLast("readTimeout", new ReadTimeoutHandler(timer, 10, TimeUnit.SECONDS)); p.addLast("writeTimeout", new WriterTimeoutHandler(timer, 10, TimeUnit.SECONDS)); ... p.addLast("handler", new MyHandler()); }

          }

          The remaining steps are same as ordinary Netty examples. Please pick one that uses ChannelPipelineFactory.

          Show
          Trustin Lee
          added a comment - In your ChannelPipelineFactory, you can add ReadTimeoutHandler and WriteTimeoutHandler. For example: public class MyChannelPipelineFactory implements ChannelPipelineFactory { // You need to call timer.stop() when shutting down the application. private final Timer timer = new HashedWheelTimer(...); public ChannelPipeline getPipeline() { ChannelPipeline p = Channels.pipeline(); p.addLast("readTimeout", new ReadTimeoutHandler(timer, 10, TimeUnit.SECONDS)); p.addLast("writeTimeout", new WriterTimeoutHandler(timer, 10, TimeUnit.SECONDS)); ... p.addLast("handler", new MyHandler()); } } The remaining steps are same as ordinary Netty examples. Please pick one that uses ChannelPipelineFactory.
          Hide
          Christian Migowski
          added a comment -

          Now I've tested it I see that you can really put the idleness detection code in your handler, thanks!
          However, in my opinion the fact that an timeout occured should not be propagated as an exception but as "timeout/idle event", because it is not really an exception but something you expect (after all, you added the handlers). But you are right, the code isn't much cluttered when you handle it as an exception (it would be just more obvious what happens as an explicit event).

          Show
          Christian Migowski
          added a comment - Now I've tested it I see that you can really put the idleness detection code in your handler, thanks! However, in my opinion the fact that an timeout occured should not be propagated as an exception but as "timeout/idle event", because it is not really an exception but something you expect (after all, you added the handlers). But you are right, the code isn't much cluttered when you handle it as an exception (it would be just more obvious what happens as an explicit event).
          Hide
          Christian Migowski
          added a comment -

          We've followed this up extensively on the mailing list, IMHO the idleness detection is complete and fully functional now, i.e. this issue can be closed from my point of view.

          Show
          Christian Migowski
          added a comment - We've followed this up extensively on the mailing list, IMHO the idleness detection is complete and fully functional now, i.e. this issue can be closed from my point of view.
          Hide
          Trustin Lee
          added a comment -

          Oh yes. I gotta close it. Thanks for your insightful yet prompt feed back!

          Show
          Trustin Lee
          added a comment - Oh yes. I gotta close it. Thanks for your insightful yet prompt feed back!

            People

            • Assignee:
              Trustin Lee
              Reporter:
              Trustin Lee
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: