question

Upvotes
Accepted
5 0 1 2

Provider accepting state interaction with ADH with discourageRequestsOnOutage enabled

We have an RSSL provider built against RFA 8.1 using the C++ API.

When the process detects that it is becoming a slow consumer it should stop accepting new requests but to infer that all existing requests are still ok. This is currently communicated to the ADH by sending a directory message with:
- load factor set to 65535;
- service state as 1 (Up); and
- accepting state as 0 (Not Accepting)

But, when this is sent to an ADH with discourageRequestsOnOutage enabled all requests are marked stale. This was using ADH 3.2.3.

Is this understanding of the accepting state incorrect? Should the process leave the accepting state as 1 (accepting) and simply "prevent" new requests by the use of the load factor alone?

treprfarfa-apiOMMrssl
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
23.6k 84 10 22

Hi @sbutler9

Based on the information you have provided, it would appear that the ADH behaviour is not as expected.

Therefore, I would recommend you raise a Premium Support ticket and/or raise a TREP support ticket - so that this can be investigated offline in more detail with input from a TREP expert.

Please include relevant trace files from the Provider, Consumer and relevant ADS/ADH logs to help with the investigation.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
23.6k 84 10 22

Hi @sbutler9

When you say all requests are marked stale, do you mean new request or do you actually mean existing open items are receiving Stale status messages?

If you set AcceptingRequests to false, it indicates to the ADH that your provider will not accept any new requests.


Also, may I ask if you are developing a new Provider application with RFA or updating an existing application? If a new development, our recommendation is that any new development work is done using our newer strategic Refintiv Realtime SDK - rather than the legacy RFA APIs. The EMA part of the RealtimeSDK is much easier to learn, implement and maintain (than RFA) and will be supported for a much longer time period in the future.

The link above is for the Java version and it is also available C++


1602072174318.png (61.7 KiB)
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

The above appears to be from the RDM Usage guide and is what we have been using as our reference. Our intent is to not accept new requests but keep existing ones ticking over. Our provider includes a status of Open/Ok/None in this scenario. It does not include a group filter entry.

The adh logs the following:

"Source Application is no longer accepting requests and dismountOnOutage is enabled. The server will be removed from the network."

A test consumer connected to the ADS receives a group entry with a Closed Recover/Suspect/None state and text of "A23: Service has gone down. Will recall when service becomes available."