Memory leaks best practices

2014-02-06 Thread Maxim Solodovnik
Hello All,

Recently we have deployed our project to wicket project to production
server.
And start getting OutOfMemory PermGenSpace.

I believe we have memory leak in our application
maybe there is best practices how to deal with Models and JPA entities to
resolve this?

Thanks in advance

-- 
WBR
Maxim aka solomax


RE: Memory leaks best practices

2014-02-06 Thread Richter, Marvin
If you have Models or Components as fields in you classes you should override 
the classes method onDetach.

Example:

Public class MyPanel extends Panel  {

private final IModelObject objectModel;

public MyPanel(String id, IModelObject objectModel) {
super(id,objectModel);
this.objectModel = objectModel;
}

@Override
protected void onDetach() {
super.onDetach();
objectModel.detach();
 }
}

Marvin Richter


-Original Message-
From: Maxim Solodovnik [mailto:solomax...@gmail.com] 
Sent: Thursday, February 06, 2014 1:09 PM
To: users@wicket.apache.org
Subject: Memory leaks best practices

Hello All,

Recently we have deployed our project to wicket project to production server.
And start getting OutOfMemory PermGenSpace.

I believe we have memory leak in our application maybe there is best practices 
how to deal with Models and JPA entities to resolve this?

Thanks in advance

--
WBR
Maxim aka solomax


Re: Memory leaks best practices

2014-02-06 Thread Sven Meier

Probably a class-loading issue:

http://stackoverflow.com/questions/88235/dealing-with-java-lang-outofmemoryerror-permgen-space-error

Sven

On 02/06/2014 01:07 PM, Maxim Solodovnik wrote:

Hello All,

Recently we have deployed our project to wicket project to production
server.
And start getting OutOfMemory PermGenSpace.

I believe we have memory leak in our application
maybe there is best practices how to deal with Models and JPA entities to
resolve this?

Thanks in advance




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: Memory leaks best practices

2014-02-06 Thread Martin Grigorov
Hi,

OOM in PermGen is not what you ask for.
If you leak normal memory than the error would be with heap space.
PermGen memory is used to keep the Class instances and interned Strings.
If you deploy your app for first time then most probably you just need to
set the proper initial and max value :
-XX:PermSize and -XX:MaxPermSize.
Use JConsole to see what size you need.

If this error happens on redeploy then most probably you have a ClassLoader
memory leak, i.e. you keep references to Class instances and they cannot be
released so the PermGen is overloaded. Those are very tricky to be debugged.


Martin Grigorov
Wicket Training and Consulting


On Thu, Feb 6, 2014 at 1:07 PM, Maxim Solodovnik solomax...@gmail.comwrote:

 Hello All,

 Recently we have deployed our project to wicket project to production
 server.
 And start getting OutOfMemory PermGenSpace.

 I believe we have memory leak in our application
 maybe there is best practices how to deal with Models and JPA entities to
 resolve this?

 Thanks in advance

 --
 WBR
 Maxim aka solomax



Re: Memory leaks best practices

2014-02-06 Thread Maxim Solodovnik
Thanks a lot for quick answers have already added -Xms512M -Xmx2G -Xss1M
-XX:PermSize=192m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled

Now will add *Model.detach(); to the code and will check the stability
(currently application works ~2days before PermGen)

Redeployment is performed using Tomcat 7.0.50 restart.

Any other ideas are appreciated


On Thu, Feb 6, 2014 at 7:28 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 OOM in PermGen is not what you ask for.
 If you leak normal memory than the error would be with heap space.
 PermGen memory is used to keep the Class instances and interned Strings.
 If you deploy your app for first time then most probably you just need to
 set the proper initial and max value :
 -XX:PermSize and -XX:MaxPermSize.
 Use JConsole to see what size you need.

 If this error happens on redeploy then most probably you have a ClassLoader
 memory leak, i.e. you keep references to Class instances and they cannot be
 released so the PermGen is overloaded. Those are very tricky to be
 debugged.


 Martin Grigorov
 Wicket Training and Consulting


 On Thu, Feb 6, 2014 at 1:07 PM, Maxim Solodovnik solomax...@gmail.com
 wrote:

  Hello All,
 
  Recently we have deployed our project to wicket project to production
  server.
  And start getting OutOfMemory PermGenSpace.
 
  I believe we have memory leak in our application
  maybe there is best practices how to deal with Models and JPA entities to
  resolve this?
 
  Thanks in advance
 
  --
  WBR
  Maxim aka solomax
 




-- 
WBR
Maxim aka solomax


Re: Memory leaks best practices

2014-02-06 Thread Shengche Hsiao
I had the same issue, my problem was doesn't close the database connection!


On Thu, Feb 6, 2014 at 8:54 PM, Maxim Solodovnik solomax...@gmail.comwrote:

 Thanks a lot for quick answers have already added -Xms512M -Xmx2G -Xss1M
 -XX:PermSize=192m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled

 Now will add *Model.detach(); to the code and will check the stability
 (currently application works ~2days before PermGen)

 Redeployment is performed using Tomcat 7.0.50 restart.

 Any other ideas are appreciated


 On Thu, Feb 6, 2014 at 7:28 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi,
 
  OOM in PermGen is not what you ask for.
  If you leak normal memory than the error would be with heap space.
  PermGen memory is used to keep the Class instances and interned Strings.
  If you deploy your app for first time then most probably you just need to
  set the proper initial and max value :
  -XX:PermSize and -XX:MaxPermSize.
  Use JConsole to see what size you need.
 
  If this error happens on redeploy then most probably you have a
 ClassLoader
  memory leak, i.e. you keep references to Class instances and they cannot
 be
  released so the PermGen is overloaded. Those are very tricky to be
  debugged.
 
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Thu, Feb 6, 2014 at 1:07 PM, Maxim Solodovnik solomax...@gmail.com
  wrote:
 
   Hello All,
  
   Recently we have deployed our project to wicket project to production
   server.
   And start getting OutOfMemory PermGenSpace.
  
   I believe we have memory leak in our application
   maybe there is best practices how to deal with Models and JPA entities
 to
   resolve this?
  
   Thanks in advance
  
   --
   WBR
   Maxim aka solomax
  
 



 --
 WBR
 Maxim aka solomax




-- 

---
We do this not because it is easy. We do this because it is hard.
---
ShengChe Hsiao
---
front...@gmail.com
front...@tc.edu.tw
---
VoIP : 070-910-2450
---


Re: Memory leaks best practices

2014-02-06 Thread Maxim Solodovnik
In my case OpenJPA handle DB connection open/close/pooling, so I hope this
is not the case.

Maybe you can suggest server side memory profiler for Ubuntu server?


On Thu, Feb 6, 2014 at 9:12 PM, Shengche Hsiao shengchehs...@gmail.comwrote:

 I had the same issue, my problem was doesn't close the database connection!


 On Thu, Feb 6, 2014 at 8:54 PM, Maxim Solodovnik solomax...@gmail.com
 wrote:

  Thanks a lot for quick answers have already added -Xms512M -Xmx2G -Xss1M
  -XX:PermSize=192m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
 
  Now will add *Model.detach(); to the code and will check the stability
  (currently application works ~2days before PermGen)
 
  Redeployment is performed using Tomcat 7.0.50 restart.
 
  Any other ideas are appreciated
 
 
  On Thu, Feb 6, 2014 at 7:28 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Hi,
  
   OOM in PermGen is not what you ask for.
   If you leak normal memory than the error would be with heap space.
   PermGen memory is used to keep the Class instances and interned
 Strings.
   If you deploy your app for first time then most probably you just need
 to
   set the proper initial and max value :
   -XX:PermSize and -XX:MaxPermSize.
   Use JConsole to see what size you need.
  
   If this error happens on redeploy then most probably you have a
  ClassLoader
   memory leak, i.e. you keep references to Class instances and they
 cannot
  be
   released so the PermGen is overloaded. Those are very tricky to be
   debugged.
  
  
   Martin Grigorov
   Wicket Training and Consulting
  
  
   On Thu, Feb 6, 2014 at 1:07 PM, Maxim Solodovnik solomax...@gmail.com
   wrote:
  
Hello All,
   
Recently we have deployed our project to wicket project to production
server.
And start getting OutOfMemory PermGenSpace.
   
I believe we have memory leak in our application
maybe there is best practices how to deal with Models and JPA
 entities
  to
resolve this?
   
Thanks in advance
   
--
WBR
Maxim aka solomax
   
  
 
 
 
  --
  WBR
  Maxim aka solomax
 



 --

 ---
 We do this not because it is easy. We do this because it is hard.
 ---
 ShengChe Hsiao
 ---
 front...@gmail.com
 front...@tc.edu.tw
 ---
 VoIP : 070-910-2450
 ---




-- 
WBR
Maxim aka solomax


Re: Memory leaks best practices

2014-02-06 Thread Martin Grigorov
The best memory profiler is Eclipse MAT - https://www.eclipse.org/mat/
But again it helps only with debugging problems in the heap, not in the
perm gen

Martin Grigorov
Wicket Training and Consulting


On Thu, Feb 6, 2014 at 3:18 PM, Maxim Solodovnik solomax...@gmail.comwrote:

 In my case OpenJPA handle DB connection open/close/pooling, so I hope this
 is not the case.

 Maybe you can suggest server side memory profiler for Ubuntu server?


 On Thu, Feb 6, 2014 at 9:12 PM, Shengche Hsiao shengchehs...@gmail.com
 wrote:

  I had the same issue, my problem was doesn't close the database
 connection!
 
 
  On Thu, Feb 6, 2014 at 8:54 PM, Maxim Solodovnik solomax...@gmail.com
  wrote:
 
   Thanks a lot for quick answers have already added -Xms512M -Xmx2G
 -Xss1M
   -XX:PermSize=192m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
  
   Now will add *Model.detach(); to the code and will check the stability
   (currently application works ~2days before PermGen)
  
   Redeployment is performed using Tomcat 7.0.50 restart.
  
   Any other ideas are appreciated
  
  
   On Thu, Feb 6, 2014 at 7:28 PM, Martin Grigorov mgrigo...@apache.org
   wrote:
  
Hi,
   
OOM in PermGen is not what you ask for.
If you leak normal memory than the error would be with heap
 space.
PermGen memory is used to keep the Class instances and interned
  Strings.
If you deploy your app for first time then most probably you just
 need
  to
set the proper initial and max value :
-XX:PermSize and -XX:MaxPermSize.
Use JConsole to see what size you need.
   
If this error happens on redeploy then most probably you have a
   ClassLoader
memory leak, i.e. you keep references to Class instances and they
  cannot
   be
released so the PermGen is overloaded. Those are very tricky to be
debugged.
   
   
Martin Grigorov
Wicket Training and Consulting
   
   
On Thu, Feb 6, 2014 at 1:07 PM, Maxim Solodovnik 
 solomax...@gmail.com
wrote:
   
 Hello All,

 Recently we have deployed our project to wicket project to
 production
 server.
 And start getting OutOfMemory PermGenSpace.

 I believe we have memory leak in our application
 maybe there is best practices how to deal with Models and JPA
  entities
   to
 resolve this?

 Thanks in advance

 --
 WBR
 Maxim aka solomax

   
  
  
  
   --
   WBR
   Maxim aka solomax
  
 
 
 
  --
 
  ---
  We do this not because it is easy. We do this because it is hard.
  ---
  ShengChe Hsiao
  ---
  front...@gmail.com
  front...@tc.edu.tw
  ---
  VoIP : 070-910-2450
  ---
 



 --
 WBR
 Maxim aka solomax



Re: Memory leaks best practices

2014-02-06 Thread francois meillet
http://www.yourkit.com/docs/kb/class_loaders.jsp

François


On Thu, Feb 6, 2014 at 3:22 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 The best memory profiler is Eclipse MAT - https://www.eclipse.org/mat/
 But again it helps only with debugging problems in the heap, not in the
 perm gen

 Martin Grigorov
 Wicket Training and Consulting


 On Thu, Feb 6, 2014 at 3:18 PM, Maxim Solodovnik solomax...@gmail.com
 wrote:

  In my case OpenJPA handle DB connection open/close/pooling, so I hope
 this
  is not the case.
 
  Maybe you can suggest server side memory profiler for Ubuntu server?
 
 
  On Thu, Feb 6, 2014 at 9:12 PM, Shengche Hsiao shengchehs...@gmail.com
  wrote:
 
   I had the same issue, my problem was doesn't close the database
  connection!
  
  
   On Thu, Feb 6, 2014 at 8:54 PM, Maxim Solodovnik solomax...@gmail.com
   wrote:
  
Thanks a lot for quick answers have already added -Xms512M -Xmx2G
  -Xss1M
-XX:PermSize=192m -XX:MaxPermSize=512m -XX:+CMSClassUnloadingEnabled
   
Now will add *Model.detach(); to the code and will check the
 stability
(currently application works ~2days before PermGen)
   
Redeployment is performed using Tomcat 7.0.50 restart.
   
Any other ideas are appreciated
   
   
On Thu, Feb 6, 2014 at 7:28 PM, Martin Grigorov 
 mgrigo...@apache.org
wrote:
   
 Hi,

 OOM in PermGen is not what you ask for.
 If you leak normal memory than the error would be with heap
  space.
 PermGen memory is used to keep the Class instances and interned
   Strings.
 If you deploy your app for first time then most probably you just
  need
   to
 set the proper initial and max value :
 -XX:PermSize and -XX:MaxPermSize.
 Use JConsole to see what size you need.

 If this error happens on redeploy then most probably you have a
ClassLoader
 memory leak, i.e. you keep references to Class instances and they
   cannot
be
 released so the PermGen is overloaded. Those are very tricky to be
 debugged.


 Martin Grigorov
 Wicket Training and Consulting


 On Thu, Feb 6, 2014 at 1:07 PM, Maxim Solodovnik 
  solomax...@gmail.com
 wrote:

  Hello All,
 
  Recently we have deployed our project to wicket project to
  production
  server.
  And start getting OutOfMemory PermGenSpace.
 
  I believe we have memory leak in our application
  maybe there is best practices how to deal with Models and JPA
   entities
to
  resolve this?
 
  Thanks in advance
 
  --
  WBR
  Maxim aka solomax
 

   
   
   
--
WBR
Maxim aka solomax
   
  
  
  
   --
  
  
 ---
   We do this not because it is easy. We do this because it is hard.
  
 ---
   ShengChe Hsiao
  
 ---
   front...@gmail.com
   front...@tc.edu.tw
  
 ---
   VoIP : 070-910-2450
  
 ---
  
 
 
 
  --
  WBR
  Maxim aka solomax