Hi All,
On Mon, Jun 16, 2014 at 11:53 AM, Imesh Gunaratne <[email protected]> wrote: > 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. > I have discussed about this offline with Jeewantha and figured out some exceptional cases where we get to add mediators after a send mediator. @Kasun, Why do we execute the flow after a send mediator since we expect only a non-blocking behavior from a send mediator? If so, we need to attend and sync these scenarios in ESB and Dev studio. > 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 > > Thanks, -- *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/>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
