Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <679305120.1203870674325.JavaMail.jira@brutus>
Date: Sun, 24 Feb 2008 08:31:14 -0800 (PST)
From: "Takayuki Kaneko (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Updated: (POOL-75) [pool] GenericObjectPool not FIFO with
 respect to borrowing threads
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/POOL-75?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:all-tabpanel ]

Takayuki Kaneko updated POOL-75:
--------------------------------

    Attachment: java3.patch

Hi Phil,

Thanks for pointing out my patch's problems.

1) I'm trying to fix the issue on unit cases. I fixed some issue so I attac=
h a new patch.
I wonder about TestGenericObjectPool#checkEvictorVisiting method. At line 3=
35, pool's _numActive is greater than _maxActive because objects were alrea=
dy borrowed at line 294.
Is this a correct behavior?

2) "depth" is used to implement reentrant locking.=E3=80=80Reentrant lockin=
g is popular feature on lock algorithm.
But I had another think coming, in GenericObjectPool it is unnecessary feat=
ure.

3) Yeah, I accept this patch applies APL.

Please let me know about 1).
I will work more on this issue because fairness is really useful on enterpr=
ise use!

Regards,

> [pool] GenericObjectPool not FIFO with respect to borrowing threads
> -------------------------------------------------------------------
>
>                 Key: POOL-75
>                 URL: https://issues.apache.org/jira/browse/POOL-75
>             Project: Commons Pool
>          Issue Type: Improvement
>    Affects Versions: Nightly Builds
>         Environment: Operating System: All
> Platform: All
>            Reporter: Gordon Mohr
>            Priority: Minor
>             Fix For: 1.5
>
>         Attachments: ctest.fairness.png, ctest.original.png, java.patch, =
java2.patch, java3.patch
>
>
> GenericObjectPool has recently been made FIFO with respect to the managed=
 pool
> objects -- however, it is still not FIFO with respect to threads requesti=
ng
> those objects. Specifically, because standard non-fair Java synchronizati=
on
> monitors are used, later threads may barge ahead of earlier threads that =
are
> already waiting for a pool object to become available. At its extreme, so=
me
> threads can cycle objects through the pool many times while others wait
> interminable.=20
> Not every application needs FIFO fairness with respect to threads, and su=
ch
> fairness implies an overhead, so it  need not be the default behavior, bu=
t it
> would be a valuable option where many threads are sharing a smaller numbe=
r of
> pool objects.=20
> I can submit a FairGenericObjectPool which achieves thread-fairness; it o=
nly
> requires small changes to GenericObjectPool which allow some subclass ove=
rriding.

--=20
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.