Hi Mike, I just got word from one of our engineers that the problem is markedly less pronounced with Magnolia 3.5, though it apparently still exists. So good news there.
Another interesting point is that the issue is slowed markedly when Tomcat sessions are allowed to persist. (Our caching architecture had been eating the session cookies until we tweaked it recently.) Memory use still grows when all our site visitors are channeled through a single Tomcat session, but at a fairly reduced rate. We'll be entering everything we know into Vivian's Jira ticket shortly. Sean On 1/11/08 9:33 AM, "Mike D. Jones" <[email protected]> wrote: > Hi all, > > I'm concerned to hear this happening in 3.5... We've had the same problem with > Jackrabbit 1.0.1 and Magnolia 3.0. I was hoping that an upgrade to 3.5 would > fix the problem. > > Currently, a thread stack dump of the JVM shows no problems with the > application, but a dump of the heap shows a nearly total memory usage, most > likely generated from org.apache.jackrabbit.util.WeakIdentityCollection. > > > Mike D. Jones > >> -----Original Message----- >> From: [email protected] [mailto:[EMAIL PROTECTED] >> Sent: Friday, January 11, 2008 10:24 AM >> To: [email protected] >> Subject: Re: [magnolia-user] Jackrabbit 1.3.3 and Memory Usage >> >> Hi sean, >> >> We also did the transition to JackRabbit 1.3.3 before Magnolia did. And >> we >> are facing to the same problem. I would enjoy to work with you to solve >> this issue or at least to find a hack or some workaround. >> >> Regards, >> >> CAPITAINE Harold >> >> >>> Hi Folks, >>> >>> We upgraded to Jackrabbit 1.3.3 over the break, looking forward to >> the >>> performance and reliability enhancements it promised. Unfortunately, >> we >>> have >>> found that it uses a ton more memory than the older version of >> Jackrabbit >>> did. As a result, our public instance has become very unstable, as it >>> tends >>> to exhaust the available 1GB within about 75 minutes. Since we're >> using >>> BDB >>> as our data store, having to forcibly shut down tomcat also appears >> to be >>> introducing data corruption, as we've been having more and more nodes >> that >>> are unable to be updated or deleted in the public instance. This, of >>> course, >>> makes our users very unhappy indeed. >>> >>> Since the memory use appears to grow steadily, this seems very much >> like a >>> memory leak, and appears to be present both when using BDB or >> PostGreSQL >>> for >>> persistence, and under both Magnolia 3.0.5 and Magnolia 3.5. >>> >>> We're faced now with reverting to the earlier version of Jackrabbit >> and >>> tweaking the XML for all of our 200 sites so that it can be imported >> by >>> the >>> earlier version of Jackrabbit. >>> >>> Needless to say, we'd very much like to avoid this scenario. If any >> one >>> can >>> provide any help to get Jackrabbit 1.3.3's memory usage under >> control, >>> we'd >>> very much like to hear it. >>> >>> Thanks in advance for any insight. >>> >>> Sean >>> >>> >>> ---------------------------------------------------------------- >>> for list details see >>> http://documentation.magnolia.info/docs/en/editor/stayupdated.html >>> ---------------------------------------------------------------- >>> >> >> >> >> >> >> >> ---------------------------------------------------------------- >> for list details see >> http://documentation.magnolia.info/docs/en/editor/stayupdated.html >> ---------------------------------------------------------------- > > ---------------------------------------------------------------- > for list details see > http://documentation.magnolia.info/docs/en/editor/stayupdated.html > ---------------------------------------------------------------- ---------------------------------------------------------------- for list details see http://documentation.magnolia.info/docs/en/editor/stayupdated.html ----------------------------------------------------------------
