Waiting for service IDN_RDF UP. Item recovery in progress...

I am using RFA 8 java version. I got the below message after my login is accepted by my host. Login is successful I can see it in the log. After sending the item requests I received the below event. I don't see any traffic is dropping in the communication from my host. I don't think this is a firewall issue.
MESSAGE
Msg Type: MsgType.STATUS_RESP
Msg Model Type: MARKET_PRICE
Indication Flags:
Hint Flags: HAS_ATTRIB_INFO | HAS_STATE
State: OPEN, SUSPECT, NONE, "Waiting for service IDN_RDF UP. Item recovery in progress..."
AttribInfo
ServiceName: IDN_RDF
Name: 0#USAGENCY=TWEB
NameType: 1 (RIC)
Payload: None
Best Answer
-
@chavalit.jintamalit
Issue Resolved. In the event queue, first of all I am receiving STATUS_RESP message event, so in the example code they are closing the request. When I commented this.closeRequest(); It is processing the next events Now I am getting my data.if (respMsg.getMsgType() == OMMMsg.MsgType.STATUS_RESP)
{
// If receive STATUS_RESP, display the message and close the request
GenericOMMParser.parse(respMsg);
this.closeRequest();
}0
Answers
-
Yeah, well. The SDK examples show you to fire off item requests before just about anything is ready. As everything in the API is asynchronous it means you can do things in (almost) any order, but it doesn't mean you should. Just my two cents.
In other words I suggest to wait for the directory response before you start firing off item requests. Otherwise you may for a short while see this message. The API doesn't yet know if the service is really up or down.
Another reason may be that TREP has lost upstream connectivity to the source app for IDN_RDF. But I'm leaning towards my first explanation. :-)
Lars
Addicticks
0 -
Let me tell you what I am doing,
Modified service name, items, username in
C:\rfaj8.0.1.E2.all.rrg\rfaj8.0.1.E2.all.rrg\Examples\com\reuters\rfa\example\quickstart\QuickStartConsumer and serverlist to my ADS server.
One way: I ran the
C:\rfaj8.0.1.E2.all.rrg\rfaj8.0.1.E2.all.rrg\QuickStart\QuickStartConsumer.bat and I am able to login and able send item requests and received all events.
Second way: I created maven project and moved all *.java files from above directory and ran the QSConsumer.java. here I am able to login and able send item requests and received the waiting messag
0 -
I don't understand what I am missing in my second way
0 -
I'm not sure what the difference is between the two scenarios (maven execute and non-maven execute). The situation I'm describing would be temporary, i.e. you would first receive the message as described in your original posting but then very shortly after this you would receive message with state OK. Are you saying it simply hangs and doesn't receive more messages?
0 -
On another note I'm thinking that you may also get some help by comparing your own results to that of TRexplorer.
TRexplorer is also based on RFA Java.
Step 1: Make sure Output Window is visible.
Step 2: When configuring your connection make sure message tracing is enabled.
Step 3: Connect
Step 4: Have a look in the Output window. You'll see all messages exchanged.
Now compare this with your own development. The answer is in the difference.
0 -
Yes it simply hangs and not receiving any messages at all
0 -
You already confirmed that you received all the event.
So I think the session was not ready when you tried to put the item request.
// 4. Acquire a Session
_session = Session.acquire( "myNamespace::consSession" );
if ( _session == null )
{
System.out.println( "Could not acquire session." );
Context.uninitialize();
System.exit(1);
}
Thread.sleep(5000); // << wait for the session to be ready
// 5. Create an OMMConsumer event source
_consumer = (OMMConsumer) _session.createEventSource(EventSource.OMM_CONSUMER, "myOMMConsumer", true);If you add waiting period for it like the sample code above, you should not get the information message.
0 -
Hello @applicationdevelopment
This error can happen when the application makes
an item request to a service that is not available (i.e. service down, or non-existing
service),RFA will immediately
respond with Open-Suspect status with the status text shown above.To fix this problem, please contact
- your Thomson Reuters Account team if you connect to Thomson Reuters Server
or
-your server's admin if you connect to your company server.
to confirm if IDN_RDF is a correct service name and it is still up.
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 24 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 279 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 714 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛