Re: OutOfMemoryException Processing Velocity Template

2006-02-08 Thread Malcolm Edgar
Yes my experience with the singleton memory leak was with Tomcat,
when it was auto reloading the application when class files changed.

regards Malcolm Edgar

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: OutOfMemoryException Processing Velocity Template

2006-02-07 Thread e v a n

Hmm. I wasn't aware of the leak issue, I'll make a note of that.

As for other work arounds, I have one that will work just fine for my
situation. But I'm still curious about the specialized tiles tool for the
purpose of streaming output to the browser, instead of buffering the whole
page in a string before sending it as the tiles tool does.  But that's
another question, and probably for the tiles developers.  

Thank you for your help.

-Evan
 

-Original Message-
From: Malcolm Edgar [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 06, 2006 8:35 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

If your are reloading your application a lot, i.e. doing development work,
the singleton pattern causes a memory leak. This could be expressed in OOME
when rendering templates.

regards Malcolm Edgar

On 2/7/06, Nathan Bubna [EMAIL PROTECTED] wrote:
 i'm not sure.  Edgar?

 as for your question about a specialized TilesTool...  i'm not aware 
 of this having been done.  if it has, it wasn't shared with the list.

 have you taken the other advice in the thread and profiled your 
 application?  if you aren't up for writing a specialized TilesTool, 
 then there may be other ways you can cut down on your memory use.

 On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
 
  Yes it looks like we still are using v1.1 in out project.  How does 
  this affect the rendering of large HTML files and getting OOMEs when
doing so?
 
  Evan
 
 
  -Original Message-
  From: Nathan Bubna [mailto:[EMAIL PROTECTED]
  Sent: Monday, February 06, 2006 1:11 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  that depends on which version of VelocityTools you are using.  in 
  1.2, we rewrote things to use a VelocityEngine instead of the 
  singleton, which was causing problems for us.
 
  On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
  
   I believe that I'm using the singletone pattern.  I using the 
   VelocityViewServlet to startup velocity, and I believe its written 
   to use the runtime singleton by calling Velocity.init().
   Is that correct?
  
   -Evan
  
  
  
  
  
   -Original Message-
   From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
   Sent: Saturday, February 04, 2006 4:35 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   Are you using Velocity singleton pattern or VelocityEngine?
  
   regards Malcolm Edgar
  
   On 2/4/06, e v a n [EMAIL PROTECTED] wrote:
   
Hello,
   
I just picked up on this thread[1] from 5-10-2005 today because 
I'm running into a similar issue trying to render a large HTML 
page via velocity that's included via Tiles.  In this post [2] 
in the thread, there is talk of making a specialized TilesTool 
for cases where large html files need to be written out with 
Velocity. To anyone's knowledge, has anyone come up with such a
patch?
   
Thank You,
Evan Leonard
   
   
[1] -
http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velo
city
-T
emplat
e-t5193.html
[2] -
http://www.nabble.com/Re:-OutOfMemoryException-Processing-Veloci
ty-T
em
plate-
p23480.html
   
   
   
   


- To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   
   
  
   --
   --- To unsubscribe, e-mail: 
   [EMAIL PROTECTED]
   For additional commands, e-mail: 
   [EMAIL PROTECTED]
  
  
  
   --
   --- To unsubscribe, e-mail: 
   [EMAIL PROTECTED]
   For additional commands, e-mail: 
   [EMAIL PROTECTED]
  
  
 
  
  - To unsubscribe, e-mail: 
  [EMAIL PROTECTED]
  For additional commands, e-mail: 
  [EMAIL PROTECTED]
 
 
 
  
  - To unsubscribe, e-mail: 
  [EMAIL PROTECTED]
  For additional commands, e-mail: 
  [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: OutOfMemoryException Processing Velocity Template

2006-02-07 Thread Barbara Baughman
And here all the time I thought it was a Tomcat issue with reloading.

All of my web applications use the VelocityEngine rather than the
singleton, and I notice that Tomcat throws an OutOfMemoryException
after a lot of reloads.

Is there something I should be during in the HttpServlet destroy
method to clear out the VelocityEngine?

Barbara Baughman
X2157

On Tue, 7 Feb 2006, e v a n wrote:


 Hmm. I wasn't aware of the leak issue, I'll make a note of that.

 As for other work arounds, I have one that will work just fine for my
 situation. But I'm still curious about the specialized tiles tool for the
 purpose of streaming output to the browser, instead of buffering the whole
 page in a string before sending it as the tiles tool does.  But that's
 another question, and probably for the tiles developers.

 Thank you for your help.

 -Evan


 -Original Message-
 From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 06, 2006 8:35 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template

 If your are reloading your application a lot, i.e. doing development work,
 the singleton pattern causes a memory leak. This could be expressed in OOME
 when rendering templates.

 regards Malcolm Edgar

 On 2/7/06, Nathan Bubna [EMAIL PROTECTED] wrote:
  i'm not sure.  Edgar?
 
  as for your question about a specialized TilesTool...  i'm not aware
  of this having been done.  if it has, it wasn't shared with the list.
 
  have you taken the other advice in the thread and profiled your
  application?  if you aren't up for writing a specialized TilesTool,
  then there may be other ways you can cut down on your memory use.
 
  On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
  
   Yes it looks like we still are using v1.1 in out project.  How does
   this affect the rendering of large HTML files and getting OOMEs when
 doing so?
  
   Evan
  
  
   -Original Message-
   From: Nathan Bubna [mailto:[EMAIL PROTECTED]
   Sent: Monday, February 06, 2006 1:11 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   that depends on which version of VelocityTools you are using.  in
   1.2, we rewrote things to use a VelocityEngine instead of the
   singleton, which was causing problems for us.
  
   On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
   
I believe that I'm using the singletone pattern.  I using the
VelocityViewServlet to startup velocity, and I believe its written
to use the runtime singleton by calling Velocity.init().
Is that correct?
   
-Evan
   
   
   
   
   
-Original Message-
From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
Sent: Saturday, February 04, 2006 4:35 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template
   
Are you using Velocity singleton pattern or VelocityEngine?
   
regards Malcolm Edgar
   
On 2/4/06, e v a n [EMAIL PROTECTED] wrote:

 Hello,

 I just picked up on this thread[1] from 5-10-2005 today because
 I'm running into a similar issue trying to render a large HTML
 page via velocity that's included via Tiles.  In this post [2]
 in the thread, there is talk of making a specialized TilesTool
 for cases where large html files need to be written out with
 Velocity. To anyone's knowledge, has anyone come up with such a
 patch?

 Thank You,
 Evan Leonard


 [1] -
 http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velo
 city
 -T
 emplat
 e-t5193.html
 [2] -
 http://www.nabble.com/Re:-OutOfMemoryException-Processing-Veloci
 ty-T
 em
 plate-
 p23480.html




 
 
 - To unsubscribe, e-mail:
 [EMAIL PROTECTED]
 For additional commands, e-mail:
 [EMAIL PROTECTED]


   
--
--- To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   
   
   
--
--- To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   
   
  
   
   - To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]
  
  
  
   
   - To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail

Re: OutOfMemoryException Processing Velocity Template

2006-02-07 Thread Will Glass-Husain
I have this issue with Tomcat JSP apps as well as Velocity.  So it is a 
Tomcat issue.  I
think it holds on to static references in the classloader.  Tomcat's great 
in general but the deployment I find is really not robust.


WILL

- Original Message - 
From: Barbara Baughman [EMAIL PROTECTED]

To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Tuesday, February 07, 2006 1:33 PM
Subject: RE: OutOfMemoryException Processing Velocity Template



And here all the time I thought it was a Tomcat issue with reloading.

All of my web applications use the VelocityEngine rather than the
singleton, and I notice that Tomcat throws an OutOfMemoryException
after a lot of reloads.

Is there something I should be during in the HttpServlet destroy
method to clear out the VelocityEngine?

Barbara Baughman
X2157

On Tue, 7 Feb 2006, e v a n wrote:



Hmm. I wasn't aware of the leak issue, I'll make a note of that.

As for other work arounds, I have one that will work just fine for my
situation. But I'm still curious about the specialized tiles tool for the
purpose of streaming output to the browser, instead of buffering the
whole
page in a string before sending it as the tiles tool does.  But that's
another question, and probably for the tiles developers.

Thank you for your help.

-Evan


-Original Message-
From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
Sent: Monday, February 06, 2006 8:35 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

If your are reloading your application a lot, i.e. doing development
work,
the singleton pattern causes a memory leak. This could be expressed in
OOME
when rendering templates.

regards Malcolm Edgar

On 2/7/06, Nathan Bubna [EMAIL PROTECTED] wrote:
 i'm not sure.  Edgar?

 as for your question about a specialized TilesTool...  i'm not aware
 of this having been done.  if it has, it wasn't shared with the list.

 have you taken the other advice in the thread and profiled your
 application?  if you aren't up for writing a specialized TilesTool,
 then there may be other ways you can cut down on your memory use.

 On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
 
  Yes it looks like we still are using v1.1 in out project.  How does
  this affect the rendering of large HTML files and getting OOMEs when
doing so?
 
  Evan
 
 
  -Original Message-
  From: Nathan Bubna [mailto:[EMAIL PROTECTED]
  Sent: Monday, February 06, 2006 1:11 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  that depends on which version of VelocityTools you are using.  in
  1.2, we rewrote things to use a VelocityEngine instead of the
  singleton, which was causing problems for us.
 
  On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
  
   I believe that I'm using the singletone pattern.  I using the
   VelocityViewServlet to startup velocity, and I believe its written
   to use the runtime singleton by calling Velocity.init().
   Is that correct?
  
   -Evan
  
  
  
  
  
   -Original Message-
   From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
   Sent: Saturday, February 04, 2006 4:35 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   Are you using Velocity singleton pattern or VelocityEngine?
  
   regards Malcolm Edgar
  
   On 2/4/06, e v a n [EMAIL PROTECTED] wrote:
   
Hello,
   
I just picked up on this thread[1] from 5-10-2005 today because
I'm running into a similar issue trying to render a large HTML
page via velocity that's included via Tiles.  In this post [2]
in the thread, there is talk of making a specialized TilesTool
for cases where large html files need to be written out with
Velocity. To anyone's knowledge, has anyone come up with such a
patch?
   
Thank You,
Evan Leonard
   
   
[1] -
http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velo
city
-T
emplat
e-t5193.html
[2] -
http://www.nabble.com/Re:-OutOfMemoryException-Processing-Veloci
ty-T
em
plate-
p23480.html
   
   
   
   


- To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   
   
  
   --
   --- To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]
  
  
  
   --
   --- To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]
  
  
 
  
  - To unsubscribe, e-mail:
  [EMAIL PROTECTED]
  For additional commands, e-mail:
  [EMAIL PROTECTED]
 
 
 
  
  - To unsubscribe, e-mail:
  [EMAIL PROTECTED

RE: OutOfMemoryException Processing Velocity Template

2006-02-06 Thread e v a n

I believe that I'm using the singletone pattern.  I using the
VelocityViewServlet to startup velocity, and I believe its written to use
the runtime singleton by calling Velocity.init().
Is that correct?

-Evan



 

-Original Message-
From: Malcolm Edgar [mailto:[EMAIL PROTECTED] 
Sent: Saturday, February 04, 2006 4:35 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

Are you using Velocity singleton pattern or VelocityEngine?

regards Malcolm Edgar

On 2/4/06, e v a n [EMAIL PROTECTED] wrote:

 Hello,

 I just picked up on this thread[1] from 5-10-2005 today because I'm 
 running into a similar issue trying to render a large HTML page via 
 velocity that's included via Tiles.  In this post [2] in the thread, 
 there is talk of making a specialized TilesTool for cases where large 
 html files need to be written out with Velocity. To anyone's 
 knowledge, has anyone come up with such a patch?

 Thank You,
 Evan Leonard


 [1] -
 http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity-T
 emplat
 e-t5193.html
 [2] -
 http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-Tem
 plate-
 p23480.html




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2006-02-06 Thread Nathan Bubna
that depends on which version of VelocityTools you are using.  in 1.2,
we rewrote things to use a VelocityEngine instead of the singleton,
which was causing problems for us.

On 2/6/06, e v a n [EMAIL PROTECTED] wrote:

 I believe that I'm using the singletone pattern.  I using the
 VelocityViewServlet to startup velocity, and I believe its written to use
 the runtime singleton by calling Velocity.init().
 Is that correct?

 -Evan





 -Original Message-
 From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
 Sent: Saturday, February 04, 2006 4:35 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template

 Are you using Velocity singleton pattern or VelocityEngine?

 regards Malcolm Edgar

 On 2/4/06, e v a n [EMAIL PROTECTED] wrote:
 
  Hello,
 
  I just picked up on this thread[1] from 5-10-2005 today because I'm
  running into a similar issue trying to render a large HTML page via
  velocity that's included via Tiles.  In this post [2] in the thread,
  there is talk of making a specialized TilesTool for cases where large
  html files need to be written out with Velocity. To anyone's
  knowledge, has anyone come up with such a patch?
 
  Thank You,
  Evan Leonard
 
 
  [1] -
  http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity-T
  emplat
  e-t5193.html
  [2] -
  http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-Tem
  plate-
  p23480.html
 
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: OutOfMemoryException Processing Velocity Template

2006-02-06 Thread e v a n

Yes it looks like we still are using v1.1 in out project.  How does this
affect the rendering of large HTML files and getting OOMEs when doing so?

Evan
 

-Original Message-
From: Nathan Bubna [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 06, 2006 1:11 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

that depends on which version of VelocityTools you are using.  in 1.2, we
rewrote things to use a VelocityEngine instead of the singleton, which was
causing problems for us.

On 2/6/06, e v a n [EMAIL PROTECTED] wrote:

 I believe that I'm using the singletone pattern.  I using the 
 VelocityViewServlet to startup velocity, and I believe its written to 
 use the runtime singleton by calling Velocity.init().
 Is that correct?

 -Evan





 -Original Message-
 From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
 Sent: Saturday, February 04, 2006 4:35 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template

 Are you using Velocity singleton pattern or VelocityEngine?

 regards Malcolm Edgar

 On 2/4/06, e v a n [EMAIL PROTECTED] wrote:
 
  Hello,
 
  I just picked up on this thread[1] from 5-10-2005 today because I'm 
  running into a similar issue trying to render a large HTML page via 
  velocity that's included via Tiles.  In this post [2] in the thread, 
  there is talk of making a specialized TilesTool for cases where 
  large html files need to be written out with Velocity. To anyone's 
  knowledge, has anyone come up with such a patch?
 
  Thank You,
  Evan Leonard
 
 
  [1] -
  http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity
  -T
  emplat
  e-t5193.html
  [2] -
  http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-T
  em
  plate-
  p23480.html
 
 
 
 
  
  - To unsubscribe, e-mail: 
  [EMAIL PROTECTED]
  For additional commands, e-mail: 
  [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2006-02-06 Thread Nathan Bubna
i'm not sure.  Edgar?

as for your question about a specialized TilesTool...  i'm not aware
of this having been done.  if it has, it wasn't shared with the list.

have you taken the other advice in the thread and profiled your
application?  if you aren't up for writing a specialized TilesTool,
then there may be other ways you can cut down on your memory use.

On 2/6/06, e v a n [EMAIL PROTECTED] wrote:

 Yes it looks like we still are using v1.1 in out project.  How does this
 affect the rendering of large HTML files and getting OOMEs when doing so?

 Evan


 -Original Message-
 From: Nathan Bubna [mailto:[EMAIL PROTECTED]
 Sent: Monday, February 06, 2006 1:11 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template

 that depends on which version of VelocityTools you are using.  in 1.2, we
 rewrote things to use a VelocityEngine instead of the singleton, which was
 causing problems for us.

 On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
 
  I believe that I'm using the singletone pattern.  I using the
  VelocityViewServlet to startup velocity, and I believe its written to
  use the runtime singleton by calling Velocity.init().
  Is that correct?
 
  -Evan
 
 
 
 
 
  -Original Message-
  From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
  Sent: Saturday, February 04, 2006 4:35 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  Are you using Velocity singleton pattern or VelocityEngine?
 
  regards Malcolm Edgar
 
  On 2/4/06, e v a n [EMAIL PROTECTED] wrote:
  
   Hello,
  
   I just picked up on this thread[1] from 5-10-2005 today because I'm
   running into a similar issue trying to render a large HTML page via
   velocity that's included via Tiles.  In this post [2] in the thread,
   there is talk of making a specialized TilesTool for cases where
   large html files need to be written out with Velocity. To anyone's
   knowledge, has anyone come up with such a patch?
  
   Thank You,
   Evan Leonard
  
  
   [1] -
   http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity
   -T
   emplat
   e-t5193.html
   [2] -
   http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-T
   em
   plate-
   p23480.html
  
  
  
  
   
   - To unsubscribe, e-mail:
   [EMAIL PROTECTED]
   For additional commands, e-mail:
   [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2006-02-06 Thread Malcolm Edgar
If your are reloading your application a lot, i.e. doing development
work, the singleton pattern causes a memory leak. This could be
expressed in OOME when rendering templates.

regards Malcolm Edgar

On 2/7/06, Nathan Bubna [EMAIL PROTECTED] wrote:
 i'm not sure.  Edgar?

 as for your question about a specialized TilesTool...  i'm not aware
 of this having been done.  if it has, it wasn't shared with the list.

 have you taken the other advice in the thread and profiled your
 application?  if you aren't up for writing a specialized TilesTool,
 then there may be other ways you can cut down on your memory use.

 On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
 
  Yes it looks like we still are using v1.1 in out project.  How does this
  affect the rendering of large HTML files and getting OOMEs when doing so?
 
  Evan
 
 
  -Original Message-
  From: Nathan Bubna [mailto:[EMAIL PROTECTED]
  Sent: Monday, February 06, 2006 1:11 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  that depends on which version of VelocityTools you are using.  in 1.2, we
  rewrote things to use a VelocityEngine instead of the singleton, which was
  causing problems for us.
 
  On 2/6/06, e v a n [EMAIL PROTECTED] wrote:
  
   I believe that I'm using the singletone pattern.  I using the
   VelocityViewServlet to startup velocity, and I believe its written to
   use the runtime singleton by calling Velocity.init().
   Is that correct?
  
   -Evan
  
  
  
  
  
   -Original Message-
   From: Malcolm Edgar [mailto:[EMAIL PROTECTED]
   Sent: Saturday, February 04, 2006 4:35 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   Are you using Velocity singleton pattern or VelocityEngine?
  
   regards Malcolm Edgar
  
   On 2/4/06, e v a n [EMAIL PROTECTED] wrote:
   
Hello,
   
I just picked up on this thread[1] from 5-10-2005 today because I'm
running into a similar issue trying to render a large HTML page via
velocity that's included via Tiles.  In this post [2] in the thread,
there is talk of making a specialized TilesTool for cases where
large html files need to be written out with Velocity. To anyone's
knowledge, has anyone come up with such a patch?
   
Thank You,
Evan Leonard
   
   
[1] -
http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity
-T
emplat
e-t5193.html
[2] -
http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-T
em
plate-
p23480.html
   
   
   
   

- To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
   
   
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: OutOfMemoryException Processing Velocity Template

2006-02-04 Thread e v a n

Hello, 

I just picked up on this thread[1] from 5-10-2005 today because I'm running
into a similar issue trying to render a large HTML page via velocity that's
included via Tiles.  In this post [2] in the thread, there is talk of making
a specialized TilesTool for cases where large html files need to be written
out with Velocity. To anyone's knowledge, has anyone come up with such a
patch?

Thank You,
Evan Leonard


[1] -
http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity-Templat
e-t5193.html
[2] -
http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-Template-
p23480.html




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2006-02-04 Thread Malcolm Edgar
Are you using Velocity singleton pattern or VelocityEngine?

regards Malcolm Edgar

On 2/4/06, e v a n [EMAIL PROTECTED] wrote:

 Hello,

 I just picked up on this thread[1] from 5-10-2005 today because I'm running
 into a similar issue trying to render a large HTML page via velocity that's
 included via Tiles.  In this post [2] in the thread, there is talk of making
 a specialized TilesTool for cases where large html files need to be written
 out with Velocity. To anyone's knowledge, has anyone come up with such a
 patch?

 Thank You,
 Evan Leonard


 [1] -
 http://www.nabble.com/RE%3A-OutOfMemoryException-Processing-Velocity-Templat
 e-t5193.html
 [2] -
 http://www.nabble.com/Re:-OutOfMemoryException-Processing-Velocity-Template-
 p23480.html




 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2005-05-11 Thread Michael Salmon

If there is a need for a specialized TileTools, then the person with the
problem should implement a specialized TileTools and share it with the public.

The impl could be set via a velocity property, but default would stay as-is.


On Tue, May 10, 2005 at 05:18:50PM -0700, Will Glass-Husain wrote:
 You've probably already considered this - but do you really *need* 66,000 
 rows?
 
 Possibly a simpler solution might be to restructure your appoach to output 
 data in smaller chunks.  Just wondering.
 
 I assume you must be exporting to Excel or some other software - it's hard 
 for me to think of a use case where a user wants to scroll down 66K rows.
 
 WILL
 
 - Original Message - 
 From: Mike Curwen [EMAIL PROTECTED]
 To: 'Velocity Users List' velocity-user@jakarta.apache.org
 Sent: Tuesday, May 10, 2005 5:09 PM
 Subject: RE: OutOfMemoryException Processing Velocity Template
 
 
 From way back in your first email:
 
 unless I set the tomcat JVM to use a heap size of at least 256M
 
 I'm of two minds:
 
 1) Is there something wrong with that size?  What I mean is, the default
 heap size is fairly small, considering that most servers worth their name
 have *at least* 512MB to spare.  And I'm not trying to make fun of anyone's
 server here... I'm just asking: Is this now a bug, or more of a application
 memory sizing/requirements issue?  p.s.  I *wish* I could run the apps I do
 at work on as little as 256.
 
 2) 150+MB just to do html pushing *does* seem extreme.  But on the other
 hand, how many HTML pages have 66k+ rows?  I think most clients, never mind
 servers, would start to choke on that.  So for sure, there ought to be a way
 to do better.  But I go back to #1 - the TilesTool seems to 'do 90% of
 everyone's jobs', and your job is an edgecase; perhaps not for you, but
 certainly for me and any apps I've ever written.
 
 
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Tuesday, May 10, 2005 6:21 PM
 To: Nathan Bubna
 Cc: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 *Gasp*   Ok so I did what you suggested and when I request
 the particular template WITHOUT using tiles, it works.   But
 what now?  We've located that the memory problem is indeed in
 TilesTools (probably cause it uses a BtyeArrayOutputStream),
 but my application is heavily reliant on the use of the TilesTool ...
 
 Suggestions?
 
 -L
 
 P.S.  I actually did get the FileOutputStream method to work
 with Tiles, but on the page with the huge table, it broke.
 
 On Tue, May 10, 2005 at 02:35:14PM -0700, Nathan Bubna wrote:
  oops.  didn't mean to take this off the list...
 
  i'm quite skeptical that you could get the FileOutputStream
 method to
  work with Tiles.  you might be able extend the
 VelocityViewServlet to
  do something like that though.  i'm not sure what the best tactic
  there would be.
 
  as for just requesting the particular template and not using Tiles,
  that should be simple.  the tile being requested is just a template
  like any other.  the TilesRequestProcessor is just making
 an internal
  servlet request (forward or include).  all you need to do
 is request
  the same template of the VVS directly.  in other words, get
 your app
  running, enter the URL for the template in question (or one
 that does
  the same thing), rather than the parent template that is
 requesting it
  as a tile ($tile.foo), and see what happens.
 
  On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   How would I do that?
  
   I changed the ImportSupport class to use a
 FileOutputStream, which writes out to a temp file.   Then the
 getString() method reads that temp file.  What happens when I
 do this, however, is when I get to the page with the 66000
 row table, it sits there for about 1 minute until it runs out
 of memory.   I'm thoroughly confused!
  
   -L
  
   On Tue, May 10, 2005 at 11:31:17AM -0700, Nathan Bubna wrote:
hmm.  yeah, i don't know what to do then.  without some good
profiling to see what is hogging the memory, it's hard to say.
have you tried just requesting the template in question
 directly
with the VVS rather than trying to hold it in memory as a tile?
   
that might at least narrow down the area with the problem.
   
On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Ok I tried that, but unfortunately, it didn't do the
 trick =(.   I verified that getResponseWriter was returning
 an OutputStreamWriter, but it didn't help.   Maybe I'll have
 to change TilesTool to return an FileOutputStream that writes
 to a temp file but would that work?   Oh well, anything
 is worth trying now!

 -L

 On Tue, May 10, 2005 at 10:44:05AM -0700, Nathan Bubna wrote:
  well, maybe you can just override the VVS's
  getResponseWriter() method somehow to try calling/using
  getOutputStream() on requests first.  but i'm not sure that
  will do the trick.  it might, if it's

Re: OutOfMemoryException Processing Velocity Template

2005-05-11 Thread lawrence
Thanks everyone for your thoughts.   The reason I am concerned about the large 
heap size needed to host a SINGLE 66k row page is because of simultaneous 
access to many pages that COULD return reports of 66k rows.   Even though my 
app will be running on a Server with 4GB of memory, that is only 16 
simultaneous users at once, in the worst case scenario.   I'm not sure this is 
an acceptable solution.  
Secondly, 66k rows doesn't seem extreme to me, especially when the JVM only 
needs ~8MB to hold that List in memory.   In addition, without use of the 
TilesTools, by directly forwarding to the velocity template instead of a tiles 
def, I only have to set the heap size to 32.  With the use of TilesTools, this 
jumps to 250MB.   This doesn't make sense to me.   I'm not claiming that this 
is a bug, or even an implementation oversight, but there should be a better, 
more memory effecient, solution to this problem.   I tried playing around with 
the TileTools, but haven't been able to come up with anything that works.  

-L

On Tue, May 10, 2005 at 11:14:49PM -0700, Michael Salmon wrote:
 
 If there is a need for a specialized TileTools, then the person with the
 problem should implement a specialized TileTools and share it with the public.
 
 The impl could be set via a velocity property, but default would stay as-is.
 
 
 On Tue, May 10, 2005 at 05:18:50PM -0700, Will Glass-Husain wrote:
  You've probably already considered this - but do you really *need* 66,000 
  rows?
  
  Possibly a simpler solution might be to restructure your appoach to output 
  data in smaller chunks.  Just wondering.
  
  I assume you must be exporting to Excel or some other software - it's hard 
  for me to think of a use case where a user wants to scroll down 66K rows.
  
  WILL
  
  - Original Message - 
  From: Mike Curwen [EMAIL PROTECTED]
  To: 'Velocity Users List' velocity-user@jakarta.apache.org
  Sent: Tuesday, May 10, 2005 5:09 PM
  Subject: RE: OutOfMemoryException Processing Velocity Template
  
  
  From way back in your first email:
  
  unless I set the tomcat JVM to use a heap size of at least 256M
  
  I'm of two minds:
  
  1) Is there something wrong with that size?  What I mean is, the default
  heap size is fairly small, considering that most servers worth their name
  have *at least* 512MB to spare.  And I'm not trying to make fun of anyone's
  server here... I'm just asking: Is this now a bug, or more of a application
  memory sizing/requirements issue?  p.s.  I *wish* I could run the apps I do
  at work on as little as 256.
  
  2) 150+MB just to do html pushing *does* seem extreme.  But on the other
  hand, how many HTML pages have 66k+ rows?  I think most clients, never mind
  servers, would start to choke on that.  So for sure, there ought to be a way
  to do better.  But I go back to #1 - the TilesTool seems to 'do 90% of
  everyone's jobs', and your job is an edgecase; perhaps not for you, but
  certainly for me and any apps I've ever written.
  
  
  
  
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Tuesday, May 10, 2005 6:21 PM
  To: Nathan Bubna
  Cc: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
  
  
  *Gasp*   Ok so I did what you suggested and when I request
  the particular template WITHOUT using tiles, it works.   But
  what now?  We've located that the memory problem is indeed in
  TilesTools (probably cause it uses a BtyeArrayOutputStream),
  but my application is heavily reliant on the use of the TilesTool ...
  
  Suggestions?
  
  -L
  
  P.S.  I actually did get the FileOutputStream method to work
  with Tiles, but on the page with the huge table, it broke.
  
  On Tue, May 10, 2005 at 02:35:14PM -0700, Nathan Bubna wrote:
   oops.  didn't mean to take this off the list...
  
   i'm quite skeptical that you could get the FileOutputStream
  method to
   work with Tiles.  you might be able extend the
  VelocityViewServlet to
   do something like that though.  i'm not sure what the best tactic
   there would be.
  
   as for just requesting the particular template and not using Tiles,
   that should be simple.  the tile being requested is just a template
   like any other.  the TilesRequestProcessor is just making
  an internal
   servlet request (forward or include).  all you need to do
  is request
   the same template of the VVS directly.  in other words, get
  your app
   running, enter the URL for the template in question (or one
  that does
   the same thing), rather than the parent template that is
  requesting it
   as a tile ($tile.foo), and see what happens.
  
   On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
How would I do that?
   
I changed the ImportSupport class to use a
  FileOutputStream, which writes out to a temp file.   Then the
  getString() method reads that temp file.  What happens when I
  do this, however, is when I get to the page with the 66000
  row

Re: OutOfMemoryException Processing Velocity Template

2005-05-11 Thread Llewellyn Falco
Hey there,
we also have a webapp with reports with lots of rows.
We used to use a homegrown template parser, and recently switched to 
velocity for standards and tools, and on the whole i've been quite happy 
minus a few little issues, most which where solvable with the right 
convience classes.

however, when we switched, a page that would run at 20megs, blew up to over 
160.
We haven't been able to solve this as of yet, and merely upgraded the jvm 
memory.

Anyways the point is, memory before velocity + size of string returned from 
velocity is really as close to big as velocity should really need to get, 
but it isn't.

Not having gone through velocity's code (other than the jprobe analysis to 
figure out what's going on) i'm not sure why this is, but on the good side, 
it's not a leak, all memory is reclaimed at the end of the parse.

anyways, for what it's worth the bug/ineffectincy  exist in velocity.
   llewellyn. 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemoryException Processing Velocity Template

2005-05-11 Thread Llewellyn Falco
Hey we've been using macro's to workaround complex setting issues.
The problem is that if we use the global defaults, we can't overwrite the 
marco's and the concept of using them as a variable is lost, and if we turn 
it on
props.put(velocimacro.context.localscope,  + true);
then the parsed file doesn't seem to have scope to it.

any suggestions, or does anyone know a better way to
#set ($var =
many
lines
of
code
)
thanks,
llewellyn.
example of usage.
#macro (manyLineOfText)
this
prints
many
lines
of
$randomText
text
#end
#parse (someFile)
-
someFile.vm
-
firstBlock
#manyLinesOfText()
secondBlock
#manyLinesOfText()


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemoryException Processing Velocity Template

2005-05-11 Thread Will Glass-Husain
Well, the #set approach will work with the latest version of Velocity in 
source control.  (If you put the text in quotes).  Or if not, you can use 
the new concatenation operator +.

http://cvs.apache.org/snapshots/velocity/
WILL
- Original Message - 
From: Llewellyn Falco [EMAIL PROTECTED]
To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Wednesday, May 11, 2005 1:32 PM
Subject: Re: OutOfMemoryException Processing Velocity Template


Hey we've been using macro's to workaround complex setting issues.
The problem is that if we use the global defaults, we can't overwrite the 
marco's and the concept of using them as a variable is lost, and if we 
turn it on
props.put(velocimacro.context.localscope,  + true);
then the parsed file doesn't seem to have scope to it.

any suggestions, or does anyone know a better way to
#set ($var =
many
lines
of
code
)
thanks,
llewellyn.
example of usage.
#macro (manyLineOfText)
this
prints
many
lines
of
$randomText
text
#end
#parse (someFile)
-
someFile.vm
-
firstBlock
#manyLinesOfText()
secondBlock
#manyLinesOfText()


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Ilkka Priha
$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at 
org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at 
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:534)
So I suppose the question is, how effecient is ServletOutputStream?  When I use 
an FileOutputStream, very little memory is required.
-L
On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:
Maybe you are not referring to this memory eating template directly from 
VelocityServlet, but through some tool, #include, etc., which uses a nested 
StringWriter and not the servlet's OutputStreamWriter directly. According 
to your first post, the original oom exception was thrown by the Velocity 
Struts Tiles tool...

-- Ilkka
[EMAIL PROTECTED] wrote:
Ok now I'm confused (suprise, suprise!).   I looked at the source for 
VelocityServlet, and mergeTemplate has:

vw = (VelocityWriter) writerPool.get();
if (vw == null)
{
  vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 * 
  1024, true);
}
else
{
  vw.recycle(new OutputStreamWriter(output, encoding));
}
template.merge(context, vw);

===
So the VelocityServlet DOES use OutputStreamWriter already ... so then why 
does it still utilize so much memory?

-L
On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:

Alright, I changed the Writer to be:
OutputStreamWriter w = new OutputStreamWriter(new 
FileOutputStream(test.html));

And this fixes the memory problem.
However, my application is running Velocity as a servlet, how should I 
extend the VelocityServlet to use an OutputStreamWriter intead of a 
StringWriter?  Should I post a different email thread about this?

-L
On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:

Well, Open a file, use a FileWriter.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 1:48 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

I printed out the available memory before and after I call
mergeTemplate:
Free memory before merge: 217393352
Free memory after merge: 16271392
so I would assume the StringWriter is approximately 200MB after the
merge.   What should I use/do instead?   

-Lawrence
On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:

Why do you use StringWriter? That is cached in the memory.
How big is the StringWriter after the merge?
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 1:22 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

Alright, I ran this little piece of code:
public static void main( String args[] ) throws Exception
 {
 /* first, we init the runtime engine.  Defaults are fine. */
 Velocity.init();
 /* lets make a Context and put data into it */
 VelocityContext context = new VelocityContext();
 List results = ReportBean.runLargeReport();
 
 context.put(List, results);
 
 /* lets render a template */

 StringWriter w = new StringWriter();
 Velocity.mergeTemplate(/myfile.vm, context, w );
 System.out.println( template :  + w );
 /* lets make our own string to render */
 }
results is a List of 66000 objects and requires about 8megs of memory.
The mergeTemplate requires at least 230 MB of memory.   Any
suggestions?
-L
On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:

Hi, 

I guess the writer Ilkka talked about is when using Velocity as a
standalone template engine.
Right now I don't have a good clue, could you run Velocity as a
standalone template engine and render the page to see if there is a
huge memory usage?
Cheers,
Jian
On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Sorry, I'm not sure what you mean by what kind of writer I'm
using.   Where would I find out?   How would I change this (to maybe a
StringBuffer writer?)

Also, each column contains a String that is at most, 200
characters,

most are closer to 10-20.   There are a total of 10 columns.

Thanks.
-Lawrence
On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:

What kind of writer are you using and how long are the items? 66
000 HTML

table rows with 5 numeric columns consumes about 32 MB when
buffered into a

string writer. If the items are longer, it takes much more
memory.

-- Ilkka

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread lawrence
)
  at 
  
  org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
  at 
  
  org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
  at 
  
  org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at 
  org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at 
  
  org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
  at 
  
  org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at 
  
  org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at 
  org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at 
  org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
  at 
  org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
  at 
  org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
  at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
  at 
  
  org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
  at 
  org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
  at 
  
  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
  at java.lang.Thread.run(Thread.java:534)
 
 So I suppose the question is, how effecient is ServletOutputStream?  When 
 I use an FileOutputStream, very little memory is required.
 
 -L
 
 On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:
 
 Maybe you are not referring to this memory eating template directly from 
 VelocityServlet, but through some tool, #include, etc., which uses a 
 nested StringWriter and not the servlet's OutputStreamWriter directly. 
 According to your first post, the original oom exception was thrown by 
 the Velocity Struts Tiles tool...
 
 -- Ilkka
 
 
 [EMAIL PROTECTED] wrote:
 
 Ok now I'm confused (suprise, suprise!).   I looked at the source for 
 VelocityServlet, and mergeTemplate has:
 
 vw = (VelocityWriter) writerPool.get();
 
 if (vw == null)
 {
   vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 * 
   1024, true);
 }
 else
 {
   vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already ... so then 
 why does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
 
 
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new 
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, how should I 
 extend the VelocityServlet to use an OutputStreamWriter intead of a 
 StringWriter?  Should I post a different email thread about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 
 
 Well, Open a file, use a FileWriter.
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 I printed out the available memory before and after I call
 mergeTemplate:
 
 Free memory before merge: 217393352
 Free memory after merge: 16271392
 
 so I would assume the StringWriter is approximately 200MB after the
 merge.   What should I use/do instead?   
 
 -Lawrence
 
 On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
 
 
 Why do you use StringWriter? That is cached in the memory.
 How big is the StringWriter after the merge?
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:22 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 Alright, I ran this little piece of code:
 
 public static void main( String args[] ) throws Exception
  {
  /* first, we init the runtime engine.  Defaults are fine. */
 
  Velocity.init();
 
  /* lets make a Context and put data into it */
 
  VelocityContext context = new VelocityContext();
 
  List results = ReportBean.runLargeReport();
  
  context.put(List, results);
  
  /* lets render a template */
 
  StringWriter w = new StringWriter();
 
  Velocity.mergeTemplate(/myfile.vm, context, w );
  System.out.println( template :  + w );
 
  /* lets make our own string to render */
  }
 
 results is a List of 66000 objects and requires about 8megs of memory.
 The mergeTemplate requires at least 230 MB of memory.   Any
 suggestions?
 
 -L
 
 On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
 
 
 Hi, 
 
 I guess the writer Ilkka talked about is when using Velocity as a
 standalone template engine.
 
 Right now I don't have a good clue, could you run Velocity as a
 standalone

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Nathan Bubna
:643)
   at
   
   org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at
   org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at
   
   org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
   at
   
   org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
   at
   
   org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at
   
   org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
   at
   
   org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
   at
   
   org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
   at
   
   org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
   at
   
   org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at
   org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at
   
   org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
   at
   
   org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
   at
   
   org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
   at
   org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
   at
   
   org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
   at
   org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
   at
   org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
   at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
   at
   
   org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
   at
   org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
   at
   
   org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
   at java.lang.Thread.run(Thread.java:534)
  
  So I suppose the question is, how effecient is ServletOutputStream?  When
  I use an FileOutputStream, very little memory is required.
  
  -L
  
  On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:
  
  Maybe you are not referring to this memory eating template directly from
  VelocityServlet, but through some tool, #include, etc., which uses a
  nested StringWriter and not the servlet's OutputStreamWriter directly.
  According to your first post, the original oom exception was thrown by
  the Velocity Struts Tiles tool...
  
  -- Ilkka
  
  
  [EMAIL PROTECTED] wrote:
  
  Ok now I'm confused (suprise, suprise!).   I looked at the source for
  VelocityServlet, and mergeTemplate has:
  
  vw = (VelocityWriter) writerPool.get();
  
  if (vw == null)
  {
vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 *
1024, true);
  }
  else
  {
vw.recycle(new OutputStreamWriter(output, encoding));
  }
  template.merge(context, vw);
  
  ===
  
  So the VelocityServlet DOES use OutputStreamWriter already ... so then
  why does it still utilize so much memory?
  
  -L
  
  On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
  
  
  Alright, I changed the Writer to be:
  
  OutputStreamWriter w = new OutputStreamWriter(new
  FileOutputStream(test.html));
  
  And this fixes the memory problem.
  
  However, my application is running Velocity as a servlet, how should I
  extend the VelocityServlet to use an OutputStreamWriter intead of a
  StringWriter?  Should I post a different email thread about this?
  
  -L
  
  On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
  
  
  Well, Open a file, use a FileWriter.
  
  David
  
  
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:48 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
  
  I printed out the available memory before and after I call
  mergeTemplate:
  
  Free memory before merge: 217393352
  Free memory after merge: 16271392
  
  so I would assume the StringWriter is approximately 200MB after the
  merge.   What should I use/do instead?
  
  -Lawrence
  
  On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
  
  
  Why do you use StringWriter? That is cached in the memory.
  How big is the StringWriter after the merge?
  
  David
  
  
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:22 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
  
  Alright, I ran this little piece of code:
  
  public static void main( String args[] ) throws Exception
   {
   /* first, we

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread lawrence
)
at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at

org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at

org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2415)
at

org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
at

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at

org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
at

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at

org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
at

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at

org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
at

org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
at

org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
at

org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
at

org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
at

org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
at

org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
at
org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at

org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:534)
   
   So I suppose the question is, how effecient is ServletOutputStream?  When
   I use an FileOutputStream, very little memory is required.
   
   -L
   
   On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:
   
   Maybe you are not referring to this memory eating template directly from
   VelocityServlet, but through some tool, #include, etc., which uses a
   nested StringWriter and not the servlet's OutputStreamWriter directly.
   According to your first post, the original oom exception was thrown by
   the Velocity Struts Tiles tool...
   
   -- Ilkka
   
   
   [EMAIL PROTECTED] wrote:
   
   Ok now I'm confused (suprise, suprise!).   I looked at the source for
   VelocityServlet, and mergeTemplate has:
   
   vw = (VelocityWriter) writerPool.get();
   
   if (vw == null)
   {
 vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 *
 1024, true);
   }
   else
   {
 vw.recycle(new OutputStreamWriter(output, encoding));
   }
   template.merge(context, vw);
   
   ===
   
   So the VelocityServlet DOES use OutputStreamWriter already ... so then
   why does it still utilize so much memory?
   
   -L
   
   On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
   
   
   Alright, I changed the Writer to be:
   
   OutputStreamWriter w = new OutputStreamWriter(new
   FileOutputStream(test.html));
   
   And this fixes the memory problem.
   
   However, my application is running Velocity as a servlet, how should I
   extend the VelocityServlet to use an OutputStreamWriter intead of a
   StringWriter?  Should I post a different email thread about this?
   
   -L
   
   On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
   
   
   Well, Open a file, use a FileWriter.
   
   David
   
   
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   Sent: Friday, May 06, 2005 1:48 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
   
   I printed out the available memory before and after I call
   mergeTemplate:
   
   Free memory before merge: 217393352
   Free memory after merge: 16271392
   
   so I would assume the StringWriter is approximately 200MB after the
   merge.   What should I use/do instead?
   
   -Lawrence
   
   On Fri, May 06

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Nathan Bubna
 PROTECTED]
   Sent: Friday, May 06, 2005 1:48 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
   
   I printed out the available memory before and after I call
   mergeTemplate:
   
   Free memory before merge: 217393352
   Free memory after merge: 16271392
   
   so I would assume the StringWriter is approximately 200MB after the
   merge.   What should I use/do instead?
   
   -Lawrence
   
   On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
   
   
   Why do you use StringWriter? That is cached in the memory.
   How big is the StringWriter after the merge?
   
   David
   
   
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   Sent: Friday, May 06, 2005 1:22 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
   
   Alright, I ran this little piece of code:
   
   public static void main( String args[] ) throws Exception
{
/* first, we init the runtime engine.  Defaults are fine. */
   
Velocity.init();
   
/* lets make a Context and put data into it */
   
VelocityContext context = new VelocityContext();
   
List results = ReportBean.runLargeReport();
   
context.put(List, results);
   
/* lets render a template */
   
StringWriter w = new StringWriter();
   
Velocity.mergeTemplate(/myfile.vm, context, w );
System.out.println( template :  + w );
   
/* lets make our own string to render */
}
   
   results is a List of 66000 objects and requires about 8megs of 
   memory.
   The mergeTemplate requires at least 230 MB of memory.   Any
   suggestions?
   
   -L
   
   On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
   
   
   Hi,
   
   I guess the writer Ilkka talked about is when using Velocity as a
   standalone template engine.
   
   Right now I don't have a good clue, could you run Velocity as a
   standalone template engine and render the page to see if there is a
   huge memory usage?
   
   Cheers,
   
   Jian
   
   On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
   
   Sorry, I'm not sure what you mean by what kind of writer I'm
   
   using.   Where would I find out?   How would I change this (to 
   maybe a
   StringBuffer writer?)
   
   
   Also, each column contains a String that is at most, 200
   
   characters,
   
   
   most are closer to 10-20.   There are a total of 10 columns.
   
   
   Thanks.
   
   -Lawrence
   
   On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
   
   
   What kind of writer are you using and how long are the items? 66
   
   000 HTML
   
   
   table rows with 5 numeric columns consumes about 32 MB when
   
   buffered into a
   
   
   string writer. If the items are longer, it takes much more
   
   memory.
   
   
   -- Ilkka
   
   
   [EMAIL PROTECTED] wrote:
   
   
   I tried putting static HTML in the #foreach loop, same problem.
   
   Then I
   
   
   tried setting the large list as a local varible:
   
   #set ($localList = $List)
   #foreach($row in $localList)
   ...
   
   but that didnt help either.   I don't see why velocity should
   
   use
   
   
   250+ MB
   
   
   of memory iterating over a list ~8MB in size...
   -L
   
   On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
   
   
   
   Well, I don't have a good clue now.
   
   What about do the debugging step by step, i.e., use just
   
   static
   
   
   html
   
   
   in your #foreach loop? Will that blow up the memory?
   
   Cheers,
   
   Jian
   
   
   
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
   
   
   Thanks for the suggestion.   I tried putting that, along with
   
   file.resource.loader.cache = true
   
   in my velocity.properties file.   Both did not work.   Any
   
   other
   
   
   suggestions?
   
   Thanks!
   
   -L
   
   On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
   
   
   
   Hi,
   
   This maybe because you haven't turned on template caching. I
   
   had
   
   
   similar problem before, and even if I only used
   
   evaluate(...)
   
   
   method
   
   
   and load the template using my own java program, it happened
   
   when the
   
   
   for loop is lot of iterations.
   
   The bottom line for my problem is I need to turn on template
   
   caching,
   
   
   so, velocity will not try to cache the objects it parsed
   
   during each
   
   
   time of the iteration.
   
   I did:
   ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE,
   
   true);
   
   
   where ri is a runtime instance.
   
   Will this fix your issue?
   
   Cheers,
   
   Jian
   
   
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED]
   
   wrote:
   
   
   I am getting an OutOfMemoryException:
   
   org.apache.velocity.exception.MethodInvocationException:
   
   Invocation of
   
   
   method 'get' in  class

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Nathan Bubna
 Velocity as a servlet, how 
should I
extend the VelocityServlet to use an OutputStreamWriter intead of a
StringWriter?  Should I post a different email thread about this?

-L

On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:


Well, Open a file, use a FileWriter.

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 06, 2005 1:48 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

I printed out the available memory before and after I call
mergeTemplate:

Free memory before merge: 217393352
Free memory after merge: 16271392

so I would assume the StringWriter is approximately 200MB after the
merge.   What should I use/do instead?

-Lawrence

On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:


Why do you use StringWriter? That is cached in the memory.
How big is the StringWriter after the merge?

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 06, 2005 1:22 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

Alright, I ran this little piece of code:

public static void main( String args[] ) throws Exception
 {
 /* first, we init the runtime engine.  Defaults are fine. */

 Velocity.init();

 /* lets make a Context and put data into it */

 VelocityContext context = new VelocityContext();

 List results = ReportBean.runLargeReport();

 context.put(List, results);

 /* lets render a template */

 StringWriter w = new StringWriter();

 Velocity.mergeTemplate(/myfile.vm, context, w );
 System.out.println( template :  + w );

 /* lets make our own string to render */
 }

results is a List of 66000 objects and requires about 8megs of 
memory.
The mergeTemplate requires at least 230 MB of memory.   Any
suggestions?

-L

On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:


Hi,

I guess the writer Ilkka talked about is when using Velocity as a
standalone template engine.

Right now I don't have a good clue, could you run Velocity as a
standalone template engine and render the page to see if there 
is a
huge memory usage?

Cheers,

Jian

On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:


Sorry, I'm not sure what you mean by what kind of writer I'm

using.   Where would I find out?   How would I change this (to 
maybe a
StringBuffer writer?)


Also, each column contains a String that is at most, 200

characters,


most are closer to 10-20.   There are a total of 10 columns.


Thanks.

-Lawrence

On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:


What kind of writer are you using and how long are the items? 
66

000 HTML


table rows with 5 numeric columns consumes about 32 MB when

buffered into a


string writer. If the items are longer, it takes much more

memory.


-- Ilkka


[EMAIL PROTECTED] wrote:


I tried putting static HTML in the #foreach loop, same 
problem.

Then I


tried setting the large list as a local varible:

#set ($localList = $List)
#foreach($row in $localList)
...

but that didnt help either.   I don't see why velocity should

use


250+ MB


of memory iterating over a list ~8MB in size...
-L

On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:



Well, I don't have a good clue now.

What about do the debugging step by step, i.e., use just

static


html


in your #foreach loop? Will that blow up the memory?

Cheers,

Jian



On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:



Thanks for the suggestion.   I tried putting that, along 
with

file.resource.loader.cache = true

in my velocity.properties file.   Both did not work.   Any

other


suggestions?

Thanks!

-L

On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:



Hi,

This maybe because you haven't turned on template caching. 
I

had


similar problem before, and even if I only used

evaluate(...)


method


and load the template using my own java program, it 
happened

when the


for loop is lot of iterations.

The bottom line

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread lawrence
 VelocityWriter(new OutputStreamWriter(output, 
  encoding),4 *
   1024, true);
 }
 else
 {
   vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already ... so 
 then
 why does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
 
 
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, how 
 should I
 extend the VelocityServlet to use an OutputStreamWriter intead of 
 a
 StringWriter?  Should I post a different email thread about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 
 
 Well, Open a file, use a FileWriter.
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 I printed out the available memory before and after I call
 mergeTemplate:
 
 Free memory before merge: 217393352
 Free memory after merge: 16271392
 
 so I would assume the StringWriter is approximately 200MB after 
 the
 merge.   What should I use/do instead?
 
 -Lawrence
 
 On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
 
 
 Why do you use StringWriter? That is cached in the memory.
 How big is the StringWriter after the merge?
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 06, 2005 1:22 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 Alright, I ran this little piece of code:
 
 public static void main( String args[] ) throws Exception
  {
  /* first, we init the runtime engine.  Defaults are fine. 
  */
 
  Velocity.init();
 
  /* lets make a Context and put data into it */
 
  VelocityContext context = new VelocityContext();
 
  List results = ReportBean.runLargeReport();
 
  context.put(List, results);
 
  /* lets render a template */
 
  StringWriter w = new StringWriter();
 
  Velocity.mergeTemplate(/myfile.vm, context, w );
  System.out.println( template :  + w );
 
  /* lets make our own string to render */
  }
 
 results is a List of 66000 objects and requires about 8megs of 
 memory.
 The mergeTemplate requires at least 230 MB of memory.   Any
 suggestions?
 
 -L
 
 On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
 
 
 Hi,
 
 I guess the writer Ilkka talked about is when using Velocity 
 as a
 standalone template engine.
 
 Right now I don't have a good clue, could you run Velocity as a
 standalone template engine and render the page to see if there 
 is a
 huge memory usage?
 
 Cheers,
 
 Jian
 
 On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 
 Sorry, I'm not sure what you mean by what kind of writer I'm
 
 using.   Where would I find out?   How would I change this (to 
 maybe a
 StringBuffer writer?)
 
 
 Also, each column contains a String that is at most, 200
 
 characters,
 
 
 most are closer to 10-20.   There are a total of 10 columns.
 
 
 Thanks.
 
 -Lawrence
 
 On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
 
 
 What kind of writer are you using and how long are the 
 items? 66
 
 000 HTML
 
 
 table rows with 5 numeric columns consumes about 32 MB when
 
 buffered into a
 
 
 string writer. If the items are longer, it takes much more
 
 memory.
 
 
 -- Ilkka
 
 
 [EMAIL PROTECTED] wrote:
 
 
 I tried putting static HTML in the #foreach loop, same 
 problem.
 
 Then I
 
 
 tried setting the large list as a local varible:
 
 #set ($localList = $List)
 #foreach($row in $localList)
 ...
 
 but that didnt help either.   I don't see why velocity 
 should
 
 use
 
 
 250+ MB
 
 
 of memory iterating over a list ~8MB in size...
 -L
 
 On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
 
 
 
 Well, I don't have a good clue now.
 
 What about do the debugging step by step, i.e., use just
 
 static

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Nathan Bubna
)
 at
 
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at
 
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
 at
 
 org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
 at
 
 org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
 at
 
 org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
 at
 
 org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
 at
 
 org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
 at
 
 org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
 at 
 org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
 at
 
 org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
 at
 
 org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
 at
 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
 at java.lang.Thread.run(Thread.java:534)

So I suppose the question is, how effecient is 
ServletOutputStream?  When
I use an FileOutputStream, very little memory is required.

-L

On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:

Maybe you are not referring to this memory eating template 
directly from
VelocityServlet, but through some tool, #include, etc., which 
uses a
nested StringWriter and not the servlet's OutputStreamWriter 
directly.
According to your first post, the original oom exception was 
thrown by
the Velocity Struts Tiles tool...

-- Ilkka


[EMAIL PROTECTED] wrote:

Ok now I'm confused (suprise, suprise!).   I looked at the 
source for
VelocityServlet, and mergeTemplate has:

vw = (VelocityWriter) writerPool.get();

if (vw == null)
{
  vw = new VelocityWriter(new OutputStreamWriter(output, 
 encoding),4 *
  1024, true);
}
else
{
  vw.recycle(new OutputStreamWriter(output, encoding));
}
template.merge(context, vw);

===

So the VelocityServlet DOES use OutputStreamWriter already 
... so then
why does it still utilize so much memory?

-L

On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] 
wrote:


Alright, I changed the Writer to be:

OutputStreamWriter w = new OutputStreamWriter(new
FileOutputStream(test.html));

And this fixes the memory problem.

However, my application is running Velocity as a servlet, 
how should I
extend the VelocityServlet to use an OutputStreamWriter 
intead of a
StringWriter?  Should I post a different email thread about 
this?

-L

On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:


Well, Open a file, use a FileWriter.

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 06, 2005 1:48 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity 
Template

I printed out the available memory before and after I call
mergeTemplate:

Free memory before merge: 217393352
Free memory after merge: 16271392

so I would assume the StringWriter is approximately 200MB 
after the
merge.   What should I use/do instead?

-Lawrence

On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:


Why do you use StringWriter? That is cached in the memory.
How big is the StringWriter after the merge?

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, May 06, 2005 1:22 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity 
Template

Alright, I ran this little piece of code:

public static void main( String args[] ) throws Exception

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread lawrence
)
  at
  
  org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180)
  at
  
  org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at
  
  org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:171)
  at
  
  org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
  at
  
  org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172)
  at
  
  org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641)
  at
  
  org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at
  
  org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at
  
  org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174)
  at
  
  org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643)
  at
  
  org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480)
  at
  
  org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995)
  at
  
  org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223)
  at
  
  org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
  at
  
  org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
  at 
  org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:604)
  at
  
  org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:562)
  at
  
  org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
  at
  
  org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
  at java.lang.Thread.run(Thread.java:534)
 
 So I suppose the question is, how effecient is 
 ServletOutputStream?  When
 I use an FileOutputStream, very little memory is required.
 
 -L
 
 On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:
 
 Maybe you are not referring to this memory eating template 
 directly from
 VelocityServlet, but through some tool, #include, etc., 
 which uses a
 nested StringWriter and not the servlet's 
 OutputStreamWriter directly.
 According to your first post, the original oom exception 
 was thrown by
 the Velocity Struts Tiles tool...
 
 -- Ilkka
 
 
 [EMAIL PROTECTED] wrote:
 
 Ok now I'm confused (suprise, suprise!).   I looked at the 
 source for
 VelocityServlet, and mergeTemplate has:
 
 vw = (VelocityWriter) writerPool.get();
 
 if (vw == null)
 {
   vw = new VelocityWriter(new OutputStreamWriter(output, 
  encoding),4 *
   1024, true);
 }
 else
 {
   vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already 
 ... so then
 why does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL 
 PROTECTED] wrote:
 
 
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, 
 how should I
 extend the VelocityServlet to use an OutputStreamWriter 
 intead of a
 StringWriter?  Should I post a different email thread 
 about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 
 
 Well, Open a file, use a FileWriter.
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity 
 Template
 
 I printed out the available memory before and after I 
 call
 mergeTemplate:
 
 Free memory

RE: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Mike Curwen
From way back in your first email:

unless I set the tomcat JVM to use a heap size of at least 256M

I'm of two minds:

1) Is there something wrong with that size?  What I mean is, the default
heap size is fairly small, considering that most servers worth their name
have *at least* 512MB to spare.  And I'm not trying to make fun of anyone's
server here... I'm just asking: Is this now a bug, or more of a application
memory sizing/requirements issue?  p.s.  I *wish* I could run the apps I do
at work on as little as 256.

2) 150+MB just to do html pushing *does* seem extreme.  But on the other
hand, how many HTML pages have 66k+ rows?  I think most clients, never mind
servers, would start to choke on that.  So for sure, there ought to be a way
to do better.  But I go back to #1 - the TilesTool seems to 'do 90% of
everyone's jobs', and your job is an edgecase; perhaps not for you, but
certainly for me and any apps I've ever written.




 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, May 10, 2005 6:21 PM
 To: Nathan Bubna
 Cc: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 *Gasp*   Ok so I did what you suggested and when I request 
 the particular template WITHOUT using tiles, it works.   But 
 what now?  We've located that the memory problem is indeed in 
 TilesTools (probably cause it uses a BtyeArrayOutputStream), 
 but my application is heavily reliant on the use of the TilesTool ... 
 
 Suggestions?
 
 -L
 
 P.S.  I actually did get the FileOutputStream method to work 
 with Tiles, but on the page with the huge table, it broke.
 
 On Tue, May 10, 2005 at 02:35:14PM -0700, Nathan Bubna wrote:
  oops.  didn't mean to take this off the list...
  
  i'm quite skeptical that you could get the FileOutputStream 
 method to 
  work with Tiles.  you might be able extend the 
 VelocityViewServlet to 
  do something like that though.  i'm not sure what the best tactic 
  there would be.
  
  as for just requesting the particular template and not using Tiles, 
  that should be simple.  the tile being requested is just a template 
  like any other.  the TilesRequestProcessor is just making 
 an internal 
  servlet request (forward or include).  all you need to do 
 is request 
  the same template of the VVS directly.  in other words, get 
 your app 
  running, enter the URL for the template in question (or one 
 that does 
  the same thing), rather than the parent template that is 
 requesting it 
  as a tile ($tile.foo), and see what happens.
  
  On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   How would I do that?
   
   I changed the ImportSupport class to use a 
 FileOutputStream, which writes out to a temp file.   Then the 
 getString() method reads that temp file.  What happens when I 
 do this, however, is when I get to the page with the 66000 
 row table, it sits there for about 1 minute until it runs out 
 of memory.   I'm thoroughly confused!
   
   -L
   
   On Tue, May 10, 2005 at 11:31:17AM -0700, Nathan Bubna wrote:
hmm.  yeah, i don't know what to do then.  without some good 
profiling to see what is hogging the memory, it's hard to say.  
have you tried just requesting the template in question 
 directly 
with the VVS rather than trying to hold it in memory as a tile?
   
that might at least narrow down the area with the problem.
   
On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Ok I tried that, but unfortunately, it didn't do the 
 trick =(.   I verified that getResponseWriter was returning 
 an OutputStreamWriter, but it didn't help.   Maybe I'll have 
 to change TilesTool to return an FileOutputStream that writes 
 to a temp file but would that work?   Oh well, anything 
 is worth trying now!

 -L

 On Tue, May 10, 2005 at 10:44:05AM -0700, Nathan Bubna wrote:
  well, maybe you can just override the VVS's 
  getResponseWriter() method somehow to try calling/using 
  getOutputStream() on requests first.  but i'm not sure that 
  will do the trick.  it might, if it's just 
 StringWriter that 
  is the problem and the whole of the tile's content can be 
  reasonably held in memory with a 
 ByteArrayOutputStream (which 
  is what the ImportResponseWrapper uses to hold the 
 tile content if
  getOutputStream() is called instead of getWriter()).
 
  might be worth a shot at least.
 
  On 5/10/05, [EMAIL PROTECTED] 
 [EMAIL PROTECTED] wrote:
   Hm, thats interesting.  Thanks for the info.   
 What would you suggest I do?   Can I easily override a method 
 in VelocityViewServlet that fixes this problem?
  
   -L
  
   On Tue, May 10, 2005 at 10:32:40AM -0700, Nathan Bubna 
   wrote:
if you are using the TilesTool, note that it extends 
ImportSupport which uses a custom 
HttpServletResponseWrapper (an internal class called 
ImportResponseWrapper

Re: OutOfMemoryException Processing Velocity Template

2005-05-10 Thread Will Glass-Husain
You've probably already considered this - but do you really *need* 66,000 
rows?

Possibly a simpler solution might be to restructure your appoach to output 
data in smaller chunks.  Just wondering.

I assume you must be exporting to Excel or some other software - it's hard 
for me to think of a use case where a user wants to scroll down 66K rows.

WILL
- Original Message - 
From: Mike Curwen [EMAIL PROTECTED]
To: 'Velocity Users List' velocity-user@jakarta.apache.org
Sent: Tuesday, May 10, 2005 5:09 PM
Subject: RE: OutOfMemoryException Processing Velocity Template


From way back in your first email:
unless I set the tomcat JVM to use a heap size of at least 256M
I'm of two minds:
1) Is there something wrong with that size?  What I mean is, the default
heap size is fairly small, considering that most servers worth their name
have *at least* 512MB to spare.  And I'm not trying to make fun of anyone's
server here... I'm just asking: Is this now a bug, or more of a application
memory sizing/requirements issue?  p.s.  I *wish* I could run the apps I do
at work on as little as 256.
2) 150+MB just to do html pushing *does* seem extreme.  But on the other
hand, how many HTML pages have 66k+ rows?  I think most clients, never mind
servers, would start to choke on that.  So for sure, there ought to be a way
to do better.  But I go back to #1 - the TilesTool seems to 'do 90% of
everyone's jobs', and your job is an edgecase; perhaps not for you, but
certainly for me and any apps I've ever written.


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 10, 2005 6:21 PM
To: Nathan Bubna
Cc: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template
*Gasp*   Ok so I did what you suggested and when I request
the particular template WITHOUT using tiles, it works.   But
what now?  We've located that the memory problem is indeed in
TilesTools (probably cause it uses a BtyeArrayOutputStream),
but my application is heavily reliant on the use of the TilesTool ...
Suggestions?
-L
P.S.  I actually did get the FileOutputStream method to work
with Tiles, but on the page with the huge table, it broke.
On Tue, May 10, 2005 at 02:35:14PM -0700, Nathan Bubna wrote:
 oops.  didn't mean to take this off the list...

 i'm quite skeptical that you could get the FileOutputStream
method to
 work with Tiles.  you might be able extend the
VelocityViewServlet to
 do something like that though.  i'm not sure what the best tactic
 there would be.

 as for just requesting the particular template and not using Tiles,
 that should be simple.  the tile being requested is just a template
 like any other.  the TilesRequestProcessor is just making
an internal
 servlet request (forward or include).  all you need to do
is request
 the same template of the VVS directly.  in other words, get
your app
 running, enter the URL for the template in question (or one
that does
 the same thing), rather than the parent template that is
requesting it
 as a tile ($tile.foo), and see what happens.

 On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  How would I do that?
 
  I changed the ImportSupport class to use a
FileOutputStream, which writes out to a temp file.   Then the
getString() method reads that temp file.  What happens when I
do this, however, is when I get to the page with the 66000
row table, it sits there for about 1 minute until it runs out
of memory.   I'm thoroughly confused!
 
  -L
 
  On Tue, May 10, 2005 at 11:31:17AM -0700, Nathan Bubna wrote:
   hmm.  yeah, i don't know what to do then.  without some good
   profiling to see what is hogging the memory, it's hard to say.
   have you tried just requesting the template in question
directly
   with the VVS rather than trying to hold it in memory as a tile?
  
   that might at least narrow down the area with the problem.
  
   On 5/10/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Ok I tried that, but unfortunately, it didn't do the
trick =(.   I verified that getResponseWriter was returning
an OutputStreamWriter, but it didn't help.   Maybe I'll have
to change TilesTool to return an FileOutputStream that writes
to a temp file but would that work?   Oh well, anything
is worth trying now!
   
-L
   
On Tue, May 10, 2005 at 10:44:05AM -0700, Nathan Bubna wrote:
 well, maybe you can just override the VVS's
 getResponseWriter() method somehow to try calling/using
 getOutputStream() on requests first.  but i'm not sure that
 will do the trick.  it might, if it's just
StringWriter that
 is the problem and the whole of the tile's content can be
 reasonably held in memory with a
ByteArrayOutputStream (which
 is what the ImportResponseWrapper uses to hold the
tile content if
 getOutputStream() is called instead of getWriter()).

 might be worth a shot at least.

 On 5/10/05, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
  Hm, thats interesting.  Thanks

Re: OutOfMemoryException Processing Velocity Template

2005-05-09 Thread lawrence
)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:679)
at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:619)
at java.lang.Thread.run(Thread.java:534)

So I suppose the question is, how effecient is ServletOutputStream?  When I use 
an FileOutputStream, very little memory is required.

-L

On Sat, May 07, 2005 at 11:43:03AM +0300, Ilkka Priha wrote:
 Maybe you are not referring to this memory eating template directly from 
 VelocityServlet, but through some tool, #include, etc., which uses a nested 
 StringWriter and not the servlet's OutputStreamWriter directly. According 
 to your first post, the original oom exception was thrown by the Velocity 
 Struts Tiles tool...
 
 -- Ilkka
 
 
 [EMAIL PROTECTED] wrote:
 Ok now I'm confused (suprise, suprise!).   I looked at the source for 
 VelocityServlet, and mergeTemplate has:
 
 vw = (VelocityWriter) writerPool.get();
 
 if (vw == null)
 {
 vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 * 
 1024, true);
 }
 else
 {
 vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already ... so then why 
 does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
 
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new 
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, how should I 
 extend the VelocityServlet to use an OutputStreamWriter intead of a 
 StringWriter?  Should I post a different email thread about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 
 Well, Open a file, use a FileWriter.
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 I printed out the available memory before and after I call
 mergeTemplate:
 
 Free memory before merge: 217393352
 Free memory after merge: 16271392
 
 so I would assume the StringWriter is approximately 200MB after the
 merge.   What should I use/do instead?   
 
 -Lawrence
 
 On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
 
 Why do you use StringWriter? That is cached in the memory.
 How big is the StringWriter after the merge?
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:22 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 Alright, I ran this little piece of code:
 
 public static void main( String args[] ) throws Exception
{
/* first, we init the runtime engine.  Defaults are fine. */
 
Velocity.init();
 
/* lets make a Context and put data into it */
 
VelocityContext context = new VelocityContext();
 
List results = ReportBean.runLargeReport();

context.put(List, results);

/* lets render a template */
 
StringWriter w = new StringWriter();
 
Velocity.mergeTemplate(/myfile.vm, context, w );
System.out.println( template :  + w );
 
/* lets make our own string to render */
}
 
 results is a List of 66000 objects and requires about 8megs of memory.
 The mergeTemplate requires at least 230 MB of memory.   Any
 suggestions?
 
 -L
 
 On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
 
 Hi, 
 
 I guess the writer Ilkka talked about is when using Velocity as a
 standalone template engine.
 
 Right now I don't have a good clue, could you run Velocity as a
 standalone template engine and render the page to see if there is a
 huge memory usage?
 
 Cheers,
 
 Jian
 
 On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 Sorry, I'm not sure what you mean by what kind of writer I'm
 
 using.   Where would I find out?   How would I change this (to maybe a
 StringBuffer writer?)
 
 Also, each column contains a String that is at most, 200
 
 characters,
 
 most are closer to 10-20.   There are a total of 10 columns.
 
 Thanks.
 
 -Lawrence
 
 On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
 
 What kind of writer are you using and how long are the items? 66
 
 000 HTML
 
 table rows with 5 numeric columns consumes about 32 MB when
 
 buffered into a
 
 string writer. If the items are longer, it takes much more
 
 memory.
 
 -- Ilkka
 
 
 [EMAIL PROTECTED] wrote:
 
 I tried putting static HTML in the #foreach loop, same problem.
 
 Then I
 
 tried setting the large list as a local varible:
 
 #set ($localList = $List)
 #foreach($row in $localList)
 ...
 
 but that didnt help either.   I don't see why velocity should
 
 use
 
 250+ MB
 
 of memory iterating over a list ~8MB in size...
 -L
 
 On Thu, May 05, 2005 at 02:56:28PM -0700, jian

Re: OutOfMemoryException Processing Velocity Template

2005-05-07 Thread Ilkka Priha
Maybe you are not referring to this memory eating template directly from 
VelocityServlet, but through some tool, #include, etc., which uses a nested 
StringWriter and not the servlet's OutputStreamWriter directly. According to 
your first post, the original oom exception was thrown by the Velocity Struts 
Tiles tool...

-- Ilkka
[EMAIL PROTECTED] wrote:
Ok now I'm confused (suprise, suprise!).   I looked at the source for 
VelocityServlet, and mergeTemplate has:
vw = (VelocityWriter) writerPool.get();
if (vw == null)
{
vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 * 1024, 
true);
}
else
{
vw.recycle(new OutputStreamWriter(output, encoding));
}
template.merge(context, vw);
===
So the VelocityServlet DOES use OutputStreamWriter already ... so then why does 
it still utilize so much memory?
-L
On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
Alright, I changed the Writer to be:
OutputStreamWriter w = new OutputStreamWriter(new 
FileOutputStream(test.html));
And this fixes the memory problem.
However, my application is running Velocity as a servlet, how should I extend 
the VelocityServlet to use an OutputStreamWriter intead of a StringWriter?  
Should I post a different email thread about this?
-L
On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
Well, Open a file, use a FileWriter.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 1:48 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

I printed out the available memory before and after I call
mergeTemplate:
Free memory before merge: 217393352
Free memory after merge: 16271392
so I would assume the StringWriter is approximately 200MB after the
merge.   What should I use/do instead?   

-Lawrence
On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
Why do you use StringWriter? That is cached in the memory.
How big is the StringWriter after the merge?
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 1:22 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

Alright, I ran this little piece of code:
public static void main( String args[] ) throws Exception
   {
   /* first, we init the runtime engine.  Defaults are fine. */
   Velocity.init();
   /* lets make a Context and put data into it */
   VelocityContext context = new VelocityContext();
   List results = ReportBean.runLargeReport();
   
   context.put(List, results);
   
   /* lets render a template */

   StringWriter w = new StringWriter();
   Velocity.mergeTemplate(/myfile.vm, context, w );
   System.out.println( template :  + w );
   /* lets make our own string to render */
   }
results is a List of 66000 objects and requires about 8megs of memory.
The mergeTemplate requires at least 230 MB of memory.   Any
suggestions?
-L
On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
Hi, 

I guess the writer Ilkka talked about is when using Velocity as a
standalone template engine.
Right now I don't have a good clue, could you run Velocity as a
standalone template engine and render the page to see if there is a
huge memory usage?
Cheers,
Jian
On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Sorry, I'm not sure what you mean by what kind of writer I'm
using.   Where would I find out?   How would I change this (to maybe a
StringBuffer writer?)
Also, each column contains a String that is at most, 200
characters,
most are closer to 10-20.   There are a total of 10 columns.
Thanks.
-Lawrence
On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
What kind of writer are you using and how long are the items? 66
000 HTML
table rows with 5 numeric columns consumes about 32 MB when
buffered into a
string writer. If the items are longer, it takes much more
memory.
-- Ilkka
[EMAIL PROTECTED] wrote:
I tried putting static HTML in the #foreach loop, same problem.
Then I
tried setting the large list as a local varible:
#set ($localList = $List)
#foreach($row in $localList)
...
but that didnt help either.   I don't see why velocity should
use
250+ MB
of memory iterating over a list ~8MB in size...
-L
On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:

Well, I don't have a good clue now.
What about do the debugging step by step, i.e., use just
static
html
in your #foreach loop? Will that blow up the memory?
Cheers,
Jian

On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Thanks for the suggestion.   I tried putting that, along with
file.resource.loader.cache = true
in my velocity.properties file.   Both did not work.   Any
other
suggestions?
Thanks!
-L
On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:

Hi,
This maybe because you haven't turned on template caching. I
had
similar problem before, and even if I only used
evaluate(...)
method
and load the template using my own java

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread jian chen
Well, I don't have a good clue now. 

What about do the debugging step by step, i.e., use just static html
in your #foreach loop? Will that blow up the memory?

Cheers,

Jian



On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Thanks for the suggestion.   I tried putting that, along with
 
 file.resource.loader.cache = true
 
 in my velocity.properties file.   Both did not work.   Any other suggestions?
 
 Thanks!
 
 -L
 
 On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
  Hi,
 
  This maybe because you haven't turned on template caching. I had
  similar problem before, and even if I only used evaluate(...) method
  and load the template using my own java program, it happened when the
  for loop is lot of iterations.
 
  The bottom line for my problem is I need to turn on template caching,
  so, velocity will not try to cache the objects it parsed during each
  time of the iteration.
 
  I did:
  ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
 
  where ri is a runtime instance.
 
  Will this fix your issue?
 
  Cheers,
 
  Jian
 
 
  On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   I am getting an OutOfMemoryException:
  
   org.apache.velocity.exception.MethodInvocationException: Invocation of 
   method 'get' in  class org.apache.velocity.tools.struts.TilesTool threw 
   exception class java.lang.OutOfMemoryError : null
  
   when I am creating a large velocity file.  The vm file itself is fairly 
   small, but this piece of velocity is causing the exception:
  
   #foreach($row in $List)
   tr
   td height=20 class=tbltxt$!row.item1/td
   td class=tbltxt$!row.item2/td
   td class=tbltxt$!row.item3/td
   td class=tbltxt$!row.item4/td
   td class=tbltxt$!number.format('currency', $!row.item5)/td
   /tr
   #end
  
   List is a list of relatively small objects (5-6 Strings, a couple of 
   BigDecimals), but the List itself contains approximately 66,000 entries.  
   Unfortunately, unless I set the tomcat JVM to use a heap size of at least 
   256M, this velocity template throws an OutOfMemoryException when it is 
   being processed.
  
   Any suggestions?
  
   Thanks.
  
   -L
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
I tried putting static HTML in the #foreach loop, same problem.  Then I tried 
setting the large list as a local varible:

#set ($localList = $List)
#foreach($row in $localList)
...

but that didnt help either.   I don't see why velocity should use 250+ MB of 
memory iterating over a list ~8MB in size...  

-L

On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
 Well, I don't have a good clue now. 
 
 What about do the debugging step by step, i.e., use just static html
 in your #foreach loop? Will that blow up the memory?
 
 Cheers,
 
 Jian
 
 
 
 On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Thanks for the suggestion.   I tried putting that, along with
  
  file.resource.loader.cache = true
  
  in my velocity.properties file.   Both did not work.   Any other 
  suggestions?
  
  Thanks!
  
  -L
  
  On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
   Hi,
  
   This maybe because you haven't turned on template caching. I had
   similar problem before, and even if I only used evaluate(...) method
   and load the template using my own java program, it happened when the
   for loop is lot of iterations.
  
   The bottom line for my problem is I need to turn on template caching,
   so, velocity will not try to cache the objects it parsed during each
   time of the iteration.
  
   I did:
   ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
  
   where ri is a runtime instance.
  
   Will this fix your issue?
  
   Cheers,
  
   Jian
  
  
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I am getting an OutOfMemoryException:
   
org.apache.velocity.exception.MethodInvocationException: Invocation of 
method 'get' in  class org.apache.velocity.tools.struts.TilesTool threw 
exception class java.lang.OutOfMemoryError : null
   
when I am creating a large velocity file.  The vm file itself is fairly 
small, but this piece of velocity is causing the exception:
   
#foreach($row in $List)
tr
td height=20 class=tbltxt$!row.item1/td
td class=tbltxt$!row.item2/td
td class=tbltxt$!row.item3/td
td class=tbltxt$!row.item4/td
td class=tbltxt$!number.format('currency', $!row.item5)/td
/tr
#end
   
List is a list of relatively small objects (5-6 Strings, a couple of 
BigDecimals), but the List itself contains approximately 66,000 
entries.  Unfortunately, unless I set the tomcat JVM to use a heap size 
of at least 256M, this velocity template throws an OutOfMemoryException 
when it is being processed.
   
Any suggestions?
   
Thanks.
   
-L
   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   
  
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
Ok, I think I've located the problem, although I can't think of a reasonable 
solution.   

Basically, if I make the #foreach loop EMPTY, it uses barely any memory:
#foreach($row in $List)

#end

As I add more to the body of the #foreach:
#foreach($row in $List)
tr
/tr
#end

The amount of memory starts to grow (exponentially?).  

I did some playing around, and found that this:

#foreach($row in $List)
tr
td height=20 class=tbltxt$!row.item1/td
td class=tbltxt$!row.item2/td
td class=tbltxt$!row.item3/td
/tr
#end

Uses approximately 100+ MB of memory.   Something is going on ... but I have no 
clue what it is.

-L


On Fri, May 06, 2005 at 10:36:25AM -0700, [EMAIL PROTECTED] wrote:
 I tried putting static HTML in the #foreach loop, same problem.  Then I tried 
 setting the large list as a local varible:
 
 #set ($localList = $List)
 #foreach($row in $localList)
 ...
 
 but that didnt help either.   I don't see why velocity should use 250+ MB of 
 memory iterating over a list ~8MB in size...  
 
 -L
 
 On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
  Well, I don't have a good clue now. 
  
  What about do the debugging step by step, i.e., use just static html
  in your #foreach loop? Will that blow up the memory?
  
  Cheers,
  
  Jian
  
  
  
  On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   Thanks for the suggestion.   I tried putting that, along with
   
   file.resource.loader.cache = true
   
   in my velocity.properties file.   Both did not work.   Any other 
   suggestions?
   
   Thanks!
   
   -L
   
   On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
Hi,
   
This maybe because you haven't turned on template caching. I had
similar problem before, and even if I only used evaluate(...) method
and load the template using my own java program, it happened when the
for loop is lot of iterations.
   
The bottom line for my problem is I need to turn on template caching,
so, velocity will not try to cache the objects it parsed during each
time of the iteration.
   
I did:
ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
   
where ri is a runtime instance.
   
Will this fix your issue?
   
Cheers,
   
Jian
   
   
On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 I am getting an OutOfMemoryException:

 org.apache.velocity.exception.MethodInvocationException: Invocation 
 of method 'get' in  class org.apache.velocity.tools.struts.TilesTool 
 threw exception class java.lang.OutOfMemoryError : null

 when I am creating a large velocity file.  The vm file itself is 
 fairly small, but this piece of velocity is causing the exception:

 #foreach($row in $List)
 tr
 td height=20 class=tbltxt$!row.item1/td
 td class=tbltxt$!row.item2/td
 td class=tbltxt$!row.item3/td
 td class=tbltxt$!row.item4/td
 td class=tbltxt$!number.format('currency', $!row.item5)/td
 /tr
 #end

 List is a list of relatively small objects (5-6 Strings, a couple of 
 BigDecimals), but the List itself contains approximately 66,000 
 entries.  Unfortunately, unless I set the tomcat JVM to use a heap 
 size of at least 256M, this velocity template throws an 
 OutOfMemoryException when it is being processed.

 Any suggestions?

 Thanks.

 -L

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]


   
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
   
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread Ilkka Priha
What kind of writer are you using and how long are the items? 66 000 HTML table 
rows with 5 numeric columns consumes about 32 MB when buffered into a string 
writer. If the items are longer, it takes much more memory.

-- Ilkka
[EMAIL PROTECTED] wrote:
I tried putting static HTML in the #foreach loop, same problem.  Then I tried setting the 
large list as a local varible:
#set ($localList = $List)
#foreach($row in $localList)
...
but that didnt help either.   I don't see why velocity should use 250+ MB of memory iterating over a list ~8MB in size...  

-L
On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
Well, I don't have a good clue now. 

What about do the debugging step by step, i.e., use just static html
in your #foreach loop? Will that blow up the memory?
Cheers,
Jian

On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Thanks for the suggestion.   I tried putting that, along with
file.resource.loader.cache = true
in my velocity.properties file.   Both did not work.   Any other suggestions?
Thanks!
-L
On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
Hi,
This maybe because you haven't turned on template caching. I had
similar problem before, and even if I only used evaluate(...) method
and load the template using my own java program, it happened when the
for loop is lot of iterations.
The bottom line for my problem is I need to turn on template caching,
so, velocity will not try to cache the objects it parsed during each
time of the iteration.
I did:
ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
where ri is a runtime instance.
Will this fix your issue?
Cheers,
Jian
On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
I am getting an OutOfMemoryException:
org.apache.velocity.exception.MethodInvocationException: Invocation of method 
'get' in  class org.apache.velocity.tools.struts.TilesTool threw exception 
class java.lang.OutOfMemoryError : null
when I am creating a large velocity file.  The vm file itself is fairly small, 
but this piece of velocity is causing the exception:
#foreach($row in $List)
tr
td height=20 class=tbltxt$!row.item1/td
td class=tbltxt$!row.item2/td
td class=tbltxt$!row.item3/td
td class=tbltxt$!row.item4/td
td class=tbltxt$!number.format('currency', $!row.item5)/td
/tr
#end
List is a list of relatively small objects (5-6 Strings, a couple of 
BigDecimals), but the List itself contains approximately 66,000 entries.  
Unfortunately, unless I set the tomcat JVM to use a heap size of at least 256M, 
this velocity template throws an OutOfMemoryException when it is being 
processed.
Any suggestions?
Thanks.
-L
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
Sorry, I'm not sure what you mean by what kind of writer I'm using.   Where 
would I find out?   How would I change this (to maybe a StringBuffer writer?)

Also, each column contains a String that is at most, 200 characters, most are 
closer to 10-20.   There are a total of 10 columns.

Thanks.

-Lawrence

On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
 What kind of writer are you using and how long are the items? 66 000 HTML 
 table rows with 5 numeric columns consumes about 32 MB when buffered into a 
 string writer. If the items are longer, it takes much more memory.
 
 -- Ilkka
 
 
 [EMAIL PROTECTED] wrote:
 I tried putting static HTML in the #foreach loop, same problem.  Then I 
 tried setting the large list as a local varible:
 
 #set ($localList = $List)
 #foreach($row in $localList)
 ...
 
 but that didnt help either.   I don't see why velocity should use 250+ MB 
 of memory iterating over a list ~8MB in size...  
 -L
 
 On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
 
 Well, I don't have a good clue now. 
 
 What about do the debugging step by step, i.e., use just static html
 in your #foreach loop? Will that blow up the memory?
 
 Cheers,
 
 Jian
 
 
 
 On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 Thanks for the suggestion.   I tried putting that, along with
 
 file.resource.loader.cache = true
 
 in my velocity.properties file.   Both did not work.   Any other 
 suggestions?
 
 Thanks!
 
 -L
 
 On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
 
 Hi,
 
 This maybe because you haven't turned on template caching. I had
 similar problem before, and even if I only used evaluate(...) method
 and load the template using my own java program, it happened when the
 for loop is lot of iterations.
 
 The bottom line for my problem is I need to turn on template caching,
 so, velocity will not try to cache the objects it parsed during each
 time of the iteration.
 
 I did:
 ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
 
 where ri is a runtime instance.
 
 Will this fix your issue?
 
 Cheers,
 
 Jian
 
 
 On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 I am getting an OutOfMemoryException:
 
 org.apache.velocity.exception.MethodInvocationException: Invocation of 
 method 'get' in  class org.apache.velocity.tools.struts.TilesTool 
 threw exception class java.lang.OutOfMemoryError : null
 
 when I am creating a large velocity file.  The vm file itself is 
 fairly small, but this piece of velocity is causing the exception:
 
 #foreach($row in $List)
 tr
 td height=20 class=tbltxt$!row.item1/td
 td class=tbltxt$!row.item2/td
 td class=tbltxt$!row.item3/td
 td class=tbltxt$!row.item4/td
 td class=tbltxt$!number.format('currency', $!row.item5)/td
 /tr
 #end
 
 List is a list of relatively small objects (5-6 Strings, a couple of 
 BigDecimals), but the List itself contains approximately 66,000 
 entries.  Unfortunately, unless I set the tomcat JVM to use a heap 
 size of at least 256M, this velocity template throws an 
 OutOfMemoryException when it is being processed.
 
 Any suggestions?
 
 Thanks.
 
 -L
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 .
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread jian chen
Hi, 

I guess the writer Ilkka talked about is when using Velocity as a
standalone template engine.

Right now I don't have a good clue, could you run Velocity as a
standalone template engine and render the page to see if there is a
huge memory usage?

Cheers,

Jian

On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Sorry, I'm not sure what you mean by what kind of writer I'm using.   Where 
 would I find out?   How would I change this (to maybe a StringBuffer writer?)
 
 Also, each column contains a String that is at most, 200 characters, most are 
 closer to 10-20.   There are a total of 10 columns.
 
 Thanks.
 
 -Lawrence
 
 On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
  What kind of writer are you using and how long are the items? 66 000 HTML
  table rows with 5 numeric columns consumes about 32 MB when buffered into a
  string writer. If the items are longer, it takes much more memory.
 
  -- Ilkka
 
 
  [EMAIL PROTECTED] wrote:
  I tried putting static HTML in the #foreach loop, same problem.  Then I
  tried setting the large list as a local varible:
  
  #set ($localList = $List)
  #foreach($row in $localList)
  ...
  
  but that didnt help either.   I don't see why velocity should use 250+ MB
  of memory iterating over a list ~8MB in size...
  -L
  
  On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
  
  Well, I don't have a good clue now.
  
  What about do the debugging step by step, i.e., use just static html
  in your #foreach loop? Will that blow up the memory?
  
  Cheers,
  
  Jian
  
  
  
  On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  
  Thanks for the suggestion.   I tried putting that, along with
  
  file.resource.loader.cache = true
  
  in my velocity.properties file.   Both did not work.   Any other
  suggestions?
  
  Thanks!
  
  -L
  
  On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
  
  Hi,
  
  This maybe because you haven't turned on template caching. I had
  similar problem before, and even if I only used evaluate(...) method
  and load the template using my own java program, it happened when the
  for loop is lot of iterations.
  
  The bottom line for my problem is I need to turn on template caching,
  so, velocity will not try to cache the objects it parsed during each
  time of the iteration.
  
  I did:
  ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
  
  where ri is a runtime instance.
  
  Will this fix your issue?
  
  Cheers,
  
  Jian
  
  
  On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  
  I am getting an OutOfMemoryException:
  
  org.apache.velocity.exception.MethodInvocationException: Invocation of
  method 'get' in  class org.apache.velocity.tools.struts.TilesTool
  threw exception class java.lang.OutOfMemoryError : null
  
  when I am creating a large velocity file.  The vm file itself is
  fairly small, but this piece of velocity is causing the exception:
  
  #foreach($row in $List)
  tr
  td height=20 class=tbltxt$!row.item1/td
  td class=tbltxt$!row.item2/td
  td class=tbltxt$!row.item3/td
  td class=tbltxt$!row.item4/td
  td class=tbltxt$!number.format('currency', $!row.item5)/td
  /tr
  #end
  
  List is a list of relatively small objects (5-6 Strings, a couple of
  BigDecimals), but the List itself contains approximately 66,000
  entries.  Unfortunately, unless I set the tomcat JVM to use a heap
  size of at least 256M, this velocity template throws an
  OutOfMemoryException when it is being processed.
  
  Any suggestions?
  
  Thanks.
  
  -L
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
  
  .
  
 
 
  -
  To unsubscribe, e-mail: [EMAIL PROTECTED]
  For additional commands, e-mail: [EMAIL PROTECTED]
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
Alright, I ran this little piece of code:

public static void main( String args[] ) throws Exception
{
/* first, we init the runtime engine.  Defaults are fine. */

Velocity.init();

/* lets make a Context and put data into it */

VelocityContext context = new VelocityContext();

List results = ReportBean.runLargeReport();

context.put(List, results);

/* lets render a template */

StringWriter w = new StringWriter();

Velocity.mergeTemplate(/myfile.vm, context, w );
System.out.println( template :  + w );

/* lets make our own string to render */
}

results is a List of 66000 objects and requires about 8megs of memory.   The 
mergeTemplate requires at least 230 MB of memory.   Any suggestions?

-L

On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
 Hi, 
 
 I guess the writer Ilkka talked about is when using Velocity as a
 standalone template engine.
 
 Right now I don't have a good clue, could you run Velocity as a
 standalone template engine and render the page to see if there is a
 huge memory usage?
 
 Cheers,
 
 Jian
 
 On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Sorry, I'm not sure what you mean by what kind of writer I'm using.   
  Where would I find out?   How would I change this (to maybe a StringBuffer 
  writer?)
  
  Also, each column contains a String that is at most, 200 characters, most 
  are closer to 10-20.   There are a total of 10 columns.
  
  Thanks.
  
  -Lawrence
  
  On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
   What kind of writer are you using and how long are the items? 66 000 HTML
   table rows with 5 numeric columns consumes about 32 MB when buffered into 
   a
   string writer. If the items are longer, it takes much more memory.
  
   -- Ilkka
  
  
   [EMAIL PROTECTED] wrote:
   I tried putting static HTML in the #foreach loop, same problem.  Then I
   tried setting the large list as a local varible:
   
   #set ($localList = $List)
   #foreach($row in $localList)
   ...
   
   but that didnt help either.   I don't see why velocity should use 250+ MB
   of memory iterating over a list ~8MB in size...
   -L
   
   On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
   
   Well, I don't have a good clue now.
   
   What about do the debugging step by step, i.e., use just static html
   in your #foreach loop? Will that blow up the memory?
   
   Cheers,
   
   Jian
   
   
   
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
   Thanks for the suggestion.   I tried putting that, along with
   
   file.resource.loader.cache = true
   
   in my velocity.properties file.   Both did not work.   Any other
   suggestions?
   
   Thanks!
   
   -L
   
   On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
   
   Hi,
   
   This maybe because you haven't turned on template caching. I had
   similar problem before, and even if I only used evaluate(...) method
   and load the template using my own java program, it happened when the
   for loop is lot of iterations.
   
   The bottom line for my problem is I need to turn on template caching,
   so, velocity will not try to cache the objects it parsed during each
   time of the iteration.
   
   I did:
   ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);
   
   where ri is a runtime instance.
   
   Will this fix your issue?
   
   Cheers,
   
   Jian
   
   
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
   I am getting an OutOfMemoryException:
   
   org.apache.velocity.exception.MethodInvocationException: Invocation 
   of
   method 'get' in  class org.apache.velocity.tools.struts.TilesTool
   threw exception class java.lang.OutOfMemoryError : null
   
   when I am creating a large velocity file.  The vm file itself is
   fairly small, but this piece of velocity is causing the exception:
   
   #foreach($row in $List)
   tr
   td height=20 class=tbltxt$!row.item1/td
   td class=tbltxt$!row.item2/td
   td class=tbltxt$!row.item3/td
   td class=tbltxt$!row.item4/td
   td class=tbltxt$!number.format('currency', $!row.item5)/td
   /tr
   #end
   
   List is a list of relatively small objects (5-6 Strings, a couple of
   BigDecimals), but the List itself contains approximately 66,000
   entries.  Unfortunately, unless I set the tomcat JVM to use a heap
   size of at least 256M, this velocity template throws an
   OutOfMemoryException when it is being processed.
   
   Any suggestions?
   
   Thanks.
   
   -L
   
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
   
   
   
   -
   To unsubscribe, e-mail: [EMAIL PROTECTED]
   For additional commands, e-mail: [EMAIL PROTECTED]
   
   -

RE: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread David You
Why do you use StringWriter? That is cached in the memory.
How big is the StringWriter after the merge?

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 1:22 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

Alright, I ran this little piece of code:

public static void main( String args[] ) throws Exception
{
/* first, we init the runtime engine.  Defaults are fine. */

Velocity.init();

/* lets make a Context and put data into it */

VelocityContext context = new VelocityContext();

List results = ReportBean.runLargeReport();

context.put(List, results);

/* lets render a template */

StringWriter w = new StringWriter();

Velocity.mergeTemplate(/myfile.vm, context, w );
System.out.println( template :  + w );

/* lets make our own string to render */
}

results is a List of 66000 objects and requires about 8megs of memory.
The mergeTemplate requires at least 230 MB of memory.   Any
suggestions?

-L

On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
 Hi, 
 
 I guess the writer Ilkka talked about is when using Velocity as a
 standalone template engine.
 
 Right now I don't have a good clue, could you run Velocity as a
 standalone template engine and render the page to see if there is a
 huge memory usage?
 
 Cheers,
 
 Jian
 
 On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
  Sorry, I'm not sure what you mean by what kind of writer I'm
using.   Where would I find out?   How would I change this (to maybe a
StringBuffer writer?)
  
  Also, each column contains a String that is at most, 200 characters,
most are closer to 10-20.   There are a total of 10 columns.
  
  Thanks.
  
  -Lawrence
  
  On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
   What kind of writer are you using and how long are the items? 66
000 HTML
   table rows with 5 numeric columns consumes about 32 MB when
buffered into a
   string writer. If the items are longer, it takes much more memory.
  
   -- Ilkka
  
  
   [EMAIL PROTECTED] wrote:
   I tried putting static HTML in the #foreach loop, same problem.
Then I
   tried setting the large list as a local varible:
   
   #set ($localList = $List)
   #foreach($row in $localList)
   ...
   
   but that didnt help either.   I don't see why velocity should use
250+ MB
   of memory iterating over a list ~8MB in size...
   -L
   
   On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
   
   Well, I don't have a good clue now.
   
   What about do the debugging step by step, i.e., use just static
html
   in your #foreach loop? Will that blow up the memory?
   
   Cheers,
   
   Jian
   
   
   
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
   Thanks for the suggestion.   I tried putting that, along with
   
   file.resource.loader.cache = true
   
   in my velocity.properties file.   Both did not work.   Any
other
   suggestions?
   
   Thanks!
   
   -L
   
   On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
   
   Hi,
   
   This maybe because you haven't turned on template caching. I
had
   similar problem before, and even if I only used evaluate(...)
method
   and load the template using my own java program, it happened
when the
   for loop is lot of iterations.
   
   The bottom line for my problem is I need to turn on template
caching,
   so, velocity will not try to cache the objects it parsed
during each
   time of the iteration.
   
   I did:
   ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE,
true);
   
   where ri is a runtime instance.
   
   Will this fix your issue?
   
   Cheers,
   
   Jian
   
   
   On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   
   I am getting an OutOfMemoryException:
   
   org.apache.velocity.exception.MethodInvocationException:
Invocation of
   method 'get' in  class
org.apache.velocity.tools.struts.TilesTool
   threw exception class java.lang.OutOfMemoryError : null
   
   when I am creating a large velocity file.  The vm file itself
is
   fairly small, but this piece of velocity is causing the
exception:
   
   #foreach($row in $List)
   tr
   td height=20 class=tbltxt$!row.item1/td
   td class=tbltxt$!row.item2/td
   td class=tbltxt$!row.item3/td
   td class=tbltxt$!row.item4/td
   td class=tbltxt$!number.format('currency',
$!row.item5)/td
   /tr
   #end
   
   List is a list of relatively small objects (5-6 Strings, a
couple of
   BigDecimals), but the List itself contains approximately
66,000
   entries.  Unfortunately, unless I set the tomcat JVM to use a
heap
   size of at least 256M, this velocity template throws an
   OutOfMemoryException when it is being processed.
   
   Any suggestions?
   
   Thanks.
   
   -L
   
  
---
--
   To unsubscribe, e-mail:
[EMAIL PROTECTED]
   For additional

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
I printed out the available memory before and after I call mergeTemplate:

Free memory before merge: 217393352
Free memory after merge: 16271392

so I would assume the StringWriter is approximately 200MB after the merge.   
What should I use/do instead?   

-Lawrence

On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
 Why do you use StringWriter? That is cached in the memory.
 How big is the StringWriter after the merge?
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:22 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 Alright, I ran this little piece of code:
 
 public static void main( String args[] ) throws Exception
 {
 /* first, we init the runtime engine.  Defaults are fine. */
 
 Velocity.init();
 
 /* lets make a Context and put data into it */
 
 VelocityContext context = new VelocityContext();
 
 List results = ReportBean.runLargeReport();
 
 context.put(List, results);
 
 /* lets render a template */
 
 StringWriter w = new StringWriter();
 
 Velocity.mergeTemplate(/myfile.vm, context, w );
 System.out.println( template :  + w );
 
 /* lets make our own string to render */
 }
 
 results is a List of 66000 objects and requires about 8megs of memory.
 The mergeTemplate requires at least 230 MB of memory.   Any
 suggestions?
 
 -L
 
 On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
  Hi, 
  
  I guess the writer Ilkka talked about is when using Velocity as a
  standalone template engine.
  
  Right now I don't have a good clue, could you run Velocity as a
  standalone template engine and render the page to see if there is a
  huge memory usage?
  
  Cheers,
  
  Jian
  
  On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   Sorry, I'm not sure what you mean by what kind of writer I'm
 using.   Where would I find out?   How would I change this (to maybe a
 StringBuffer writer?)
   
   Also, each column contains a String that is at most, 200 characters,
 most are closer to 10-20.   There are a total of 10 columns.
   
   Thanks.
   
   -Lawrence
   
   On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
What kind of writer are you using and how long are the items? 66
 000 HTML
table rows with 5 numeric columns consumes about 32 MB when
 buffered into a
string writer. If the items are longer, it takes much more memory.
   
-- Ilkka
   
   
[EMAIL PROTECTED] wrote:
I tried putting static HTML in the #foreach loop, same problem.
 Then I
tried setting the large list as a local varible:

#set ($localList = $List)
#foreach($row in $localList)
...

but that didnt help either.   I don't see why velocity should use
 250+ MB
of memory iterating over a list ~8MB in size...
-L

On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:

Well, I don't have a good clue now.

What about do the debugging step by step, i.e., use just static
 html
in your #foreach loop? Will that blow up the memory?

Cheers,

Jian



On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Thanks for the suggestion.   I tried putting that, along with

file.resource.loader.cache = true

in my velocity.properties file.   Both did not work.   Any
 other
suggestions?

Thanks!

-L

On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:

Hi,

This maybe because you haven't turned on template caching. I
 had
similar problem before, and even if I only used evaluate(...)
 method
and load the template using my own java program, it happened
 when the
for loop is lot of iterations.

The bottom line for my problem is I need to turn on template
 caching,
so, velocity will not try to cache the objects it parsed
 during each
time of the iteration.

I did:
ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE,
 true);

where ri is a runtime instance.

Will this fix your issue?

Cheers,

Jian


On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

I am getting an OutOfMemoryException:

org.apache.velocity.exception.MethodInvocationException:
 Invocation of
method 'get' in  class
 org.apache.velocity.tools.struts.TilesTool
threw exception class java.lang.OutOfMemoryError : null

when I am creating a large velocity file.  The vm file itself
 is
fairly small, but this piece of velocity is causing the
 exception:

#foreach($row in $List)
tr
td height=20 class=tbltxt$!row.item1/td
td class=tbltxt$!row.item2/td
td class=tbltxt$!row.item3/td
td class=tbltxt$!row.item4/td
td class=tbltxt$!number.format('currency',
 $!row.item5)/td
/tr
#end

RE: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread David You
Well, Open a file, use a FileWriter.

David


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 1:48 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

I printed out the available memory before and after I call
mergeTemplate:

Free memory before merge: 217393352
Free memory after merge: 16271392

so I would assume the StringWriter is approximately 200MB after the
merge.   What should I use/do instead?   

-Lawrence

On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
 Why do you use StringWriter? That is cached in the memory.
 How big is the StringWriter after the merge?
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:22 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 Alright, I ran this little piece of code:
 
 public static void main( String args[] ) throws Exception
 {
 /* first, we init the runtime engine.  Defaults are fine. */
 
 Velocity.init();
 
 /* lets make a Context and put data into it */
 
 VelocityContext context = new VelocityContext();
 
 List results = ReportBean.runLargeReport();
 
 context.put(List, results);
 
 /* lets render a template */
 
 StringWriter w = new StringWriter();
 
 Velocity.mergeTemplate(/myfile.vm, context, w );
 System.out.println( template :  + w );
 
 /* lets make our own string to render */
 }
 
 results is a List of 66000 objects and requires about 8megs of memory.
 The mergeTemplate requires at least 230 MB of memory.   Any
 suggestions?
 
 -L
 
 On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
  Hi, 
  
  I guess the writer Ilkka talked about is when using Velocity as a
  standalone template engine.
  
  Right now I don't have a good clue, could you run Velocity as a
  standalone template engine and render the page to see if there is a
  huge memory usage?
  
  Cheers,
  
  Jian
  
  On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
   Sorry, I'm not sure what you mean by what kind of writer I'm
 using.   Where would I find out?   How would I change this (to maybe a
 StringBuffer writer?)
   
   Also, each column contains a String that is at most, 200
characters,
 most are closer to 10-20.   There are a total of 10 columns.
   
   Thanks.
   
   -Lawrence
   
   On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
What kind of writer are you using and how long are the items? 66
 000 HTML
table rows with 5 numeric columns consumes about 32 MB when
 buffered into a
string writer. If the items are longer, it takes much more
memory.
   
-- Ilkka
   
   
[EMAIL PROTECTED] wrote:
I tried putting static HTML in the #foreach loop, same problem.
 Then I
tried setting the large list as a local varible:

#set ($localList = $List)
#foreach($row in $localList)
...

but that didnt help either.   I don't see why velocity should
use
 250+ MB
of memory iterating over a list ~8MB in size...
-L

On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:

Well, I don't have a good clue now.

What about do the debugging step by step, i.e., use just
static
 html
in your #foreach loop? Will that blow up the memory?

Cheers,

Jian



On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:

Thanks for the suggestion.   I tried putting that, along with

file.resource.loader.cache = true

in my velocity.properties file.   Both did not work.   Any
 other
suggestions?

Thanks!

-L

On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:

Hi,

This maybe because you haven't turned on template caching. I
 had
similar problem before, and even if I only used
evaluate(...)
 method
and load the template using my own java program, it happened
 when the
for loop is lot of iterations.

The bottom line for my problem is I need to turn on template
 caching,
so, velocity will not try to cache the objects it parsed
 during each
time of the iteration.

I did:
ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE,
 true);

where ri is a runtime instance.

Will this fix your issue?

Cheers,

Jian


On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED]
wrote:

I am getting an OutOfMemoryException:

org.apache.velocity.exception.MethodInvocationException:
 Invocation of
method 'get' in  class
 org.apache.velocity.tools.struts.TilesTool
threw exception class java.lang.OutOfMemoryError : null

when I am creating a large velocity file.  The vm file
itself
 is
fairly small, but this piece of velocity is causing the
 exception:

#foreach($row in $List

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
Alright, I changed the Writer to be:

OutputStreamWriter w = new OutputStreamWriter(new 
FileOutputStream(test.html));

And this fixes the memory problem.

However, my application is running Velocity as a servlet, how should I extend 
the VelocityServlet to use an OutputStreamWriter intead of a StringWriter?  
Should I post a different email thread about this?

-L

On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 Well, Open a file, use a FileWriter.
 
 David
 
 
 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 I printed out the available memory before and after I call
 mergeTemplate:
 
 Free memory before merge: 217393352
 Free memory after merge: 16271392
 
 so I would assume the StringWriter is approximately 200MB after the
 merge.   What should I use/do instead?   
 
 -Lawrence
 
 On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
  Why do you use StringWriter? That is cached in the memory.
  How big is the StringWriter after the merge?
  
  David
  
  
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
  Sent: Friday, May 06, 2005 1:22 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
  
  Alright, I ran this little piece of code:
  
  public static void main( String args[] ) throws Exception
  {
  /* first, we init the runtime engine.  Defaults are fine. */
  
  Velocity.init();
  
  /* lets make a Context and put data into it */
  
  VelocityContext context = new VelocityContext();
  
  List results = ReportBean.runLargeReport();
  
  context.put(List, results);
  
  /* lets render a template */
  
  StringWriter w = new StringWriter();
  
  Velocity.mergeTemplate(/myfile.vm, context, w );
  System.out.println( template :  + w );
  
  /* lets make our own string to render */
  }
  
  results is a List of 66000 objects and requires about 8megs of memory.
  The mergeTemplate requires at least 230 MB of memory.   Any
  suggestions?
  
  -L
  
  On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
   Hi, 
   
   I guess the writer Ilkka talked about is when using Velocity as a
   standalone template engine.
   
   Right now I don't have a good clue, could you run Velocity as a
   standalone template engine and render the page to see if there is a
   huge memory usage?
   
   Cheers,
   
   Jian
   
   On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Sorry, I'm not sure what you mean by what kind of writer I'm
  using.   Where would I find out?   How would I change this (to maybe a
  StringBuffer writer?)

Also, each column contains a String that is at most, 200
 characters,
  most are closer to 10-20.   There are a total of 10 columns.

Thanks.

-Lawrence

On Fri, May 06, 2005 at 09:11:13PM +0300, Ilkka Priha wrote:
 What kind of writer are you using and how long are the items? 66
  000 HTML
 table rows with 5 numeric columns consumes about 32 MB when
  buffered into a
 string writer. If the items are longer, it takes much more
 memory.

 -- Ilkka


 [EMAIL PROTECTED] wrote:
 I tried putting static HTML in the #foreach loop, same problem.
  Then I
 tried setting the large list as a local varible:
 
 #set ($localList = $List)
 #foreach($row in $localList)
 ...
 
 but that didnt help either.   I don't see why velocity should
 use
  250+ MB
 of memory iterating over a list ~8MB in size...
 -L
 
 On Thu, May 05, 2005 at 02:56:28PM -0700, jian chen wrote:
 
 Well, I don't have a good clue now.
 
 What about do the debugging step by step, i.e., use just
 static
  html
 in your #foreach loop? Will that blow up the memory?
 
 Cheers,
 
 Jian
 
 
 
 On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 
 Thanks for the suggestion.   I tried putting that, along with
 
 file.resource.loader.cache = true
 
 in my velocity.properties file.   Both did not work.   Any
  other
 suggestions?
 
 Thanks!
 
 -L
 
 On Thu, May 05, 2005 at 02:11:28PM -0700, jian chen wrote:
 
 Hi,
 
 This maybe because you haven't turned on template caching. I
  had
 similar problem before, and even if I only used
 evaluate(...)
  method
 and load the template using my own java program, it happened
  when the
 for loop is lot of iterations.
 
 The bottom line for my problem is I need to turn on template
  caching,
 so, velocity will not try to cache the objects it parsed
  during each
 time of the iteration.
 
 I did:
 ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE,
  true

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
This is why I'm so confused.   I wouldn't expect it to use so much memory.  
What I did to test the memory usage was:

System.out.println(Free memory before merge:  + 
Runtime.getRuntime().freeMemory());
Velocity.mergeTemplate(/myfile.vm, ISO-8859-1, context, w );
System.out.println(Free memory after merge:  + 
Runtime.getRuntime().freeMemory());

And then setting the JVM to -Xms256M and -Xmx256M.   When I use a String 
writer, the free memory is reduced by ~200MB.   When I use an 
OutputStreamWriter, it is reduced ~13MB, a huge difference.

BTW, I am using 1.4.2_05

-L

On Fri, May 06, 2005 at 02:22:01PM -0700, Will Glass-Husain wrote:
 Hi Lawrence,
 
 I got interested, and just ran some similar code with JProfiler looking at 
 VM memory usage.  I created a list of 60,000 objects, each with 10 100char 
 columns.  Then I used StringWriter to merge as you did.
 
 The VM used 3MB at the start, 6.5 MB after creating the list, and 25 after 
 merging.  (before I closed the writer).  Nowhere close to 200.  So perhaps 
 there's something else going on.  Although if the problem is one with 
 StringWriter, a lot may depend on the specific JVM you're using.  (I'm 
 using Sun 1.4.2_04-b05).
 
 WILL
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: Velocity Users List velocity-user@jakarta.apache.org
 Sent: Friday, May 06, 2005 2:08 PM
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 Ok now I'm confused (suprise, suprise!).   I looked at the source for 
 VelocityServlet, and mergeTemplate has:
 
 vw = (VelocityWriter) writerPool.get();
 
 if (vw == null)
 {
vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 * 
 1024, true);
 }
 else
 {
vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already ... so then why 
 does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new 
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, how should I 
 extend the VelocityServlet to use an OutputStreamWriter intead of a 
 StringWriter?  Should I post a different email thread about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
  Well, Open a file, use a FileWriter.
 
  David
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:48 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  I printed out the available memory before and after I call
  mergeTemplate:
 
  Free memory before merge: 217393352
  Free memory after merge: 16271392
 
  so I would assume the StringWriter is approximately 200MB after the
  merge.   What should I use/do instead?
 
  -Lawrence
 
  On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
   Why do you use StringWriter? That is cached in the memory.
   How big is the StringWriter after the merge?
  
   David
  
  
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   Sent: Friday, May 06, 2005 1:22 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   Alright, I ran this little piece of code:
  
   public static void main( String args[] ) throws Exception
   {
   /* first, we init the runtime engine.  Defaults are fine. */
  
   Velocity.init();
  
   /* lets make a Context and put data into it */
  
   VelocityContext context = new VelocityContext();
  
   List results = ReportBean.runLargeReport();
  
   context.put(List, results);
  
   /* lets render a template */
  
   StringWriter w = new StringWriter();
  
   Velocity.mergeTemplate(/myfile.vm, context, w );
   System.out.println( template :  + w );
  
   /* lets make our own string to render */
   }
  
   results is a List of 66000 objects and requires about 8megs of 
   memory.
   The mergeTemplate requires at least 230 MB of memory.   Any
   suggestions?
  
   -L
  
   On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
Hi,
   
I guess the writer Ilkka talked about is when using Velocity as a
standalone template engine.
   
Right now I don't have a good clue, could you run Velocity as a
standalone template engine and render the page to see if there is a
huge memory usage?
   
Cheers,
   
Jian
   
On 5/6/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Sorry, I'm not sure what you mean by what kind of writer I'm
   using.   Where would I find out?   How would I change this (to maybe 
   a
   StringBuffer writer?)

 Also, each column contains a String that is at most, 200
  characters,
   most are closer to 10-20

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread Will Glass-Husain
You might consider trying a profiler.  Most of them have trial version 
available.  This could tell you exactly where the memory is going.

I just bought JProfiler, and it seems a bit better priced than the others. 
Here's a user review:
http://www.jlamp.com/blog/2005/02/01/1107280975000.html

You might also check out Hyades from the Eclipse project for an open source 
option.

WILL
- Original Message - 
From: [EMAIL PROTECTED]
To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Friday, May 06, 2005 2:39 PM
Subject: Re: OutOfMemoryException Processing Velocity Template


This is why I'm so confused.   I wouldn't expect it to use so much memory. 
What I did to test the memory usage was:

System.out.println(Free memory before merge:  + 
Runtime.getRuntime().freeMemory());
Velocity.mergeTemplate(/myfile.vm, ISO-8859-1, context, w );
System.out.println(Free memory after merge:  + 
Runtime.getRuntime().freeMemory());

And then setting the JVM to -Xms256M and -Xmx256M.   When I use a String 
writer, the free memory is reduced by ~200MB.   When I use an 
OutputStreamWriter, it is reduced ~13MB, a huge difference.

BTW, I am using 1.4.2_05
-L
On Fri, May 06, 2005 at 02:22:01PM -0700, Will Glass-Husain wrote:
Hi Lawrence,
I got interested, and just ran some similar code with JProfiler looking 
at
VM memory usage.  I created a list of 60,000 objects, each with 10 
100char
columns.  Then I used StringWriter to merge as you did.

The VM used 3MB at the start, 6.5 MB after creating the list, and 25 
after
merging.  (before I closed the writer).  Nowhere close to 200.  So 
perhaps
there's something else going on.  Although if the problem is one with
StringWriter, a lot may depend on the specific JVM you're using.  (I'm
using Sun 1.4.2_04-b05).

WILL
- Original Message - 
From: [EMAIL PROTECTED]
To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Friday, May 06, 2005 2:08 PM
Subject: Re: OutOfMemoryException Processing Velocity Template

Ok now I'm confused (suprise, suprise!).   I looked at the source for
VelocityServlet, and mergeTemplate has:

vw = (VelocityWriter) writerPool.get();

if (vw == null)
{
   vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 *
1024, true);
}
else
{
   vw.recycle(new OutputStreamWriter(output, encoding));
}
template.merge(context, vw);

===

So the VelocityServlet DOES use OutputStreamWriter already ... so then 
why
does it still utilize so much memory?

-L

On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
Alright, I changed the Writer to be:

OutputStreamWriter w = new OutputStreamWriter(new
FileOutputStream(test.html));

And this fixes the memory problem.

However, my application is running Velocity as a servlet, how should I
extend the VelocityServlet to use an OutputStreamWriter intead of a
StringWriter?  Should I post a different email thread about this?

-L

On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 Well, Open a file, use a FileWriter.

 David


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template

 I printed out the available memory before and after I call
 mergeTemplate:

 Free memory before merge: 217393352
 Free memory after merge: 16271392

 so I would assume the StringWriter is approximately 200MB after the
 merge.   What should I use/do instead?

 -Lawrence

 On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
  Why do you use StringWriter? That is cached in the memory.
  How big is the StringWriter after the merge?
 
  David
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:22 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  Alright, I ran this little piece of code:
 
  public static void main( String args[] ) throws Exception
  {
  /* first, we init the runtime engine.  Defaults are fine. 
  */
 
  Velocity.init();
 
  /* lets make a Context and put data into it */
 
  VelocityContext context = new VelocityContext();
 
  List results = ReportBean.runLargeReport();
 
  context.put(List, results);
 
  /* lets render a template */
 
  StringWriter w = new StringWriter();
 
  Velocity.mergeTemplate(/myfile.vm, context, w );
  System.out.println( template :  + w );
 
  /* lets make our own string to render */
  }
 
  results is a List of 66000 objects and requires about 8megs of
  memory.
  The mergeTemplate requires at least 230 MB of memory.   Any
  suggestions?
 
  -L
 
  On Fri, May 06, 2005 at 11:53:30AM -0700, jian chen wrote:
   Hi,
  
   I guess the writer Ilkka talked about is when using Velocity as a
   standalone template engine.
  
   Right now I don't have a good clue, could you run Velocity as a
   standalone

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread lawrence
Ok I tried using JProfiler and used a StringWriter, and found that the item 
that was taking the most memory (150 MB) was. char[]!  Ok now I'm 
completely stumped and clueless.

-L

On Fri, May 06, 2005 at 02:51:15PM -0700, Will Glass-Husain wrote:
 You might consider trying a profiler.  Most of them have trial version 
 available.  This could tell you exactly where the memory is going.
 
 I just bought JProfiler, and it seems a bit better priced than the others. 
 Here's a user review:
 http://www.jlamp.com/blog/2005/02/01/1107280975000.html
 
 You might also check out Hyades from the Eclipse project for an open source 
 option.
 
 WILL
 
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: Velocity Users List velocity-user@jakarta.apache.org
 Sent: Friday, May 06, 2005 2:39 PM
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 This is why I'm so confused.   I wouldn't expect it to use so much memory. 
 What I did to test the memory usage was:
 
 System.out.println(Free memory before merge:  + 
 Runtime.getRuntime().freeMemory());
 Velocity.mergeTemplate(/myfile.vm, ISO-8859-1, context, w );
 System.out.println(Free memory after merge:  + 
 Runtime.getRuntime().freeMemory());
 
 And then setting the JVM to -Xms256M and -Xmx256M.   When I use a String 
 writer, the free memory is reduced by ~200MB.   When I use an 
 OutputStreamWriter, it is reduced ~13MB, a huge difference.
 
 BTW, I am using 1.4.2_05
 
 -L
 
 On Fri, May 06, 2005 at 02:22:01PM -0700, Will Glass-Husain wrote:
 Hi Lawrence,
 
 I got interested, and just ran some similar code with JProfiler looking 
 at
 VM memory usage.  I created a list of 60,000 objects, each with 10 
 100char
 columns.  Then I used StringWriter to merge as you did.
 
 The VM used 3MB at the start, 6.5 MB after creating the list, and 25 
 after
 merging.  (before I closed the writer).  Nowhere close to 200.  So 
 perhaps
 there's something else going on.  Although if the problem is one with
 StringWriter, a lot may depend on the specific JVM you're using.  (I'm
 using Sun 1.4.2_04-b05).
 
 WILL
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: Velocity Users List velocity-user@jakarta.apache.org
 Sent: Friday, May 06, 2005 2:08 PM
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 Ok now I'm confused (suprise, suprise!).   I looked at the source for
 VelocityServlet, and mergeTemplate has:
 
 vw = (VelocityWriter) writerPool.get();
 
 if (vw == null)
 {
vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4 *
 1024, true);
 }
 else
 {
vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already ... so then 
 why
 does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, how should I
 extend the VelocityServlet to use an OutputStreamWriter intead of a
 StringWriter?  Should I post a different email thread about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
  Well, Open a file, use a FileWriter.
 
  David
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:48 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  I printed out the available memory before and after I call
  mergeTemplate:
 
  Free memory before merge: 217393352
  Free memory after merge: 16271392
 
  so I would assume the StringWriter is approximately 200MB after the
  merge.   What should I use/do instead?
 
  -Lawrence
 
  On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
   Why do you use StringWriter? That is cached in the memory.
   How big is the StringWriter after the merge?
  
   David
  
  
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   Sent: Friday, May 06, 2005 1:22 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   Alright, I ran this little piece of code:
  
   public static void main( String args[] ) throws Exception
   {
   /* first, we init the runtime engine.  Defaults are fine. 
   */
  
   Velocity.init();
  
   /* lets make a Context and put data into it */
  
   VelocityContext context = new VelocityContext();
  
   List results = ReportBean.runLargeReport();
  
   context.put(List, results);
  
   /* lets render a template */
  
   StringWriter w = new StringWriter();
  
   Velocity.mergeTemplate(/myfile.vm, context, w );
   System.out.println( template :  + w );
  
   /* lets make our own string to render

Re: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread Will Glass-Husain
Yes, but which ones?
The char[] in the StringWriter, the char[] in the Template object, or the
char[] in the strings in your original objects?  That would be useful info.
WILL
- Original Message - 
From: [EMAIL PROTECTED]
To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Friday, May 06, 2005 3:45 PM
Subject: Re: OutOfMemoryException Processing Velocity Template


Ok I tried using JProfiler and used a StringWriter, and found that the
item that was taking the most memory (150 MB) was. char[]!  Ok now I'm
completely stumped and clueless.
-L
On Fri, May 06, 2005 at 02:51:15PM -0700, Will Glass-Husain wrote:
You might consider trying a profiler.  Most of them have trial version
available.  This could tell you exactly where the memory is going.
I just bought JProfiler, and it seems a bit better priced than the
others.
Here's a user review:
http://www.jlamp.com/blog/2005/02/01/1107280975000.html
You might also check out Hyades from the Eclipse project for an open
source
option.
WILL
- Original Message - 
From: [EMAIL PROTECTED]
To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Friday, May 06, 2005 2:39 PM
Subject: Re: OutOfMemoryException Processing Velocity Template

This is why I'm so confused.   I wouldn't expect it to use so much
memory.
What I did to test the memory usage was:

System.out.println(Free memory before merge:  +
Runtime.getRuntime().freeMemory());
Velocity.mergeTemplate(/myfile.vm, ISO-8859-1, context, w );
System.out.println(Free memory after merge:  +
Runtime.getRuntime().freeMemory());

And then setting the JVM to -Xms256M and -Xmx256M.   When I use a String
writer, the free memory is reduced by ~200MB.   When I use an
OutputStreamWriter, it is reduced ~13MB, a huge difference.

BTW, I am using 1.4.2_05

-L

On Fri, May 06, 2005 at 02:22:01PM -0700, Will Glass-Husain wrote:
Hi Lawrence,

I got interested, and just ran some similar code with JProfiler looking
at
VM memory usage.  I created a list of 60,000 objects, each with 10
100char
columns.  Then I used StringWriter to merge as you did.

The VM used 3MB at the start, 6.5 MB after creating the list, and 25
after
merging.  (before I closed the writer).  Nowhere close to 200.  So
perhaps
there's something else going on.  Although if the problem is one with
StringWriter, a lot may depend on the specific JVM you're using.  (I'm
using Sun 1.4.2_04-b05).

WILL

- Original Message - 
From: [EMAIL PROTECTED]
To: Velocity Users List velocity-user@jakarta.apache.org
Sent: Friday, May 06, 2005 2:08 PM
Subject: Re: OutOfMemoryException Processing Velocity Template


Ok now I'm confused (suprise, suprise!).   I looked at the source for
VelocityServlet, and mergeTemplate has:

vw = (VelocityWriter) writerPool.get();

if (vw == null)
{
   vw = new VelocityWriter(new OutputStreamWriter(output, encoding),4
 *
1024, true);
}
else
{
   vw.recycle(new OutputStreamWriter(output, encoding));
}
template.merge(context, vw);

===

So the VelocityServlet DOES use OutputStreamWriter already ... so then
why
does it still utilize so much memory?

-L

On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED] wrote:
Alright, I changed the Writer to be:

OutputStreamWriter w = new OutputStreamWriter(new
FileOutputStream(test.html));

And this fixes the memory problem.

However, my application is running Velocity as a servlet, how should
I
extend the VelocityServlet to use an OutputStreamWriter intead of a
StringWriter?  Should I post a different email thread about this?

-L

On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
 Well, Open a file, use a FileWriter.

 David


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
 Sent: Friday, May 06, 2005 1:48 PM
 To: Velocity Users List
 Subject: Re: OutOfMemoryException Processing Velocity Template

 I printed out the available memory before and after I call
 mergeTemplate:

 Free memory before merge: 217393352
 Free memory after merge: 16271392

 so I would assume the StringWriter is approximately 200MB after the
 merge.   What should I use/do instead?

 -Lawrence

 On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
  Why do you use StringWriter? That is cached in the memory.
  How big is the StringWriter after the merge?
 
  David
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:22 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  Alright, I ran this little piece of code:
 
  public static void main( String args[] ) throws Exception
  {
  /* first, we init the runtime engine.  Defaults are fine.
  */
 
  Velocity.init();
 
  /* lets make a Context and put data into it */
 
  VelocityContext context = new VelocityContext();
 
  List results = ReportBean.runLargeReport();
 
  context.put(List, results);
 
  /* lets render a template

RE: OutOfMemoryException Processing Velocity Template

2005-05-06 Thread David You
I remember reading the performance book, which mentioned that Java
Writer does not optimize on the Writer. It does not reuse the internal
char[] buffer.

But that should not overflow, it just makes the GC busier.

Regards
David




-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Sent: Friday, May 06, 2005 3:46 PM
To: Velocity Users List
Subject: Re: OutOfMemoryException Processing Velocity Template

Ok I tried using JProfiler and used a StringWriter, and found that the
item that was taking the most memory (150 MB) was. char[]!  Ok now
I'm completely stumped and clueless.

-L

On Fri, May 06, 2005 at 02:51:15PM -0700, Will Glass-Husain wrote:
 You might consider trying a profiler.  Most of them have trial version

 available.  This could tell you exactly where the memory is going.
 
 I just bought JProfiler, and it seems a bit better priced than the
others. 
 Here's a user review:
 http://www.jlamp.com/blog/2005/02/01/1107280975000.html
 
 You might also check out Hyades from the Eclipse project for an open
source 
 option.
 
 WILL
 
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: Velocity Users List velocity-user@jakarta.apache.org
 Sent: Friday, May 06, 2005 2:39 PM
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 This is why I'm so confused.   I wouldn't expect it to use so much
memory. 
 What I did to test the memory usage was:
 
 System.out.println(Free memory before merge:  + 
 Runtime.getRuntime().freeMemory());
 Velocity.mergeTemplate(/myfile.vm, ISO-8859-1, context, w );
 System.out.println(Free memory after merge:  + 
 Runtime.getRuntime().freeMemory());
 
 And then setting the JVM to -Xms256M and -Xmx256M.   When I use a
String 
 writer, the free memory is reduced by ~200MB.   When I use an 
 OutputStreamWriter, it is reduced ~13MB, a huge difference.
 
 BTW, I am using 1.4.2_05
 
 -L
 
 On Fri, May 06, 2005 at 02:22:01PM -0700, Will Glass-Husain wrote:
 Hi Lawrence,
 
 I got interested, and just ran some similar code with JProfiler
looking 
 at
 VM memory usage.  I created a list of 60,000 objects, each with 10 
 100char
 columns.  Then I used StringWriter to merge as you did.
 
 The VM used 3MB at the start, 6.5 MB after creating the list, and 25

 after
 merging.  (before I closed the writer).  Nowhere close to 200.  So 
 perhaps
 there's something else going on.  Although if the problem is one
with
 StringWriter, a lot may depend on the specific JVM you're using.
(I'm
 using Sun 1.4.2_04-b05).
 
 WILL
 
 - Original Message - 
 From: [EMAIL PROTECTED]
 To: Velocity Users List velocity-user@jakarta.apache.org
 Sent: Friday, May 06, 2005 2:08 PM
 Subject: Re: OutOfMemoryException Processing Velocity Template
 
 
 Ok now I'm confused (suprise, suprise!).   I looked at the source
for
 VelocityServlet, and mergeTemplate has:
 
 vw = (VelocityWriter) writerPool.get();
 
 if (vw == null)
 {
vw = new VelocityWriter(new OutputStreamWriter(output,
encoding),4 *
 1024, true);
 }
 else
 {
vw.recycle(new OutputStreamWriter(output, encoding));
 }
 template.merge(context, vw);
 
 ===
 
 So the VelocityServlet DOES use OutputStreamWriter already ... so
then 
 why
 does it still utilize so much memory?
 
 -L
 
 On Fri, May 06, 2005 at 02:02:07PM -0700, [EMAIL PROTECTED]
wrote:
 Alright, I changed the Writer to be:
 
 OutputStreamWriter w = new OutputStreamWriter(new
 FileOutputStream(test.html));
 
 And this fixes the memory problem.
 
 However, my application is running Velocity as a servlet, how
should I
 extend the VelocityServlet to use an OutputStreamWriter intead of
a
 StringWriter?  Should I post a different email thread about this?
 
 -L
 
 On Fri, May 06, 2005 at 01:59:19PM -0700, David You wrote:
  Well, Open a file, use a FileWriter.
 
  David
 
 
  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
  Sent: Friday, May 06, 2005 1:48 PM
  To: Velocity Users List
  Subject: Re: OutOfMemoryException Processing Velocity Template
 
  I printed out the available memory before and after I call
  mergeTemplate:
 
  Free memory before merge: 217393352
  Free memory after merge: 16271392
 
  so I would assume the StringWriter is approximately 200MB after
the
  merge.   What should I use/do instead?
 
  -Lawrence
 
  On Fri, May 06, 2005 at 01:43:50PM -0700, David You wrote:
   Why do you use StringWriter? That is cached in the memory.
   How big is the StringWriter after the merge?
  
   David
  
  
   -Original Message-
   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
   Sent: Friday, May 06, 2005 1:22 PM
   To: Velocity Users List
   Subject: Re: OutOfMemoryException Processing Velocity Template
  
   Alright, I ran this little piece of code:
  
   public static void main( String args[] ) throws Exception
   {
   /* first, we init the runtime engine.  Defaults are
fine. 
   */
  
   Velocity.init();
  
   /* lets make a Context and put data

Re: OutOfMemoryException Processing Velocity Template

2005-05-05 Thread jian chen
Hi,

This maybe because you haven't turned on template caching. I had
similar problem before, and even if I only used evaluate(...) method
and load the template using my own java program, it happened when the
for loop is lot of iterations.

The bottom line for my problem is I need to turn on template caching,
so, velocity will not try to cache the objects it parsed during each
time of the iteration.

I did:
ri.setProperty(RuntimeConstants.FILE_RESOURCE_LOADER_CACHE, true);

where ri is a runtime instance. 

Will this fix your issue?

Cheers,

Jian


On 5/5/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 I am getting an OutOfMemoryException:
 
 org.apache.velocity.exception.MethodInvocationException: Invocation of method 
 'get' in  class org.apache.velocity.tools.struts.TilesTool threw exception 
 class java.lang.OutOfMemoryError : null
 
 when I am creating a large velocity file.  The vm file itself is fairly 
 small, but this piece of velocity is causing the exception:
 
 #foreach($row in $List)
 tr
 td height=20 class=tbltxt$!row.item1/td
 td class=tbltxt$!row.item2/td
 td class=tbltxt$!row.item3/td
 td class=tbltxt$!row.item4/td
 td class=tbltxt$!number.format('currency', $!row.item5)/td
 /tr
 #end
 
 List is a list of relatively small objects (5-6 Strings, a couple of 
 BigDecimals), but the List itself contains approximately 66,000 entries.  
 Unfortunately, unless I set the tomcat JVM to use a heap size of at least 
 256M, this velocity template throws an OutOfMemoryException when it is being 
 processed.
 
 Any suggestions?
 
 Thanks.
 
 -L
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]