Is it possible to generate multiple copies of rfa.log, one per process, rather than one per machine?

Bondy_Bo

If you refer to the RFA_ConfigGuide.pdf for the fileLoggerFilename parameter, it mentions the ability to include things like Process ID in the filename.

e.g. \Logger\AppLogger\fileLoggerFilename="rfa{p}.log"

will generate a log filename named something like rfa1234.log

I have just tested briefly here with RFAC++7.4 on Windows and ran two concurrent instances of the same app and two seperate rfaxxx.log files were generated in the current working directory

DevTrev

It's been a while since I've used the RFA Market Data Interfaces (the name is really a misnomer, isn't it?) but first thing you'll have to make sure you have the request throttling that RFA applies itself under control so that it doesn't interfere with your results. Configuration variables to look into are throttle*. Have you considered those?

Secondly I know the ADS can be tuned to give more attention to serving new requests as opposed to serving existing requests with updates. The default settings in ADS favours servicing existing subscriptions ... which makes a lot of sense.

Lastly your request performance will always depend more than anything else on whether the ADS already has the item in its cache or if it has to go the ultimate source to get it. You can really only test request performance if you warmup and lock-in all your items in the ADS's cache before your begin your test of request performance.

If it is just a matter of avoiding timeouts then simply tune the timeout parameters in RFA and tune things like OpenWindow (or is it OpenLimit??) on the ADS and the throttleMaxCount in RFA. If - on the other hand - you really want to increase the request throughput performance (which of course will also give you less timeouts) then you have to do a more thorough analysis.

But coming back to your question: Is there something that can be done on the event queue model in RFA? Sure you can make your application multi-threaded and fire your requests on multiple connections concurrently. But I bet your immediate problem is elsewhere so this may not be worth the trouble.

If you upgrade your application to be a RSSL consumer then you'll see increased request performance just from that move. Also RSSL has things like batch requests which SSL doesn't have.

I hope this gave you some pointers.