I can comment on at least a couple of the issues you've raised.
Drew Cox wrote:
> Hi JSP enthusiasts,
>
> Ever since I started playing more seriously with JSP's a few months ago
> (ie. getting paid for it), I have been suffering what appears to be
> memory leaks in the web apps. Or maybe not ? I'm hoping someone can
> give me a few pointers on how to further investigate this. The runtime
> environment is JDK 1.2.2, JSWDK 1.0, Win NT 4.0, MS Access 98.
>
> The web app is a simple affair, about 4 different JSP pages (no
> servlets) that query and MS Access database using search criteria
> entered in form fields and produce various reports. Each JSP page has
> some session and request scoped beans defined with <jsp:usebean> and
> then your normal scriptlets and jsp tags to produce the result. I have
> appended the text of one of the pages at the end of this message, if
> anyone is *really* keen...
>
> (I have to tell you, this stuff is SOOO much better to develop and
> maintain than the ASP apps we have done in the past, even without the
> tag extensions comming in 1.1)
>
> The thing is, after I start the JSWDK server and exercise each page, the
> Win NT Task Manager shows the java.exe VM using about 12Mb of virtual
> memory. Over a few days (probably only 100 page hits), this will creep
> up to about 25Mb, at which stage I normally stop and restart the server
> and it goes back to 12Mb. If I let it go long enough, The JSWDK server
> will get an "Out of virtual memory" error from NT. Has anyone else had
> this sort of problem ?
>
What do you have the "maximum heap size" of your VM set for in the command line
that starts up the JSWDK server? If I remember right, the default for JDK 1.2.2
is 32 megabytes -- which means that the Java garbage collector won't forcibly kick
in until the allocated heap approaches that value (unless you call it yourself
using Runtime.gc()).
>
> I have gone though all the bean code and make sure I am closing all the
> JDBC result sets and prepared statements, I had read that these can
> cause leaks in the JDBC-ODBC driver ?
>
Not closing JDBC result sets and statements is one of the most common causes of
memory consumption. Another is if you maintain any references to variables that
you aren't really using any more.
I don't use the JDBC-ODBC driver, so can't comment on any memory links it might
have. I do note that, at least in previous versions, the documentation did not
encourage using this driver in production systems.
>
> My current thought is that perhaps the session stored beans are never
> being released and thus stopping the tree of objects they reference from
> being GC'd ? There is a bit in the webserver.xml comments that reads
>
> The WebApplication.maxInactiveInterval is not
> utilized at this time and will likely specify
> the "session time out in minutes" threshold in
> a future release.
>
> Does this mean that sessions never time-out ? I'm pretty sure that when
> I close the browser and reconnect I get a new session, which I think
> makes sense because I belive the session mechanism uses non-persistant
> cookies. But maybe the old session is still hanging around in the
> server forever ?
>
This property will be used in the future (presumably) to set the *default* timeout
interval for sessions. The current default is "never time out", but you can
modify it yourself on a per-session basis with
HttpSession.setMaxInactiveInterval().
>
> This would be bad, as most of my beans keep a reference to the last
> calling page context, to get access to the various bean scopes. (This
> in itself is not ideal, as it makes it impossible to make the JSP page
> thread-safe, I'm working on something different, but suggestions on this
> are also welcome!)
>
> So, can someone out there *confirm* that sessions definately do timeout
> (after how long ?) and the JSWDK de-references all objects stored in the
> session scope ? I can then rule that out as my problem.
>
I can confirm that if you set your own timeout interval, the JSWDK 1.0 final
release does in fact time out your sessions. If your user interface includes a
"log on" action, you can also train users to invoke it when they are done, and
invalidate() the session immediately for the users that actually do this.
>
> Failing that, any suggestions on how to investigate this sort of problem
> would be appreaciated. I did manage to get the JSWDK 1.0 ea running
> under the JProbe evaluation, but I could not find anything conclusive,
> due to my lack of expertise with the product. It looks like I may have
> to invest some more time there....
>
My experience has been that it's pretty hard to tell if you have a "real" memory
leak in a long-running Java application, because the amount of free memory goes up
and down dramatically in normal use. But you will definitely want to configure
the maximum heap size to match how much physical+virtual memory your server has
available, to avoid OS-level (as opposed to Java exception level) out of memory
errors. For maximum performance, you will also want to use just physical memory
with no OS-level swapping.
Memory issues aside, you will want to switch to the final release due to bug
fixes. One annoying thing is that the EA release had a bug that made you use the
word "imports" in your page directive, while the final release obeys the spec and
uses the word "import" instead.
>
> Thanks
>
> Drew Cox
> Barrack Consulting
>
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
