RFA API Connect fail in murex

we have an 3rd party software is named Murex. this softward using your RFA tools to connect our TREP server. but connection are very unstable. we try to increase "*ads*maxOutputBuffers" value in TREP's rmds.cnf and connect success, but we had modify it four times since last year. it may be an good soluation. could you help to check what is we can do?

our setting in murex RFA Configuration Editor :

(MX current Reuters RFA Java API is using rfaj7.2.0.E3.)

connectionType : RSSL

serverList : trep1, trep2

serviceList : IDN_SELECTFEED

downloadDataDic : false

and trep server ads log find some warning :

<taireuter2.1.ads: Info: Mon Jun 06 18:42:42 2016>
The following AppIds will be ignored when calculating the maxMounts for Software Statistics: 56,160
<END>

<taireuter2.1.ads: Warning: Mon Jun 06 18:42:46 2016>
Output threshold breached for murex at position 172.17.213.148/ST on host MUREXAP2T using application 185 on channel 13.
<END>

and TREP Server rmds.cnf setting modify item :

*ads*guaranteedOutputBuffers : 400 (default) --> 500
*ads*maxOutputBuffers : 500(default) -> 2000 --> 2400 --> 3000 (four times)
*ads*poolSize : 50000 (defalt) --> 100000

Find more posts tagged with

trep

rfa

rfa-api

Accepted answers

Lars-at-Addicticks

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

All comments