David,

        I ran into a memory leak with the Minerva JDBC pools a while ago and
posted the same question. I found that the XADataSourceImpl, which is older
code, does not seems to have the same memory leak. I posted my findings here
about a month ago, I will just attach them here again. I hope that they help
you out:


-----------Original Letter-----------------
DATE: Wed 2/20/2002 11:39 AM

I have spent the past week looking into this memory leak and have found a
work around. I thought I would post it here, since no one seemed to have any
clues for me, I thought that there might be some other people out there
hoping for an answer.

BACKGROUND:
See the attached letter for my problem with the Minerva pools. In short,
they seem to suffer from a memory leak.


WORK AROUND:
First, I tried to use the -Xincgc with the JVM. The JVM would start larger
(~70MB as opposed to the ~62-63MB w/o -Xincgc), but would recovery a lot of
memory (drop to about 62MB) rather quickly. After about 1hr of operation,
the JVM would start losing memory again, at a slightly slower rate than w/o
incremental garbage collection.

Either way, my application would not live the night w/o a restart. So I
updated from JBoss-2.4.1 and Tomcat-3.2.3 to JBoss-2.4.4 Tomcat-4.0.1. I
found no difference between the two in loss rate. 

Finally, I rolled back from Minerva pools to the older
org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl objects. I asked about these
a couple months ago and everyone told me that these are being phased out,
and that I should migrate to the minerva pools. It looks like these are
indeed not available as part of Jboss3.0. But I tried them anyway with the
following in my jboss.jcml.

  <mbean code="org.jboss.jdbc.XADataSourceLoader"
name="DefaultDomain:service=XADataSource,name=minerva_jdbc_matrix">
    <attribute name="PoolName">minerva_jdbc_matrix</attribute>
    <attribute
name="DataSourceClass">org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl</attr
ibute>
    <attribute name="Properties"></attribute>
    <attribute
name="URL">jdbc:HypersonicSQL:hsql://localhost:9019</attribute>
    <attribute name="GCMinIdleTime">1200000</attribute>
    <attribute name="JDBCUser">sa</attribute>
    <attribute name="MaxSize">200</attribute>
    <attribute name="Password" />
    <attribute name="GCEnabled">false</attribute>
    <attribute name="InvalidateOnError">false</attribute>
    <attribute name="TimestampUsed">false</attribute>
    <attribute name="Blocking">true</attribute>
    <attribute name="GCInterval">120000</attribute>
    <attribute name="IdleTimeout">1800000</attribute>
    <attribute name="IdleTimeoutEnabled">false</attribute>
    <attribute name="LoggingEnabled">true</attribute>
    <attribute name="MaxIdleTimeoutPercent">1.0</attribute>
    <attribute name="MinSize">0</attribute>
  </mbean>

And my application has been running for two days now at a stable 65MB of
memory.

CONCLUSION:
My experience with the Minerva pools is that have a memory leak that make
them unsuitable for production systems that the
org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl does not suffer from. I
would like to use Minerva pools when they have them production ready,
because they seem to offer a JCA standardized approach that would be nice to
work with. Further more, if Jboss3.0 does not offer the
org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl, and the memory leak in the
Miverva pools is not addressed; then Jboss3.0 will not be suitable for my
production systems.


        Lucas McGregor, NovaLogic


-----Original Message-----
From: Lucas McGregor [mailto:[EMAIL PROTECTED]]
Sent: Friday, February 15, 2002 10:51 AM
To: [EMAIL PROTECTED]
Subject: [JBoss-user] Memory leak in Minerva DB Pool


        I have noticed a memory leak in my JBoss Minerva pool and am
wondering if there is a known fix or work around. I have checked the manual,
the forum, and the newsgroups with little luck. Let me give you the
specifics:

        I am running on Solaris8 on x86, JBoss-2.4.1 and Tomcat-3.2.3. I
have a pool with the following configuration in my jboss.jcml


  <mbean code="org.jboss.resource.ConnectionFactoryLoader"
 
name="JCA:service=ConnectionFactoryLoader,name=minerva_jdbc_matrix">
    <attribute name="FactoryName">minerva_jdbc_matrix</attribute>
    <attribute name="RARDeployerName">JCA:service=RARDeployer</attribute>
    <attribute name="ResourceAdapterName">
      Minerva JDBC LocalTransaction ResourceAdapter
    </attribute>
    <attribute name="Properties">
      ConnectionURL=jdbc:HypersonicSQL:hsql://localhost:9019
    </attribute>

    <attribute name="ConnectionManagerFactoryName">
      MinervaSharedLocalCMFactory
    </attribute>

    <attribute name="ConnectionManagerProperties">
      # Pool type - uncomment to force, otherwise it is the default
      #PoolConfiguration=per-factory

      # Connection pooling properties - see
      # org.jboss.pool.PoolParameters
      MinSize=0
      MaxSize=50
      Blocking=true
      GCEnabled=true
      IdleTimeoutEnabled=true
      InvalidateOnError=true
      TrackLastUsed=false
      GCIntervalMillis=120000
      GCMinIdleMillis=120000
      IdleTimeoutMillis=120000
      MaxIdleTimeoutPercent=1.0
    </attribute>


    <attribute name="PrincipalMappingClass">
      org.jboss.resource.security.ManyToOnePrincipalMapping
    </attribute>
    <attribute name="PrincipalMappingProperties">
      userName=sa
      password=
      TransactionIsolation=TRANSACTION_READ_COMMITED
    </attribute>
  </mbean>

        I have a stateless session bean which contains the code snippet:

        try {
            InitialContext ic = new InitialContext();
            DataSource ds = (DataSource)
ic.lookup("java:/minerva_jdbc_matrix");
            Connection con = ds.getConnection();
            con.close();
        } catch (Exception e) {
        }

        I didn't include the con.close() in a finally, since the only way a
connection could be opened is by ds.getConnection() working, which means
that it would always get to con.close() if a connection had opened.

        I hit this bean with a client that runs 250 concurrent request. I
notice that in about 5-8 hrs, the memory of the Java process crawls from
about 70M to 120M at which point it will starts to throw OutOfMemory errors
and I can never get a connection the database again. If I turn off the
client, and let the box's CPU get down to about 99% idle, the memory never
clears up. I am forced to restart my server.

        I have tried this with two different databases and jdbc drivers
(hsql and ms sql) and have gotten similar results, so I don't think it is a
bug in the drivers. 

        Am I using the pools incorrectly? Is that a pool configuration
parameter that I should try?

        Thanks in advance for any help or clues,
        Lucas McGregor, NovaLogic
        

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



-----Original Message-----
From: David Cao [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 06, 2002 12:20 PM
To: Jboss Mailing List
Cc: David Cao; Stephen Gesin
Subject: [JBoss-user] Memory Leak on Lunix!!!


We am running JBoss2.4.4 Tomcat 3.2.3 on Linux 7.2 in production, I
realized there is a memory leak as well, The memory usage seems increase
pretty fast, out of memory for less than one week, also encounter out of
memory exception if webserver is running for some time when update jsp.
we didn't count this problem in our internal website which is using
Windows 2000. 

Is this a issue with jdbc pool, or jvm on Linux or jboss related ? or
just some coding is not correct? Any suggestion are welcome.

Thanks
David



-----Original Message-----
From: John LYC [mailto:[EMAIL PROTECTED]]
Sent: Monday, November 26, 2001 7:43 PM
To: Jboss Mailing List
Subject: [JBoss-user] Memory Leak!!!


HI ,
i'm running JBoss-2.4.3_Tomcat-3.2.3 on redhat linux 7.1.
Jdk1.3.1_01 with j2sdkee1.2.1.

I realized there seem to be a memory leak.
i have not been able to pinpoint exactly where the leak is coming from
at
this point of time and am still investigating...

currently, my application uses Jakarta Struts as well.
the memory usage will slowly increment thru the weeks.....
at one point of time, the memory used by jboss was at 100MB!

the java garbage collector seem to be working..
the memory did get restored back whenever the collector is working...

at one point, after many weeks of not restarting Jboss, halfway thru a
deployment, i encounter a out of memory exception.

another colleague of mine has a diff and very simple application that
basically read data  from text file and update the database. his apps is
running on another server altogether and he is having the same issue
too. so
much so that the infra-structure guys are complaining abt the memory
usage.


i also do not know if it is the way the applications is being coded?
but the 2 apps and the developers involved do not work with each other
at
all.

anyway, i will continue my investigation and find out more.

In the meantime, has anyone encounter similar problem?
or know of anything?

thanks
John


_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user

Reply via email to