Re: [Dev] cron job on MessageProcessor?

[John Hawkins]

Hi Folks,

Gentle nudge on this if I may - trying to write an article on this stuff so
any help would be much appreciated :-) Anyone know what the message is
that's sent to the deactive sequence?

many thanks,
john.

John Hawkins
Director: Solutions Architecture


On Fri, Sep 11, 2015 at 8:51 AM, John Hawkins  wrote:

> 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 
> wrote:
>
>>
>> [1] jira for the doc
>> https://wso2.org/jira/browse/DOCUMENTATION-952
>>
>> On Thu, Sep 10, 2015 at 11:44 AM, Vanjikumaran Sivajothy 
>> wrote:
>>
>>> Hi John,
>>>
>>>
>>> On Wed, Sep 9, 2015 at 4:51 AM, John Hawkins  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 
 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  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 
>> 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  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  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
> 

Re: [Dev] cron job on MessageProcessor?

[John Hawkins]

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 
wrote:

>
> [1] jira for the doc
> https://wso2.org/jira/browse/DOCUMENTATION-952
>
> On Thu, Sep 10, 2015 at 11:44 AM, Vanjikumaran Sivajothy 
> wrote:
>
>> Hi John,
>>
>>
>> On Wed, Sep 9, 2015 at 4:51 AM, John Hawkins  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 
>>> 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  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 
> 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  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 
>>> 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,

Re: [Dev] cron job on MessageProcessor?

[Vanjikumaran Sivajothy]

[1] jira for the doc
https://wso2.org/jira/browse/DOCUMENTATION-952

On Thu, Sep 10, 2015 at 11:44 AM, Vanjikumaran Sivajothy 
wrote:

> Hi John,
>
>
> On Wed, Sep 9, 2015 at 4:51 AM, John Hawkins  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 
>> 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  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 
 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  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 
>> 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  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 
 

Re: [Dev] cron job on MessageProcessor?

[Vanjikumaran Sivajothy]

Hi John,


On Wed, Sep 9, 2015 at 4:51 AM, John Hawkins  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 
> 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  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 
>>> 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  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 
> 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  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 

Re: [Dev] cron job on MessageProcessor?

[Ravindra Ranwala]

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  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 
> 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  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 
>>> 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  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
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


 --
 Ravindra Ranwala
 Software Engineer
 WSO2, Inc: http://wso2.com
 
 Mobile: +94714198770


>>>
>>
>>
>> --
>> Ravindra Ranwala
>> Software Engineer
>> WSO2, Inc: http://wso2.com
>> 
>> Mobile: +94714198770
>>
>>
>


-- 
Ravindra Ranwala
Software Engineer
WSO2, Inc: http://wso2.com

Re: [Dev] cron job on MessageProcessor?

[Prabath Ariyarathna]

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  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 
> 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  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 
>>> 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  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 
> 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  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:

Re: [Dev] cron job on MessageProcessor?

[John Hawkins]

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  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  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
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Ravindra Ranwala
> Software Engineer
> WSO2, Inc: http://wso2.com
> 
> Mobile: +94714198770
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] cron job on MessageProcessor?

[John Hawkins]

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  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  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 
>> 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  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 
 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  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: 

Re: [Dev] cron job on MessageProcessor?

[Ravindra Ranwala]

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  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 
> 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  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
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Ravindra Ranwala
>> Software Engineer
>> WSO2, Inc: http://wso2.com
>> 
>> Mobile: +94714198770
>>
>>
>


-- 
Ravindra Ranwala
Software Engineer
WSO2, Inc: http://wso2.com

Mobile: +94714198770
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] cron job on MessageProcessor?

[John Hawkins]

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  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  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 
>> 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  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
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Ravindra Ranwala
>>> Software Engineer
>>> WSO2, Inc: http://wso2.com
>>> 
>>> Mobile: +94714198770
>>>
>>>
>>
>
>
> --
> Ravindra Ranwala
> Software Engineer
> WSO2, Inc: http://wso2.com
> 
> Mobile: +94714198770
>
>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] cron job on MessageProcessor?

[John Hawkins]

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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] cron job on MessageProcessor?

[Ravindra Ranwala]

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  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
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Ravindra Ranwala
Software Engineer
WSO2, Inc: http://wso2.com

Mobile: +94714198770
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev