Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 gay...@wso2.com wrote:
Hi All,
On Mon, Jun 16, 2014 at 11:53 AM, Imesh Gunaratne im...@wso2.com 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 gay...@wso2.com
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 im...@wso2.com
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 ayashkan...@wso2.com 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 im...@wso2.com
wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com
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
sinth...@wso2.com 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 im...@wso2.com
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
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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
jeewan...@wso2.com 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 gay...@wso2.com
wrote:
Hi All,
On Mon, Jun 16, 2014 at 11:53 AM, Imesh Gunaratne im...@wso2.com 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 gay...@wso2.com
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 im...@wso2.com
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 ayashkan...@wso2.com 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 im...@wso2.com
wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com
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
sinth...@wso2.com 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 im...@wso2.com
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
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 gay...@wso2.com 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 im...@wso2.com 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 ayashkan...@wso2.com 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 im...@wso2.com wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com
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
sinth...@wso2.com 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 im...@wso2.com
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
Dev@wso2.org
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
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
Hi All,
On Mon, Jun 16, 2014 at 11:53 AM, Imesh Gunaratne im...@wso2.com 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 gay...@wso2.com
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 im...@wso2.com 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 ayashkan...@wso2.com 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 im...@wso2.com
wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com
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
sinth...@wso2.com 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 im...@wso2.com
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
*Sinthuja Rajendran*
Software Engineer http://wso2.com/
WSO2,
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 im...@wso2.com 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 ayashkan...@wso2.com 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 im...@wso2.com wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com
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 sinth...@wso2.com
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 im...@wso2.com
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
Dev@wso2.org
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Ayashkantha Ramasinghe
Software Engineer WSO2, Inc.
email: ayashkan...@wso2.com sanj...@wso2.com;
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
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 im...@wso2.com wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com 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 sinth...@wso2.com
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 im...@wso2.com 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
Dev@wso2.org
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Ayashkantha Ramasinghe
Software Engineer WSO2, Inc.
email: ayashkan...@wso2.com sanj...@wso2.com;
TP: +94 77 7 487 669
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 ayashkan...@wso2.com 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 im...@wso2.com wrote:
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com 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 sinth...@wso2.com
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 im...@wso2.com
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
Dev@wso2.org
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
--
Ayashkantha Ramasinghe
Software Engineer WSO2, Inc.
email: ayashkan...@wso2.com sanj...@wso2.com;
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 sinth...@wso2.comwrote:
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 im...@wso2.com 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
Dev@wso2.org
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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
s/comapred/compared/g
s/millisecods/milliseconds/g
On Thu, Feb 13, 2014 at 10:21 AM, Imesh Gunaratne im...@wso2.com 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 sinth...@wso2.comwrote:
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 im...@wso2.com 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
Dev@wso2.org
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] [BAM] Optimizing BAM Mediator Data Publishing Logic
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 im...@wso2.com 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
Dev@wso2.org
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
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
