Rick Hillegas wrote:
I volunteer to manage a 10.4 maintenance release at the end of August.
Thanks for volunteering, Rick!
Specifically, I would like to:
1) Circulate release notes the week of August 18.
2) Post a release candidate the week of August 25.
Could the community be ready for a release at the end of August? In
particular
A) By the evening of August 18, could people be done posting their
release notes?
I don't think any of my fixes will require a release note.
B) By the evening of August 25, could people be done porting their
important bug fixes to 10.4?
I'm on vacation starting August 8, and will be back August 25. So I have
to get everything done this week. I'll summarize what I have been
working on for the 10.4.2 release below. Most issues are regarding LOBs
or connection pooling environments.
The following Jiras are on my list of current important fixes:
DERBY-3799 : NPE with LOBs seen when using connection pooling
DERBY-3791 : Excessive memory usage when fetching small Clobs
DERBY-3766 : EmbedBlob.setPosition is highly ineffective for streams
These have all been committed to trunk already, but DERBY-3791 and
DERBY-3766 have to be backported.
In addition the following issues are already backported to 10.4:
DERBY-3735 : Incorrect position calculation in PositionedStoreStream
with read(byte[],...)
DERBY-3768 : Make EmbedBlob.length use skip instead of read
DERBY-3769 : Make LOBStoredProcedure on the server side smarter about
the read buffer size
DERBY-3781 : PositionedStoreStream.reposition(pos) with pos greater
than length leaves the stream object in an inconsistent state
DERBY-3783 : LOBStreamControl shouldn't throw SQLException
DERBY-3596 : Creation of logical connections from a pooled connection
causes resource leak on the server
There are more fixes coming in this area of the code, but I probably
won't have time to get them done for 10.4.2.
BTW; If anyone has some free cycles, I would appreciate some input on
DERBY-2822 (Add caching of store stream length in StoreStreamClob, if
appropriate), which should be a rather simple fix if it is valid. It was
when looking a bit into this I observed DERBY-3811.
regards,
--
Kristian
Thanks,
-Rick
