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

Camel netty4 requestTimeout doesn't work as expected

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • fuse-6.3-R16-GA
    • jboss-fuse-6.2.1
    • Camel

    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
              rhn-support-adongre Avinash Dongre
              Lucia Drozdova Lucia Drozdova
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: