[jira] [Resolved] (AMQ-6007) Regression from 5.8.0: old scheduledJobId set by client causes ignoring AMQ_SCHEDULED_DELAY

["Christopher L. Shannon (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/AMQ-6007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Christopher L. Shannon resolved AMQ-6007.
-----------------------------------------
    Resolution: Not A Problem

I'm resolving this as not a problem because this is the intended behavior with the new implementation of the job scheduler.  The check on the jobId is necessary to prevent things like duplicates.  

I went ahead and updated the documentation to warn about this condition at http://activemq.apache.org/delay-and-schedule-message-delivery.html 

> Regression from 5.8.0: old scheduledJobId set by client causes ignoring AMQ_SCHEDULED_DELAY
> -------------------------------------------------------------------------------------------
>
>                 Key: AMQ-6007
>                 URL: https://issues.apache.org/jira/browse/AMQ-6007
>             Project: ActiveMQ
>          Issue Type: Improvement
>            Reporter: Andrei Shakirin
>            Assignee: Christopher L. Shannon
>
> Hi ActiveMQ community,
> I am observing a following regression from AMQ 5.8.0:
> Use case: 
> 1) client receives message already scheduled for broker with AMQ_SCHEDULED_DELAY
> 2) client creates new message and copies scheduledJobId property from received one
> 3) clients sets new AMQ_SCHEDULED_DELAY and sends the new  message
> Expected behavior: new message will be scheduled for broker honoring AMQ_SCHEDULED_DELAY
> Current behavior: new message will not be scheduled and is delivered immediately. AMQ_SCHEDULED_DELAY property stays in message.
> In ActiveMQ 5.8.0 this scenario works without problems. I am not sure is it intended behavior or bug. 
> Can easily happens in Camel routes reading and re-sending the messages. Camel takes over all JMS properties into Exchange and old scheduledJobId can be sent as a property of new message (if wouldn't be reset explicitly) that prevents scheduling of new message. Nasty bug that is quite difficult to debug.
> Regards,
> Andrei.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)