Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 931 invoked from network); 13 Jun 2009 08:42:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 13 Jun 2009 08:42:02 -0000 Received: (qmail 81112 invoked by uid 500); 13 Jun 2009 08:42:13 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 81032 invoked by uid 500); 13 Jun 2009 08:42:12 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 81024 invoked by uid 99); 13 Jun 2009 08:42:12 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Jun 2009 08:42:12 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: unknown (nike.apache.org: error in processing during lookup of nospam@kaigrabfelder.de) Received: from [85.25.124.179] (HELO mail.special-host.de) (85.25.124.179) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Jun 2009 08:42:00 +0000 Received: from localhost (localhost [127.0.0.1]) by mail.special-host.de (Postfix) with ESMTP id EA1B66A08D for ; Sat, 13 Jun 2009 08:41:39 +0000 (UTC) X-Virus-Scanned: LINUX amavisd-new at special-host.de X-Spam-Score: -4.198 X-Spam-Level: Received: from mail.special-host.de ([127.0.0.1]) by localhost (mail.special-host.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVvi5lZX-pcg for ; Sat, 13 Jun 2009 08:41:28 +0000 (UTC) Received: from [192.168.2.103] (p3EE04C55.dip.t-dialin.net [62.224.76.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nospam@kaigrabfelder.de) by mail.special-host.de (Postfix) with ESMTP id 38B6E6A087 for ; Sat, 13 Jun 2009 08:41:26 +0000 (UTC) Message-ID: <4A33663A.9050600@kaigrabfelder.de> Date: Sat, 13 Jun 2009 10:41:30 +0200 From: Kai Grabfelder Reply-To: nospam@kaigrabfelder.de User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: user-java@ibatis.apache.org Subject: Re: Memeory leak in com.iBatis.sqlmap.engine.impl.SqlMapClientImpl class References: <14105662.post@talk.nabble.com> <14146385.post@talk.nabble.com> <14164086.post@talk.nabble.com> <14175337.post@talk.nabble.com> <23996768.post@talk.nabble.com> In-Reply-To: <23996768.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Status: No, score=-4.198 tagged_above=-9999.9 required=7 tests=[ALL_TRUSTED=-1.8, AWL=0.201, BAYES_00=-2.599] So are you already using a singleton pattern for the sqlmap client? Or do you have nothing in common with the setup described in the cited text below? Best Regards Kai --- Original Nachricht --- Absender: ankurgur Datum: 12.06.2009 12:58 > Hi there, > > I am in dire need of help regarding Memory leak problem i am facing in my > application. > After analysis it seems there is some problem with the way we are using > iBATIS in our application. > Actually we are uploading huge amount of data (around 50k) into DB through > our application using transaction management and batch insertion and > updation facility provided by iBATIS. > > Our deployment environment has the max JVM heap as 458Mb available for use. > After our application reaches to say around 30k records the performance > starts degrading with heap utilization getting to a very high limit. > Sometimes it starts throwing OutOfMemoryException and the system goes down. > > The heap analyzing team came up with this Comment > > "Looks like, the memory leak is coming from iBatis objects being stored > inside the > com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread." > > Can anybody please help in what general precautions we can take to avoid > this situation created by our iBATIS implementation. > > pooven wrote: >> >> Jeff, >> >> Thanks for your reply. Really what you have replied is very helpful. >> >> Here with I have attached my code as well as the some screeen shots of the >> heap analyser. >> >> In our code each action class we called the >> >> Reader reader = Resources.getResourceAsReader("abatorConfig.xml"); >> sqlMapper = SqlMapClientBuilder.buildSqlMapClient(reader); >> >> This is blender mistake I believe. >> >> Kindly correct me the following set of code to call the above set of code >> with use of singleton pattern. >> >> In all the 183 action classes the code is same , now only I realized the >> problem. For simultaneous access of reports from different users is it >> correct to have the following code to call the >> SqlMapClientBuilder.buildSqlMapClient(reader); each time >> >> >> public class SqlMapClientBuilderSingleton{ >> private static final SqlMapClient sqlMap; >> static { >> try { >> Reader reader = >> Resources.getResourceAsReader("abatorConfig.xml"); >> sqlMap = >> SqlMapClientBuilder.buildSqlMapClient(reader); >> } catch (Exception e) { >> e.printStackTrace(); >> throw new RuntimeException ("SqlMap initialisation >> Error: " + e); >> } >> } >> public static SqlMapClient getSqlMapInstance () { >> return sqlMap; >> } >> >> } >> >> SqlMapClientBuilderSingleton >> >> Then when I need it in the code I can use this way >> >> SqlMapClient >> sqlMapper=SqlMapClientBuilderSingleton.getSqlMapInstance (); >> >> >> >> Is the above said way is right ? if you have any correction in the above >> code pls let me know , we are not using the spring FrameWork hence pls >> advise me he best way to call the SqlMapClient each time in the action. >> do we need to call the sqlMapper.flushDataCache() wherever is necessary >> for flushing the dataCache , where would be the closing all would be done. >> >> I am not able to find any easy examples of how to go about with the >> iBatis. >> >> >> Thanks for your efforts and time. >> >> Thanks once again >> >> Poovendran >> >> >> >> Jeff Butler-2 wrote: >>> >>> I just took a closer look at this. What you are showing is the object >>> tree >>> related to the SqlMapClient - which is very large in your case. That >>> probably means you have a lot of mapped statements (perhaps 8208 of >>> them). >>> That should be ok - because this object tree should only occur one time >>> and >>> should not change once it is built. >>> >>> Are you seeing that this tree is built and destroyed over and over again? >>> Or are there multiple instances of this tree? This is a common misuse of >>> iBATIS. You should build the SqlMapClient one and only one time. You >>> should keep it for the life of the application somewhere (like a >>> singleton, >>> or let Spring build it and hold onto it). >>> >>> Jeff Butler >>> >>> >>> >>> On Dec 4, 2007 8:55 PM, Jeff Butler wrote: >>> >>>> Interesting. The char[] are inside Strings, which are inside HashMaps, >>>> which appear to be inside the parameters you are passing to iBATIS. It >>>> appears that you have some large HashMaps being passed into iBATIS. I >>>> submit that this is not an iBATIS problem but a problem in the way you >>>> are >>>> USING iBATIS. >>>> >>>> Make sure that you are not holding onto these large HashMaps you are >>>> using >>>> as parameters - it would be very interesting to see higher in the >>>> HeapAnalyser than what you've shown - where in your code are these >>>> HashMaps >>>> being created? >>>> >>>> Jeff Butler >>>> >>>> >>>> >>>> On Dec 4, 2007 8:38 PM, pooven wrote: >>>> >>>> > >>>> > Hi, >>>> > >>>> > Here with I am attaching the screen shot of the Heapdump analyser >>>> which >>>> > shows clearly the break up where in which package of the iBatis class >>>> > causing the memory leak. >>>> > >>>> > Kindly if any one knows how to get rid of this issue , greatly >>>> > appreciated. >>>> > Thanks and regds, >>>> > Poovendran >>>> > >>>> > >>>> > >>>> > >>>> > pns77 wrote: >>>> > > >>>> > > I am also facing a similar issue with ibatis - we arrived at the >>>> > > conclusion after an analysis of heap dump. The following was the >>>> > response >>>> > > that we got for a ticket we had raised with IBM. >>>> > > >>>> > > " ..Maximum heap was set to 1024m and almost 1000mb of heap is in >>>> use. >>>> > > Anlaysis of the heapdump shows the com/ibatis/sqlmap/engine/* code >>>> > > occupying most of heap(Nearly 900mb). .." >>>> > > >>>> > > There seems to be too many char[] (character array) objects that get >>>> > > created from com.iBatis.sqlmap.engine.impl.SqlMapClientImpl class. >>>> In >>>> > our >>>> > > application side we had explcitly set the "daoManager" object >>>> > reference to >>>> > > null so that it could be GC'ed. Still, we dont see any improvement. >>>> > > >>>> > > Would apprecitate if some one could suggest a solution. >>>> > > >>>> > > We use WebSphere 6 on AIX / ibatis accessing DB2 database. >>>> > > >>>> > > Thanks, >>>> > > P.N.Subramanian >>>> > > >>>> > > >>>> > > pooven wrote: >>>> > >> >>>> > >> We are using a iBatis 2.3.677 along with CrystalReport >>>> 11.8,Websphere >>>> > >> AppServer 6.0.23 and DB2 8.2 and Websphere Portal Server 5.1.0.4, >>>> in >>>> > our >>>> > >> struts based portlet application. >>>> > >> >>>> > >> There are 183 reports we are using. >>>> > >> >>>> > >> We are facing the outOfMemory issue. After analysing the heapDump >>>> > file >>>> > >> through the IBM HeapAnalyser we came to know that there is a memory >>>> > >> leakage around 8 MB in the >>>> > >> >>>> > >> com.iBatis.sqlmap.engine.impl.SqlMapClientImpl class, >>>> > >> >>>> > >> I called flushDataCache from the sqlMapper , still it is of no use. >>>> > >> >>>> > >> Can any one guide me in this regard. >>>> > >> >>>> > >> >>>> > >> Thanks, >>>> > >> P.Poovendran >>>> > >> >>>> > > >>>> > > >>>> > http://www.nabble.com/file/p14164086/iBatis%2BMemory%2BLeak.bmp >>>> > iBatis+Memory+Leak.bmp >>>> > -- >>>> > View this message in context: >>>> > >>>> http://www.nabble.com/Memeory-leak-in-com.iBatis.sqlmap.engine.impl.SqlMapClientImpl-class-tf4928332.html#a14164086 >>>> > Sent from the iBATIS - User - Java mailing list archive at >>>> Nabble.com >>>> > . >>>> > >>>> > >>>> >>> >>> >> http://www.nabble.com/file/p14175337/MemoryLeak.zip MemoryLeak.zip >> >