Performance issue with SymbolList / BDS
We have a Java RFA v. 8.0.1 consumer that maintains an item reference database by keeping open streams 16 symbol lists defined as BDSs in our Edge (our path is Consumer -> ADS -> ADH -> Edge).
For simplicity all 16 streams are opened at the same time even though only one stream provides refresh messages while the rest of the streams reports "Item Request Timeout".
Only when a refresh is completed the next stream starts supplying refresh messages until all 16 are done.
In general that works fine but now and then the symbol lists responds with states like :
F2:Source application did not respond.
Waiting for service XXX. Item recovery in progress...
No connection or service is currently up that supports this request.
It's not clear to us if these states are generated by ADH, ADS or Edge ?
Are these states side-effects of asking Edge to maintain databases of effectively all items available on the ILA ?
Does TR have any recommendations or guides on how to tune Edge to support this kind of usage ?
I should probably add that we now and then have multiple consumers (for different environments) running at the same time.
So maybe it is ADS or ADH that actually gives up serving multiple consumers of the same symbol lists - especially as a full refresh easily can take 5 minutes...
Hello @John.Westi
To let me investigate this issue in detail, could you please give me the following information?
- Does the application subscribe 16 symbol lists in batch or separate request messages?
- The ADH and ADS versions
- The RFA trace files when the problem occurs and when the application works fine. The RFA trace file contains incoming/outgoing messages between the API and ADS server. It will let me verify this issue (focusing on incoming Refresh Response) in detail.
You can configure the following RFA Java configurations to enable the log file
- <namespace>/Connections/<Connection Name>/ipcTraceFlags = 7
- <namespace>/ Connections/<Connection Name>/mountTrace = True
- <namespace>/ Connections/<Connection Name>/logFileName=<path to log file>
Example RFA Java Configuration for the trace file
<node name="rsslConnection">
<map>
<entry key="connectionType" value="RSSL"/>
<entry key="serverList" value="localhost"/>
<entry key="portNumber" value="14002"/>
<entry key="ipcTraceFlags" value="7"/>
<entry key="mountTrace " value="True"/>
<entry key="logFileName" value=".\logs\RSSL_%U.log"/>
</map>
</node>
Hello @John.Westi
F2:Source application did not respond: This message is generated from the ADH server. ADH sends this message as a response to an item open request when the ADH times out the request.
Waiting for service XXX. Item recovery in progress: The message indicates the subscription service is not available (DOWN) in the TREP level (ADS, ADH or EZD) and RFA Java is waiting for the service to become available (UP). This could occur when the service is down or the connection between the application and the server is lost. Basically, RFA Java handles this scenario automatically and the application does not need to handle this by itself. Once the connection is re-established or the service becomes UP, the application will automatically continue to receive the subscribed data as normal.
No connection or service is currently up that supports this request.: This message
indicates that the service to which the application was requesting did not support the subscription model.