On Sun, Jun 28, 2020 at 11:39 PM Vanjikumaran Sivajothy < vanjikuma...@gmail.com> wrote:
> Since it is a part of the Message processor itself; > Why can't we stick to <parameter name="throttle">true</parameter>? > Yeah. I think you are right. Compared to what I suggested *throttle* seems to be better. <messageProcessor class= "org.apache.synapse.message.processors.forward.ScheduledMessageForwardingProcessor" name="ScheduledProcessor" messageStore="MyStore"> <parameter name="interval" >10000</parameter> *<parameter name="throttle">true</parameter>* <parameter name="max.deliver.attempts">3</parameter> <parameter name="max.deliver.drop" >true</parameter> </messageProcessor> Other option we can go with is *consume.all *and the configuration would look like as below, <messageProcessor class= "org.apache.synapse.message.processors.forward.ScheduledMessageForwardingProcessor" name="ScheduledProcessor" messageStore="MyStore"> <parameter name="interval" >10000</parameter> *<parameter name="consume.all">true</parameter>* < parameter name="max.deliver.attempts">3</parameter> <parameter name= "max.deliver.drop">true</parameter> </messageProcessor> I prefer the latter but what do you think ? > On Sun, Jun 28, 2020 at 10:32 AM Shafreen <anfar.shafr...@gmail.com> > wrote: > >> Hi All, >> >> On Sun, Jun 14, 2020 at 8:15 AM Shafreen <anfar.shafr...@gmail.com> >> wrote: >> >>> Hi All, >>> >>> If everyone is okay. I can go ahead with the implementation. The below >>> is the property that will be introduced. >>> >>> <parameter name="throttle.message.processing">true</parameter> >>> >>> Users can use the property to decide what they want to do when the >>> message processor is triggered. >>> >>> 1. Consume all the messages at once >>> 2. Consume messages at the rate in which message processor is triggered >>> >> >> Any idea on the aforementioned property ? If you all are okay I can go >> ahead and implement the feature. >> >> >>> >>> Thanks, >>> Shafreen >>> >>> On Fri, May 29, 2020 at 7:18 PM Shafreen <anfar.shafr...@gmail.com> >>> wrote: >>> >>>> I thought of simply using the time interval that is there for Message >>>> Processor. >>>> >>>> On Fri, May 29, 2020 at 12:04 PM Vanjikumaran Sivajothy < >>>> vanjikuma...@gmail.com> wrote: >>>> >>>>> What about the configuration of the interval? >>>>> >>>>> On Thu, May 28, 2020 at 8:53 AM Shafreen <anfar.shafr...@gmail.com> >>>>> wrote: >>>>> >>>>>> Hi All, >>>>>> >>>>>> How about a property name as below? we can make it false by default >>>>>> which would give us the current behaviour. >>>>>> >>>>>> <parameter name="throttle.message.processing">true</parameter> >>>>>> >>>>>> On Mon, May 25, 2020 at 10:41 AM prabath <prabathm...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> +1 to support both behaviors. >>>>>>> >>>>>>> On Sun, May 24, 2020 at 12:26 AM Shafreen <anfar.shafr...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Vanji, >>>>>>>> >>>>>>>> On Sat, May 23, 2020 at 2:51 PM Vanjikumaran Sivajothy < >>>>>>>> vanjikuma...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Let’s consider the current behaviors as a default. >>>>>>>>> >>>>>>>>> Adding additional Optional property may control to make sure the >>>>>>>>> backward comparability. >>>>>>>>> >>>>>>>> >>>>>>>> Okay. We can add a new parameter, that way we can have both >>>>>>>> behaviors as you mentioned. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, May 23, 2020 at 12:46 AM Shafreen < >>>>>>>>> anfar.shafr...@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Hi All, >>>>>>>>>> >>>>>>>>>> Current behaviour of the Message Forwarding Processor is to >>>>>>>>>> consume all the messages at once. For instance, say, the Message >>>>>>>>>> Forwarding >>>>>>>>>> Processor is configured to run every 10 seconds and the Message >>>>>>>>>> store is >>>>>>>>>> filled with 5 messages within the 10 second gap. In such a situation, >>>>>>>>>> Message Forwarding Processor consumes all 5 messages and try to send >>>>>>>>>> it to >>>>>>>>>> back-end as fast as possible. I think this behaviour is not optimal. >>>>>>>>>> The >>>>>>>>>> purpose of Message Forwarding Processor it to send messages to the >>>>>>>>>> back-end >>>>>>>>>> in a controlled rate. So that the back-end server can handle the >>>>>>>>>> load. IMO, >>>>>>>>>> ideal behaviour should be to consume one message at a time and try >>>>>>>>>> to send >>>>>>>>>> it to the back-end as per the configured interval. >>>>>>>>>> >>>>>>>>>> However, if the configured interval is a cron expression, in such >>>>>>>>>> cases the current behaviour is correct. Because cron expressions >>>>>>>>>> could have >>>>>>>>>> very large intervals. >>>>>>>>>> >>>>>>>>>> Therefore, I think it is best to keep the current behaviour for >>>>>>>>>> cron intervals but change it for normal intervals as aforementioned. >>>>>>>>>> >>>>>>>>>> WDYT ? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Shafreen >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> Sent from Gmail Mobile >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Prabath Ariyarathna. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> -- >>>>> Best Regards, >>>>> Vanji >>>>> >>>> > > -- > Best Regards, > Vanji >
