Bug #2938: Rudder 2.4.0 could crash about OutOfMemory while reading file - Rudder - Issue Tracker

Actions

Copy link

Bug #2938

closed

Rudder 2.4.0 could crash about OutOfMemory while reading file

Added by Nicolas PERRON about 12 years ago. Updated over 9 years ago.

Status:

Rejected

Priority:

Assignee:

Nicolas CHARLES

Category:

Packaging

Target version:

2.4.2

Pull Request:

Severity:

UX impact:

User visibility:

Effort required:

Priority:

Name check:

Fix check:

Regression:

Description

Rudder 2.4.0.beta5 was used on a SLES 11 64 bits with 1550 Mb of RAM and with these options in /etc/default/jetty:

-server
-Xms1024m -Xmx1024m
-XX:PermSize=128m -XX:MaxPermSize=256m
-XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC
-XX:+PrintGCDetails
-Xloggc:/var/log/rudder/gc.log
-Drudder.configFile=/opt/rudder/etc/rudder-web.properties
-Drudder.authFile=/opt/rudder/etc/rudder-users.xml
-Dinventoryweb.configFile=/opt/rudder/etc/inventory-web.properties
-Dlogback.configurationFile=/opt/rudder/etc/logback.xml
-Drun.mode=production"

The error messages in /var/log/rudder/webapp/XXXXX.log:

[...]
2012-09-24 17:32:13.439:WARN::Error for /rudder/javascript/jquery/ui/jquery-ui-1.8.13.custom.js
java.lang.OutOfMemoryError
        at java.io.UnixFileSystem.getBooleanAttributes0(Native Method)
        at java.io.UnixFileSystem.getBooleanAttributes(Unknown Source)
        at java.io.File.isDirectory(Unknown Source)
        at org.eclipse.jetty.util.resource.FileResource.isDirectory(FileResource.java:232)
        at org.eclipse.jetty.util.resource.FileResource.addPath(FileResource.java:139)
        at org.eclipse.jetty.server.handler.ContextHandler.getResource(ContextHandler.java:1356)
        at org.eclipse.jetty.webapp.WebAppContext.getResource(WebAppContext.java:370)
        at org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1190)
        at net.liftweb.http.provider.servlet.HTTPServletContext.resource(HTTPServletContext.scala:34)
        at net.liftweb.http.provider.HTTPProvider$class.isLiftRequest_$qmark(HTTPProvider.scala:139)
        at net.liftweb.http.LiftFilter.isLiftRequest_$qmark(LiftServlet.scala:757)
[...]

Rudder was not used when the error appeared.

Actions

Copy link

Updated by Nicolas PERRON about 12 years ago

The log about Garbage Collector doesn't seem to add enough informations but didn't displayed any anormal state. Sadly, the logs have been erased after a restart of Jetty.

Actions

Copy link

Updated by Nicolas CHARLES about 12 years ago

Category set to 11
Status changed from New to Discussion
Assignee set to Nicolas PERRON

There is something odd here :
- it fails on openning a JS script. How can it happen if Rudder is not used ?
- we really need to see the output of the gc log, and compare it with the eventlog database to see if some actions uses too much memory

One last point : it seems all the OOM happen on SLES... something may be wrong with the Jetty shipped on SLES?

Actions

Copy link

Updated by Nicolas PERRON about 12 years ago

Nicolas CHARLES wrote:

There is something odd here :
- it fails on openning a JS script. How can it happen if Rudder is not used ?

I was surely meant to say that before to try to go to a page on Rudder, no action was led on Rudder.

- we really need to see the output of the gc log, and compare it with the eventlog database to see if some actions uses too much memory

I don't have these logs... and I"ve noticed that after each restart of Jetty, gc.log is reinitialized.

One last point : it seems all the OOM happen on SLES... something may be wrong with the Jetty shipped on SLES?

I don't think so, this is the same binaries and located at the same directories. This bug was discovered on my VirtualBox VM which seems to not be stable.

Actions

Copy link