Hi Gayan, Thanks for the input, yes I noticed this in Developer Studio. By any chance do you know the reason for adding this restriction?
As I understand there could be scenarios where we need to add mediators after a send mediator in an out sequence such as BAM and log. One other point to note here is that ESB has not restricted this. Thanks On Mon, Jun 16, 2014 at 9:57 AM, Gayan Yalpathwala <[email protected]> wrote: > Hi Imesh, > > Considering perf details you have mentioned, having the BAM mediator after > a send mediator would optimize the situation. But it is not the recommended > to add any mediator after a send mediator. If you check in Developer > studio, we have deliberately restricted this behavior. > > Thanks, > > > On Fri, Jun 13, 2014 at 10:20 AM, Imesh Gunaratne <[email protected]> wrote: > >> HI Ayash, >> >> Yes after doing the optimisations we placed the BAM mediator after the >> "send" call in the out mediation flow. >> >> Thanks >> >> >> On Fri, Jun 13, 2014 at 2:33 AM, Ayash <[email protected]> wrote: >> >>> Hi Imesh, >>> >>> While experiencing this problem, do you remember where the BAM Mediators >>> were in the mediation flow? Have you kept them after calling "send" or >>> before in the mediation flow? >>> >>> Thanks, >>> -Ayash >>> >>> >>> On Thu, Feb 13, 2014 at 2:18 PM, Imesh Gunaratne <[email protected]> wrote: >>> >>>> s/comapred/compared/g >>>> s/millisecods/milliseconds/g >>>> >>>> >>>> On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne <[email protected]> >>>> wrote: >>>> >>>>> Hi Sinthuja, >>>>> >>>>> Thanks for your response. Absolutely the concern is not with the data >>>>> publisher but with the bam mediator logic being executed in the mediation >>>>> flow. >>>>> >>>>> This is something I experienced during last couple of days while >>>>> configuring several BAM mediators in an ESB flow. When a load test was run >>>>> (with a set of concurrent users) and the ESB mediation latency was >>>>> monitored, the BAM mediators were taking considerable amount of time >>>>> comapred with the ESB latency without having the BAM mediators. It was >>>>> like >>>>> 90 ms with the BAM mediators and 35 ms without them. >>>>> >>>>> What I wanted to highlight here is that, I could not see any reason >>>>> for executing the above logic in the mediation flow and adding several >>>>> millisecods to the ESB latency. >>>>> >>>>> Thanks >>>>> >>>>> >>>>> On Thu, Feb 13, 2014 at 12:32 AM, Sinthuja Ragendran < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Imesh, >>>>>> >>>>>> Publish() method in data publisher is not a blocking call, it's a >>>>>> asynchronous call. Within data publisher the events are put into a queue >>>>>> and a separate thread does the real publishing to BAM. Also in BAM >>>>>> mediator, the AsyncDataPublisher is being used therefore the connection >>>>>> to >>>>>> BAM is also made asynchronous. Hence IMHO it's not required to spawn a >>>>>> new >>>>>> thread externally to publish the events and make it complicated. >>>>>> >>>>>> Thanks, >>>>>> Sinthuja. >>>>>> >>>>>> >>>>>> On Thu, Feb 13, 2014 at 2:15 AM, Imesh Gunaratne <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> This is regarding the BAM Mediator 4.2.0. >>>>>>> As it looks like currently the BAM Mediator is executing the data >>>>>>> publishing logic in the same thread which the current message mediation >>>>>>> is >>>>>>> happening: >>>>>>> >>>>>>> public class BamMediator: >>>>>>> >>>>>>> public boolean mediate(MessageContext messageContext) { >>>>>>> ... >>>>>>> try { >>>>>>> stream.sendEvents(messageContext); >>>>>>> } catch (BamMediatorException e) { >>>>>>> return true; >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> public class Stream { >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> public void sendEvents(MessageContext messageContext) throws >>>>>>> BamMediatorException { >>>>>>> ActivityIDSetter activityIDSetter = new ActivityIDSetter(); >>>>>>> activityIDSetter.setActivityIdInTransportHeader(messageContext); >>>>>>> try { >>>>>>> if (!isPublisherCreated) { >>>>>>> initializeDataPublisher(this); >>>>>>> isPublisherCreated = true; >>>>>>> } >>>>>>> this.publishEvent(messageContext); >>>>>>> } catch (BamMediatorException e) { >>>>>>> String errorMsg = "Problem occurred while logging events in >>>>>>> the BAM Mediator. " + e.getMessage(); >>>>>>> log.error(errorMsg, e); >>>>>>> throw new BamMediatorException(errorMsg, e); >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> } >>>>>>> >>>>>>> I think if we move this logic to a new thread we could reduce the >>>>>>> time it takes to execute the data publishing logic from the main message >>>>>>> flow. WDYT? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -- >>>>>>> *Imesh Gunaratne* >>>>>>> Technical Lead >>>>>>> WSO2 Inc: http://wso2.com >>>>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>>>> W: http://imesh.gunaratne.org >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> [email protected] >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Sinthuja Rajendran* >>>>>> Software Engineer <http://wso2.com/> >>>>>> WSO2, Inc.:http://wso2.com >>>>>> >>>>>> Blog: http://sinthu-rajan.blogspot.com/ >>>>>> Mobile: +94774273955 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Imesh Gunaratne* >>>>> Technical Lead >>>>> WSO2 Inc: http://wso2.com >>>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>>> W: http://imesh.gunaratne.org >>>>> Lean . Enterprise . Middleware >>>>> >>>>> >>>> >>>> >>>> -- >>>> *Imesh Gunaratne* >>>> Technical Lead >>>> WSO2 Inc: http://wso2.com >>>> T: +94 11 214 5345 M: +94 77 374 2057 >>>> W: http://imesh.gunaratne.org >>>> Lean . Enterprise . Middleware >>>> >>>> >>>> _______________________________________________ >>>> Dev mailing list >>>> [email protected] >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>> >>> >>> -- >>> Ayashkantha Ramasinghe >>> Software Engineer WSO2, Inc. >>> email: [email protected] <[email protected]>; >>> TP: +94 77 7 487 669 >>> >> >> >> >> -- >> *Imesh Gunaratne* >> Technical Lead >> WSO2 Inc: http://wso2.com >> T: +94 11 214 5345 M: +94 77 374 2057 >> W: http://imesh.gunaratne.org >> Lean . Enterprise . Middleware >> >> >> _______________________________________________ >> Dev mailing list >> [email protected] >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > *Gayan Kaushalya Yalpathwala* > Software Engineer > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 71 8682704 <http://asia14.wso2con.com/> > > <http://asia14.wso2con.com/> > -- *Imesh Gunaratne* Technical Lead WSO2 Inc: http://wso2.com T: +94 11 214 5345 M: +94 77 374 2057 W: http://imesh.gunaratne.org Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
