sebb wrote:
> On 14/01/2010, Phil Steitz <phil.ste...@gmail.com> wrote:
>> On 1/14/10, sebb <seb...@gmail.com> wrote:
>>  >
>>  > On 14/01/2010, Phil Steitz <phil.ste...@gmail.com> wrote:
>>  > > Unless I am reading the output of the latest failures wrong or we
>>  > >  are picking up the wrong hashcode (should be innermost delegate),
>>  >
>>  > It's currently the connection returned by getConnection().
>>  > I'll fix that.
>>
>>
>>
>> Should actually be correct as is.  As you recall from equals() discussion,.
>>  DelegatingConnection hashCode gets it from the
>>  innermostDelegate. System.idendityHashCode should pick this up.  Could be
>>  overrriden somewhere, but I don't think so.
>>
> 
> System.identityHashCode() uses Object.hashCode().
> 
> Had I used conn.hashCode() it would have been OK, but I thought I
> wanted to distinguish different "equal" objects. That was possibly
> wrong.

Yeah, sorry, temporary brain deadness.  The Delegating connection
returned is new each time and you need to use the overridden
hashCode to see if the underlying connection is the same.
> 
> However, after fixing it to use the innermost delegate I ran a local
> test with hold=wait and I could see the same hash being re-used.

That is good.  Consistent with subsequent Continuum runs.

Phi
> 
>>  Phil
>>
>>
>>  >  this is now looking like it could be a pool bug - allowing more than
>>  > >  maxActive distinct connections to be simultaneously active.  Need to
>>  > >  look at this some more.  It is worth temporarily modifying the pom
>>  > >  to use pool 1.4 for a test.
>>  >
>>  > OK; I think we should see if there are duplicate hashes first.
>>  >
>>  > >
>>  > >  Phil
>>  > >
>>  > >  ---------------------------------------------------------------------
>>  > >  To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  > >  For additional commands, e-mail: dev-h...@commons.apache.org
>>  > >
>>  > >
>>  >
>>  > ---------------------------------------------------------------------
>>  > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>  > For additional commands, e-mail: dev-h...@commons.apache.org
>>  >
>>  >
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to