Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of rporras@agssa.net designates
 190.184.22.61 as permitted sender)
Received-SPF: pass (agssa.net: 10.0.0.14 is whitelisted) receiver=agssa.net;
 client-ip=10.0.0.14; helo=dev06.agssa.net; envelope-from=rporras@agssa.net;
 x-software=spfmilter 0.97 http://www.acme.com/software/spfmilter/ with
 libspf2-1.0.0;
Message-ID: <4849ABD9.7010002@agssa.net>
Date: Fri, 06 Jun 2008 15:27:53 -0600
From: =?ISO-8859-1?Q?Reynaldo_Porras_Garc=EDa?= <rporras@agssa.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: poi hssf-serializer built in limitation
References: <447D87C2.1060406@outerthought.org>
In-Reply-To: <447D87C2.1060406@outerthought.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi Marc,

I got hit by this issue. I found the answer to your questions in the 
following thread:

http://markmail.org/message/d4iemconxozxgb2v

I did my own tests in a recent cocoon revision 2.1.12-dev (r662435) 
running on 64M of Memory and I found if a StyleRegion is around 2^22 
cells it throws out an OOME. Hence it looks that the limit makes sense.

Here is the sample region I tested:

<gmr:StyleRegion startCol="0" startRow="0" endCol="255" endRow="16383">
.....
</gmr:StyleRegion>

On the other side the current limit of 2,000 cells is quite low. I think 
we can change it to a higher value up to 2^21 to stay safe in a 64MB 
environment. But the problem is that it generates a huge XLS document of 
20MB. Another problem I found switching to 2^21 is that I cannot 
generated the same document a 2nd time.

Perhaps switching from 2K to 2^16 as suggested by Matt Savino in his 
mail makes sense. Quoting:

"I changed the MAX_AREA constant to 65536 so that it could handle one entire
column. I saved the Excel file using both MAX_AREAs and at least for my app
there was no appreciable difference in file size (765k v. 766k)."

WDYT?

Best Regards,


Reynaldo Porras 


Marc Portier escribi�:
> Hi there,
>
> I've ran accross a hard-coded limit in our ms-excel-format serizalizer
> (and it looks like I'm the second one :-)
>  http://issues.apache.org/bugzilla/show_bug.cgi?id=24490 )
>
> $ find -name EPStyleRegion.java |xargs cat -n |head -65|tail
> $ find -name EPStyleRegion.java |xargs cat -n |head -102|tail -16
>
> It causes style-formatting-regions to be ignored if they span more then
> 2000 cells.
>
> Apart from the (to me quite dense) remarks in the code there is little
> to be found about what are the actual motives for this, or how we could
> assess if the limitations still stand in todays world or not.
>
> In fact, in terms of code-evolution I could only find this limit
> appeared to be in the original commit already.
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=103825320630080&w=2
>
>
> Does anybody remember anything about this?
> Does anybody have an idea about verifying if the limitation could be
> removed?
>
> kind regards,
> -marc=
>