Thanks for your thoroughness folks !! I'm not sure, from the description, what gets sent to the message.processor.deactivate.sequence - is it the message that failed or just the reply from the server or both?
cheers, John. John Hawkins Director: Solutions Architecture On Thu, Sep 10, 2015 at 7:47 PM, Vanjikumaran Sivajothy <[email protected]> wrote: > > [1] jira for the doc > https://wso2.org/jira/browse/DOCUMENTATION-952 > > On Thu, Sep 10, 2015 at 11:44 AM, Vanjikumaran Sivajothy <[email protected]> > wrote: > >> Hi John, >> >> >> On Wed, Sep 9, 2015 at 4:51 AM, John Hawkins <[email protected]> wrote: >> >>> Aargh - I meant "max.delivery.drop" ! I can't see that docced anywhere? >>> >> >> >> This new parameter is introduced in ESB 4.9.0 onwards. It should be there >> in the 490 documentation according to [1] >> >> [1] https://docs.wso2.com/display/ESB490/Message+Forwarding+Processor >> >> >> >> >>> 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 >>> >>> >> >> >> -- >> Vanjikumaran Sivajothy >> *Associate Technical Lead* >> *WSO2 Inc. http://wso2.com <http://wso2.com/>* >> *USA Mobile **+1-812-361-1286* >> *Srilanka Mobile:+94-777-219-209* >> [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: >> Twitter] <https://twitter.com/vanjikumaran> [image: LinkedIn] >> <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: >> Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] >> <http://www.slideshare.net/vanjikumaran> >> >> This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may >> have received this communication in error, please reply to the >> sender indicating that fact and delete the copy you received and in >> addition, you should not print, copy, re-transmit, disseminate, or >> otherwise use the information contained in this communication. >> Internet communications cannot be guaranteed to be timely, secure, error >> or virus-free. The sender does not accept liability for any errors >> or omissions >> > > > > -- > Vanjikumaran Sivajothy > *Associate Technical Lead* > *WSO2 Inc. http://wso2.com <http://wso2.com/>* > *USA Mobile **+1-812-361-1286* > *Srilanka Mobile:+94-777-219-209* > [image: Facebook] <https://www.facebook.com/vanjikumaran> [image: Twitter] > <https://twitter.com/vanjikumaran> [image: LinkedIn] > <http://www.linkedin.com/pub/vanjikumaran-sivajothy/25/b31/293> [image: > Blogger] <http://vanjikumaran.blogspot.com/> [image: SlideShare] > <http://www.slideshare.net/vanjikumaran> > > This communication may contain privileged or other > confidential information and is intended exclusively for the addressee/s. > If you are not the intended recipient/s, or believe that you may > have received this communication in error, please reply to the > sender indicating that fact and delete the copy you received and in > addition, you should not print, copy, re-transmit, disseminate, or > otherwise use the information contained in this communication. > Internet communications cannot be guaranteed to be timely, secure, error > or virus-free. The sender does not accept liability for any errors > or omissions >
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
