0

Goodday everyone.

Faced strange OOM after switching from reading varchar field to clob from Oracle database in java application.

(We are using oracle.jdbc.driver with bonecp connection pool + spring jdbctemplate)

Heapdump shows(see picture)

temporaryLobs in heapdump

that memory stays in temporaryLobs fields inside a com.jolbox.bonecp.ConnectionPartition->freeConnections

More precisely data contained in temporaryLobs.elementData array which constantly grows (according to jvm metrics with memory used and manual heapdumps).

elementData looks like enter image description here

At moment of OOM, there was approximately 50Mb for each connection in pool (30+ actual connections), with populated temporaryLobs so we got 1Gb+ data only for connection pool.

It seems like some kind of clob "cache"?.

I will try to struggle through library code on debug with breakpoins and find what is going on, but mb there can be some kind of well known configuration for such scenario or some kind of ratio between some properties and datatypes and those temp lobs.

Thanks in advance.

recvfrom_ro
  • 87
  • 2
  • 5

1 Answers1

1

We had a slightly different problem but also OOMs due to a high amount of clobs. We solved the problem by freeing the clobs manually with clob.free() We expected them to be closed/freed after closing the resultset. So we stored the them in a list up to the part where the resulset got closed and checked the free variable of the clobs. It was still false. Our solution is to iterate throuh the list of clobs and calling .free() on each of them after closing the resultset.

Maybe it will also solve your problem.

user18911996
  • 11
  • 1