I agree with this statement. We've been using Glassfish 2 for a few years
now, as a platform for serving our JSF application (JSF only, no EJB or
other aspects of the JavaEE stack). We have run into problems, but a great
many of them were faults in our own application. Tools like VisualVM have
been instrumental in isolating these. The majority of the issues introduced
by our applicaiton were thread synchronization issues, with the odd memory
leak thrown in.
There have been cases where the issues were caused by components provided by
Glassfish, however.
- The version of Grizzly which shipped with the release of Glassfish had a
memory leak, which caused the application to run out of memory. Upgrading
to the latest version of Grizzly (appropriate for GF v2) fixed this error.
- The Sun EL implementation also caused some memory leaks, in how it pooled
EL expressions. We found that the Apache EL implementation didn't, so we
built a hybrid version and deploy that with our application when we deliver.
While it would be very nice if the official release did not deliver with
these bugs, it is worth saying that the architecture of GF made it very easy
to upgrade/replace these components, so that these issues could be
addressed.
Hope this helps,
Ed
On Sat, Aug 27, 2011 at 3:38 AM, <forums_at_java.net> wrote:
> [quote=seagate]
>
> either 2 or more times a day or every 2 days the glassfish stops and
> requires
> restart.
>
> meanwhile many of our clients are very upset and they mentioned to cancel
> their subscription.
>
> or the Glassfish says something like heap memory out of space.
>
> Please, I do not need answers like "Increase your memory!" I have already
> assigned 2.8 GB for the heap
>
> that should not only be enough, that's non-sense!
>
> [/quote]
>
> We've been using GlassFish in production since 2007. Over the years we've
> encountered about 10 issues that caused OOME crashes. Some issues took
> weeks or even months to diagnose, but in the end every single one of the
> issues was the application's fault. We use jVisualVM to capture live heap
> dumps after GlassFish has been running for a while, then analyze it. We
> sort by total instances, or total memory usage, filter by package name
> (such
> as our own company's packages or libraries we use, etc.) and use this as a
> starting point. We've encountered issues related to JPA caching, not
> releasing reasourses, our application leaking threads, etc. So, when we
> encounter an OOME we start by assuming it is our application's issue before
> blaming it on GlassFish.
>
>
>
>