james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Perry" <d.pe...@netcase.co.uk>
Subject RE: Working towards a release
Date Tue, 08 Nov 2005 09:01:07 GMT
> I am still concerned about the Derby related crash that I saw earlier.
> Anyone have a clue?  And is there anything that we need to do to cleanly
> shut Derby down?
> 	--- Noel

Given that the whole crash starts with: java.lang.OutOfMemoryError, then
maybe that caused the problem with derby.

Does anyone know anything about derby's behaviour when it runs out of
memory? I'd imagine that these errors are caught in any code that uses a lot
of memory (ie loading data) but what about other parts of code that arnt as
likely to cause that kind of problem?

I know very little about derby, but i have used hsqldb before.  It had
similar problems - if one instance of the driver opened a database, other
instances couldnt write to them (or read iirc).  So if you managed to crash
that instance of the database, you had to restart the container before you
could use it again.

This is a problem with built in java databases, and java in general.  It's a
shame there isnt a way to allocate java memory to specific services (ie,
allocate xMB to derby, xMB to core, xMB to remotedelivery, etc).

Have you tried reinstating the memory leak to see if the same crash occurs?


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message