See:
http://blog.sleepycat.com/2006/04/adler32-vs-gc.html
There's a risk of spurious OutOfMemoryError conditions
because the Sun JVM adler32 code temporarily locks GC,
and in a multi-threaded application, another thread
could need memory during that lock -- memory that would
be available if GC could occur, but isn't because of
the lock, throwing a OOME.
Using an optional BDB-JE flag can remove this risk for
BDB Adler32 operations. (There's still a risk elsewhere
because inflate/deflate native code does the same
thing... but there's no straightforward way to mitigate
that in the short term.)
Gordon Mohr
Memory
1.8.0
Public
|
Date: 2007-03-14 01:06
|
|
Date: 2006-05-05 22:29 Logged In: YES |
|
Date: 2006-05-05 21:44 Logged In: YES |
| Filename | Description | Download |
|---|---|---|
| heritrix-adler32-1482761-patch.txt | Download |
| Field | Old Value | Date | By |
|---|---|---|---|
| status_id | Open | 2006-05-05 22:37 | gojomo |
| resolution_id | None | 2006-05-05 22:37 | gojomo |
| close_date | - | 2006-05-05 22:37 | gojomo |
| assigned_to | stack-sf | 2006-05-05 22:29 | stack-sf |
| File Added | 176982: heritrix-adler32-1482761-patch.txt | 2006-05-05 21:44 | gojomo |
| assigned_to | gojomo | 2006-05-05 21:44 | gojomo |
Copyright © 2010 Geeknet, Inc. All rights reserved. Terms of Use