Hi All,
Just now I went through the mail-list "Tiles excessive memory usage" on the
struts mail archive. What I could get from that mail list is, there is
some excessive memory usage problem with the tiles. Can anybody tell me
whether the problem discussed in that mail list is solved in the struts 1.1
? I am pasting the mail list from the mail archive for your reference. If
that problem is not solved, can anybody tell me what is the exact solution
of that problem? I am using struts 1.1 in my application.
Re: Tiles excessive memory usage
From: cwilling
Subject: Re: Tiles excessive memory usage
Date: Mon, 10 Mar 2003 20:47:12 -0800
Thanks Christophe.
I will take my time seeing what youve done and to see how it best fits to
1.1. I would like to hear from Cedric too as soo as possible to be sure
there's ot something we've missed. If I have succes with 1.1 I'll be sure
to offer it to this mail list But I truly hope to hear from Cedric before
I
move to far ahead.
Thanks agin,
Chris
----- Original Message -----
From: "Christophe Warland" <[EMAIL PROTECTED]>
To: "'Struts Developers List'" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 7:00 PM
Subject: RE: Tiles excessive memory usage
> Patch is attached. Once again, please note that this is based on Tiles as
of
> 2001-09-10. I would send my sources to the list, but I have only just
joined
> struts-dev today and I don't know the etiquette in use here with regards
to
> attachments. FWIW, my modified sources fit in a 17k zip file
> (non-uuencoded).
>
> If you are not interested in my patch and prefer to implement it your
way,
> here is my advice:
> 1. go to ComponentDefinition and ComponentContext and delete the
following
> 'evil' methods
> public Map getAttributes()
> public ComponentContext(Map attributes)
> public void addAll(Map newAttributes)
> public void addMissing(Map defaultAttributes)
> 2. then refactor/recompile/refactor the rest of Tiles until you have
> something usable (pass along and keep track of ComponentDefinition
objects
> as much as you can -- never access the HashMap directly).
>
> Regards,
>
> -- Christophe
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 10, 2003 6:22 PM
> To: Struts Developers List
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: Re: Tiles excessive memory usage
>
>
> Chris,
>
> I'm just now getting to profiling our struts/tiles app and have always
had
> some concern about the efficiency of the tiles. Not that I'm a
suspecting
> type of person but I just didn't have any information and that caused me
to
> wonder.
>
> Regardles when or if this fix gets placed in a release, would you be
willing
> to offer sufficient code snippets that will give me enough understanding
to
> implement your fix in my app? I'm now getting deeper into tiles and
getting
> a good feel for what's going on so this would be a perfect time for me
> before we enter client phase. Also, I'd be willing to contribute this
> efficiency gain to the project(with your help or ok) if Cedric and the
other
> powers agree this is something that should be done.
>
> But in the meantime, could you supply me with some more detailed
information
> and snippets. This could potentially kill my project since performance
is
> the major hot word amoung manager types these days where I work. You can
> reply to [EMAIL PROTECTED] with details that don't pertain to the
> developer's group if you like.
>
> Thanks for posting this!!!!!!!
>
> Chris Willingham
> ----- Original Message -----
> From: Christophe Warland
> To: '[EMAIL PROTECTED]'
> Cc: '[EMAIL PROTECTED]' ; '[EMAIL PROTECTED]'
> Sent: Monday, March 10, 2003 4:47 PM
> Subject: Tiles excessive memory usage
>
>
> At my company, we have been recently forced to patch Tiles to solve
some
> major memory problems where Tiles was eating a lot of memory for no
apparent
> reasons. We wish to share our findings with you. And we will be happy to
> send our code change to Cedric if he wishes so.
>
> Here are some quick numbers about our J2EE runtime after complete
bootup
> (appserver and EAR file are up, deployed and ready to serve HTTP
requests):
> - With original Tiles code: 79 MB of RAM is used
> - After our custom code change: 28 MB of RAM is used
>
> Note that the Tiles version that we use is an old one (our source zip
> shows 09/10/2001). However, a quick analysis of the more recent Tiles
source
> found in Struts 1.1 RC1 shows that most the code where the defect lies is
> still in there. But we haven't actually been able to confirm the problem
at
> runtime since our app is not compatible with the latest Struts and Tiles
> development.
>
> Here are a few excerpt of our internal analysis so that you can
understand
> the issue.
>
> --
>
> Our application does not actually make use of the Tiles template
mechanism
> but instead builds on top of Tiles' i18n concept to offer localized Web
> pages based on an individual's language, country, personality and
channel.
> We make extensive use of Tiles Component definitions and inheritance in
XML
> files, and 667 out of the 668 definitions used by our app inherit from
> another one.
>
> With the help of a Java profiler, we showed that 64% of the 79 MB of
> memory was used by HashMap entries created by Tiles. This corresponds to
> 50.5 MB of RAM. After close investigation, it turns out that the very
useful
> Tiles' component inheritance has been mis-implemented.
>
> Our application has only one definition that doesn't extend another
one:
> the root "pageDefinition", which contains common information such as
> "pageCopyrightLink" for example. Other Component Definitions that extend
> "pageDefinition", such as "disbursementCB", do not need to repeat this
> information. When queried for the "pageCopyrightLink" value, the
> "disbursementCB" component will delegate the processing to its parent
> component, in this case "pageDefinition".
>
> Unfortunately, this handy conceptual delegation is actually not
> implemented in a similar way in the Tiles source code.
>
> In our example, when the "disbursementCB" component is instantiated in
> memory, the Tiles source code does not pass it a reference to the parent
> "pageDefiniton" component. Instead, Tiles forces the new "disbursementCB"
> component to make a deep copy of all values defined in its parent(s).
This
> means that, ultimately, our application ends up with 668 copies of the
> "pageCopyrightLink" value in memory, instead of one.
>
> After modification of the Tiles source code so that true delegation is
> actually happening in memory at runtime, new heap allocation statistics
> showed that the problem with excessive usage of HashMap$Entry has been
> completely solved. The most in-use object in the JVM is now of the type
> "[C", a common and normal trend in typical Java applications.
>
> The total amount of memory was also down to 28 MB. This is a pleasant
51
> MB gain over the previous result.
>
> --
>
> Finally, without being too demanding, we would appreciate if a patched
> version of Tiles could be made available for for both the upcoming Struts
> 1.1 release and the current stabe Strust 1.0.2 one.
>
>
> Best Regards,
>
>
> Christophe Warland
>
>
>
--------------------------------------------------------------------------
--
> --
>
>
> ---------------------------------------------------------------------
> 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]
*****************************************************************************************************************************
DISCLAIMER: The information contained in this message is intended only and solely for
the addressed individual or entity indicated in this message and for the exclusive use
of the said addressed individual or entity indicated in this message (or responsible
for delivery of the message to such person) and may contain legally privileged and
confidential information belonging to Tata Consultancy Services. It must not be
printed, read, copied, disclosed, forwarded, distributed or used (in whatsoever
manner) by any person other than the addressee. Unauthorized use, disclosure or
copying is strictly prohibited and may constitute unlawful act and can possibly
attract legal action, civil and/or criminal. The contents of this message need not
necessarily reflect or endorse the views of TATA Consultancy Services on any subject
matter. Any action taken or omitted to be taken based on this message is entirely at
your risk and neither the originator of this message nor Tata Consultancy Services
takes any responsibility or liability towards the same. Opinions, conclusions and any
other information contained in this message that do not relate to the official
business of Tata Consultancy Services shall be understood as neither given nor
endorsed by Tata Consultancy Services or any affiliate of Tata Consultancy Services.
If you have received this message in error, you should destroy this message and may
please notify the sender by e-mail. Thank you.
*****************************************************************************************************************************
.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
