Hi Jhone. 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.
As your comment, seems you need to continue message processor after executing the fault/dead letter sequence but in deactivate sequence you need to manually activate the message processor. Thanks On Wed, Sep 9, 2015 at 5:21 PM, John Hawkins <[email protected]> wrote: > 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 > > -- *Prabath Ariyarathna* *Associate Technical Lead* *WSO2, Inc. * *lean . enterprise . middleware * *Email: [email protected] <[email protected]>* *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>* *Flicker : https://www.flickr.com/photos/47759189@N08 <https://www.flickr.com/photos/47759189@N08>* *Mobile: +94 77 699 4730 *
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
