Bugzilla – Full Text Bug Listing
| Summary: | "resourceContains" causes out of memory errors during fast fail check | ||
|---|---|---|---|
| Product: | [WebTools] WTP Releng | Reporter: | David Williams <david_williams> |
| Component: | releng | Assignee: | David Williams <david_williams> |
| Status: | RESOLVED FIXED | QA Contact: | David Williams <david_williams> |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 3.10 | ||
| Target Milestone: | 3.10.0 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
David Williams
I've disabled the test for "fast failure" cases by using a if="checkForFastFailReasons" on the task (which is not set). We were running at the relatively lean 256M for max memory, so I raised that to 380M also ... just to play it safe, but will leave the fast fail check disabled for now. I have confirmed, from looking at Ant source, that ResourceContains does indeed read in a whole file. So, improved task will be needed, given that we have huge log files. I'm tempted just to use OS's grep via 'exec' task.
= = = =
reader = new BufferedReader(new InputStreamReader(resource.getInputStream()));
String contents = FileUtils.safeReadFully(reader);
String sub = substring;
if (!casesensitive) {
contents = contents.toLowerCase();
sub = sub.toLowerCase();
}
return contents.indexOf(sub) >= 0;
I've fixed the immediate problem by use 'grep' instead of ant task. While not portable, it'll be good to use for a while, and see a) if it helps enough to justify a new task, and b) once we do new task, what should requirements be. (For example, single pass through a file?) c) just how many "specific" things will we find to test for? In general, anytime there is a "build failed" there is probably a more specific reason we could check for, which makes it much much easier to diagnose build problems (by any one just looking at failure ... won't necessarily have to sign on in shell and browse around 100 M log file. One bad, or at least odd, thing about using grep, is that is returns a "return code" of 1 when there is no match. And then Ant and CC logging displays it in "error red" in some logs ... and since currently checking for 4 strings, 4 greps, comes back with following, for each main build step. Kind of ugly, but doesn't hurt much, I guess. checkForString [ exec ] Result: 1 checkForString [ exec ] Result: 1 checkForString [ exec ] Result: 1 checkForString [ exec ] Result: 1 |