I'd like to answer some of the other questions posed above.

Is RFA the best API for this job? If you're building a new application or making major changes to one using Java, you should choose the Elektron Java SDK. It is simpler, faster, open-source, and is Thomson Reuters' strategic API for Java. You can download it, watch and download tutorials and sample applications elsewhere on this site. You should not use RFA for a new project.

Alternately, and also for new projects, if you are interested in a Websockets API you can try the new Elektron Websockets API, which is currently in beta.

RFA is not wrong for your situation so if your application is already written and in production you should diagnose and solve these problems, not rewrite. You don't need to proactively rewrite an existing RFA application to EMA and there is nothing inherently wrong about using RFA in a web server environment.

I'm not sure what you mean by "Cloud Ready" but if you mean which is the best API upon which to build a REST service, you should choose based on the above advice. EMA for Java, EWA if you are interested in that, RFA if you are already using it. In all three cases, if you are consuming large amounts of real-time data you'll need to design and code carefully to create a match between the inbound streaming traffic and large amounts of snapshot requests. You may want to cache in your service rather than pass a lot of snapshot traffic back to TREP through the API, but the perfect approach depends on the details of your application.

On a related note, if you're creating a web service for downstream APIs, your service should incorporate Open DACS to ensure compliance by your downstream applications.

To elaborate on this question. We have a client running RFA v8.1.0 and they are experiencing memory leaks and thread wait locks when running under Tomcat.

We suspect the issue may be that RFA requires a Java EE container rather than the Java SE container specified in the documentation because RFA seems to rely heavily on JSR 238 / Concurrency and Threading that is not typical in a lightweight web container such as a servlet / JSP container.

So specifically, is RFA supported within a non-EE container? If so, what JCP/JSR features are required for RFA to provide real-time and delayed market data at low latencies and at high batch sizes?

Thanks,

-David B.

Can we please get an update here?

Hello @robert_hau & @david_boggess,

I'm unsure whether the JSR 238 that you mentioned earlier is the same meaning that I found from Java Community Process or not.

According to https://jcp.org/en/jsr/detail?id=238, the description of JSR 238 is as follows:

This JSR defines an API that provides culturally correct data formatting, sorting of text strings and application resource processing for J2ME MIDlets running in MIDP over CLDC. 

JSR 238 more likely relates to Java ME platform rather than Java SE platform.

However, when referring to the README file in RFA Java 8.1.0, it doesn't mention about Java ME platform at all.

So, I think it is possible that you may want to refer to JSR 283 (Content repository API for Java, which also relates to JSR 170). Can you please confirm whether my understanding is correct or not?

In order to explain what is RFA Java (or other real-time APIs e.g. Elektron-SDK) I can simply says that they are transport layer based applications (OSI model or TCP/IP model) which implements Thomson Reuters's proprietary protocol named SSL or RSSL (or OMM) protocol similar to others communication protocols such as telnet, FTP, etc to receive data from the server feed (such as Infrastructure -- ADH/ADS, Elektron, RDF-D, or local provider).

As you can see, the functionalities of real-time APIs are still in Java SE scope.

4. INTEROPERABILITY    
============================


This section is based on rfaj8.1.0.L1.all.rrg interoperability testing.


4.1 Supported OS and Infrastructure Components


    Core OS Platforms
    ----------------- 
    - Microsoft Windows Server 2008 (SP1 or greater) 32/64-bit
    - Microsoft Windows Server 2012 Standard 64-bit
    - Microsoft Windows 7 Professional 32/64-bit
    - Microsoft Windows 8 Professional 32/64-bit
    - Microsoft Windows 8.1 Professional 32/64-bit   
    - Microsoft Windows 10 Professional 32/64-bit   


    - Red Hat Enterprise Linux Advanced Server 6.0 (or grater) 32/64-bit 
    - Oracle Linux Server 6.0 (or greater) 32/64-bit 
    - Oracle Linux Server 7.0 (or greater) 64-bit
    - CentOS Linux 7.0 (or greater) 64-bit


    Core Java VMs  
    -------------
    - Java SE 7 (JDK1.7)
    - Java SE 8 (JDK1.8)

...

Moving back to the question, running RFA Java in Java EE platform requires a further implementation to support it (for instance, to support REST via JAX-RS which belongs to Java EE platform). Perhaps, the problem may happen from the implementation or incompatibility too.

For this reason, I need more detailed about the memory leak and thread wait lock problem to verify the actual culprit of this issue, especially memory leak problem is pretty complex to investigate because it may be a result of another problem too.

In that case, can I have the following information to verify these issues?

• Memory Leak: Memory Dump from Java's tool such as JProfiler /Java VisualVM (in JDK package). This is used to determine instances that consume memory resources.
• Thread Wait Lock: Thread Dump from jstack (in JDK package as well). It will be used to check the locking scenario.

Hi @Nipat

We can provide the heapdump and threaddump for the issue. It's over 8 gb. How and where would you like me to upload the files?

Hi,

Just to add some context, the client is using RFA and has been running it in production for something like 10-15 years. They are using Servlet containers (Tomcat etc.) but I suspect something is going awry because Interruptable Thread seems to be emitting a javax.realtime.RealtimeThread when run in an EE container or a contemporary Java Application, but seems to be returning a simple Thread within Tomcat. We are noticing performance differences (50k request per second in classic Java vs. <20 request per second in Tomcat).

-David B.

In my opinion, in order to identify where the bottleneck of the performance problem is that the application architecture design should be separated into different tears/modules as follows:

• RFA is a back-end service which is responsible for getting instrument names from a front-end service (web service interface), subscribing to the server, then return a result to the front-end.
• The front-end service is web service implementation that receives input from a user, forward to RFA, waits for the result, and returns it the use

The back-end service which contains non web service related should work as same as a pure RFA Java application. However, when you run RFA Java in Tomcat Server, its performance might drop a little bit because it is like running the application through a wrapper of Java Runtime component which has an overhead during processing program.

If the test result from running pure RFA Java in Tomcat server is acceptable, the difficult part is the integration between the back-end and the front-end that requires performance tuning up. That's why we would like to see the first 20 objects that eat up the memory, and the thread lock relates to RFA underlying layer or not.

In addition, by the nature of web services' communication is request-response, when you implement RFA Java with web service technologies. So, it is suitable for a snapshot communication rather than a real-time communication.