All thanks to Luis Filipe Nassif for diagnosis and the patch! > I have some minor modifications/simplifications Y, I wanted to change as little as possible. It is probably better to move all of the checks we do for "is this a cleaner" in unmap() up to the point where we add to the buffer. It felt suboptimal (but completely reasonable for now) to rely on ByteBuffer.allocate() to create something that didn't need to be cleaned...across all versions of Java, etc.
-----Original Message----- From: Dominik Stadler [mailto:dominik.stad...@gmx.at] Sent: Thursday, September 15, 2016 9:15 AM To: POI Developers List <dev@poi.apache.org> Subject: Re: [VOTE] Apache POI 3.15 (RC2) Hi, The mem-leak patch looks good and sane! I am still not sure how they end up with such a large amount of allocated memory for one file, but it is surely better to not keep the buffers if we do not need the special handling during close() anyway. I have some minor modifications/simplifications around these statements that I will apply post-release Dominik. On Thu, Sep 15, 2016 at 2:01 PM, Allison, Timothy B. <talli...@mitre.org> wrote: > >* I'll take a look at the patch on TIKA-2058, if it's low-risk it can > >go > in > I committed Luis Filipe Nassif's patch last night (BUG 60140). Please > do take a look to make sure the change doesn't cause any unforeseen problems. > > >> * I could do with input from those who use HSLF about whether to > >> hold > up another RC for the issue below. > > I've already patched the HSLF issue yesterday > > Thank you, Andi! > > > -----Original Message----- > From: David North [mailto:dtn-...@corefiling.co.uk] > Sent: Thursday, September 15, 2016 4:16 AM > To: dev@poi.apache.org > Subject: Re: [VOTE] Apache POI 3.15 (RC2) > > OK, current status: > > * I'll take a look at the patch on TIKA-2058, if it's low-risk it can > go in > * I could do with input from those who use HSLF about whether to hold > up another RC for the issue below. > > I may not have time to roll RC3 tonight; if not I'll do it tomorrow > night which gives us all the weekend to try it out. > > Thanks, > David > > On 14/09/16 21:39, Javen O'Neal wrote: > > The HSLF footer text regression is still open. > > https://bz.apache.org/bugzilla/show_bug.cgi?id=60003 > > https://issues.apache.org/jira/browse/TIKA-2013 > > > > On Sep 14, 2016 12:43 PM, "Dominik Stadler" <dominik.stad...@gmx.at> > wrote: > > > >> Hi, > >> > >> I'd also rather keep it as is to not break it multiple times. > >> > >> Dominik. > >> > >> On Wed, Sep 14, 2016 at 4:23 AM, Javen O'Neal > >> <javenon...@gmail.com> > >> wrote: > >> > >>> CellValue#getCellType was changed to return an enum after the 3.14 > >> release. > >>> I reverted that signature change in r1760607 (see bug 59791 > >>> comment > 13). > >>> > >>> For bug 59907, I broke backwards compatibility for ClientAnchor > >>> (both > >> HSSF > >>> and XSSF) in r1716313 (first appeared in POI 3.14 beta 1 and > >>> included in POI 3.14 final) without the usual 2 release > >>> deprecation warning. The question is do I restore the behavior of > >>> 3.13 (breaking code a second > >> time > >>> for anyone who upgraded their code to 3.14, and a third time > >>> whenever we retire the int code), or do we leave it as is and ask > >>> users to upgrade to the enum getter now? > >>> > >>> Looking at the code example from bug 59907 comment 1, the fix for > >>> them is > >>> simple: delete ".getValue()". > >>> > >>> On Sep 13, 2016 09:06, "Javen O'Neal" <javenon...@gmail.com> wrote: > >>> > >>>> I will commit a fix for this today with the goal for backwards > >>>> compatibility. > >>>> > >>>> Here's the plan: > >>>> getX() returns int > >>>> getXEnum() returns enum > >>>> setX(int) > >>>> setX(enum) > >>>> > >>>> I will also take a look at bug 59907 (client anchor enum) > >>>> > >>>> On Sep 13, 2016 6:58 AM, "David North" <dtn-...@corefiling.co.uk> > >> wrote: > >>>> > >>>>> Javen, any thoughts on this one? > >>>>> > >>>>> On 13/09/16 12:14, Dominik Stadler wrote: > >>>>>> Hi, > >>>>>> > >>>>>> I really hate to delay this further, but unfortunately we have > >>>>>> a > >>> similar > >>>>>> problem in class CellValue as we tried to fix in Cell in RC2, > >>>>>> the > >>>>>> getCellType() is now an enum whereas it was an int before, so > >>> something > >>>>>> like the following in user-code does break in POI 3.15: > >>>>>> > >>>>>> CellValue cellValue = checkAndGetCellValue(evaluator, sheet, > >>>>>> line); > >>>>>> > >>>>>> switch (cellValue.getCellType()) { > >>>>>> case Cell.CELL_TYPE_STRING: > >>>>>> > >>>>>> > >>>>>> I am sorry that I did not see this earlier but this can lead to > >>>>>> the > >>> same > >>>>>> incompatibility as we had in Cell before. > >>>>>> > >>>>>> Dominik. > >>>>>> > >>>>>> On Sun, Sep 11, 2016 at 9:46 PM, David North > >>>>>> <dno...@apache.org> > >>> wrote: > >>>>>> > >>>>>>> Hi everyone, > >>>>>>> > >>>>>>> My apologies for going AWOL in the middle of the last release > >>> attempt. > >>>>> I > >>>>>>> didn't anticipate that we'd find problems in review twice in a > >>>>>>> row, > >>> and > >>>>>>> things have been very busy for me at work lately. However, > >>>>>>> I've now rolled a second RC for 3.15. > >>>>>>> > >>>>>>> https://dist.apache.org/repos/dist/dev/poi/3.15-RC2/ > >>>>>>> > >>>>>>> Areas to review: > >>>>>>> > >>>>>>> * Does it work? > >>>>>>> * Are the sigs and hashes valid? > >>>>>>> * Have the issues with the last RC been fixed? > >>>>>>> * Are the release notes now in good shape? > >>>>>>> > >>>>>>> The vote starts now and ends at 20:55 BST on Tuesday 13 > >>>>>>> September > >>> 2016. > >>>>>>> > >>>>>>> Here is my +1. > >>>>>>> > >>>>>>> After this release is done, I'll try and find some time to > >>>>>>> profile > >>> the > >>>>>>> build & tests - 15 minutes is quite a wait on an SSD (it's > >>>>>>> possible > >>> we > >>>>>>> might want some multi-threaded options on the tests). > >>>>>>> > >>>>>>> Thanks, > >>>>>>> > >>>>>>> -- > >>>>>>> David North | www.dnorth.net > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> ---------------------------------------------------------------- > >>>>> -- > >>>>> --- To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For > >>>>> additional commands, e-mail: dev-h...@poi.apache.org > >>>>> > >>>>> > >>> > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional > commands, e-mail: dev-h...@poi.apache.org > >
