tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard W. Smith, Jr." <smithh032...@gmail.com>
Subject Re: Re : Memory leak in Tomcat 6.0.35 ( 64 bit)
Date Mon, 15 Apr 2013 20:02:45 GMT
On Mon, Apr 15, 2013 at 1:08 PM, Christopher Schultz <
chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Howard,
>
> On 4/14/13 9:53 PM, Howard W. Smith, Jr. wrote:
> > I am definitely relying on  user HttpSessions, and I do JPA-level
> > caching (statement cache and query results cache). pages are
> > PrimeFaces and primefaces = xhtml, html, jquery, and
> > MyFaces/OpenWebBeans to help with speed/performance.  And right
> > now, the app handles on a 'few' simultaneous connections/users that
> > do small and large fetches/inserts from/into relational database.
> > :)
>
> You can tune the JPA caching, etc. to meet your environmental needs,
> etc., so you don't *need* a huge heap. If you find that you need to be
> able to improve your performance, you might be able to increase your
> cache size if it in fact improves things.
>

doing this, and just made some code changes to tap a little more into JPA
caching, but one of my endusers just did a user operation on one of the
pages, and he sent me a screen capture of the nasty eclipselink error that
he experienced. evidently, i need to tweak caching or do not use the cache
at that point in the app. :)

i explained to him that i did some major changes in the app, related to
caching... and i told him that it was for 'performance improvement', and
told him the same as Mark just told me, Google is your friend (and told him
that 'wiki' keyword in the search is your friend, too).  :)



> > sometimes, i do keep large amount of data in user HttpSession
> > objects, but still being somewhat junior java/jsf developer and
> > listening to you all on tomcat list and other senior java/jsf
> > developers, I want to move some of my logic and caching of data
> > from SessionScoped beans to RequestScoped beans.
>
> You might be able to have your cake and eat it, too. There is an
> interesting class called WeakReference that you can use to interact
> with the memory manager and garbage-collector. If you have a bunch of
> stuff cached in the session, as long as you could re-construct the
> cache given some value (like user_id or whatever), you can make the
> big, cached stuff in the session into so-called weak-references. If
> the GC wants to re-claim memory, it can discard weak references and
> the WeakReference object will then point to null. That allows you to
> have a nice cache that auto-cleans if you start running low on memory.
>

very interesting. since i'm using gson to accept some JSON-wrapped data
into my app from our public website (static pages and formmail, only, for
now, until i integrate it with the web app i developed for personnel, only,
for now), i didn't like the warning/msg when tomcat/tomee 'stops'...says
that weak reference could not be deleted or something like that (sorry, i
forgot exactly what it said).  Anyway, i followed some issue in gson's
issue tracker (on code.google.com), and someone offered some code to delete
gson from weak reference, so i decided to add that to my app, when i
shutdown app.

so, i do know that the weak reference class is available. really have not
'used' it yet, though. :)

i have some things in mind what I want to do with that large session scoped
data. I am considering caching it at application level and all users have
ability to update that huge List<> and extract data. I was thinking of
using @Singleton Lock(READ) to control access. it takes no time at all to
search the List<> for the information that it needs, and it takes no time
at all to re-populate the List<>. Since we discuss GC a lot on this list, i
wonder if you all recommend to set the 'list' to null, first, and then
List<> ... = new ArrayList<>(newList), or new ArrayList<>(newList) is
sufficient for good GC.



> I've written a Filter and HttpSession wrapper that can do that kind of
> thing transparently to the application code. I don't actually use it
> right now -- it was just a proof-of concept -- but it's a quick and
> dirty way to get caching but also save a safety valve.
>

that's nice proof of concept! I guess i've heard so much bad about people
not cleaning up threadlocals, that I try to avoid usage of threadlocal, but
it's interesting, so much talk on this list about threadlocals, but they
threadlocals seem to be used by many implementations/software out there.
Not naming any names. :)



>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJRbDQhAAoJEBzwKT+lPKRY2voP/RejVzXwT9q3Bpq8C85sdmaU
> rf4l8aSAeHY9iZDuU27dGIPYcM8eD503UFdLxNrLQmsAnIGgecxcybSzTCIaA8Q1
> kqtA58KOOkSwjWzSzyLhr7glDELXlB7BW1wiKuclrSE99NLmLQIwt5osvjv6qYxi
> jPTU0y1LEKs9mXFjCmwpdjxryttMOPL+3NMjYy0PrauwxtWR1uPS3r+1bhkjtbSs
> srx4aV98bFso7NydTPrbGahOHRnY1s7deNq1AzcaYsKV0ASky5cgagmk9qRyfxMd
> UBAo4+cxQG2V9ccGO4PR+cuL6JQuLhfxexneFfR+FSbFPCmM9axNBexqi73BL79q
> 1aOffzSKLc9gS1I7MjXgMwc20K+bDYmnWOsePAJpCIt9Jl3S77AKQYzBWapCXCu0
> H+vtVEjvH38fuByNtNTBOonqztw7EFuOAMJWg1vRzWfZyeXSljewdLjw/+jTJYNA
> iULuGit9BTfIVwT2jaGfVmjebwy47GqaaisK+BF9/gLAGsG9/sSpfnYPOkjGpAZu
> 1+5nYnGzx8rqlgdPOmxh0MJiJdbLeg7yJxuFnCTe5X7i4wE7jUUkBGmqnWroiYD0
> iCxWU81XQMeJDob6WMw2Cori8ZUHt/oBGz3p33ip/NzPihQrlLqqIIx3zYwpM4vt
> H6hYuvJ+/t8PHKDhHR+K
> =guqf
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message