Hello @han.sg,

1. On RFA.Net consumer, SingleOpen is enabled by default, unless you have specified the attribute explicitly, no action is required, and your consumer implements SingleOpen.

2. On Stale/Ssuspect, no action is required, other then reporting, that the data is suspect. Disconnect and reconnect on consumer will not be helpful. The temporary suspect state is supposed to clear back to ok. If it did not for some items, the issue likely have been deeper, with publisher, infra, etc., nothing that consumer can help with, or should do, other then report.

Hello @han.sg,

First thing to check is that you are doing SingleOpen. If that is the case, RFA will try to recover open items on application's behalf whenever at all possible. See Item Recovery in Developer's Guide.

To better understand the detection, you may find this previous discussion to be of help.

Also would like to add, that if you are designing a new application, consider choosing Elektron API suite over RFA. For C#/.Net intergration, Elektron Websoket option may be a good option, depending on your requirements, for C/C++ or Java, EMA may be a good option.

Hi @zoya.farberov ,

Thank you for your responses.
1. I read on the developer guide, It states that "if a provider does not specify SingleOpen support in its login response, then RFA assumes the provider supports it. (default behavior)". On my application, I did not specify SingleOpen, so I supposed it to be true by default behavior.

2. In my case, after the server connection re-established, only some items become stale. When an item becomes Stale, what is the current behavior of RFA? With SingleOpen option, will it automatic perform item recovery for Stale Item? Is there any action needed from client side to recover for stale item?

Regards,

Hello @han.sg,

There were two questions, items recovery and items stale in the title, and I have focused on item recovery, as I feel it is very important in terms of application design, and you have mentioned that some items did not recover properly in this case.

I have concluded, from the question, that your app is a consumer, not a provider. Is this correct? In Item Recovery section I have mentioned please note "If SingleOpen is not requested by the client, the client is responsible for re-requesting all items when the connection is re-established". I have just re-read twice the passage that you mention, and it is totally correct in references to how Providers support SingleOpen. Is you app a custom provider?

Items reported stale is separate, can happen for a number of reasons, they are not closed, and application does not need to recover. It means that the state of the item can not be confirmed as current. A consumer may action this according to design, usually log/report to business tier as stale.

In conclusion, a consumer should:

• Either request SingleOpen or handle recovery of every item on reconnect explicitly
• Report Stale/Suspect status: log, message, display, in line with this applications reporting requirements

I hope this looks more clear?

Hi @zoya.farberov,

Thank you so much for your clarification,

My application is indeed a consumer. I am trying to design my application to handle the following case.

What happens to my application is that: When the server failed over, my application did not disconnect to it, after that a few names became Stale/Suspect and continued to be Stale/Suspect until EOD.

Q:

1. Would enabling SingleOpen in login request help to handle this case? (I read in the documentation, it is enabled by default behavior. So I supposed my application used it by default since my application did not specify SingleOpen to false).

2. In Stale/Suspect status event, is there any action from consumer to handle other than report Stale/Suspect status in log? Should consumer disconnect and reconnect the server in this case?

Than you again. Since I am quite new to RFA .net, I am really appreciate any more information!

Regards,