In one of our EAI implementation, we are using synchronous request/reply model with broker as the messaging layer between the modules.
We are using the service pub.publish:publishAndWait to achieve this.
Surprisingly, we have observed huge time-lags between publication of document and receiving the document.
At times, the delay runs to around 3 secs.
Please let us know if you have any suggestions for improving the performance / broker performance tuning
Also, is there any difference in the way IS/broker treats publish and publishAndWait for publishing the document

Thanks,
Prithvi

Hi Mate

These two undocumented server configs might help

watt.server.control.triggerInputControl.delays [Default =500,1000, 1500, 5000]
watt.server.control.triggerInputControl.delayIncrementInterval [Default=10000]

The first is how often the IS polls the trigger, so you might like to set it lower. The second is like a backoff, by default after 10 seconds (10000) it takes longer to make the next poll and then after another 10 seconds, longer again

so your first trigger after sometime can be waiting for this poll time, which can be as high as 5 seconds.

if you set low values for each of these you might get around some of the problems you had

cheers

Louis

Will these trigger settings have any impact on a request/reply operation where no trigger is in use?

Prithvi, you didn’t mention where the replier is located–is it another IS? Another module withing the same IS?

What’s the rationale behind using pub/sub for a synchronous call?

Hi Louis

Thanks a lot … it works …
however, i observed that every alternate document takes a longer time…
suppose if the first document takes 30ms to make it to the subscribing service, the second document takes almost 300ms …
… any idea why would this be

Rob … currently both the requester and the replier are residing on the same server, but we will be moving the replier to a different server.
pub/sub is being used here to have loose coupling between the two systems

Prithvi

The time difference could be due to any number of things, including other work the server may have been doing at the time.

“pub/sub is being used here to have loose coupling between the two systems”

Using pub/sub in a request/reply mode provides almost no loose coupling. You get decoupling at the communication level, which is an okay thing, but you’re still coupled by the messages that are exchanged AND by the fact that the replier must be on-line and responsive. If you’re worried about 300ms response time, then pub/sub is not the right solution. Particularly with IS as the Broker client. The Broker is speedy and can pump a ton a messages out in a short time. The IS is distinctly less focused on throughput.

Being able to change the location of the replier without needing to change anything on the requestor is a nice thing–but how often does that sort of change really happen?

Pub/sub can be a powerful construct. IMO, it is generally a poor mechanism to use for request/reply interactions in terms of real benefits.