What is rmi tcp connection thread in jira ?

Christophe Bordieu April 16, 2015

Hi,

Is it normal there is a RMI TCP Connection(n) thread that is always running in JIRA server (with Agile and Portfolio) ?

n is increasing as well as TID meaning (I guess) that thread sometime dies and is then restarted with n+1.

I am trying to understand why, since yesterday (around noon) when I triggered a JIRA backup (that finished (.zip was generated) but with a timeout from our proxy), there is at least one CPU that is largely more used than others (16 CPUs server) and than before, and server load increased too (x10 during the night when almost nothing happens). I look at various threads (with jvmtop) but it is not useful for me based on the fact I have no knowledge of Java.

Regards,
Christophe

1 answer

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

3 votes
crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 17, 2015

It is definitely normal when running JIRA Data Center, as Remote Method Invocation (RMI) is the technique used by our caching technology to replicate information between nodes.  I can't think of any reason offhand why RMI would be used at all in JIRA Server.  My guess would be that you have a plugin that makes use of it for something.

Threads that do I/O can be shown as "RUNNING" when they really aren't, so the information you're looking at may simply be misleading.  This is because what the JVM reports as the thread's state is only aware of the thread scheduling that it directly controls.  When it invokes a native method, the thread's scheduling leaves its control, and native I/O calls like socketRead0 block the thread without the JVM's knowledge, so it does not update the state that it reports for that thread.

RMI has a client-server structure, and the specification leaves thread management up to the implementation.  Since the easiest thing to do is create a temporary thread to handle the I/O and throw it away when finished rather than try to reuse the threads, this is what I would guess you are seeing as far as the increasing value of "n" is concerned – I'm just not sure what would be generating those RMI requests in the first place.

If you are using JDK 7, there are some aspects of how it deals with multiple CPUs that can lead to degrading performance over time, particularly in JIRA 6.2 and later.  If that is your situation, then I would recommend that you get up JIRA 6.3 or later and use JDK 8 instead (build 1.8.0_40 at least – the earlier ones have some severe bugs).

 

ChrisV April 27, 2015

Thanks for this info Chris - just to clarify, is that upgrade to JIRA 6.3+ AND JDK8, or either of those options? We're currently on JIRA 6.3.15 but still on Java 7...

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 27, 2015

Well hello, CLP! ;) It is AND. 6.3+ is required to use JDK 8, and it is JDK 8 that has the improved handling of large numbers of CPUs. See https://confluence.atlassian.com/display/JIRAKB/Java+8+Improves+JIRA+Performance+Dramatically for more details about why this matters and how to tell if it would help for a particular JIRA installation.

ChrisV April 27, 2015

Howdy indeed! Thanks for the clarification and also the headsup on that KB :D

Christophe Bordieu April 27, 2015

Thanks Chris for your explanations. I have updated my JDK from 1.7.0_60 to 1.8.0_40 as recommended (we use JIRA 6.3.15). Will let you know if we notice better behavior.

Christophe Bordieu June 18, 2015

Some feedback: very good ! CPU/Load metrics are very good and stable now compared to what we had with Java 1.7.

crf
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
June 18, 2015

Glad to hear it!

TAGS
AUG Leaders

Atlassian Community Events