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
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? Adrian Crum Sandglass Software www.sandglass-software.com On 2/9/2015 10:33 AM, Matthew Hall wrote: 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 - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
Re: [POOL2] Pooling mutable objects
If you absolutely need a unique identifier, I'd start with UUIDs. If you see them causing you headaches, then look for an alternative, but I've never had the need. On Mon, Feb 9, 2015 at 1:33 PM, Matthew Hall wrote: > 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 > - 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 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
Premature optimization. UUIDs aren't slow. On Monday, February 9, 2015, Matthew Hall 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 > For additional commands, e-mail: user-h...@commons.apache.org > > >
Re: [POOL2] Pooling mutable objects
On 9 February 2015 at 05:07, Matthew Hall 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: [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
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=14307637&page=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
UUID stands for universally unique identifier, so you should be okay as far as collisions go. Given that the length of a UUID and its alphabet is fixed, there are indeed a finite number of them (2^122), but collisions are extremely unlikely. If you do not NEED an identifier on your sessions and are only doing so in order to force uniqueness, then just get rid of it and use java's built in equals and hashCode implementation which treats every object as unique regardless of the content of its fields. Or keep the id and don't override equals and hashCode. On Sunday, February 8, 2015, Michael Osipov <1983-01...@gmx.net> wrote: > 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
Am 2015-02-08 um 14:46 schrieb Phil Steitz: 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 Looking forward too, thanks! - 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
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=14307637&page=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
On 8 February 2015 at 15:09, James Carman 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 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=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 >> >> >> On 8 February 2015 at 12:12, James Carman > > 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 >> > 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 >> >> >> - 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 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=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 > > > On 8 February 2015 at 12:12, James Carman > 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 > > 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 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
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=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637 On 8 February 2015 at 12:12, James Carman 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> 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
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
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 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 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: 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
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=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637
>
>
> On 6 February 2015 at 16:34, Mat Jaggard 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 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
>>> 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 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)
>>>>>>
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: 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=14307637&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14307637
On 6 February 2015 at 16:34, Mat Jaggard 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 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
>> 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 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.
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 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
> 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 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"
> > > > > An: "Commons Users List"
> > > > > 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 >
> > > > 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/
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"
>> An: "Commons Users List"
>> 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 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 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 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"
> > > > An: "Commons Users List"
> > > > 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
> > > 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 cooki
Re: Re: [POOL2] Pooling mutable objects
William - I'm not sure if you noticed, but they didn't hand-make anything.
On 6 February 2015 at 16:00, William Speirs 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"
> > > An: "Commons Users List"
> > > 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
> > 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: Re: [POOL2] Pooling mutable objects
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"
> > An: "Commons Users List"
> > 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
> 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: 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"
> An: "Commons Users List"
> 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 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 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: [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
>
>
[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
