db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Korneliussen <Andreas.Kornelius...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-1497) assert failure in MessageUtil, because exception thrown with too many parameters when handling OutOfMemoryError
Date Tue, 11 Jul 2006 15:34:59 GMT
Bryan Pendleton (JIRA) wrote:
>     [ http://issues.apache.org/jira/browse/DERBY-1497?page=comments#action_12420324 ]

> 
> Bryan Pendleton commented on DERBY-1497:
> ----------------------------------------
> 
> It seems like it would be nice if we printed the original exception's stack trace
> somewhere prior to discarding it.
> 
> Otherwise, when this happens, all we'll know is that we ran out of memory, but we
> will lose some potentially useful information about exactly which line of code we
> were on when we ran out of memory.
> 
> 
Unless the streaming could be fixed so that we avoid outofmemoryerrors 
on the receiver side, I would propose the following:

We know the size of the LOB, and can check if it can go into memory 
(using the Runtime class). If it cannot go into memory, we can throw an 
SQLException, instead of consuming all memory in the VM until we get 
OutOfMemoryError, catch the OutOfMemoryException and throw a new 
SQLException.

I think this approach is better, because of the following:

* Although it is the LOB which is taking almost all the memory in the 
VM, the OutOfMemoryError may be thrown in another thread in the VM, 
causing side-effects on other connections or on the application itself.
* We may actually go out of memory when trying to create a new 
SQLException in the error handler for the OutOfMemoryError

I think this could be done both on the server side and the client side.

-- Andreas

Mime
View raw message