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):
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?
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.
Note that I did find the API/Component compatibility matrix URL so it seems that the answer to my first question should be yes:
Our Java API version is 8.0 according to the docs
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.
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.
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 (184.108.40.206) from the Open Elektron package and everything worked as expected so I think we're back on track.