This code works when executed as a command line application, but the call to Session.Acquire hangs when run from an IIS application. This issue affects v188.8.131.52. However, v7.x works correctly.
if (Context.Initialize() == false) throw new System.Exception("Failed to initialize RFA Context.");
cfgDataBase = ConfigDatabase.Acquire(new RFA_String("RFA")); if (cfgDataBase == null) throw new System.Exception("Failed to acquire RFA Config Database");
stgCfgDataBase = StagingConfigDatabase.Create(); if (stgCfgDataBase == null) throw new System.Exception("Failed to create RFA Staging Database");
var result = stgCfgDataBase.Load(ConfigRepositoryTypeEnum.flatFile, new RFA_String("./ElektronRFAConfig.cfg")); if (result == false) throw new System.Exception("Failed to load RFA Config Database");
result = cfgDataBase.Merge(stgCfgDataBase); if (result == false) throw new System.Exception("Failed to merge RFA Staging and Config Databases");
eventQueue = EventQueue.Create(new RFA_String("Queue1")); if (eventQueue == null) throw new System.Exception("Failed to create application event queue.");
session = Session.Acquire(new RFA_String("Session1"));
I hate to admit this but I just spent a day and a half trying to figure out why an RFA application we've been using for almost 10 years all of the sudden stopped working when we tried to run it on a new server. I was going nuts making sure we had the appropriate VC++ redistributables, DACs ID settings, port numbers, and checking RFA settings out the wazoo. Not to mention the fact that I've been driving our Infrastructure and Reuters Admins nuts about ports being blocked and permissions not being set up properly. Looks like I'm going to be eating a nice slice of crow for dinner this evening!
@paulofogaca - if you don't mind would you please take a moment to explain the scenario that causes this and why adding that property to the config fixes it? There is little in the way of information in the RFA ConfigGuide. This is all the information we're given:
Logger\AppLogger\useInternalLogStrings When enabled, uses log strings stored internally in RFA libraries or DLL’s. RFA[x]_MsgFile.dll (static) is not required when this option is enabled. Using this option will override windowsLoggerEnabled and not log events ** Reference: App Logger Fields in RFA Config Guide (Table 12)
I've searched online and from what I've been able to gather, it seems the RFA session object is looking for a user setting in the registry, but the path does not exist because the service account has never logged in to the server. Is this correct? If so, is it possible for Reuters to do something like throw an exception or exit when trying to acquire the session (as opposed to sitting there indefinitely and providing absolutely no detail at all)? I imagine it's probably a one-liner, along the lines of the following:
if (registry.Exists(path) == false) return;
In any event, thank you @Jesse_Perrin and @paulofogaca for providing a question and answer to this problem. Oh, and for helping me keep my sanity! :)
Based on the solution provided by paolo, I guess that the original issue relates to the RFA Exception thrown from RFA internal when it unable to locates the RFA Component Logger files. It looks like the user does not deploy the RFA message files in the same folder as they set in the original server.
As far as I know, running the app under IIS, the running directory is the difference from running stand-alone WPF or console app so that you might need to deploy the RFA.NET message files which are RFA DLLs in the Windows system directory or set the relative or absolute path in RFA Component Logger config instead. Please find details about the RFA component logger in RFA.NET Configuration file section 2.4.2 Component Loggers. And you also can find the details about the RFA logger in the RFA.NET Developer guide section. 10.2.1 Configuring the Logger Package.