Uploaded image for project: 'Spring Integration'
  1. Spring Integration
  2. INT-4511

Timeout is lost on AbstractMessageChannel#doSend

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Works as Designed
    • Affects Version/s: 5.0.6
    • Fix Version/s: None
    • Component/s: Core

      Description

      For example, when the channel in question is a pub-sub channel, then the implementation delegates to a broadcasting dispatcher, which simply sends the message to all subscribers, but the timeout is lost by then. I've only had a cursory look, but I think only the QueueChannel and PriorityChannel make use of that timeout argument.

      Shouldn't they set theĀ org.springframework.messaging.core.GenericMessagingTemplate#sendTimeoutHeader to the value of that timeout at least? In my case, for example, the stack trace is as follows

      at sun.misc.Unsafe.park(Unsafe.java:-1)
      at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
      at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
      at java.util.concurrent.LinkedBlockingQueue.put(LinkedBlockingQueue.java:350)
      at org.springframework.integration.channel.QueueChannel.doSend(QueueChannel.java:93)
      at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:453)
      at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:394)
      at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:181)
      at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:160)
      at org.springframework.messaging.core.GenericMessagingTemplate.doSend(GenericMessagingTemplate.java:47)
      at org.springframework.messaging.core.AbstractMessageSendingTemplate.send(AbstractMessageSendingTemplate.java:108)
      at org.springframework.integration.handler.AbstractMessageProducingHandler.sendOutput(AbstractMessageProducingHandler.java:426)
      at org.springframework.integration.handler.AbstractMessageProducingHandler.produceOutput(AbstractMessageProducingHandler.java:336)
      at org.springframework.integration.handler.AbstractMessageProducingHandler.sendOutputs(AbstractMessageProducingHandler.java:227)
      at org.springframework.integration.handler.AbstractReplyProducingMessageHandler.handleMessageInternal(AbstractReplyProducingMessageHandler.java:115)
      at org.springframework.integration.handler.AbstractMessageHandler.handleMessage(AbstractMessageHandler.java:165)
      at org.springframework.integration.dispatcher.BroadcastingDispatcher.invokeHandler(BroadcastingDispatcher.java:224)
      at org.springframework.integration.dispatcher.BroadcastingDispatcher.dispatch(BroadcastingDispatcher.java:180)
      at org.springframework.integration.channel.AbstractSubscribableChannel.doSend(AbstractSubscribableChannel.java:73)
      at org.springframework.integration.channel.AbstractMessageChannel.send(AbstractMessageChannel.java:453)
      at <custom handler>

      As you can see, the PublishSubscribeChannel broadcasts to QueueChannel instances (in this case, of capacity 1), and if it so happens that the queue has a message that hasn't been consumed, this

      a) blocks until the message is consumed, which is undesirable given that I've provided a timeout, and

      b) in case of a consumer flow that has been destroyed, blocks forever, which means we get a thread leak, because no one will ever interrupt the producer thread, which is now blocking on a QueueChannel of a dead flow. Which, of course, also means the QueueChannel is never going to be GCed.

      I guess, another way to go about this would be to make sure the user knows that the timeout isn't necessarily going to be used.

        Attachments

          Activity

            People

            • Assignee:
              abilan Artem Bilan
              Reporter:
              timurstrekalov Timur Strekalov
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: