TREP 3.2 ADH clients unable to connect to Java-based Interactive Provider application that works ...

Paul.Wuethrich2

...with TREP 2.6 ADH clients

We have a live Java-based Interactive Provider (server side provider with a single socket accepting requests from multiple clients) application that uses the following libraries from 2016 or earlier (legacy UPA Java API bundle):

ansipage.jar/jdacsUpalib.jar/rfa.jar/upa.jar/upaValueAdd.jar/upaValueAddCache.jar

This has been working with TREP 2.6 ADH clients without issue for some time.

Now, this same code base is no longer working with TREP 3.2 ADH clients as the individual client Channels become inactive and so the ADH client login requests time out since the Java Interactive Provider ends up closing/removing the Channel as its state is INACTIVE. The implementation follows the spirit of the example documented in the Java API documentation (UPAJDevGuide.pdf).

1) Do we need to update the corresponding Java API libraries (jar) to work with TREP 3.2+?

2) Is there anything that's changed in the API that would require an update to how we instantiate the UPA server (e.g. BindOptions, etc.), accept incoming client requests, etc?

zoya faberov

Hello @Paul.Wuethrich2,

It looks like the issue is specific to your provider and will require an in-depth investigation, code walk-through, etc.

If you organization is an RDC member, the best approach is for one of the named RDC users to open an RDC support case via “Contact Premium Support” link atContact Premium Support

If not, or you are not sure, the best approach is to get in touch with your Refinitiv account team on the information about RDC membership.

Paul.Wuethrich2

Note that I did find the API/Component compatibility matrix URL so it seems that the answer to my first question should be yes:

https://developers.refinitiv.com/elektron/elektron-sdk-cc/docs?content=5403&type=documentation_item

Our Java API version is 8.0 according to the docs

zoya faberov

Hello @Paul.Wuethrich2,

UPA8 and RFA8 providers are supported by ADH/ADS 3.2, this is correct.

The providers are not TREP 2.6-specific.

Therefore, something else must be happening that causes the client behavior as you describe with this provider.

As an approach to finding out where the disconnect is originating, would it be possible to verify the disconnect by running the example provider from UPA SDK, having your consumers connect, and see if there are disconnects?

Would also check with your market data team, to see, if any more info related to the disconnects is available from ADH/ADS logs. If not, ideally, the logging level can be increased on the infra side to allow to gain more insight.

Paul.Wuethrich2

Thanks for the note - we'll be going down this path. Right now, all we have from the remote ADH client side are Login Request timeouts messages and all we see is an inactive channel on the server side - very strange

Paul.Wuethrich2

No problem connecting using the java-based Consumer application

zoya faberov

https://community.developers.refinitiv.com/discussion/comment/40772#Comment_40772

Hello @Paul.Wuethrich2 ,

Let me confirm, are you saying that:

Your org has migrated infra from TREP 2.6 to TREP 3.2

No problem with Java example provider and your consumer?

Or no problem with Java example provider and Java example consumer?

No problem with Java custom provider and Java example consumer?

Paul.Wuethrich2

Apologies for the delayed response:

1) Java API example worked as expected (from within the firewall)

2) We have external customers running 2.6 and 3.2 as well as an internal migration to 3.3. Neither the 3..2 external customer nor the internal 3.3 ADH clients are able to connect.

3) Our Provider is written in Java and per the initial note, been running live for over a year with external 2.6 clients.

Regardless...

Our debugging/instrumentation related changes/efforts did NOT help identify why the 3.x Channels became inactive after the successful Channel connection/creation (transition to "ACTIVE") so we updated to more recent libraries (3.2.0.2) from the Open Elektron package and everything worked as expected so I think we're back on track.

Thanks