cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

understanding why too much Parseinfo instances remain active at JVM heap

Former Member

on ‎04-07-2011 6:47 PM

0 Kudos

Hi,

MaxDB 7.6.06.10 64bit community version. (please dont post notes as I dont have the password to see that)

today another system got stuck threads, the reason was all sessions got Vwait, and some command at Finalizer wants to lock a connection that is Running at java side, but waiting for Vwait at dbserver. I have many posts here, like this, but I decided create another one with maybe more or better information about the problem, as I increased my understanding of JDBC driver classes using Eclipse Memory Analyzer Tool (MAT), then here is the facts:

1) Finalizer BLOCKED in thread dump.:

"Finalizer" daemon prio=10 tid=0x000000005e887000 nid=0x67ce waiting for monitor entry [0x0000000041496000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at com.sap.dbtech.jdbc.StatementSapDB.finalize(StatementSapDB.java:450)
	- waiting to lock <0x00002aaac508ca68> (a com.sap.dbtech.jdbc.ConnectionSapDB)
	at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)

2) in MAT i issued an OQL to check what Connection the finalizer is waiting to lock the Finalizer thread have this Outgoing references:

Class Name                                                                                | Shallow Heap | Retained Heap 
-------------------------------------------------------------------------------------------------------------------------
                                                                                |              |               
java.lang.ref.Finalizer$FinalizerThread @ 0x2aaab98e1448  Finalizer Thread                |          168 |         1,384 
|- name char[9] @ 0x2aaab9bcf750  Finalizer                                               |           40 |            40 
|- <JNI Local> class com.sap.dbtech.jdbc.StatementSapDB @ 0x2aaab43a0428                  |           56 |            56 
|- <class> class java.lang.ref.Finalizer$FinalizerThread @ 0x2aaab19b9058 System Class    |            0 |             0 
|- <Java Local> com.sap.dbtech.jdbc.ConnectionSapDB @ 0x2aaac0933db8 Busy Monitor         |          200 |       138,400 
|- <Java Local> com.sap.dbtech.jdbc.StatementSapDB @ 0x2aaac0bca3f8                       |          112 |           512 
|- blockerLock java.lang.Object @ 0x2aaab9bcf710                                          |           16 |            16 
|- group java.lang.ThreadGroup @ 0x2aaab98e0d50  system                                   |           72 |           280 
|- inheritableThreadLocals java.lang.ThreadLocal$ThreadLocalMap @ 0x2aaaba6cffc0          |           32 |           240 
|- threadLocals java.lang.ThreadLocal$ThreadLocalMap @ 0x2aaabe96f3b0                     |           32 |           296 
|- <Java Local> java.lang.ref.Finalizer @ 0x2aaac0a8da10                                  |           64 |            64 
|- <Java Local> java.lang.ref.Finalizer$FinalizerThread @ 0x2aaab98e1448  Finalizer Thread|          168 |         1,384 
|- inheritedAccessControlContext java.security.AccessControlContext @ 0x2aaab9bcf720      |           48 |            48 
'- Total: 12 entries                                                                      |              |               
-------------------------------------------------------------------------------------------------------------------------

3) then inspect the ConnectionSapDB to see the sessionID atribute that is 803661865, that is related to task 164 that is in Vwait like others:

ID   UKT UNIX   TASK       APPL Current         Timeout Region     Wait 
          tid   type        pid state          priority cnt try    item 
T97    7     -1 User     26568* Vwait                 0 0               10191536(s)
T127   7     -1 User     26568* Vwait                 0 0               10191536(s)
T132   7     -1 User     26568* Vwait                 0 0               10191536(s)
T136   7     -1 User     26568* Vwait                 0 0               10191536(s)
T143   7     -1 User     26568* Vwait                 0 0               10191536(s)
T154   7     -1 User     26568* Vwait                 0 0               10191536(s)
T163   7     -1 User     26568* Vwait                 0 0               10191536(s)
T164   7     -1 User     26568* Vwait                 0 0               10191536(s)
T178   7     -1 User     26568* Vwait                 0 0               10191536(s)
T180   7     -1 User     26568* Vwait                 0 0               10191536(s)

Then here appears we have a deadlock that Finalizer wants to close a Statement but the connection is busy in Vwait in another thread, and perhaps, maybe this Vwait only will go out, if another command will be finalized.

As all times, I think, in some place we dont close all statements or result sets, then I inspected the objects that can reference back the StatementSapDB waiting to be finalize, and here is the incoming stack:

Class Name                                                                                | Shallow Heap | Retained Heap 
-------------------------------------------------------------------------------------------------------------------------------------
                                                                                |              |               
com.sap.dbtech.jdbc.StatementSapDB @ 0x2aaac0bca3f8                                                   |          112 |           512 
|- <Java Local> java.lang.ref.Finalizer$FinalizerThread @ 0x2aaab98e1448  Finalizer Thread            |          168 |         1,384 
|- referent java.lang.ref.Finalizer @ 0x2aaac0a8da10                                                  |           64 |            64 
|- statement com.sap.dbtech.jdbc.ResultSetSapDB @ 0x2aaac0bca468                                      |          120 |           224 
|  '- currentResultSet com.sap.dbtech.jdbc.StatementSapDB @ 0x2aaac0bca3f8                            |          112 |           512 
|     |- <Java Local> java.lang.ref.Finalizer$FinalizerThread @ 0x2aaab98e1448  Finalizer Thread      |          168 |         1,384 
|     |- referent java.lang.ref.Finalizer @ 0x2aaac0a8da10                                            |           64 |            64 
|     |- statement com.sap.dbtech.jdbc.ResultSetSapDB @ 0x2aaac0bca468                                |          120 |           224 
|     |  '- currentResultSet com.sap.dbtech.jdbc.StatementSapDB @ 0x2aaac0bca3f8                      |          112 |           512 
|     |     |- <Java Local> java.lang.ref.Finalizer$FinalizerThread @ 0x2aaab98e1448  Finalizer Thread|          168 |         1,384 
|     |     |- referent java.lang.ref.Finalizer @ 0x2aaac0a8da10                                      |           64 |            64 
|     |     |- statement com.sap.dbtech.jdbc.ResultSetSapDB @ 0x2aaac0bca468                          |          120 |           224 
|     |     '- Total: 3 entries                                                                       |              |               
|     '- Total: 3 entries                                                                             |              |               
'- Total: 3 entries                                                                                |              |               
-------------------------------------------------------------------------------------------------------------------------------------

here we can see that the root reference is a ResultSetSapDB, inspecting this object, we can see that the attribute isClosed is true.

inspecting more objects, I found the Parseinfo object that still opened, with this OQL:

SELECT t.sqlCmd.toString(), dominatorof(t) FROM com.sap.dbtech.jdbc.Parseinfo t WHERE (isClosed=false)

that returns about 24566 entries, then I got some that involves a table that maybe have a table lock that causes all Vwait situation, and get the incoming references:

Class Name                                                                      | Shallow Heap | Retained Heap 
---------------------------------------------------------------------------------------------------------------
com.sap.dbtech.jdbc.Parseinfo @ 0x2aaac0b71a60                                  |          120 |           216 
|- referent java.lang.ref.Finalizer @ 0x2aaac0b0b450                            |           64 |            64 
|- parseinfo com.sap.dbtech.jdbc.CallableStatementSapDB @ 0x2aaac0b71980        |          224 |           352 
|  |- referent java.lang.ref.Finalizer @ 0x2aaac0b0b490                         |           64 |            64 
|  |- _inner com.sap.dbtech.jdbc.trace.PreparedStatement @ 0x2aaac0b71ad8       |           80 |           128 
|  |  |- referent java.lang.ref.Finalizer @ 0x2aaac0b0b410                      |           64 |           192 
|  |  |- referent java.lang.ref.WeakReference @ 0x2aaac1437a08                  |           48 |            48 
|  |  |  '- weakRef com.sap.dbtech.jdbc.trace.PreparedStatement @ 0x2aaac0b71ad8|           80 |           128 
|  |  '- Total: 2 entries                                                       |              |               
|  '- Total: 2 entries                                                          |              |               
'- Total: 2 entries                                                             |              |               
---------------------------------------------------------------------------------------------------------------

Again, all appears to be closed, but still some internal classes must be finalized, that must lock connection for that.

as I checked my code, all statements get closed, with try, finally, following best pratices of JDBC when you had connection pool.

then why that Statement must be finalized? and why that must lock the Connection? and why too much ParseInfo waiting to be finalized?

With this scenario, is right to say, that MaxDB JDBC driver, cant use pool as some objects must finalized after all Statement and ResultSets are closed? Something dependent on connection avoid that to be reused? or what is the right clean code to be done with MaxDB JDBC driver, before you can reuse that connection?

regards

Clóvis

Edited by: Clovis Wichoski on Apr 7, 2011 7:47 PM

Show replies
Show replies
Answer

Accepted Solutions (0)

Answers (1)

Answers (1)

former_member229109
Active Contributor
‎04-13-2011 10:06 PM
0 Kudos

Hello,

from the first check of the reported issue "JDBC driver is blocked in finalizer", the case is looking similar to the symptom of PTS 1158384 < www.sapdb.org/webpts >

What is the JDBC version on your machine?

Post output of the command:

sdbregview -l

Regards, Natalia Khlopina

Show replies
Show replies
Former Member
‎04-14-2011 9:00 PM
0 Kudos

Hi Natalia,

The MaxDB version is 7.6.06.10, the JDBC version that comes with that is:

package com.sap.dbtech.jdbc, MaxDB JDBC Driver, SAP AG, 7.6.05 Build 006-000-008

output of sdbregview is:

/opt/sdb/programs/bin/sdbregview -l
Server Utilities           /opt/sdb/programs    7.6.06.10     64 bit    valid
DB Analyzer                /opt/sdb/programs    7.6.06.10     64 bit    valid
Synchronization Manager    /opt/sdb/programs    7.6.03.07               valid
Redist Python              /opt/sdb/programs    7.6.06.10     64 bit    valid
Base                       /opt/sdb/programs    7.6.06.10     64 bit    valid
JDBC                       /opt/sdb/programs    7.6.05.06               valid
Messages                   /opt/sdb/programs    MSG 0.8215              valid
ODBC                       /opt/sdb/programs    7.6.06.10     64 bit    valid
Database Kernel            /opt/sdb/7603        7.6.06.10     64 bit    valid
Loader                     /opt/sdb/programs    7.6.06.10     64 bit    valid
SQLDBC                     /opt/sdb/programs    7.6.06.10     64 bit    valid

about the PTS, I think that reply many other threads I post here at forum about stucked threads, appears that solution was delivered on version: 7.8.00.08, I will download community versions 7.7.07.16 and 7.8.01.18 to check if that ones contains newer JDBC version, but its safe to use a newer JDBC version with old versions? or I must migrate database too?

best regards

Clóvis

Former Member
‎04-19-2011 8:38 PM
0 Kudos

Hi Natalia,

My server crash again, with stucked threads, then I updated with newer JDBC driver got from DatabaseStudio, that is:

package com.sap.dbtech.jdbc, MaxDB JDBC Driver, SAP AG, 7.6.06 Build 007-000-009-441 (Make-Version: 7.8.01 Build 018-121-240-252)

with this version, the ParseInfo ammount reduced to 466 entries, but I still think that this are too much Parseinfo objects, as we can see many Parseinfo that isClosed equals false, but we cant find any ResultSet or Statement openned and using this Parseinfo, follow a sample of Parseinfo with incoming references:

Class Name                                                                                | Shallow Heap | Retained Heap 
--------------------------------------------------------------------------------------------------------------------------
                                                                                |              |               
com.sap.dbtech.jdbc.Parseinfo @ 0x2aaacd9d2ce0                                             |          120 |         4,280 
|- parseinfo com.sap.dbtech.jdbc.CallableStatementSapDBFinalize @ 0x2aaacd9d2b98           |          232 |           416 
|  |- _inner com.sap.dbtech.jdbc.trace.PreparedStatement @ 0x2aaacd9d2b48                  |           80 |            80 
|  |  |- referent java.lang.ref.WeakReference @ 0x2aaacd9d2b18                             |           48 |            48 
|  |  |- _stmt org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement @ 0x2aaacda2bc70    |           72 |           216 
|  |  |  |- _stmt org.apache.tomcat.dbcp.dbcp.DelegatingPreparedStatement @ 0x2aaacda2bb98 |           72 |           216 
|  |  |  |- [7] java.lang.Object[16] @ 0x2aaacdb3bf58                                      |          152 |           152 
|  |  |  |  '- elementData java.util.ArrayList @ 0x2aaacd5d1ec0                            |           40 |           192 
|  |  |  |     '- traceList org.apache.tomcat.dbcp.dbcp.PoolableConnection @ 0x2aaacd5d1e78|           72 |           264 
|  |  |  '- Total: 2 entries                                                               |              |               
|  |  |- referent java.lang.ref.Finalizer @ 0x2aaacdb48288                                 |           64 |       278,784 
|  |  '- Total: 3 entries                                                                  |              |               
|  |- referent java.lang.ref.Finalizer @ 0x2aaacdb48208                                    |           64 |       278,656 
|  '- Total: 2 entries                                                                     |              |               
|- referent java.lang.ref.Finalizer @ 0x2aaacdb48248                                       |           64 |       278,720 
'- Total: 2 entries                                                                        |              |               
--------------------------------------------------------------------------------------------------------------------------

You know if exists a newer version of JDBC driver that this one I'm using?

best regards

Clóvis

Ask a Question