I opened a JIRA ticket for the issue:
https://issues.apache.org/jira/browse/POOL-119
Christoph
Henri Yandell wrote:
On Jan 5, 2008 3:39 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
Phil Steitz wrote:
Yes. It may be ultimately best to make this configurable. If you are
OK with this approach, w
On Jan 5, 2008 3:39 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Phil Steitz wrote:
> > Yes. It may be ultimately best to make this configurable. If you are
> > OK with this approach, what I suggest is that you open a JIRA ticket,
> > attaching a version of your patch that supports configurability
Phil Steitz wrote:
Yes. It may be ultimately best to make this configurable. If you are
OK with this approach, what I suggest is that you open a JIRA ticket,
attaching a version of your patch that supports configurability. Open
the ticket against 1.3 for now but keep the patch as is (i.e. again
> >
> > The 1.2 / 1.4-RC1 code does "recheck" before initiating additional
> > makes - i.e., it will not initiate a makeObject if an idle object has
> > been returned to the pool or if maxActive has been reached. I think I
> > understand your point though, but again it doesn't seem natural to use
On Jan 5, 2008 7:49 AM, <[EMAIL PROTECTED]> wrote:
> Hi Phil,
>
> thanks for taking my issue serious.
>
> Phil Steitz wrote:
>
> > Thanks again for the feedback. Any other opinions / suggestions on
> > this are appreciated. I suggest the following compromise, which would
> > also fix the maxAct
Phil Steitz wrote:
If you are really worried about the cost of object creation then you can
configure the pool to create all the objects at start-up and block until a
free object is available.
That is unfortunately not possible under our current configuration as we
have set up our application
Hi Phil,
thanks for taking my issue serious.
Phil Steitz wrote:
Thanks again for the feedback. Any other opinions / suggestions on
this are appreciated. I suggest the following compromise, which would
also fix the maxActive exceeded by one issue I discovered with
1.2/1.4-RC1 yesterday:
(*)
On Jan 4, 2008 4:09 AM, <[EMAIL PROTECTED]> wrote:
> Mark, Thomas, thanks for your replies,
>
> Phil Steitz wrote:
> > On Jan 3, 2008 12:40 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> >> Christoph Kutzinski wrote:
> >>> - creating a new object means the pool is exhausted which in turn usually
>
Mark, Thomas, thanks for your replies,
Phil Steitz wrote:
On Jan 3, 2008 12:40 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
Christoph Kutzinski wrote:
- creating a new object means the pool is exhausted which in turn usually means
that we have a high-load situation.
- creation of new objects is
On Jan 3, 2008 12:40 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Christoph Kutzinski wrote:
> > - creating a new object means the pool is exhausted which in turn usually
> > means that we have a high-load situation.
> > - creation of new objects is expensive (probably even more in high-load
> >
Christoph Kutzinski wrote:
> - creating a new object means the pool is exhausted which in turn usually
> means that we have a high-load situation.
> - creation of new objects is expensive (probably even more in high-load
> situations). This is why we originally used the pool
> - so in conclusion
lObjectCreation ) {
return this.makeObjectLock;
} else {
return new Object();
}
}
greetings
Christoph
Original-Nachricht
> Datum: Sun, 9 Dec 2007 20:35:28 -0700
> Von: "Phil Steitz" <[EMAIL PROTECTED]>
> An: "Jakarta Commons Develope
Phil Steitz wrote:
> On Dec 9, 2007 4:46 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
>> I have taken a look at each of the issues above. Comments added to JIRA. In
>> summary:
>
> Thanks!
>
>> POOL-86 - The patch in JIRA looks good to me
> To be clear, are you referring to the patch that was appl
On Dec 9, 2007 4:46 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Mark Thomas wrote:
> > Phil Steitz wrote:
> >> On Dec 2, 2007 11:09 AM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> >>> Hi,
> >>>
> >>> Tomcat has been bitten [1] by a bug [2] in pool-1.3. Currently we are
> >>> considering reverting to
Mark Thomas wrote:
> Phil Steitz wrote:
>> On Dec 2, 2007 11:09 AM, Mark Thomas <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> Tomcat has been bitten [1] by a bug [2] in pool-1.3. Currently we are
>>> considering reverting to pool-1.2 but would obviously prefer to move to
>>> pool-1.4 (that included a
Hi,
> On Dec 2, 2007 2:24 PM, <[EMAIL PROTECTED]> wrote:
> > Phil Steitz wrote:
> >
> > >> - fully synchronized borrowObject() and returnObject() methods. I've
> > >> seen this to be a serious bottleneck when the database is under high
> > >> load and another connection needs to be created.
> > >
Phil Steitz wrote:
> On Dec 2, 2007 11:09 AM, Mark Thomas <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> Tomcat has been bitten [1] by a bug [2] in pool-1.3. Currently we are
>> considering reverting to pool-1.2 but would obviously prefer to move to
>> pool-1.4 (that included a fix for [2]) due to the man
> I think it would
> really be best to resolve the over-synch issues as well if we can do
> it quickly. I will post a separate note on what I have in mind there.
See patch and comment on POOL-108.
Phil
-
To unsubscribe, e-mail
On Dec 2, 2007 2:24 PM, <[EMAIL PROTECTED]> wrote:
> Phil Steitz wrote:
>
> >> - fully synchronized borrowObject() and returnObject() methods. I've
> >> seen this to be a serious bottleneck when the database is under high
> >> load and another connection needs to be created.
> >
> > Agreed. Ideas
Phil Steitz wrote:
- fully synchronized borrowObject() and returnObject() methods. I've
seen this to be a serious bottleneck when the database is under high
load and another connection needs to be created.
Agreed. Ideas on how to improve this without creating threadsafety
issues would be appr
On Dec 2, 2007 12:15 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I would like to offer some help, too.
Thanks in advance!
> I cannot promise that I can do some actual development work on it, but I
> would like to add some comments about some drawbacks (IMHO) in pool 1.3.
> Mainly:
>
> - changing Ge
On Dec 2, 2007 11:09 AM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Tomcat has been bitten [1] by a bug [2] in pool-1.3. Currently we are
> considering reverting to pool-1.2 but would obviously prefer to move to
> pool-1.4 (that included a fix for [2]) due to the many fixes in 1.3.
>
> A quic
Hi,
I would like to offer some help, too.
I cannot promise that I can do some actual development work on it, but I
would like to add some comments about some drawbacks (IMHO) in pool 1.3.
Mainly:
- changing GenericObjectPool from LIFO to FIFO strategy from 1.2 to 1.3
I think that a FIFO strate
Hi,
Tomcat has been bitten [1] by a bug [2] in pool-1.3. Currently we are
considering reverting to pool-1.2 but would obviously prefer to move to
pool-1.4 (that included a fix for [2]) due to the many fixes in 1.3.
A quick scan of the archives suggests that an offer of an extra pair of
hands migh
24 matches
Mail list logo
