Hi @jeff.kenyon0

I am not a Python expert, but one thing I noticed with the RDP Library is if the wait loop /sleep is not properly implemented, the library may not be function correctly in terms of callbacks and authentication. I was previously using sleep() but was advised by the RDP Lib team to use something like the following:

while (time.time() < exit_time):
    # The following line ensures the async event callback mechanism works
    asyncio.get_event_loop().run_until_complete(asyncio.sleep(1))

Also, can you confirm which version of the RDP library you are using - the latest version is

pip install refinitiv-dataplatform==1.0.0a10

and several issues have been fixed over the past few months.

Hi @jeff.kenyon0

The code snippet you provided above opens a session, performs a snapshot, then closes a session. I want to confirm if this is what you are doing every 30 seconds? If so, what I would suggest you do is:

1. Open the session
2. Every 30 seconds perform your snapshot
3. When you are done, close the session

The difference here is that you don't need to open and close the session every 30 seconds - you just need to do that once during the life of the application.

Alternatively, you don't really need to even do this. That is, you don't need to perform a snapshot every 30 seconds but instead set up your request as streaming. So during the life of the application, you can capture streaming updates within a callback that ensures the data you have is fresh and up-to-date. For example:

1. Open the session
2. Request to stream your ~40 RICs
   • You will receive a "refresh" message contain all fields requested
   • You can hold these messages within a cache
   • Whenever market conditions change for any of the ~40 rics, you will receive an update
   • For each update, you can update the fields within your cache
3. Because you are streaming your requests, your values are accurate - they are not potentially 30 seconds old which is what is happens when you perform your mechism
4. Close the session

Thanks for the response. To confirm: every 30 seconds, I open the session, snap, then close (then I add the rows to my collection data frame, then wait for the next snap).

I had initially set this up as a streaming application, but had authentication issues there as well, where, after some period of time successfully capturing streaming events, authentication would spontaneously fail. I switched to this approach because I'm fine with a snap every 30 seconds (it's possible for the instruments I'm looking at there may not be an update during the 30 minute window), but most importantly, I wanted to avoid, at all costs, these random authentication errors. I thought I'd be safe by opening and closing, and simply having separate sessions, but apparently not.

My biggest issue is that I don't know why the authentication server is failing. To me, it looks utterly random. I can't set up a test case that reliably triggers the error because sometimes it runs with no problem. And the error message is of no help. I'm apparently violating some policy, but no one will tell me what it is.

If I move the open and close session calls outside of my loop (one open and close for the 30 minute window), I feel like I'm risking a random error if/when it tries to reauthenticate during that period...which is what happened with the streaming connection.

What would be the minimal amount of change possible to make the current approach work (separate snaps, not streaming), not "flood" the system with my 60 snaps during the 30 minute window, AND guarantee that the authentication server won't take a sudden unexpected dislike to me?