Re: [POOL2] Pooling mutable objects
On Mon, Feb 09, 2015 at 06:37:32AM -0500, James Carman wrote: Premature optimization. UUIDs aren't slow. Could be indeed. Depends on the specific use case. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
On 09/02/2015 18:47, Adrian Crum wrote: I have been reading this thread for days, and I am confused. I might be wrong, but it seems to me the discussion started with a simple problem - an object borrowed from an object pool could not be returned to the pool because the object's hash value changed. Now the discussion seems to be about how to create the proper hash function so the object can be returned to the pool successfully. In other words, object A can be borrowed from the pool, and object B can be returned to the pool (instead of object A) - as long as object A and object B both return the same hash value. Does that make sense? Is that what you really want? It seems to me the object being returned to the pool should be the same object that was borrowed from the pool. A simple equality check (this object == that object) would do that. What am I missing? That a scalable solution is required when there are 10s or 100s of thousands of objects currently borrowed and we need to work out which one of those is currently being returned. Mark - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Premature optimization. UUIDs aren't slow. On Monday, February 9, 2015, Matthew Hall mh...@mhcomputing.net wrote: On Sun, Feb 08, 2015 at 11:07:59AM +0100, Michael Osipov wrote: How would you propose to use it? I would still need a random number or do you recomment to use a static one and simply increment during the lifetime of the application? If so, thing might cause trouble in the future because I would probably store the session information in a database for analysis issues and woudl have collisions. Michael Then you either have to use real big random's like UUID and accept it'd be slow, or derive the numeric values from a native DB counter (for example, a Redis counter, or a PostgreSQL sequence data type). Matthew. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: user-h...@commons.apache.org javascript:;
Re: [POOL2] Pooling mutable objects
On 9 February 2015 at 05:07, Matthew Hall mh...@mhcomputing.net wrote: On Sun, Feb 08, 2015 at 11:07:59AM +0100, Michael Osipov wrote: How would you propose to use it? I would still need a random number or do you recomment to use a static one and simply increment during the lifetime of the application? If so, thing might cause trouble in the future because I would probably store the session information in a database for analysis issues and woudl have collisions. Michael Then you either have to use real big random's like UUID and accept it'd be slow, or derive the numeric values from a native DB counter (for example, a Redis counter, or a PostgreSQL sequence data type). This is a separate issue from the pooling problem. Depending on how you are intending to create the sessions, it may be possible to use a cheaper method. For example combining system time with System.identityHashCode should work if only a single classloader is ever used at one time. Matthew. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: Re: [POOL2] Pooling mutable objects
On Fri, Feb 06, 2015 at 04:54:25PM +0100, Michael Osipov wrote: This is what I did: this.internalId = RandomStringUtils.randomAlphanumeric(8); When doing these types of tricks to assign transaction ID's or serial numbers to objects / log messages / etc., I'm more of a fan of using AtomicLong. These are handled w/ hardware accelerated instructions, whereas Random consumes lots of CPU on a crypto or semi-crypto algorithm for something which doesn't actually need to be random, and introduces the possibility of collisions, which AtomicLong will prevent, even with many threads. Matthew. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-06 um 22:13 schrieb Matthew Hall: On Fri, Feb 06, 2015 at 04:54:25PM +0100, Michael Osipov wrote: This is what I did: this.internalId = RandomStringUtils.randomAlphanumeric(8); When doing these types of tricks to assign transaction ID's or serial numbers to objects / log messages / etc., I'm more of a fan of using AtomicLong. These are handled w/ hardware accelerated instructions, whereas Random consumes lots of CPU on a crypto or semi-crypto algorithm for something which doesn't actually need to be random, and introduces the possibility of collisions, which AtomicLong will prevent, even with many threads. How would you propose to use it? I would still need a random number or do you recomment to use a static one and simply increment during the lifetime of the application? If so, thing might cause trouble in the future because I would probably store the session information in a database for analysis issues and woudl have collisions. Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-06 um 19:21 schrieb Phil Steitz: On 2/6/15 10:16 AM, sebb wrote: The existing Pool2 implementations use equals() to decide if two objects are the same. As of pool 2.3. You have to make sure that your equals() implementation returns true if and only if the objects being compared are the same as far as your use of them is concerned. So for example two Integers are equal if they have the same integral value, but two different StringBuffer instances are never equal. Once you have determined what constitutes equality for your instances, make sure that the hash code is coded accordingly, i.e. two objects that are equal() must have the same hash code. If this requirment is not met, then the HashMap used internally by Pool2 will behave unpredictably. Also, hash codes should not change between the time that an object is borrowed from the pool and subsequently returned. Again, for pool 2.0-2.3 (latest as of this post), objects under management by the pool are kept in a hashmap keyed on the objects themselves, so mutability that changes hashcodes (and / or equality) can cause problems. See the discussion on POOL-284. If this causes so many discussions and fuzz, it is worth filing another issue which should document how a pooled object should like. Required criteria. That would have spared me the searching. WDYT? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-06 um 17:14 schrieb James Carman: Try UUID.randomUUID().toString() rather than RandomStringUtils if you really want unique keys. Aren't both pseudo random? I won't have more than 30 sessions in parallel. Do you think that a collision might happen? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-06 um 17:14 schrieb James Carman: Try UUID.randomUUID().toString() rather than RandomStringUtils if you really want unique keys. Aren't both pseudo random? I won't have more than 30 sessions in parallel. Do you think that a collision might happen? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-06 um 19:21 schrieb Phil Steitz: On 2/6/15 10:16 AM, sebb wrote: The existing Pool2 implementations use equals() to decide if two objects are the same. As of pool 2.3. You have to make sure that your equals() implementation returns true if and only if the objects being compared are the same as far as your use of them is concerned. So for example two Integers are equal if they have the same integral value, but two different StringBuffer instances are never equal. Once you have determined what constitutes equality for your instances, make sure that the hash code is coded accordingly, i.e. two objects that are equal() must have the same hash code. If this requirment is not met, then the HashMap used internally by Pool2 will behave unpredictably. Also, hash codes should not change between the time that an object is borrowed from the pool and subsequently returned. Again, for pool 2.0-2.3 (latest as of this post), objects under management by the pool are kept in a hashmap keyed on the objects themselves, so mutability that changes hashcodes (and / or equality) can cause problems. See the discussion on POOL-284. If this causes so many discussions and fuzz, it is worth filing another issue which should document how a pooled object should like. Required criteria. That would have spared me the searching. WDYT? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
You aren't guaranteed for them not to collide. So, yes, it could happen. On Saturday, February 7, 2015, Michael Osipov 1983-01...@gmx.net wrote: Am 2015-02-06 um 17:14 schrieb James Carman: Try UUID.randomUUID().toString() rather than RandomStringUtils if you really want unique keys. Aren't both pseudo random? I won't have more than 30 sessions in parallel. Do you think that a collision might happen? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
On Feb 7, 2015, at 2:23 AM, Michael Osipov 1983-01...@gmx.net wrote: Am 2015-02-06 um 19:21 schrieb Phil Steitz: On 2/6/15 10:16 AM, sebb wrote: The existing Pool2 implementations use equals() to decide if two objects are the same. As of pool 2.3. You have to make sure that your equals() implementation returns true if and only if the objects being compared are the same as far as your use of them is concerned. So for example two Integers are equal if they have the same integral value, but two different StringBuffer instances are never equal. Once you have determined what constitutes equality for your instances, make sure that the hash code is coded accordingly, i.e. two objects that are equal() must have the same hash code. If this requirment is not met, then the HashMap used internally by Pool2 will behave unpredictably. Also, hash codes should not change between the time that an object is borrowed from the pool and subsequently returned. Again, for pool 2.0-2.3 (latest as of this post), objects under management by the pool are kept in a hashmap keyed on the objects themselves, so mutability that changes hashcodes (and / or equality) can cause problems. See the discussion on POOL-284. If this causes so many discussions and fuzz, it is worth filing another issue which should document how a pooled object should like. Required criteria. That would have spared me the searching. Definitely fixing javadoc and web site doco will be part of resolution of POOL-283/4. Phil WDYT? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Or not implement them at all since this is exactly what the Object class will do for you. On Sunday, February 8, 2015, sebb seb...@gmail.com wrote: Why don't you just implement equals() and hashCode() as noted here [1] ? This will allow the use of Pool2 and guarantee that different instances are treated as different, regardless of mutabiity. No need to generate unique ids for each instance. Pool2 needs an equals() method that returns true for objects that really are equal. Also equals() and hashCode() must be stable for a given object, and objects which are the same under equals() must have the same hashCode(). These are standard requirements for using a HashMap (which is what Pool2 uses currently). [1] https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 On 8 February 2015 at 12:12, James Carman ja...@carmanconsulting.com javascript:; wrote: You aren't guaranteed for them not to collide. So, yes, it could happen. On Saturday, February 7, 2015, Michael Osipov 1983-01...@gmx.net javascript:; wrote: Am 2015-02-06 um 17:14 schrieb James Carman: Try UUID.randomUUID().toString() rather than RandomStringUtils if you really want unique keys. Aren't both pseudo random? I won't have more than 30 sessions in parallel. Do you think that a collision might happen? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: user-h...@commons.apache.org javascript:; - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: user-h...@commons.apache.org javascript:;
Re: [POOL2] Pooling mutable objects
On 8 February 2015 at 15:09, James Carman ja...@carmanconsulting.com wrote: Or not implement them at all since this is exactly what the Object class will do for you. Yes, that is true for the sample RawSession class shown at the start of the thread. However if the class were changed to inherit from a class that overrides equals/hasCode then it would need to re-define the methods in order to get the same behaviour. On Sunday, February 8, 2015, sebb seb...@gmail.com wrote: Why don't you just implement equals() and hashCode() as noted here [1] ? This will allow the use of Pool2 and guarantee that different instances are treated as different, regardless of mutabiity. No need to generate unique ids for each instance. Pool2 needs an equals() method that returns true for objects that really are equal. Also equals() and hashCode() must be stable for a given object, and objects which are the same under equals() must have the same hashCode(). These are standard requirements for using a HashMap (which is what Pool2 uses currently). [1] https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 On 8 February 2015 at 12:12, James Carman ja...@carmanconsulting.com javascript:; wrote: You aren't guaranteed for them not to collide. So, yes, it could happen. On Saturday, February 7, 2015, Michael Osipov 1983-01...@gmx.net javascript:; wrote: Am 2015-02-06 um 17:14 schrieb James Carman: Try UUID.randomUUID().toString() rather than RandomStringUtils if you really want unique keys. Aren't both pseudo random? I won't have more than 30 sessions in parallel. Do you think that a collision might happen? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: user-h...@commons.apache.org javascript:; - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org javascript:; For additional commands, e-mail: user-h...@commons.apache.org javascript:; - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-08 um 14:34 schrieb sebb: Why don't you just implement equals() and hashCode() as noted here [1] ? This will allow the use of Pool2 and guarantee that different instances are treated as different, regardless of mutabiity. No need to generate unique ids for each instance. Pool2 needs an equals() method that returns true for objects that really are equal. Also equals() and hashCode() must be stable for a given object, and objects which are the same under equals() must have the same hashCode(). These are standard requirements for using a HashMap (which is what Pool2 uses currently). [1] https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 The offered solution adds another superfluous wrapper which can be avoided. the artificial id helps here. Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Am 2015-02-08 um 13:12 schrieb James Carman: You aren't guaranteed for them not to collide. So, yes, it could happen. But UUID is neither but the probability is exteremely low. Is that what you tried to say? On Saturday, February 7, 2015, Michael Osipov 1983-01...@gmx.net wrote: Am 2015-02-06 um 17:14 schrieb James Carman: Try UUID.randomUUID().toString() rather than RandomStringUtils if you really want unique keys. Aren't both pseudo random? I won't have more than 30 sessions in parallel. Do you think that a collision might happen? Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
On 8 February 2015 at 20:38, Michael Osipov 1983-01...@gmx.net wrote: Am 2015-02-08 um 14:34 schrieb sebb: Why don't you just implement equals() and hashCode() as noted here [1] ? This will allow the use of Pool2 and guarantee that different instances are treated as different, regardless of mutabiity. No need to generate unique ids for each instance. Pool2 needs an equals() method that returns true for objects that really are equal. Also equals() and hashCode() must be stable for a given object, and objects which are the same under equals() must have the same hashCode(). These are standard requirements for using a HashMap (which is what Pool2 uses currently). [1] https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 The offered solution adds another superfluous wrapper which can be avoided. I did not mean to imply that you needed to use a wrapper. Since you have control over the class, you can just write the equals()/hashCode() methods as per the wrapper. Or omit them entirely if the class inherits its equals()/hashCode() methods from Object. the artificial id helps here. I don't see how. It's not needed by Pool2 if you use the Object EQ/HC methods either by inheritance or by definition in the class. Michael - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
On Sun, Feb 08, 2015 at 11:07:59AM +0100, Michael Osipov wrote: How would you propose to use it? I would still need a random number or do you recomment to use a static one and simply increment during the lifetime of the application? If so, thing might cause trouble in the future because I would probably store the session information in a database for analysis issues and woudl have collisions. Michael Then you either have to use real big random's like UUID and accept it'd be slow, or derive the numeric values from a native DB counter (for example, a Redis counter, or a PostgreSQL sequence data type). Matthew. - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
I'd think adding a UUID then overriding equals and hashCode would do the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov 1983-01...@gmx.net wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is requested with
the fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and mutable
int might change.
Additionally, I did not implement any custom equals and hashCode methods.
I have searched the docs and the found and did not find any clear answer
which says
that pooled objects have to be immutable. Though, I have found POOL-283
and POOL-284 which
led me to the conclusion that this is a problem because the objects are
stored in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and hashCode and
provide some internal,
immutable value something like a UUID? Alternatively, I could retrieve the
JSESSIONID from the
cookie store and use this as a unique value.
Thanks,
Michael
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: Re: [POOL2] Pooling mutable objects
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
Some Eclipse magic:
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((internalId == null) ? 0 :
internalId.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RawSession other = (RawSession) obj;
if (internalId == null) {
if (other.internalId != null)
return false;
} else if (!internalId.equals(other.internalId))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org wrote:
I'd think adding a UUID then overriding equals and hashCode would do the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov 1983-01...@gmx.net wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is requested with
the fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and mutable
int might change.
Additionally, I did not implement any custom equals and hashCode methods.
I have searched the docs and the found and did not find any clear answer
which says
that pooled objects have to be immutable. Though, I have found POOL-283
and POOL-284 which
led me to the conclusion that this is a problem because the objects are
stored in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and hashCode and
provide some internal,
immutable value something like a UUID? Alternatively, I could retrieve the
JSESSIONID from the
cookie store and use this as a unique value.
Thanks,
Michael
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org wrote:
I'd think adding a UUID then overriding equals and hashCode would do the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov 1983-01...@gmx.net wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is requested with
the fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and mutable
int might change.
Additionally, I did not implement any custom equals and hashCode methods.
I have searched the docs and the found and did not find any clear answer
which says
that pooled objects have to be immutable. Though, I have found POOL-283
and POOL-284 which
led me to the conclusion that this is a problem because the objects are
stored in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and hashCode and
provide some internal,
immutable value something like a UUID? Alternatively, I could retrieve the
JSESSIONID from the
cookie store and use this as a unique value.
Thanks,
Michael
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: Re: [POOL2] Pooling mutable objects
Try UUID.randomUUID().toString() rather than RandomStringUtils if you
really want unique keys.
On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov 1983-01...@gmx.net wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
Some Eclipse magic:
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((internalId == null) ? 0 :
internalId.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RawSession other = (RawSession) obj;
if (internalId == null) {
if (other.internalId != null)
return false;
} else if (!internalId.equals(other.internalId))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org wrote:
I'd think adding a UUID then overriding equals and hashCode would do the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1] and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov 1983-01...@gmx.net wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is requested with
the fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and mutable
int might change.
Additionally, I did not implement any custom equals and hashCode methods.
I have searched the docs and the found and did not find any clear answer
which says
that pooled objects have to be immutable. Though, I have found POOL-283
and POOL-284 which
led me to the conclusion that this is a problem because the objects are
stored in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and hashCode and
provide some internal,
immutable value something like a UUID? Alternatively, I could retrieve the
JSESSIONID from the
cookie store and use this as a unique value.
Thanks,
Michael
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: Re: [POOL2] Pooling mutable objects
I'm not sure I understand your comment Mat. From what I can tell, Michael
made his own hash function. That's fine, but *might* have unexpected
collision issues. Might not too... I don't know. My guess though is that
he's not an expert (who is an expert on hash functions?) and might
unknowingly fall into a trap here.
For example, commons-lang HashBuilder uses 37 as the prime and 17 as the
initial result... Michael didn't. Maybe he's OK, maybe he's not... but why
risk it? Why not just use the library and not reinvent the wheel? (Most
valid reason would be not wanting to pull in a whole library for these two
functions/classes.)
Again, take my advice for what you paid, nothing. :-)
Bill-
On Fri, Feb 6, 2015 at 11:06 AM, Mat Jaggard matt...@jaggard.org.uk wrote:
William - I'm not sure if you noticed, but they didn't hand-make anything.
On 6 February 2015 at 16:00, William Speirs wspe...@apache.org wrote:
Why wouldn't you use the HashCodeBuilder? Much simpler:
return new HashCodeBuilder().append(internalId).toHashCode();
Done in 1 line, and probably fewer collisions than your hand-made one.
Same
with the EqualsBuilder...
If you don't want the dep on commons-lang, then I can understand... but
I'd
just borrow their internal algo.
My $0.02...
Bill-
On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov 1983-01...@gmx.net
wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
Some Eclipse magic:
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((internalId == null) ? 0 :
internalId.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RawSession other = (RawSession) obj;
if (internalId == null) {
if (other.internalId != null)
return false;
} else if (!internalId.equals(other.internalId))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org
wrote:
I'd think adding a UUID then overriding equals and hashCode would
do
the
trick. To aid you in doing this, commons-lang has EqualsBuilder [1]
and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov 1983-01...@gmx.net
wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is
requested
with
the fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and
mutable
int might change.
Additionally, I did not implement any custom equals and hashCode
methods.
I have searched the docs and the found and did not find any clear
answer
which says
that pooled objects have to be immutable. Though, I have found
POOL-283
and POOL-284 which
led me to the conclusion that this is a problem because the
objects
are
stored in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and
hashCode
and
provide some internal,
immutable value something like a UUID? Alternatively, I could
retrieve the
JSESSIONID from the
cookie store and use this as a unique value.
Thanks,
Michael
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: Re: [POOL2] Pooling mutable objects
He didn't create his own hash function, he generated it in eclipse. This is
better because you get all the testing of other eclipse users without any
runtime dependencies.
On 6 February 2015 at 16:16, William Speirs wspe...@apache.org wrote:
I'm not sure I understand your comment Mat. From what I can tell, Michael
made his own hash function. That's fine, but *might* have unexpected
collision issues. Might not too... I don't know. My guess though is that
he's not an expert (who is an expert on hash functions?) and might
unknowingly fall into a trap here.
For example, commons-lang HashBuilder uses 37 as the prime and 17 as the
initial result... Michael didn't. Maybe he's OK, maybe he's not... but why
risk it? Why not just use the library and not reinvent the wheel? (Most
valid reason would be not wanting to pull in a whole library for these two
functions/classes.)
Again, take my advice for what you paid, nothing. :-)
Bill-
On Fri, Feb 6, 2015 at 11:06 AM, Mat Jaggard matt...@jaggard.org.uk
wrote:
William - I'm not sure if you noticed, but they didn't hand-make
anything.
On 6 February 2015 at 16:00, William Speirs wspe...@apache.org wrote:
Why wouldn't you use the HashCodeBuilder? Much simpler:
return new HashCodeBuilder().append(internalId).toHashCode();
Done in 1 line, and probably fewer collisions than your hand-made one.
Same
with the EqualsBuilder...
If you don't want the dep on commons-lang, then I can understand... but
I'd
just borrow their internal algo.
My $0.02...
Bill-
On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov 1983-01...@gmx.net
wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
Some Eclipse magic:
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((internalId == null) ? 0 :
internalId.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RawSession other = (RawSession) obj;
if (internalId == null) {
if (other.internalId != null)
return false;
} else if (!internalId.equals(other.internalId))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org
wrote:
I'd think adding a UUID then overriding equals and hashCode would
do
the
trick. To aid you in doing this, commons-lang has EqualsBuilder
[1]
and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov
1983-01...@gmx.net
wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is
requested
with
the fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and
mutable
int might change.
Additionally, I did not implement any custom equals and hashCode
methods.
I have searched the docs and the found and did not find any
clear
answer
which says
that pooled objects have to be immutable. Though, I have found
POOL-283
and POOL-284 which
led me to the conclusion that this is a problem because the
objects
are
stored in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and
hashCode
and
provide some internal,
immutable value something like a UUID? Alternatively, I could
retrieve the
JSESSIONID from
Re: Re: [POOL2] Pooling mutable objects
The existing Pool2 implementations use equals() to decide if two
objects are the same.
You have to make sure that your equals() implementation returns true
if and only if the objects being compared are the same as far as your
use of them is concerned.
So for example two Integers are equal if they have the same integral
value, but two different StringBuffer instances are never equal.
Once you have determined what constitutes equality for your instances,
make sure that the hash code is coded accordingly, i.e. two objects
that are equal() must have the same hash code.
If this requirment is not met, then the HashMap used internally by
Pool2 will behave unpredictably.
If all RawSession instances are to be regarded as unique (which seems
likely), then define equals and hash code as noted in POOL-283:
https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637
On 6 February 2015 at 16:34, Mat Jaggard matt...@jaggard.org.uk wrote:
He didn't create his own hash function, he generated it in eclipse. This is
better because you get all the testing of other eclipse users without any
runtime dependencies.
On 6 February 2015 at 16:16, William Speirs wspe...@apache.org wrote:
I'm not sure I understand your comment Mat. From what I can tell, Michael
made his own hash function. That's fine, but *might* have unexpected
collision issues. Might not too... I don't know. My guess though is that
he's not an expert (who is an expert on hash functions?) and might
unknowingly fall into a trap here.
For example, commons-lang HashBuilder uses 37 as the prime and 17 as the
initial result... Michael didn't. Maybe he's OK, maybe he's not... but why
risk it? Why not just use the library and not reinvent the wheel? (Most
valid reason would be not wanting to pull in a whole library for these two
functions/classes.)
Again, take my advice for what you paid, nothing. :-)
Bill-
On Fri, Feb 6, 2015 at 11:06 AM, Mat Jaggard matt...@jaggard.org.uk
wrote:
William - I'm not sure if you noticed, but they didn't hand-make
anything.
On 6 February 2015 at 16:00, William Speirs wspe...@apache.org wrote:
Why wouldn't you use the HashCodeBuilder? Much simpler:
return new HashCodeBuilder().append(internalId).toHashCode();
Done in 1 line, and probably fewer collisions than your hand-made one.
Same
with the EqualsBuilder...
If you don't want the dep on commons-lang, then I can understand... but
I'd
just borrow their internal algo.
My $0.02...
Bill-
On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov 1983-01...@gmx.net
wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
Some Eclipse magic:
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((internalId == null) ? 0 :
internalId.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RawSession other = (RawSession) obj;
if (internalId == null) {
if (other.internalId != null)
return false;
} else if (!internalId.equals(other.internalId))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org
wrote:
I'd think adding a UUID then overriding equals and hashCode would
do
the
trick. To aid you in doing this, commons-lang has EqualsBuilder
[1]
and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael Osipov
1983-01...@gmx.net
wrote:
Hi folks,
I am developing a session pool for an HTTP backend which is
requested
with
the fabulous HttpClient.
The session object
[POOL2] Pooling mutable objects
Hi folks,
I am developing a session pool for an HTTP backend which is requested with the
fabulous HttpClient.
The session object is this:
public class RawSession {
private CookieStore cookieStore;
private String logId;
private MutableInt requestId;
private String clientId;
private String serverId;
}
There won't be any setters but as you see, the cookie store and mutable int
might change.
Additionally, I did not implement any custom equals and hashCode methods.
I have searched the docs and the found and did not find any clear answer which
says
that pooled objects have to be immutable. Though, I have found POOL-283 and
POOL-284 which
led me to the conclusion that this is a problem because the objects are stored
in a map
which relies on equals and hashCode.
Does this ultimately mean that I have to override equals and hashCode and
provide some internal,
immutable value something like a UUID? Alternatively, I could retrieve the
JSESSIONID from the
cookie store and use this as a unique value.
Thanks,
Michael
-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org
Re: Re: [POOL2] Pooling mutable objects
Hi William, William Speirs wrote: I'm not sure I understand your comment Mat. From what I can tell, Michael made his own hash function. That's fine, but *might* have unexpected collision issues. Might not too... I don't know. My guess though is that he's not an expert (who is an expert on hash functions?) and might unknowingly fall into a trap here. For example, commons-lang HashBuilder uses 37 as the prime and 17 as the initial result... Michael didn't. Maybe he's OK, maybe he's not... but why risk it? Why not just use the library and not reinvent the wheel? (Most valid reason would be not wanting to pull in a whole library for these two functions/classes.) Maybe because it can be dead-slow? https://www.mail-archive.com/user@xstream.codehaus.org/msg00677.html I use HashCodeBuilder and EqualsBilder for Mock objects only ... for good reason. Cheers, Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
On 2/6/15 10:16 AM, sebb wrote:
The existing Pool2 implementations use equals() to decide if two
objects are the same.
As of pool 2.3.
You have to make sure that your equals() implementation returns true
if and only if the objects being compared are the same as far as your
use of them is concerned.
So for example two Integers are equal if they have the same integral
value, but two different StringBuffer instances are never equal.
Once you have determined what constitutes equality for your instances,
make sure that the hash code is coded accordingly, i.e. two objects
that are equal() must have the same hash code.
If this requirment is not met, then the HashMap used internally by
Pool2 will behave unpredictably.
Also, hash codes should not change between the time that an object
is borrowed from the pool and subsequently returned. Again, for
pool 2.0-2.3 (latest as of this post), objects under management by
the pool are kept in a hashmap keyed on the objects themselves, so
mutability that changes hashcodes (and / or equality) can cause
problems. See the discussion on POOL-284.
These problems do not impact earlier (1.x) versions of Commons Pool.
If all RawSession instances are to be regarded as unique (which seems
likely), then define equals and hash code as noted in POOL-283:
https://issues.apache.org/jira/browse/POOL-283?focusedCommentId=14307637page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637
On 6 February 2015 at 16:34, Mat Jaggard matt...@jaggard.org.uk wrote:
He didn't create his own hash function, he generated it in eclipse. This is
better because you get all the testing of other eclipse users without any
runtime dependencies.
On 6 February 2015 at 16:16, William Speirs wspe...@apache.org wrote:
I'm not sure I understand your comment Mat. From what I can tell, Michael
made his own hash function. That's fine, but *might* have unexpected
collision issues. Might not too... I don't know. My guess though is that
he's not an expert (who is an expert on hash functions?) and might
unknowingly fall into a trap here.
For example, commons-lang HashBuilder uses 37 as the prime and 17 as the
initial result... Michael didn't. Maybe he's OK, maybe he's not... but why
risk it? Why not just use the library and not reinvent the wheel? (Most
valid reason would be not wanting to pull in a whole library for these two
functions/classes.)
Again, take my advice for what you paid, nothing. :-)
Bill-
On Fri, Feb 6, 2015 at 11:06 AM, Mat Jaggard matt...@jaggard.org.uk
wrote:
William - I'm not sure if you noticed, but they didn't hand-make
anything.
On 6 February 2015 at 16:00, William Speirs wspe...@apache.org wrote:
Why wouldn't you use the HashCodeBuilder? Much simpler:
return new HashCodeBuilder().append(internalId).toHashCode();
Done in 1 line, and probably fewer collisions than your hand-made one.
Same
with the EqualsBuilder...
If you don't want the dep on commons-lang, then I can understand... but
I'd
just borrow their internal algo.
My $0.02...
Bill-
On Fri, Feb 6, 2015 at 10:54 AM, Michael Osipov 1983-01...@gmx.net
wrote:
This is what I did:
this.internalId = RandomStringUtils.randomAlphanumeric(8);
Some Eclipse magic:
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + ((internalId == null) ? 0 :
internalId.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
RawSession other = (RawSession) obj;
if (internalId == null) {
if (other.internalId != null)
return false;
} else if (!internalId.equals(other.internalId))
return false;
return true;
}
Gesendet: Freitag, 06. Februar 2015 um 16:47 Uhr
Von: James Carman ja...@carmanconsulting.com
An: Commons Users List user@commons.apache.org
Betreff: Re: [POOL2] Pooling mutable objects
Or just let your IDE generate the methods.
On Fri, Feb 6, 2015 at 9:05 AM, William Speirs wspe...@apache.org
wrote:
I'd think adding a UUID then overriding equals and hashCode would
do
the
trick. To aid you in doing this, commons-lang has EqualsBuilder
[1]
and
HashCodeBuilder [2], I highly recommend using them.
Bill-
[1]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/EqualsBuilder.html
[2]
https://commons.apache.org/proper/commons-lang/javadocs/api-3.3.2/org/apache/commons/lang3/builder/HashCodeBuilder.html
On Fri, Feb 6, 2015 at 9:00 AM, Michael
