Question regarding Rest services

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.

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.

What is the size of threaddump file? I believe that it shouldn't be over than 1 GB, am I correct? If so, I think you can upload it to the forum for analysis.

For the heapdump file, instead of uploading the entire file, is it possible to use the profiler tool that you captured data to summarize only the top 20 significant objects/instants that consumed memory heavily?

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.