So recently I was engaged by a client to lifecycle some complex event processor applications, migrating from the old and creaky object-based TibMsg interface to the new and shiny OMM interface to listen to Reuters prices over the Reuters Robust Foundation (RFA) API version 7.6.

So the implementation was done – which required a complete change in thinking. It was a sharp departure from the warm and familiar world of over-the-wire object transmission to the far less reassuring domain of asynchronous messages.

The TibMsg interface requires actors (consumers and producers) to interact with RFA using preconstructed objects. Login and subscription/publication objects are constructed by the actors application code and then listeners are implemented to receive responses from RFA in the form of TibMsg objects. The listeners only need to be implemented for market price data and system events. Nice and easy.

The OMM interface uses the same login/subscription/publication pattern, but requires the caller to “message” RFA instead. That means that the login step is independent of the subscription/publication step and so on. Added to the mix is the fact that each message will be responded to asynchronously, using a listener running on a different thread which only must exist until the desired response is received and then the thread must exit –  with the notable exception of the market price listeners. The upshot is that the caller is forced to write a bunch of Futures (i.e. threads that return a value later on) to monitor response messages. It got quite messy to orchestrate.

Anyway, the OMM interface was successfully implemented and deployed to a development linux server for two components .  One component was (accidentally) configured to log each RFA call at the finest trace level, producing very large and useless log files for, get this, both components!

Yep, configure OMM for one component, and the other “automagically” takes on that unrelated components OMM config too. Bah!

After much head scratching and a quite a bit of blue air, it became apparent that this automagic was in fact due to a hidden configuration directory which had been snuck into the root of the app users home directory i.e. ~/.java/.userPrefs/com/reuters/rfa/RDMS.  Here there were two directories: Sessions/ and Connections/. The directory names under these sub directories were mad: “/::|&%%’ and so on.

So whenever one of the components was (re)started, RFA would copy the config shipped with the application to this hidden location and then start.  It was not clear to me if the copying action was exclusively additive, so if a config property, such as logging, was removed from the component config, the hidden properties location did not remove the unwanted property.

Anyhow, this is explained why when only one component was started it took on the (bad) configuration of the other application!

The cure was simple: fix the component config, removing the unwanted logging properties, shut down all relevant components, delete the Sessions/ and Connections/ directories in the hidden preferences directory, set the hidden preferences directory to read only AND then start a component.  Piece of cake.

Suffice it to say that this spooky action at a distance was not well documented … Thanks RFA!