question

Upvotes
Accepted
20 7 8 11

TREP 3.2 ADH clients unable to connect to Java-based Interactive Provider application that works 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?

elektronelektron-sdktreprrtjavaeta-apielektron-transport-apiinteractive-provider
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.

@Paul.Wuethrich2

Hi,

Thank you for your participation in the forum.

Are any of the replies below satisfactory in resolving your query?

If yes please click the 'Accept' text next to the most appropriate reply. If you have an answer, please share your answer, and then accept it. This will guide all community members who have a similar question.

Otherwise please post again offering further insight into your question.

Thanks,

AHS

Hello @Paul.Wuethrich2

Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query?

If so please can you click the 'Accept' text next to the appropriate reply. This will guide all community members who have a similar question.

Thanks,

AHS

@Paul.Wuethrich2

Hi,

Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.

Thanks,

AHS

Upvotes
Accepted
32.2k 40 11 20

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.

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.

Hello @Paul.Wuethrich2,

Were you able to proceed on the suggestion?

Upvotes
20 7 8 11

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

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
32.2k 40 11 20

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.

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
20 7 8 11

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

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
20 7 8 11

No problem connecting using the java-based Consumer application

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.

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?

Upvotes
20 7 8 11

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

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.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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