"Bergquist, Brett" <[email protected]> writes: > I have a customer that is periodically having a problem and unknown to > me, they have been accessing the Derby database using a query such as > in the following and have been repeatedly experienced a server issue. > I finally figured out it was an OutOfMemory error (PermGen). So I just > wrote a little application that performs the same query over and over > against a copy of the database and the Derby Network Server. In just a > few hours, the Derby Network Server gave up the ghost with a > OutOfMemory(PermGen) error. > > This is running against Derby 10.8.2.2. There is no other access to > the database from any other process during this test. > > Note that the query returns no data as there are no records in the > database that satisfy the query. Also, note that the table NPAResults > is actually a View that looks like: >
[...] > > Each time I run this sample, after a few hours, the OutOfMemory > occurs. Any ideas on this will be greatly appreciated. Hi Brett, I don't see anything obvious that should cause problems in the code you posted. I tried to run it myself, but it didn't seem to cause any leak in my environment. Of course, I didn't run the exact same code, since I don't know exactly what your table function does. (And I ran it with -XX:MaxPermSize=16M since I didn't want to wait for hours to see the result...) If you manage to come up with a full repro that others could run, it might be easier to see what's going on. By the way, have you changed the statement cache size, or are you running with default size? I'm asking because the size of the statement cache will affect how soon generated classes can be garbage collected. -- Knut Anders
