ActiveMQ
  1. ActiveMQ
  2. AMQ-3597

Enable RedeliveryPolicy to determine next delay independent of the consumer

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 5.5.1
    • Fix Version/s: 5.x
    • Component/s: Broker
    • Labels:
      None

      Description

      Currently the redelivery is bound to the consumer instance requiring the end user to use the same message consumer instance. This is due to the fact that the redelivery delay is computated based on the previous redelivery delay (stored with the consumer instance) and not based on the redeliveryCount of the message.

        Issue Links

          Activity

          Hide
          Timothy Bish added a comment -

          We do something like this in the .NET ActiveMQ client where we calculate the redelivery delay based on the number of redeliveries of the message and no to the consumers record of the last delay.

          Show
          Timothy Bish added a comment - We do something like this in the .NET ActiveMQ client where we calculate the redelivery delay based on the number of redeliveries of the message and no to the consumers record of the last delay.
          Hide
          Eric Hubert added a comment -

          Implementing this part alone is really trivial and was very quickly done, but the problem is, that this is not the only limitation why the same consumer instance must be used. So this alone would be of no value.

          Currently the ActiveMQMessageConcumser is scheduling a task to perform the relivery. If there are multiple consumers, another consumer will simply grab the same message arriving again from the broker and do a normal delivery (so without any delay and completely asynchrounous to the scheduled thread still waiting). At some point I have not yet clearly identified the broker must get an ACK or something like this. Maybe as a result of a consumer or session close.

          So far I have just experimented with the code to get a better understanding on how this was ever intended to work correctly (especially if using a transaction manager to mange the transactions explicitely and not letting AMQ automatically perform the commit or rollback based on exceptions with a transacted session).

          According to the design document at http://activemq.apache.org/message-redelivery-and-dlq-handling.html

          " [...] On rollback, since nothing has been acked yet, and all messages are still available in an internal consumer queue, the messages are re-dispatched from the internal consumer queue. This reduces redelivery dispatch overhead, at the cost of the broker not being aware that redeliveries are occurring. [...]"

          since ActiveMQ 4 the broker shall not be aware of redeliveries at all and only the consumer should perform the redelivery from a local queue to possibly relieve the broker from some work improving scalability. Unfortunately if I got it right the end user cannot choose between either client or broker controlled redelivery (or 4.x versus 3.x behavior).

          In order to make this work I would only see the two theoretical options (not sure whether any of those are correct and feasible):

          a) The broker will not be informed about the redeliveries as a result of a rollback at all (only indirectly, if optionally persisting modified messages (redeliverey counter). As long as a consumer is not acknowledging the broker will not deliver the same message to another consumer. But I think incase of a transacted session, such an acknowledgement must be sent, or?

          b) The broker will be informed about rollbacks in order to trigger a resend of the same message. Any consumer receiving a message will first check the current redelivery count and postpone the actual delivery of this message for a calculated duration if required. If the redelivery count is 0, it will of course be processed immediately.

          As I could not quickly detect the place where the broker gets signaled that it shall resend the message for which a rollback was done, I simply "hacked a bit of code" for the purpose of testing and understanding, which performs the conditional wait based on the modified RedeliveryPolicy calculating the delay based on the counter right inside the ActiveMQSessionExecutor#execute prior dispatching the message. So any message arriving at this point will be hold of from dispatching to the local queue until the calculated delay according to the redelivery attempt has passed. Of course in parallel I commented the scheduled redelivery task for asynchronous execution. So this is something a long the line of option b) mentioned above.

          And this is the first time I could see a working redelivery with multiple consumer threads using the PooledConnectionFactory, an external TransactionManager, and neither cache level, sessionAcknowledgeMode nor sessionTransacted configured on Spring's DefaultMessageListenerContainer:

          DEBUG 2011-11-17 19:14:04,687 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:1:1'
          DEBUG 2011-11-17 19:14:05,296 [primary-3] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:1:1 syncCount: 2'
          DEBUG 2011-11-17 19:14:06,322 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:3:1'
          DEBUG 2011-11-17 19:14:06,357 [primary-4] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:3:1 syncCount: 2'
          DEBUG 2011-11-17 19:14:09,375 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:4:1'
          DEBUG 2011-11-17 19:14:09,410 [primary-5] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:4:1 syncCount: 2'
          DEBUG 2011-11-17 19:14:18,423 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:5:1'
          DEBUG 2011-11-17 19:14:18,442 [primary-6] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:5:1 syncCount: 2'
          DEBUG 2011-11-17 19:14:45,456 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:6:1'
          DEBUG 2011-11-17 19:14:45,479 [primary-7] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:6:1 syncCount: 2'
          DEBUG 2011-11-17 19:16:06,491 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:7:1'
          DEBUG 2011-11-17 19:16:06,533 [primary-8] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:7:1 syncCount: 2'

          It is probably needless to say, that this approach is neither clean nor likely to work with CACHE_CONSUMER as I don't think the broker will be "triggered" in this case to do a resend.
          I did not test this though, as I could not get cache level CACHE_CONSUMER in conjunction with an external transaction manager (which I can't avoid for my use case) to work, as the session needs to be transacted and is only transacted if either having XA Transactions (but I use a LocalTransaction) OR the acknowledgeMode is SESSION_TRANSACTED (which does not seem to be achievable in conjunction with CACHE_CONSUMER, unless setting sessionTransacted to true (which again does not work in conjunction with an external transaction manager).

          It would be great if someone with more knowledge about JMS could describe the correct behavior if one wants to achieve a correctly working transaction handling using an external transaction manager with a local transaction where redelivery works as descired and best possilbe performance is reached.
          Once I know the desired flow, I can check with the code what it currently does to then find out what to potentially adjust. At the moment I'm really struggling through a quite feature rich and rather complex implementation.

          Although we would be happy to contribute improvements, it is very hard without at least some pointers from other more experienced devs from the AMQ team.

          Many thanks for anyone helping on this!

          If we do not find a way to move forward, will very likely have to try out the same scenario with another JMS broker like JBoss HornetQ and have a look at their implementation. Although I think at the moment they only support a constant redelivery-delay, which is not very suiteable either and would need to be improved for most real world use cases. But such a change is very small compared to completely modifying the general handling of redeliveries.

          Show
          Eric Hubert added a comment - Implementing this part alone is really trivial and was very quickly done, but the problem is, that this is not the only limitation why the same consumer instance must be used. So this alone would be of no value. Currently the ActiveMQMessageConcumser is scheduling a task to perform the relivery. If there are multiple consumers, another consumer will simply grab the same message arriving again from the broker and do a normal delivery (so without any delay and completely asynchrounous to the scheduled thread still waiting). At some point I have not yet clearly identified the broker must get an ACK or something like this. Maybe as a result of a consumer or session close. So far I have just experimented with the code to get a better understanding on how this was ever intended to work correctly (especially if using a transaction manager to mange the transactions explicitely and not letting AMQ automatically perform the commit or rollback based on exceptions with a transacted session). According to the design document at http://activemq.apache.org/message-redelivery-and-dlq-handling.html " [...] On rollback, since nothing has been acked yet, and all messages are still available in an internal consumer queue, the messages are re-dispatched from the internal consumer queue. This reduces redelivery dispatch overhead, at the cost of the broker not being aware that redeliveries are occurring. [...] " since ActiveMQ 4 the broker shall not be aware of redeliveries at all and only the consumer should perform the redelivery from a local queue to possibly relieve the broker from some work improving scalability. Unfortunately if I got it right the end user cannot choose between either client or broker controlled redelivery (or 4.x versus 3.x behavior). In order to make this work I would only see the two theoretical options (not sure whether any of those are correct and feasible): a) The broker will not be informed about the redeliveries as a result of a rollback at all (only indirectly, if optionally persisting modified messages (redeliverey counter). As long as a consumer is not acknowledging the broker will not deliver the same message to another consumer. But I think incase of a transacted session, such an acknowledgement must be sent, or? b) The broker will be informed about rollbacks in order to trigger a resend of the same message. Any consumer receiving a message will first check the current redelivery count and postpone the actual delivery of this message for a calculated duration if required. If the redelivery count is 0, it will of course be processed immediately. As I could not quickly detect the place where the broker gets signaled that it shall resend the message for which a rollback was done, I simply "hacked a bit of code" for the purpose of testing and understanding, which performs the conditional wait based on the modified RedeliveryPolicy calculating the delay based on the counter right inside the ActiveMQSessionExecutor#execute prior dispatching the message. So any message arriving at this point will be hold of from dispatching to the local queue until the calculated delay according to the redelivery attempt has passed. Of course in parallel I commented the scheduled redelivery task for asynchronous execution. So this is something a long the line of option b) mentioned above. And this is the first time I could see a working redelivery with multiple consumer threads using the PooledConnectionFactory, an external TransactionManager, and neither cache level, sessionAcknowledgeMode nor sessionTransacted configured on Spring's DefaultMessageListenerContainer: DEBUG 2011-11-17 19:14:04,687 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:1:1' DEBUG 2011-11-17 19:14:05,296 [primary-3] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:1:1 syncCount: 2' DEBUG 2011-11-17 19:14:06,322 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:3:1' DEBUG 2011-11-17 19:14:06,357 [primary-4] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:3:1 syncCount: 2' DEBUG 2011-11-17 19:14:09,375 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:4:1' DEBUG 2011-11-17 19:14:09,410 [primary-5] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:4:1 syncCount: 2' DEBUG 2011-11-17 19:14:18,423 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:5:1' DEBUG 2011-11-17 19:14:18,442 [primary-6] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:5:1 syncCount: 2' DEBUG 2011-11-17 19:14:45,456 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:6:1' DEBUG 2011-11-17 19:14:45,479 [primary-7] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:6:1 syncCount: 2' DEBUG 2011-11-17 19:16:06,491 [primary-1] TransactionContext 'Begin:TX:ID:ldev3001-32202-1321553518048-0:7:1' DEBUG 2011-11-17 19:16:06,533 [primary-8] TransactionContext 'Rollback: TX:ID:ldev3001-32202-1321553518048-0:7:1 syncCount: 2' It is probably needless to say, that this approach is neither clean nor likely to work with CACHE_CONSUMER as I don't think the broker will be "triggered" in this case to do a resend. I did not test this though, as I could not get cache level CACHE_CONSUMER in conjunction with an external transaction manager (which I can't avoid for my use case) to work, as the session needs to be transacted and is only transacted if either having XA Transactions (but I use a LocalTransaction) OR the acknowledgeMode is SESSION_TRANSACTED (which does not seem to be achievable in conjunction with CACHE_CONSUMER, unless setting sessionTransacted to true (which again does not work in conjunction with an external transaction manager). It would be great if someone with more knowledge about JMS could describe the correct behavior if one wants to achieve a correctly working transaction handling using an external transaction manager with a local transaction where redelivery works as descired and best possilbe performance is reached. Once I know the desired flow, I can check with the code what it currently does to then find out what to potentially adjust. At the moment I'm really struggling through a quite feature rich and rather complex implementation. Although we would be happy to contribute improvements, it is very hard without at least some pointers from other more experienced devs from the AMQ team. Many thanks for anyone helping on this! If we do not find a way to move forward, will very likely have to try out the same scenario with another JMS broker like JBoss HornetQ and have a look at their implementation. Although I think at the moment they only support a constant redelivery-delay, which is not very suiteable either and would need to be improved for most real world use cases. But such a change is very small compared to completely modifying the general handling of redeliveries.
          Hide
          Timothy Bish added a comment -

          I think there's a bit of misunderstanding regards redelivery vs redispatch of a message. From the client side when a transaction is rolled back the messages are redelivered from the consumers own internal storage and the broker is only notified after one retry is attempted and fails that redelivery has occurred. The client continues to retry delivery each time the transaction is rolled back until some configured limit is reached (if one is desired) and then poisons the message which causes it to be sent to the DLQ.

          If the consumer were to be closed for some reason before the transaction was committed then the broker would need to redispatch the message to another consumer. To this new consumer its the first time that its ever seen this message regardless of whether it a new message or one that's been redelivered so the need for a delay in this case seems odd to me but perhaps I don't fully understand your use case or the problem you are trying to solve.

          Perhaps you might find the solution defined in AMQ-2710 to be of use in your scenario. Here the messages that are poisoned because they were deemed undeliverable are moved from the DLQ and rescheduled for send after a delay using the brokers own scheduled message feature.

          If this isn't want you are going for then perhaps you can take a step back and better define what the use case is and what problem you are trying to solve. The current implementation of the consumer doesn't have an easy way to delay a message on dispatch only on rollback so if you want to add something like that you'd need to do some work.

          Show
          Timothy Bish added a comment - I think there's a bit of misunderstanding regards redelivery vs redispatch of a message. From the client side when a transaction is rolled back the messages are redelivered from the consumers own internal storage and the broker is only notified after one retry is attempted and fails that redelivery has occurred. The client continues to retry delivery each time the transaction is rolled back until some configured limit is reached (if one is desired) and then poisons the message which causes it to be sent to the DLQ. If the consumer were to be closed for some reason before the transaction was committed then the broker would need to redispatch the message to another consumer. To this new consumer its the first time that its ever seen this message regardless of whether it a new message or one that's been redelivered so the need for a delay in this case seems odd to me but perhaps I don't fully understand your use case or the problem you are trying to solve. Perhaps you might find the solution defined in AMQ-2710 to be of use in your scenario. Here the messages that are poisoned because they were deemed undeliverable are moved from the DLQ and rescheduled for send after a delay using the brokers own scheduled message feature. If this isn't want you are going for then perhaps you can take a step back and better define what the use case is and what problem you are trying to solve. The current implementation of the consumer doesn't have an easy way to delay a message on dispatch only on rollback so if you want to add something like that you'd need to do some work.
          Hide
          Eric Hubert added a comment -

          Timothy, you are absolutely right that we did not associate the term redelivery with the meaning consumer internal reprocessing (using a consumer-side queue) and redispatch with broker to consumer and thus may have used them interchangeable potentially leading to confusion.

          Stepping back explaining the use case and problem to solve might indeed be the best proposal I'd like to follow hereby.

          1) Use Case/Problem Context:
          In our use case the consumer has the responsibility to send the message polled from the broker's queue to http web service endpoints and ensure the message has reached the endpoint it was meant for. This receiving endpoint may not always be available. So a configurable number of retries with a configurable non-constant, increasing delay shall take place before considering the message as non-deliverable at some point (DLQ use). Within this time even the rules determining the actual service endpoint may change.
          I think at this point I need to add that this whole process is taking place as mediation logic inside an ESB product integrating any JMS message broker via Spring. Sending to the endpoint is done using non-blocking http transports.
          The setup must be highly available and process high message volumes. Messages must never get lost. The ESB nodes are the only consumers on those JMS queues, so it is a rather very small number of consumers.
          So consequently there are multiple ESB nodes and multiple brokers in master slave setup. Ideally the delays between send attempts to the service endpoints should follow the calculation independent of an ESB node (JMS consumer) unavailability (due to maintenance, crash or whatever reason) or broker unavailability (master slave failover should take place transparently).
          So from a business perspective we only care for the full transfer between JMS broker and service endpoint and consider this as the delivery process in this context. The same applies for redelivery attempts.

          2) Current solution approach:

          • The ESB basically uses Spring’s DefaultMessageListenerContainer (DMLC) in conjunction with Spring’s PlatformTransactionManager (PTM).
            -The message received from the queue arrives at the incoming message sequence of the mediation logic starting a transaction. If there are no "routing rules" an immediate rollback will be performed to trigger a scheduled redelivery. Whether this is done from the same consumer (ESB node) or any should not play a role. In case routing rules are available the transaction will be suspended and the message will be send to the service endpoint. ESB-internally this is an asynchronous, non-blocking operation. At some point either an error occurs or a response message arrives which will be inspected in the out message sequence in order to resume the transaction and either perform a commit (on success) or a rollback (on failure) to schedule a resend (intentionally trying to avoid the terms redelivery or redispatch here).

          3) Issues with current solution approach:
          If we got it right AMQ redelivery feature is consumer-based requiring a transacted session AND the same consumer instance to be used for redeliveries. In terms of concrete DMLC configuration this requires cache level CACHE_CONSUMER as well as sessionTransacted set to true.
          This seems to make it impossible to have control over the transaction and use the PTM to suspend, resume, commit or rollback a message.
          Using only CACHE_CONSUMER with PTM does not work (session not transacted, no reaction on rollback). Using any other cache level, the transaction handling is working fine, the messages are also scheduled for redelivery, but the message to be redelivered is redispatched from the broker (likely a result of a consumer close in DMLC) resulting in another undelayed delivery attempt.
          So infact we do not get our desired transactional behavior plus redelivery to work. In addition, even if we could get this to work properly I assume a consumer crash or shutdown while a redelivery process is going on (which could be configured to take place over multiple days with maximum delays of an hour) would result in an automatic rollback and a message redispatch to another consumer starting from scratch with an immediate (undelayed) delivery irrespective of the redelivery counter on the message and the delay which shall take place here.
          If understanding AMQ-2710 correctly and another non-configurable behavior of consumer based-redelivery with strict JMS semantics is always a blocking of consumption of further messages in case of a running redelivery process (to guarantee the order). This would be another reason why we could not use this approach unless we would use a separate queue for each individual logical routing target as any problem sending to one service endpoint must not block message sending to other endpoints.
          So indeed it looks like AMQ-2710 could be an alternative as this seems to be a realization of broker -based delayed redelivery. I know, for the sake of clarity one should rather call a solution with broker -based delayed redispatch loosing order guarantee.
          I will further investigate this suggestion (also checking the linked old JIRA issue AMQ-1853), but still I don’t get why this simple use case seems to be so hard to realize and why I have to integrate an EIP framework like Camel for this to work around.

          If there is some way to get DMLC with CACHE_CONSUMER, local transactions via PTM and redelivery to work properly, which we tried hard but failed, this would of course also still be interesting.

          Timothy, in any case many thanks for this feedback! It was the first one moving us slightly forward in terms of understanding of the AMQ implementation.

          Show
          Eric Hubert added a comment - Timothy, you are absolutely right that we did not associate the term redelivery with the meaning consumer internal reprocessing (using a consumer-side queue) and redispatch with broker to consumer and thus may have used them interchangeable potentially leading to confusion. Stepping back explaining the use case and problem to solve might indeed be the best proposal I'd like to follow hereby. 1) Use Case/Problem Context: In our use case the consumer has the responsibility to send the message polled from the broker's queue to http web service endpoints and ensure the message has reached the endpoint it was meant for. This receiving endpoint may not always be available. So a configurable number of retries with a configurable non-constant, increasing delay shall take place before considering the message as non-deliverable at some point (DLQ use). Within this time even the rules determining the actual service endpoint may change. I think at this point I need to add that this whole process is taking place as mediation logic inside an ESB product integrating any JMS message broker via Spring. Sending to the endpoint is done using non-blocking http transports. The setup must be highly available and process high message volumes. Messages must never get lost. The ESB nodes are the only consumers on those JMS queues, so it is a rather very small number of consumers. So consequently there are multiple ESB nodes and multiple brokers in master slave setup. Ideally the delays between send attempts to the service endpoints should follow the calculation independent of an ESB node (JMS consumer) unavailability (due to maintenance, crash or whatever reason) or broker unavailability (master slave failover should take place transparently). So from a business perspective we only care for the full transfer between JMS broker and service endpoint and consider this as the delivery process in this context. The same applies for redelivery attempts. 2) Current solution approach: The ESB basically uses Spring’s DefaultMessageListenerContainer (DMLC) in conjunction with Spring’s PlatformTransactionManager (PTM). -The message received from the queue arrives at the incoming message sequence of the mediation logic starting a transaction. If there are no "routing rules" an immediate rollback will be performed to trigger a scheduled redelivery. Whether this is done from the same consumer (ESB node) or any should not play a role. In case routing rules are available the transaction will be suspended and the message will be send to the service endpoint. ESB-internally this is an asynchronous, non-blocking operation. At some point either an error occurs or a response message arrives which will be inspected in the out message sequence in order to resume the transaction and either perform a commit (on success) or a rollback (on failure) to schedule a resend (intentionally trying to avoid the terms redelivery or redispatch here). 3) Issues with current solution approach: If we got it right AMQ redelivery feature is consumer-based requiring a transacted session AND the same consumer instance to be used for redeliveries. In terms of concrete DMLC configuration this requires cache level CACHE_CONSUMER as well as sessionTransacted set to true. This seems to make it impossible to have control over the transaction and use the PTM to suspend, resume, commit or rollback a message. Using only CACHE_CONSUMER with PTM does not work (session not transacted, no reaction on rollback). Using any other cache level, the transaction handling is working fine, the messages are also scheduled for redelivery, but the message to be redelivered is redispatched from the broker (likely a result of a consumer close in DMLC) resulting in another undelayed delivery attempt. So infact we do not get our desired transactional behavior plus redelivery to work. In addition, even if we could get this to work properly I assume a consumer crash or shutdown while a redelivery process is going on (which could be configured to take place over multiple days with maximum delays of an hour) would result in an automatic rollback and a message redispatch to another consumer starting from scratch with an immediate (undelayed) delivery irrespective of the redelivery counter on the message and the delay which shall take place here. If understanding AMQ-2710 correctly and another non-configurable behavior of consumer based-redelivery with strict JMS semantics is always a blocking of consumption of further messages in case of a running redelivery process (to guarantee the order). This would be another reason why we could not use this approach unless we would use a separate queue for each individual logical routing target as any problem sending to one service endpoint must not block message sending to other endpoints. So indeed it looks like AMQ-2710 could be an alternative as this seems to be a realization of broker -based delayed redelivery. I know, for the sake of clarity one should rather call a solution with broker -based delayed redispatch loosing order guarantee. I will further investigate this suggestion (also checking the linked old JIRA issue AMQ-1853 ), but still I don’t get why this simple use case seems to be so hard to realize and why I have to integrate an EIP framework like Camel for this to work around. If there is some way to get DMLC with CACHE_CONSUMER, local transactions via PTM and redelivery to work properly, which we tried hard but failed, this would of course also still be interesting. Timothy, in any case many thanks for this feedback! It was the first one moving us slightly forward in terms of understanding of the AMQ implementation.
          Hide
          Eric Hubert added a comment -

          I now worked through AM-1853 and see that this one was actually about making the consumer behavior during redeliveries configurable (blocking versus non-blocking) which is indeed an expected configuration option. But this will be available only once 5.6 is released.

          Personally in addition to this configuration option I had expected another configuration option for the end user to decide at which place the redelivery process is initiated/controlled (broker versus consumer) as the use cases may predetermine the more suitable approach. Using Camel as described in AMQ-2710 can be either seen as a workaround for the solution implemented in AMQ-1853 or as a workaround for a missing "native" support for broker-based redelivery/redispatch.

          Last but no least I also have to agree that the theoretical workaround I described under my initial option b) to somehow circumvent the missing broker-side delay in letting the consumer perform the delay would be indeed an odd counter-intuitive mixture of broker and consumer controlled redelivery and only a result of neither getting the one nor the other approach to work.

          Show
          Eric Hubert added a comment - I now worked through AM-1853 and see that this one was actually about making the consumer behavior during redeliveries configurable (blocking versus non-blocking) which is indeed an expected configuration option. But this will be available only once 5.6 is released. Personally in addition to this configuration option I had expected another configuration option for the end user to decide at which place the redelivery process is initiated/controlled (broker versus consumer) as the use cases may predetermine the more suitable approach. Using Camel as described in AMQ-2710 can be either seen as a workaround for the solution implemented in AMQ-1853 or as a workaround for a missing "native" support for broker-based redelivery/redispatch. Last but no least I also have to agree that the theoretical workaround I described under my initial option b) to somehow circumvent the missing broker-side delay in letting the consumer perform the delay would be indeed an odd counter-intuitive mixture of broker and consumer controlled redelivery and only a result of neither getting the one nor the other approach to work.
          Hide
          Timothy Bish added a comment -

          Working as designed. Consumer redelivery happens on the client side until the consumer is closed without acking the messages, or committing the TX. Once a consumer is closed the messages are redelivered to another consumer.

          Show
          Timothy Bish added a comment - Working as designed. Consumer redelivery happens on the client side until the consumer is closed without acking the messages, or committing the TX. Once a consumer is closed the messages are redelivered to another consumer.
          Hide
          Gary Tully added a comment -

          Broker redelivery is implemented on trunk via https://issues.apache.org/jira/browse/AMQ-3894

          Show
          Gary Tully added a comment - Broker redelivery is implemented on trunk via https://issues.apache.org/jira/browse/AMQ-3894

            People

            • Assignee:
              Timothy Bish
              Reporter:
              Eric Hubert
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development