[
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16348998#comment-16348998
]
Saleem Akbar commented on COLLECTIONS-599:
------------------------------------------
I also came across this problem (in my scenario I ended up with an
out-of-memory error using non-sticky session replication) and also figured out
the same solution, which was to to calculate the threshold before populating
the data.
Anyway, I've submitted the following PR's for 3.2.x (we're currently using
3.2.2) and master.
[https://github.com/apache/commons-collections/pull/34]
[https://github.com/apache/commons-collections/pull/35]
If approved, could we please have an official 3.2.x release (at this point
3.2.3) asap?
Cheers
Saleem
> HashEntry array object naming data initialized with double the size during
> deserialization
> ------------------------------------------------------------------------------------------
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
> Issue Type: Bug
> Components: Collection, Map
> Affects Versions: 3.1
> Reporter: Tejas Patel
> Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks
> including struts2.
> Supose a LinkedMap object it is created and have size greater than zero is
> serialized. While deserializing this object , array of HashEntry naming data
> delacred in AbstractHashedMap always initialises with a new capacity of
> double its double of the serialized object.
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
> {
> if (this.size >= this.threshold)
> {
> int newCapacity = this.data.length * 2;
> if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
