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

Camel netty4 requestTimeout doesn't work as expected

    XMLWordPrintable

Details

    Description

      It seems that camel netty4 does not enforce the read timeout for every single request. It appears to be channel-specific. So, if the response for a request is received, the timeout handler is removed from its channel and if a subsequent request uses the same channel, the read timeout is never triggered for it.

      *First Message with immediate response:*
      2019-12-27 11:28:44.347 DEBUG 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Creating connector to address: localhost:8082
      2019-12-27 11:28:44.349 DEBUG 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Channel: [id: 0x1cec011f, L:/127.0.0.1:35600 - R:localhost/127.0.0.1:8082] writing body: [115, 100, 102, 119, 97, 101, 102, 119, 101, 102, 97, 119, 101, 102, 115, 97, 100, 102, 97, 115, 100, 102, 10]
      2019-12-27 11:28:44.393 TRACE 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Operation complete DefaultChannelPromise@4cc9ffa(success)
      2019-12-27 11:28:44.394 TRACE 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Channel open: [id: 0x1cec011f, L:/127.0.0.1:35600 - R:localhost/127.0.0.1:8082]
      2019-12-27 11:28:48.404 TRACE 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Message received: [83, 101, 110, 100, 105, 110, 103, 32, 116, 104, 105, 115, 32, 114, 101, 115, 112, 111, 110, 115, 101]
      2019-12-27 11:28:48.404 TRACE 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Removing timeout channel as we received message
      2019-12-27 11:28:48.405 DEBUG 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Channel: [id: 0x1cec011f, L:/127.0.0.1:35600 - R:localhost/127.0.0.1:8082] received body: [83, 101, 110, 100, 105, 110, 103, 32, 116, 104, 105, 115, 32, 114, 101, 115, 112, 111, 110, 115, 101]
      2019-12-27 11:28:48.409 TRACE 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Putting channel back to pool [id: 0x1cec011f, L:/127.0.0.1:35600 - R:localhost/127.0.0.1:8082]
      
      *Second message with delayed response:*
      2019-12-27 11:28:48.464  INFO 8048 --- [msConsumer[ALQ]] route1                                   : Sending message delay
      2019-12-27 11:28:48.465 TRACE 8048 --- [msConsumer[ALQ]] o.a.c.component.netty4.NettyProducer     : Pool[active=0, idle=1]
      2019-12-27 11:28:48.465 TRACE 8048 --- [msConsumer[ALQ]] o.a.c.component.netty4.NettyProducer     : activateObject channel request: AbstractBootstrap$PendingRegistrationPromise@47972e3b(success) -> {}
      2019-12-27 11:28:48.465 TRACE 8048 --- [msConsumer[ALQ]] o.a.c.component.netty4.NettyProducer     : Validating channel: [id: 0x1cec011f, L:/127.0.0.1:35600 - R:localhost/127.0.0.1:8082] -> true
      2019-12-27 11:28:48.466 TRACE 8048 --- [msConsumer[ALQ]] o.a.c.component.netty4.NettyProducer     : Got channel request from pool AbstractBootstrap$PendingRegistrationPromise@47972e3b(success)
      2019-12-27 11:28:48.468 DEBUG 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Channel: [id: 0x1cec011f, L:/127.0.0.1:35600 - R:localhost/127.0.0.1:8082] writing body: [100, 101, 108, 97, 121]
      2019-12-27 11:28:48.470 TRACE 8048 --- [ClientTCPWorker] o.a.c.component.netty4.NettyProducer     : Operation complete DefaultChannelPromise@5b0622d2(success)
      

      Attachments

        Issue Links

          Activity

            People

              jondruse@redhat.com Jiri Ondrusek
              jondruse@redhat.com Jiri Ondrusek
              Francesco Mongiardo Francesco Mongiardo
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: