Aargh - I meant "max.delivery.drop" ! I can't see that docced anywhere?
So we are implementing a trigger sequence for when MessageProcessor gets de-activated? I think is the same thing I'm thinking of isn't it ? When the message fails to get sent after n retries then the sequence gets called - presumably with the message that's failing as part of the payload in the sequence - along with the error message from the server too? cheers for the clarifications ! John. John Hawkins Director: Solutions Architecture On Wed, Sep 9, 2015 at 12:41 PM, Ravindra Ranwala <[email protected]> wrote: > Hi John, > > Message Processor Max Delivery attempt parameter is clearly documented > here [1]. > > > Anyway in ESB 4.9.0 version we have deactivateSequence, which can be > triggered when the Message Processor is deactivated after reaching > max-delivery-attempts. In that sequence you may implement DLC pattern. > > Also I understand that your requirement is valid, and you may create a > public jira to track that. We may incorporate it in to the product in a > future release. > > > > [1] https://docs.wso2.com/display/ESB481/Message+Forwarding+Processor > > > > Thanks & Regards, > > On Wed, Sep 9, 2015 at 4:07 PM, John Hawkins <[email protected]> wrote: > >> Hi Ravindra, >> I'm thinking about this a lot now.... >> max.delivery.attempts is not documented anywhere nor is it in the >> MessageProcessor wizard (but it is in a few JIRA's and blog entries). Is >> this deliberate do you know - are we hiding it for some reason? >> >> Personally I would expect some kind of 'retries fail' sequence to be an >> optional thing I can set. Then I could do what I wanted with the message >> and the MessageProcessor can continue. Are you aware of any thoughts like >> this at all? If not then I think I need to create a JIRA to at least >> document this feature as-is. >> >> cheers, >> john. >> >> John Hawkins >> Director: Solutions Architecture >> >> >> On Wed, Sep 9, 2015 at 11:03 AM, Ravindra Ranwala <[email protected]> >> wrote: >> >>> Hi John, >>> >>> There is no DLC behaviour after reaching the max-retry-count at the >>> moment. >>> >>> >>> Thanks & Regards, >>> >>> On Wed, Sep 9, 2015 at 3:23 PM, John Hawkins <[email protected]> wrote: >>> >>>> Another question - is there no Dead Letter Queue behaviour then if a >>>> message fails to get sent after max_retry is done? >>>> >>>> John Hawkins >>>> Director: Solutions Architecture >>>> >>>> >>>> On Thu, Sep 3, 2015 at 4:41 PM, Ravindra Ranwala <[email protected]> >>>> wrote: >>>> >>>>> Hi John, >>>>> >>>>> The Cron expression in MP is used to create firing schedules such as >>>>> "At 8:00am every Monday through Friday" [1]. If it is set the MP will run >>>>> according to that. Otherwise MP will poll the queue with the specified >>>>> interval value continuously. >>>>> >>>>> Also the MP has a parameter called max_delivery_attempts (defaults to >>>>> 4), which defines the maximum retry attempts in case of a failure in end >>>>> point. By default if the MP could not send the message to the end point >>>>> after this number of retry count, it deactivates itself. But that message >>>>> remains in the queue. After that you have to activate the MP explicitly to >>>>> make the next schedule to be effective. Otherwise it will remain >>>>> deactivated. >>>>> >>>>> If you need to override the above behaviour, you need to enable >>>>> max-delivery-drop parameter, so that if the MP could not send the message >>>>> after this number of attempts, it merely drops the message and continues. >>>>> Here you loose the message if the endpoint is down. >>>>> >>>>> >>>>> [1] >>>>> http://www.quartz-scheduler.org/documentation/quartz-1.x/tutorials/crontrigger >>>>> >>>>> >>>>> Thanks & Regards, >>>>> >>>>> On Thu, Sep 3, 2015 at 8:05 PM, John Hawkins <[email protected]> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> I'm trying to figure out when does the "cron schedule" get used that >>>>>> I can configure on the MessageProcessor? >>>>>> >>>>>> The logic that I think is happening is - if the message fails to get >>>>>> sent 'retry' number of times then it's put to the dead letter queue (or >>>>>> DLC >>>>>> as its called in qpid) . The Message Processor then looks at the DLC >>>>>> based >>>>>> on when the cron job tells it to? >>>>>> >>>>>> If this logic is correct (?) then I have a number of other questions >>>>>> please: >>>>>> >>>>>> 1) what if this cron job is not set - does the message remain on the >>>>>> DLQ? >>>>>> 2) Where is the DLQ defined to synapse/the message processor so that >>>>>> it knows where to go? >>>>>> 3) What if the message gets removed from the DLC for some reason >>>>>> (manually or otherwise)? Do we fail quietly or log it somewhere? >>>>>> 4) What if other messages from other parts of the ESB get put to the >>>>>> DLQ ? How does the MessageProcessor know which messages are for it? >>>>>> >>>>>> >>>>>> many thanks for your help ! >>>>>> john. >>>>>> >>>>>> >>>>>> John Hawkins >>>>>> Director: Solutions Architecture >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> [email protected] >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Ravindra Ranwala >>>>> Software Engineer >>>>> WSO2, Inc: http://wso2.com >>>>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>>>> Mobile: +94714198770 >>>>> >>>>> >>>> >>> >>> >>> -- >>> Ravindra Ranwala >>> Software Engineer >>> WSO2, Inc: http://wso2.com >>> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> >>> Mobile: +94714198770 >>> >>> >> > > > -- > Ravindra Ranwala > Software Engineer > WSO2, Inc: http://wso2.com > <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg> > Mobile: +94714198770 > >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
