JDBC Connections are not counted properly for Jira or Confluence

[GoogleCodeExporter]

Take a look on how the graph is looking for a configured Jira or Confluence 
Instance. 
Java Melody was already configured to monitor JIRA's JNDI connection and you 
can see this from the graph.

Still, the DB connections are clearly not correct. The server is configured to 
use up to 60 connections and obviouly cannot have so few connections.

I suspect the cause is because this is polling the connections open at one 
moment in time, instead of having connections used during last measuring 
interval. This makes the graph almost useless.

Here is a page that could help 
https://confluence.atlassian.com/display/DOC/Live+Monitoring+Using+the+JMX+Inter
face

If will be glad to provide more information if needed.

Original issue reported on code.google.com by sorin.sb...@gmail.com on 9 Feb 2014 at 12:55

Attachments:

• activeConnections.png

[GoogleCodeExporter]

I am surprised of what you suppose about JIRA and about this graph, without 
giving any other measured metrics.

Moreover, the maximum of connections may perhaps be related to the "used jdbc 
connections" graph, but it is pointless to relate the maximum to the "active 
jdbc connections".

Note that "active jdbc connections" is the number of connections executing a 
SQL query. (Fetching the result of a SQL query or rendering a http response do 
not count in "active jdbc connections".)

In fact, your graph seems correct to me.
So I think that we can close this issue as invalid.
OK?

Original comment by evernat@free.fr on 14 Feb 2014 at 9:39

[GoogleCodeExporter]

Last week I got JIRA running out of database connections (30), and after this I 
installed Java Melody, hopping that it will help me track the connections, so I 
would know if they are lost or was just a very short peak.

My JIRA instance is under heady load and I do see 1-2 db connections, never 
more than this, even while jira is performing a background reindex.

Original comment by sorin.sb...@gmail.com on 18 Feb 2014 at 6:15

Attachments:

• JavaMelody__dowa%2d08_2_18_14.pdf

[GoogleCodeExporter]

I still think that the "active jdbc connections" graph is correct.

Given that PDF report, what has happen is probably:
- starting just before 14h00, 18 Feb, cpu is completely saturated (almost 100% 
until 14h30),
- at about 14h30, this high cpu causes active threads and system load average 
to skyrocket in just 1 or 2 minutes (86 active threads and system load of 29 
were recorded), but jdbc connections seem still ok,
- in this situation, your server is now in limbo and can't answer to anyone,
- the jdbc connections may have reached the maximum of 30, but given that all 
users were trying again and again to have a sign of life from the server, 
that's probably just a side effect,
- of course, the server finally crashed or was killed.

So, I think that you can:
- either increase cpu resources,
- or find why cpu was saturated (take thread dumps next time with 
http://host/monitoring?part=threadsDump). And you may start with why getting 
the batch.css from your server is slow (which is probably the root cause and 
which is a known issue in JIRA servers for several reasons).

If I am right, I have saved many thousand dollars from your frustrated users 
and boss.

Original comment by evernat@free.fr on 20 Feb 2014 at 11:17

[GoogleCodeExporter]

As said before, the "active jdbc connections" graph is correct.
So resolving the issue as invalid.

Original comment by evernat@free.fr on 8 Mar 2014 at 10:01

• Changed state: Invalid