The real problem is that Murex is not consuming the data from your TREP fast enough. Technically speaking it is not reading fast enough from the TCP socket.

Anything you do on the TREP (ADS) host is treating the symptom, not the cause.

You can have a look at what goes on by looking at the channel from within the ADS Monitor tool. Here you can see something about message rates that you are expecting Murex to handle and you can see how fast the ADS is filling up its output buffers towards Murex. However, at the end of the day, all of that is really just ammo for your discussion with Murex. The only solution I can come up with that doesn't involve Murex is that you can try to conflate the data stream before it hits Murex. For example the ADS has a Traffic Management feature (trafficManagement=true) that attempts to do on-the-fly conflation when it detects a slow consumer. Never used it but may be worth trying if you cannot fix the problem in Murex.

You can continue to increase the buffers on the side of the ADS but if you do a bit of math on it you may realize that you have increased the buffers to such a size so that data can actually grow quite old in the buffer before Murex reads its (old = minutes, perhaps).

The buffers in ADS are really there for handling sudden bursts which the consumer for whatever reason cannot drain fast enough. If Murex 99.9% of the time is able to keep the buffer at a low level (i.e. it is continuously draining fast enough to not fall behind) then I believe the strategy to increase the buffer may be acceptable. Example: An application may be consuming fast enough most of the time but struggling every Friday when US release the Non-Farm Payroll statistics (=all prices move). In this case the increase-the-buffer-size strategy has some justification ... depending on the type of the application and what conclusions it draws from the data.

Best of luck

Lars

Addicticks