Grails

With "grails run-app ", Error automatically restarting container: IO error scanning directory

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Cannot Reproduce
  • Affects Version/s: None
  • Fix Version/s: 1.1.1
  • Component/s: None
  • Labels:
    None
  • Environment:
    XUbuntu 8.0.4, Java 1.6.10

Description

Just grails create-app test, then cd test, grials run-app, after minutes, errors reported.
Error automatically restarting container: IO error scanning directory '/opt/studio/test/src/groovy' ...
: IO error scanning directory '/opt/studio/test/src/groovy'
at org.apache.tools.ant.DirectoryScanner.scandir(DirectoryScanner.java:1065)
at org.apache.tools.ant.DirectoryScanner.checkIncludePatterns(DirectoryScanner.java:856)
at org.apache.tools.ant.DirectoryScanner.scan(DirectoryScanner.java:817)
at org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:435)
at org.apache.tools.ant.taskdefs.MatchingTask.getDirectoryScanner(MatchingTask.java:192)
at org.codehaus.groovy.ant.Groovyc.execute(Groovyc.java:535)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at Package_groovy$_run_closure9.doCall(Package_groovy:344)
at RunApp_groovy$_run_closure3.doCall(RunApp_groovy:128)
at RunApp_groovy$_run_closure3.doCall(RunApp_groovy)
at RunApp_groovy$_run_closure1.doCall(RunApp_groovy:61)
at RunApp_groovy$_run_closure1.doCall(RunApp_groovy)
at gant.Gant.dispatch(Gant.groovy:271)
at gant.Gant.this$2$dispatch(Gant.groovy)
at gant.Gant.invokeMethod(Gant.groovy)
at gant.Gant.processTargets(Gant.groovy:436)
at gant.Gant.processArgs(Gant.groovy:372)

I tried with grails 1.0.3, no error reported except "Premature end of file........."

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Huub Daems added a comment -

Did some testing on different systems.

  • OSX 10.4 with jdk1.5 and grails-1.04 – OK
  • WINXP with sun-dk1.5 and grails-1.04 – OK
  • Ubuntu 8.04LTS with sun-jdk15 32bit and grails-1.04-- OK
  • Ubuntu 8.04LTS with sun-jdk16 32bit and grails-1.04-- ERROR
  • Ubuntu 8.04LTS with sun-jdk16 64bit and grails-1.04-- ERROR
  • Ubuntu 8.04LTS with openjdk16 32bit and grails-1.04-- ERROR
    that's all the testing we (Huub & Anton) did for the moment. Seems to be jdk1.6 related. See also GRAILS-3318.
Show
Huub Daems added a comment - Did some testing on different systems.
  • OSX 10.4 with jdk1.5 and grails-1.04 – OK
  • WINXP with sun-dk1.5 and grails-1.04 – OK
  • Ubuntu 8.04LTS with sun-jdk15 32bit and grails-1.04-- OK
  • Ubuntu 8.04LTS with sun-jdk16 32bit and grails-1.04-- ERROR
  • Ubuntu 8.04LTS with sun-jdk16 64bit and grails-1.04-- ERROR
  • Ubuntu 8.04LTS with openjdk16 32bit and grails-1.04-- ERROR that's all the testing we (Huub & Anton) did for the moment. Seems to be jdk1.6 related. See also GRAILS-3318.
Hide
Permalink
Matt Raible added a comment -

Happens for me on OSX with 10.5.6 both in prod and dev mode. I'm running Java 5.

Show
Matt Raible added a comment - Happens for me on OSX with 10.5.6 both in prod and dev mode. I'm running Java 5.
Hide
Permalink
Mikko Taivainen added a comment -

Same here with grails 1.0.4, Ubuntu 8.10 (32 bit) and JDK 1.6 from Sun. After some investigation and test I found the cause (I hope): maximum number of open files per user is exceeded. In Ubuntu the default limit is 1024 files for normal uses and if you think about the Grails environment, all the development files, classes, jars, templates etc., it's quite easy to reach the limit.

Following code simulates the situation (it opens files until a limit is reached):

public class FileListTest {
public static void main(String[] args) throws Exception {
final int N = 2048;
File dir = new File("/home/mikko/src/aplan/aplan-grails/src/groovy");
System.out.println("Trying to open " + N + " files");
InputStream streams[] = new InputStream[N];
for (int i = 0; i < N; i++) {
File f = new File(dir, "test.groovy");
streams[i] = new FileInputStream(f);
String[] files = dir.list();
if (null == files) { System.err.println("File.list() returned null after " + (i + 1) + " opened files"); break; }
}
System.out.println("Your system seems to support at least " + N + " open files");
}
}

Show
Mikko Taivainen added a comment - Same here with grails 1.0.4, Ubuntu 8.10 (32 bit) and JDK 1.6 from Sun. After some investigation and test I found the cause (I hope): maximum number of open files per user is exceeded. In Ubuntu the default limit is 1024 files for normal uses and if you think about the Grails environment, all the development files, classes, jars, templates etc., it's quite easy to reach the limit. Following code simulates the situation (it opens files until a limit is reached): public class FileListTest { public static void main(String[] args) throws Exception { final int N = 2048; File dir = new File("/home/mikko/src/aplan/aplan-grails/src/groovy"); System.out.println("Trying to open " + N + " files"); InputStream streams[] = new InputStream[N]; for (int i = 0; i < N; i++) { File f = new File(dir, "test.groovy"); streams[i] = new FileInputStream(f); String[] files = dir.list(); if (null == files) { System.err.println("File.list() returned null after " + (i + 1) + " opened files"); break; } } System.out.println("Your system seems to support at least " + N + " open files"); } }
Hide
Permalink
Mikko Taivainen added a comment -

After writing the previous comment I started to think about this problem. I wrote that "it's quite easy to reach the limit", and although it's true, the limit should be high enough for normal situations.

I collected some diagnostics data with lsof and results were alarming: there were at least 30 file descriptors open for every groovy file in my project. I'm not sure, but I think that there might be a bug somewhere in grails code that leaves scanned groovy files open.

Show
Mikko Taivainen added a comment - After writing the previous comment I started to think about this problem. I wrote that "it's quite easy to reach the limit", and although it's true, the limit should be high enough for normal situations. I collected some diagnostics data with lsof and results were alarming: there were at least 30 file descriptors open for every groovy file in my project. I'm not sure, but I think that there might be a bug somewhere in grails code that leaves scanned groovy files open.
Hide
Permalink
Mikko Taivainen added a comment -

The problem seems to be in method DefaultGrailsPlugin.checkModified(Resource, long). The method is opening a URLConnection to watched resource(s), but the connection is never explicitly closed. AFAIK FileURLConnection closes the file descriptor in its finalizer, which requires that a) object gets dereferenced and b) gc has collected the object. In this case no object references are kept after the checkModified() method returns, but after some testing I found out that it's easy to reach the 1024 file limit if temporary URLConnection objects are not explicitly closed. I also tested if my GC theory is correct and it seems to be: call to System.gc() releases all the file handles opened by FileURLConnection objects.

Right now I'm using a temporary workaround: I increased the limit of open files from 1024 to 65536. Now the limit is not reached before GC gets a change to do the cleanup.

Please see the checkModified() method:

http://fisheye.codehaus.org/browse/grails/trunk/grails/src/commons/org/codehaus/groovy/grails/plugins/DefaultGrailsPlugin.java?r=7056#l493

Show
Mikko Taivainen added a comment - The problem seems to be in method DefaultGrailsPlugin.checkModified(Resource, long). The method is opening a URLConnection to watched resource(s), but the connection is never explicitly closed. AFAIK FileURLConnection closes the file descriptor in its finalizer, which requires that a) object gets dereferenced and b) gc has collected the object. In this case no object references are kept after the checkModified() method returns, but after some testing I found out that it's easy to reach the 1024 file limit if temporary URLConnection objects are not explicitly closed. I also tested if my GC theory is correct and it seems to be: call to System.gc() releases all the file handles opened by FileURLConnection objects. Right now I'm using a temporary workaround: I increased the limit of open files from 1024 to 65536. Now the limit is not reached before GC gets a change to do the cleanup. Please see the checkModified() method: http://fisheye.codehaus.org/browse/grails/trunk/grails/src/commons/org/codehaus/groovy/grails/plugins/DefaultGrailsPlugin.java?r=7056#l493
Hide
Permalink
Graeme Rocher added a comment -

This has been resolved. The checkModified method no longer uses URLConnection, if you can stil reproduce then please re-open the issue

Show
Graeme Rocher added a comment - This has been resolved. The checkModified method no longer uses URLConnection, if you can stil reproduce then please re-open the issue

People

Vote (4)
Watch (6)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.1#660-r161644) | Report a problem
Powered by a free Atlassian JIRA open source license for Grails project. Try JIRA - bug tracking software for your team.