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
