Hi Jeewantha, Thanks for your clarification. That sums up the issue and I guess the restriction in Dev Studio helps in that case. Currently Dev Studio has no intelligence to identify context sensitive mediators in a mediation flow and then allow/block mediators after a send mediator.
Thanks, On Fri, Jun 20, 2014 at 1:38 PM, Jeewantha Dharmaparakrama < [email protected]> wrote: > Hi Gayan, > > This does not always work. For example the following give an > org.apache.axiom.om.OMException Error. > > <proxy name="testProxy" transports="https http" startOnLoad="true" > trace="disable"> > <description/> > <target> > <inSequence> > <send> > <endpoint> > <address uri="http://localhost:9000"/> > </endpoint> > </send> > <log level="full"/> > </inSequence> > <outSequence> > <send/> > </outSequence> > </target> > </proxy> > > > The reason is the message is not fully built when the log mediator is > executed. If you add another <log level="full"/> before the send mediator, > both log mediators will work. > > Thanks, > Jeewantha > > > On Tue, Jun 17, 2014 at 9:50 AM, Gayan Yalpathwala <[email protected]> > wrote: > >> 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/> >> > > > > -- > Jeewantha Dharmaparakrama > Software Engineer; WSO2, Inc.; http://wso2.com/ > Phone : (+94) 774726790 > Skype : prasad.jeewantha > LinkedIn : http://www.linkedin.com/in/jeewanthad > Twitter: https://twitter.com/jeewamp > Blog: http://jeewanthad.blogspot.com/ > -- *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
