WEBSPHERE?: ModificationWatcher OutOfMemory errors

[RUMikeP]

Hi

After starting my local Webpshere Application Server (6.1.0.15), running my wicket application (1.3.4) in development mode, the ModificationWatcher appears to devour memory, until eventually I get out of memory exceptions (when my latest exception occured, my wicket instance was using 1.7GB (less than 10 pages visited).

If I run in deployment mode, the memory use is stable as it does not invoke the ModificationWatcher.

Anyone else seeing this behaviour on Websphere or have any guesses?  Will have a closer look myself as soon as I get a chance, but hoping that someone else has seen this before ...

[7/16/08 12:33:33:465 CAT] 00000046 Task          E org.apache.wicket.util.thread.Task$1 run Task ModificationWatcher terminated
                                 java.lang.OutOfMemoryError: ZIP004:OutOfMemoryError, MEM_ERROR in inflateInit2
        at java.util.zip.Inflater.init(Native Method)
        at java.util.zip.Inflater.<init>(Inflater.java:105)
        at java.util.zip.ZipFile.getInflater(ZipFile.java:416)
        at java.util.zip.ZipFile.getInputStream(ZipFile.java:359)
        at java.util.zip.ZipFile.getInputStream(ZipFile.java:324)
        at com.ibm.ws.classloader.Handler$ClassLoaderURLConnection.getInputStream(Handler.java:288)
        at org.apache.wicket.util.resource.UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)
        at org.apache.wicket.markup.MarkupResourceStream.lastModifiedTime(MarkupResourceStream.java:144)
        at org.apache.wicket.util.watch.ModificationWatcher$1.run(ModificationWatcher.java:176)
        at org.apache.wicket.util.thread.Task$1.run(Task.java:115)
        at java.lang.Thread.run(Thread.java:810)

Notes: 1.  the only zips/jars are the wicket-related jars in the web-inf/lib dir
          2.  it is not possible to deploy my app on Tomcat, but the wicket-examples deployed on tomcat in development mode does not create the same issue.

Thanks
Mike

[Johan Compagner]

wicket has special support for that:

    if (urlConnection instanceof JarURLConnection)
                {
                    JarURLConnection jarUrlConnection =
(JarURLConnection)urlConnection;
                    URL jarFileUrl = jarUrlConnection.getJarFileURL();
                    URLConnection jarFileConnection =
jarFileUrl.openConnection();
                    try
                    {
                        lastModified = jarFileConnection.getLastModified();
                    }
                    finally
                    {
                        jarFileConnection.getInputStream().close();
                    }
                }
                else
                {
                    close = true;
                    lastModified = urlConnection.getLastModified();
                }

and then in the finally:

if (urlConnection != null)
                {
                    if (urlConnection instanceof HttpURLConnection)
                    {
                        ((HttpURLConnection)urlConnection).disconnect();
                    }
                    else if (close)
                    {
                        try
                        {
                            urlConnection.getInputStream().close(); << 293
                        }
                        catch (Exception ex)
                        {
                            // ignore
                        }
                    }
                }


thats inside UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)

So it seems that websphere has its own jar/zip handler thats not a
JarURLConnection

and if that is the case we ask really for the entry the last modified
instead of just of the jar file..
That means that it constantly must open it and so on. And now we are
encountering a problem  with all those URLConnections
there is not good way to close one... So we try to do it with
getInputStream().close()

johan




On Wed, Jul 16, 2008 at 2:34 PM, RUMikeP <mikep@...> wrote:

>
> Hi
>
> After starting my local Webpshere Application Server (6.1.0.15), running
> my
> wicket application (1.3.4) in development mode, the ModificationWatcher
> appears to devour memory, until eventually I get out of memory exceptions
> (when my latest exception occured, my wicket instance was using 1.7GB (less
> than 10 pages visited).
>
> If I run in deployment mode, the memory use is stable as it does not invoke
> the ModificationWatcher.
>
> Anyone else seeing this behaviour on Websphere or have any guesses?  Will
> have a closer look myself as soon as I get a chance, but hoping that
> someone
> else has seen this before ...
>
> [7/16/08 12:33:33:465 CAT] 00000046 Task          E
> org.apache.wicket.util.thread.Task$1 run Task ModificationWatcher
> terminated
>                                 java.lang.OutOfMemoryError:
> ZIP004:OutOfMemoryError, MEM_ERROR in inflateInit2
>        at java.util.zip.Inflater.init(Native Method)
>        at java.util.zip.Inflater.<init>(Inflater.java:105)
>        at java.util.zip.ZipFile.getInflater(ZipFile.java:416)
>        at java.util.zip.ZipFile.getInputStream(ZipFile.java:359)
>        at java.util.zip.ZipFile.getInputStream(ZipFile.java:324)
>        at
>
> com.ibm.ws.classloader.Handler$ClassLoaderURLConnection.getInputStream(Handler.java:288)
>        at
>
> org.apache.wicket.util.resource.UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)
>        at
>
> org.apache.wicket.markup.MarkupResourceStream.lastModifiedTime(MarkupResourceStream.java:144)
>        at
>
> org.apache.wicket.util.watch.ModificationWatcher$1.run(ModificationWatcher.java:176)
>        at org.apache.wicket.util.thread.Task$1.run(Task.java:115)
>        at java.lang.Thread.run(Thread.java:810)
>
> Notes: 1.  the only zips/jars are the wicket-related jars in the
> web-inf/lib
> dir
>          2.  it is not possible to deploy my app on Tomcat, but the
> wicket-examples deployed on tomcat in development mode does not create the
> same issue.
>
> Thanks
> Mike
> --
> View this message in context:
> http://www.nabble.com/WEBSPHERE-%3A-ModificationWatcher-OutOfMemory-errors-tp18486458p18486458.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Johan Compagner]

thats not for classes. Wicket doesnt have by default (there are some
solutions) a class reloader
What you see is for for the markup files (and we also do that for other
resources)

johan


On Thu, Jul 17, 2008 at 10:05 AM, <mikep@...> wrote:

> As always, excellent feedback- a HUGE thank you for your quick and
> insightful reply - much appreciated :-)
>
> Do you think the ability to switch off jar file watching would be useful?
>  I personally would only expect the classes in my project to be reloaded,
> and will probably have to implement this change for our WAS environment
> anyway.
>
> Thanks
> Mike
>
> Johan Compagner wrote:
> >
> > wicket has special support for that:
> >
> >     if (urlConnection instanceof JarURLConnection)
> >                 {
> >                     JarURLConnection jarUrlConnection =
> > (JarURLConnection)urlConnection;
> >                     URL jarFileUrl = jarUrlConnection.getJarFileURL();
> >                     URLConnection jarFileConnection =
> > jarFileUrl.openConnection();
> >                     try
> >                     {
> >                         lastModified =
> > jarFileConnection.getLastModified();
> >                     }
> >                     finally
> >                     {
> >                         jarFileConnection.getInputStream().close();
> >                     }
> >                 }
> >                 else
> >                 {
> >                     close = true;
> >                     lastModified = urlConnection.getLastModified();
> >                 }
> >
> > and then in the finally:
> >
> > if (urlConnection != null)
> >                 {
> >                     if (urlConnection instanceof HttpURLConnection)
> >                     {
> >                         ((HttpURLConnection)urlConnection).disconnect();
> >                     }
> >                     else if (close)
> >                     {
> >                         try
> >                         {
> >                             urlConnection.getInputStream().close(); <<
> 293
> >                         }
> >                         catch (Exception ex)
> >                         {
> >                             // ignore
> >                         }
> >                     }
> >                 }
> >
> >
> > thats inside
> > UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)
> >
> > So it seems that websphere has its own jar/zip handler thats not a
> > JarURLConnection
> >
> > and if that is the case we ask really for the entry the last modified
> > instead of just of the jar file..
> > That means that it constantly must open it and so on. And now we are
> > encountering a problem  with all those URLConnections
> > there is not good way to close one... So we try to do it with
> > getInputStream().close()
> >
> > johan
> >
> >
> >
> >
> > On Wed, Jul 16, 2008 at 2:34 PM, RUMikeP <mikep@...> wrote:
> >
> >>
> >> Hi
> >>
> >> After starting my local Webpshere Application Server (6.1.0.15),
> running
> >> my
> >> wicket application (1.3.4) in development mode, the ModificationWatcher
> >> appears to devour memory, until eventually I get out of memory
> exceptions
> >> (when my latest exception occured, my wicket instance was using 1.7GB
> >> (less
> >> than 10 pages visited).
> >>
> >> If I run in deployment mode, the memory use is stable as it does not
> >> invoke
> >> the ModificationWatcher.
> >>
> >> Anyone else seeing this behaviour on Websphere or have any guesses?
>  Will
> >> have a closer look myself as soon as I get a chance, but hoping that
> >> someone
> >> else has seen this before ...
> >>
> >> [7/16/08 12:33:33:465 CAT] 00000046 Task          E
> >> org.apache.wicket.util.thread.Task$1 run Task ModificationWatcher
> >> terminated
> >>                                 java.lang.OutOfMemoryError:
> >> ZIP004:OutOfMemoryError, MEM_ERROR in inflateInit2
> >>        at java.util.zip.Inflater.init(Native Method)
> >>        at java.util.zip.Inflater.<init>(Inflater.java:105)
> >>        at java.util.zip.ZipFile.getInflater(ZipFile.java:416)
> >>        at java.util.zip.ZipFile.getInputStream(ZipFile.java:359)
> >>        at java.util.zip.ZipFile.getInputStream(ZipFile.java:324)
> >>        at
> >>
> >>
> com.ibm.ws.classloader.Handler$ClassLoaderURLConnection.getInputStream(Handler.java:288)
> >>        at
> >>
> >>
> org.apache.wicket.util.resource.UrlResourceStream.lastModifiedTime(UrlResourceStream.java:293)
> >>        at
> >>
> >>
> org.apache.wicket.markup.MarkupResourceStream.lastModifiedTime(MarkupResourceStream.java:144)
> >>        at
> >>
> >>
> org.apache.wicket.util.watch.ModificationWatcher$1.run(ModificationWatcher.java:176)
> >>        at org.apache.wicket.util.thread.Task$1.run(Task.java:115)
> >>        at java.lang.Thread.run(Thread.java:810)
> >>
> >> Notes: 1.  the only zips/jars are the wicket-related jars in the
> >> web-inf/lib
> >> dir
> >>          2.  it is not possible to deploy my app on Tomcat, but the
> >> wicket-examples deployed on tomcat in development mode does not create
> >> the
> >> same issue.
> >>
> >> Thanks
> >> Mike
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/WEBSPHERE-%3A-ModificationWatcher-OutOfMemory-errors-tp18486458p18486458.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
> Quoted from:
>
> http://www.nabble.com/WEBSPHERE-%3A-ModificationWatcher-OutOfMemory-errors-tp18486458p18489140.html
>
>