Re: [DBCP] Remove SQLNestedException
On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: DBCP-143 talks about problem with propagation of SQLNestedException to clients and the comment suggests a conversion to normal Java nested exception when we switch to Java 1.4. Since we made the leap, I did a bit of refactoring to remove this exception class. Basically I replace: new SQLNestedException(msg, e); with: (SQLException) new SQLException(msg).initCause(e); I attached this at a patch to 143 as I'm not 100% sure we want to go this direction. So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove legacy casts in client code, since we never advertise this exception. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove SQLNestedException
On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: DBCP-143 talks about problem with propagation of SQLNestedException to clients and the comment suggests a conversion to normal Java nested exception when we switch to Java 1.4. Since we made the leap, I did a bit of refactoring to remove this exception class. Basically I replace: new SQLNestedException(msg, e); with: (SQLException) new SQLException(msg).initCause(e); I attached this at a patch to 143 as I'm not 100% sure we want to go this direction. So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove legacy casts in client code, since we never advertise this exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove SQLNestedException
On 7/24/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: snip/ So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove legacy casts in client code, since we never advertise this exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. snap/ He means v2.0 AFAICT. Details [1]. -Rahul [1] http://jakarta.apache.org/commons/releases/versioning.html -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove SQLNestedException
On 7/24/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 7/24/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 24, 2007, at 7:56 AM, Phil Steitz wrote: On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: snip/ So, should we drop SQLNestedException? This is tempting, but it breaks backward compatibility, so we should probably deprecate in 1.3 and remove in the next major release. I guess the deprecation warning / release notes should just tell people to remove legacy casts in client code, since we never advertise this exception. Sounds good. I marked the class as deprecated, moved DBCP-143 to 1.4, and added a note to the change log. snap/ He means v2.0 AFAICT. Details [1]. -Rahul [1] http://jakarta.apache.org/commons/releases/versioning.html Yes that's what I meant, following our rules. In this case, that is a little extreme, however, since the only breakage that I can think of is old 1.3 code that includes explicit casts in catch blocks, or direct usage or extension of the since-1.4-obsolete exception class itself. Is this really worth waiting for 2.0? Am I missing something here? Phil Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] JIRA workflow?
2007/7/23, Dain Sundstrom [EMAIL PROTECTED]: When issues are complete, do you close or resolve them? I have been closing them, but just noticed that may are resolved. In Tiles, we resolve the issues when the fix is done. We close them when a release gained a positive vote. Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. Should I commit the patch that removes the excessive synchronization from PoolableConnectionFactory. It won't fix this problem but may alleviate some other ones. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] JIRA workflow?
On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: When issues are complete, do you close or resolve them? I have been closing them, but just noticed that may are resolved. I close em. Also, should I create a DBCP 1.4 and move the issues (like max time limit for pooled objects) we aren't going to get to for 1.3 over. +1. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On 7/23/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. Should I commit the patch that removes the excessive synchronization from PoolableConnectionFactory. It won't fix this problem but may alleviate some other ones. +1 to committing the patch. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] close issues
On Jul 21, 2007, at 12:35 PM, Phil Steitz wrote: Its not quite that bad now; but the returning orphans do not get closed on return. What happens now is that the GOP throws IllegalStateException when you try to return an object (or perform any other operation) on a closed pool. We could include a patch in pool 1.3.1 to passivate and destroy a returning orphan before throwing the IllegalStateException, taking a baby step toward better lifeclycle management. Since the pool does not hold references to these orphans once its closed, I am not sure how big a problem this is in general; though certainly for dbcp, the underlying physical connections do not get closed right away in this case. I implemented the IllegalStateException idea. Now when close is called on BasicDataSource, it is marked as close and no new connections will be created (you get a SQLException). As before the idle connections are immedately destroyed and the close method returns. As the active connections are closed, they are destroyed. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] close issues
On Jul 20, 2007, at 10:15 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I am fine waiting to DBCP 1.4, since unless we are talking about different things, this really amounts to a significant change to both dbcp and pool. If what we want is to *always* track open connections and have the lingering close apply to the active (i.e. checked out) as well as idle connections, we need to follow through on what looks like it was the original plan of moving AbandonedObjectPool to pool and use this _all the time_ in place of GenericObjectPool, which is really just an idle object pool (maintains no references to borrowed objects). I think there are two features here also. The first is a lingering close where we close the data source along with all idle connection. Then as the checked out connections are returned to the pool, we destroy them instead of putting them in a closed pool. The second feature is a force close which as you pointed out requires tracking of active connection. After looking at the pooling code, I think that will take a lot of work to implement with the current code. In any case, we need to get a pool release out ASAP since pool 1.3 introduced some bugs that are causing problems (see for example POOL-97) since dbcp started using this version. Synchronization was increased in pool 1.3 as well. The hang here is lack of volunteer time and difficulty getting into the codebase. I have only recently started working on the pool code base. The compositepool package includes an alternative impl that we have been thinking about as a pool 2.0. The plan that I proposed a while back (http://www.mail-archive.com/commons-dev@jakarta.apache.org/ msg94027.html) was to push out a pool 1.3.1 patch release fixing POOL-97 (when reviewing the patch there, remember that dbcp statement pooling can create quite a few pools) and other bugs fixed since 1.3 and have DBCP 1.3 depend on that, both fully backward compatible with current versions. I still think we should do that. I can handle the RM duty for both of these and close a couple more of the pool bugs, but what we need to speed things up is more eyeballs validating and testing and contributing - and applying - patches. I'll try to review the patch. If we do do a 1.3.1, I think we should change GOP and GKOP to destroy objects returned to the pool after the pool is closed. Otherwise you end up with stuck objects in a closed pool. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 5:26 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. Yes, and at least for dbcp 1.3, I would prefer not to hop all the way to 1.5 required JDK level. I agree. I also wouldn't want to switch dbcp to a pool that hasn't been heavily tested first. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. Before writing another one, have a look at the compositepool package in pool head. Well, I got this email after hacking on one for about 6 hours. I the kind of person that needs to finish things I start, so I'm going to keep hacking on it. I will take a look at composite pool in 2.0 and assuming my version doesn't suck. I'll see if I can merge any of my good features into that code. In the end I may just end up wasting a lot of my time, but at least I'll learn how hard it is to write a good pool:) -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] close issues
On 7/21/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 10:15 PM, Phil Steitz wrote: On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I am fine waiting to DBCP 1.4, since unless we are talking about different things, this really amounts to a significant change to both dbcp and pool. If what we want is to *always* track open connections and have the lingering close apply to the active (i.e. checked out) as well as idle connections, we need to follow through on what looks like it was the original plan of moving AbandonedObjectPool to pool and use this _all the time_ in place of GenericObjectPool, which is really just an idle object pool (maintains no references to borrowed objects). I think there are two features here also. The first is a lingering close where we close the data source along with all idle connection. Then as the checked out connections are returned to the pool, we destroy them instead of putting them in a closed pool. The second feature is a force close which as you pointed out requires tracking of active connection. After looking at the pooling code, I think that will take a lot of work to implement with the current code. Agreed. Let's focus on getting dbcp 1.3 out with current (incomplete) lifecycle semantics supported by pool 1.3 and postpone major surgery for now. We should open a pool JIRA at some point, though, summarizing the need for full lifecycle support. In any case, we need to get a pool release out ASAP since pool 1.3 introduced some bugs that are causing problems (see for example POOL-97) since dbcp started using this version. Synchronization was increased in pool 1.3 as well. The hang here is lack of volunteer time and difficulty getting into the codebase. I have only recently started working on the pool code base. The compositepool package includes an alternative impl that we have been thinking about as a pool 2.0. The plan that I proposed a while back (http://www.mail-archive.com/commons-dev@jakarta.apache.org/ msg94027.html) was to push out a pool 1.3.1 patch release fixing POOL-97 (when reviewing the patch there, remember that dbcp statement pooling can create quite a few pools) and other bugs fixed since 1.3 and have DBCP 1.3 depend on that, both fully backward compatible with current versions. I still think we should do that. I can handle the RM duty for both of these and close a couple more of the pool bugs, but what we need to speed things up is more eyeballs validating and testing and contributing - and applying - patches. I'll try to review the patch. If we do do a 1.3.1, I think we should change GOP and GKOP to destroy objects returned to the pool after the pool is closed. Otherwise you end up with stuck objects in a closed pool. Its not quite that bad now; but the returning orphans do not get closed on return. What happens now is that the GOP throws IllegalStateException when you try to return an object (or perform any other operation) on a closed pool. We could include a patch in pool 1.3.1 to passivate and destroy a returning orphan before throwing the IllegalStateException, taking a baby step toward better lifeclycle management. Since the pool does not hold references to these orphans once its closed, I am not sure how big a problem this is in general; though certainly for dbcp, the underlying physical connections do not get closed right away in this case. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Release 1.3 soon?
On 7/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says Close and release all connections that are currently stored in the connection pool associated with our data source. Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the pool is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is sorry, no way to do that. Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to closeDBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support restart. This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource immutable-once-initialized. Here are some open JIRAs I think we can close: Fixed: DBCP-194 BasicDataSource.setLogWriter should not do createDataSource DBCP-102 setReadOnly setAutoCommit called too many times DBCP-97 setAutoCommit(true) when returning connection to the pool DBCP-212 PoolingDataSource closes physical connections +1 and thanks for verifying 97. Invalid: DBCP-209 Is DataSource.getConnection(user, pass) working the way it is suppose to? User should be using either SharedPoolDataSource or the PerUserPoolDataSource. DBCP-53 commons dbcp does not supports Firebird DB Torque bug or misconfiguration by user. +1 Won't fix DBCP-115 allow to set = 6 parameters to do non-global SSL Request for mysql specific feature DBCP-152 add a socketFactory attribute to BasicDataSource (to allow SSL thread-safe) Request for mysql specific feature +1 I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). We should also address DBCP-4 (by using jdk logging, since we have bumped to 1.4 level). I think it would be good to start adding some simple instrumentation in 1.3 that we could add to in subsequent releases. Having things like physical connection opens / closes, pool high water marks, waits, etc., loggable would make debuggng and performance tuning much easier. I will finish reviewing recent patches tomorrow and come up with a straw man release plan this weekend if no one beats me to it. Thanks for all of your help on this, Dain. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Release 1.3 soon?
On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: On 7/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says Close and release all connections that are currently stored in the connection pool associated with our data source. Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the pool is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is sorry, no way to do that. Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to closeDBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support restart. This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource immutable-once-initialized. I think these are basically the same issue. I agree with the comments in DBCP-221 which seems to want a lingering close. This is in line with how I expect close to work (having not read any of the pooling code yet). I think the root of this problem is we don't have a clear start/stop life-cycle methods. Currently, we are using the first getConnection () for start and close() for stop, which I think are good choices. Maybe we could keep those choices, and introduce an explicit start(), stop() and stop(long maxWait). This way we can support the close lingering and close immediately options people seem to be asking for. Once we have this functionality, it should be easy to add restart() which would close() lingering the existing inner datasource and create/start a new one. I'm not sure this is something that can be done without changes to pool, but I'll take a look at it today. snip/ I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. We should also address DBCP-4 (by using jdk logging, since we have bumped to 1.4 level). I think it would be good to start adding some simple instrumentation in 1.3 that we could add to in subsequent releases. Having things like physical connection opens / closes, pool high water marks, waits, etc., loggable would make debuggng and performance tuning much easier. In the future, I'd like these events to be available via a listener interface, so I can write monitoring code (like an mbean). Of course working out that interface takes time, so I think we should add the logging in 1.3 and a listener in 1.4. Are there any notes on how we'd like to use util.Logging (log names, levels, etc.)? I will finish reviewing recent patches tomorrow and come up with a straw man release plan this weekend if no one beats me to it. I'll look at DBCP-44 since I think it is an easy small fix. Then the close() issue and finally logging, unless someone beats me to them. BTW, it is getting challenging to write new patches with the current patches I have out. I have been trying to keep patches so there aren't file overlaps. I may need to start putting ordering information into the patches like apply after DBCP-1234. Thanks for all of your help on this, Dain. No prob. This code is like programming crack for me Small tasks for a big programming high :) -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] DBCP-44 Deadlock
On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: I would love to have a fix for DBCP-44; but that could wait on pool 1.4 if necessary (and Ipersonally see no way to fix it just within dbcp. It would be great if I was wrong on that). I think the makeObject method is over synchronized. Actually, the class doesn't look it's synchronized properly at all. I'll take a shot at fixing this. I attached a patch that fixes the synchronization in PoolableConnectionFactory, but the deadlock still persists. The problem is GenericObjectPool.borrowObject() is synchronized so when it needs to makeObject that method is called while the synchronized block is held. I think this would take major surgery to make GenericObjectPool not perform this way. Thats what I feared. Thanks for looking in any case. I think the way to solve this is to write a new pool implementation that is much more async. This easier with the Java5 concurrent packages, but still quite tricky. Yes, and at least for dbcp 1.3, I would prefer not to hop all the way to 1.5 required JDK level. I'll attempt to put together one in a few days. Regardless, I don't think this is something we should target for this release. Before writing another one, have a look at the compositepool package in pool head. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] close issues
On 7/20/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 20, 2007, at 11:26 AM, Dain Sundstrom wrote: On Jul 19, 2007, at 11:19 PM, Phil Steitz wrote: On 7/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: Are there any DBCP-1.3 release plans? Based on the JIRAs I think we are close to being ready to release. Are there any items that are planned but don't have JIRAs? There are two things that I would like to at least talk about that relate to various JIRAs and comments on the list: 1) Intended current and future contract of close() on a connection pool, in particular the contract of BasicDataSource.close. The javadoc says Close and release all connections that are currently stored in the connection pool associated with our data source. Some users interpret this - incorrectly - to mean that close will close *active* as well as idle connections. Even when AbandonedConfig is used (in which case the pool holds references to connections that have been checked out), close only closes idle connections (since the pool is really and idle object pool). So the answer to the question in, e.g. DBCP-221, is sorry, no way to do that. Javadoc should be improved in any case. 2) Immutable-once-initialized status of BasicDataSource. I am inclined to close DBCP-221 as WONTFIX, but in this case we should rip out the remnants of what must have seemed like a good idea at the time to support restart. This is sort of related to 1), because if we are going to attempt to allow BasicDataSource to be mutable once it has been initialized, I don't see any way to do that consistently without closing or appropriately modifying connections that have been checked out. Since we don't do that now, we can't really support this. My vote would be to keep BasicDataSource immutable-once-initialized. I think these are basically the same issue. I agree with the comments in DBCP-221 which seems to want a lingering close. This is in line with how I expect close to work (having not read any of the pooling code yet). I think the root of this problem is we don't have a clear start/ stop life-cycle methods. Currently, we are using the first getConnection() for start and close() for stop, which I think are good choices. Maybe we could keep those choices, and introduce an explicit start(), stop() and stop(long maxWait). This way we can support the close lingering and close immediately options people seem to be asking for. Once we have this functionality, it should be easy to add restart() which would close() lingering the existing inner datasource and create/start a new one. I'm not sure this is something that can be done without changes to pool, but I'll take a look at it today. I think this will require a patch to pooling (documented in DBCP-221). What are the plans for pooling? This is a tiny change so we could do a pool 1.3.1 or 1.4 release. Alternatively, we could wait until DBCP 1.4 (and the next pool release) to address this issue. I am fine waiting to DBCP 1.4, since unless we are talking about different things, this really amounts to a significant change to both dbcp and pool. If what we want is to *always* track open connections and have the lingering close apply to the active (i.e. checked out) as well as idle connections, we need to follow through on what looks like it was the original plan of moving AbandonedObjectPool to pool and use this _all the time_ in place of GenericObjectPool, which is really just an idle object pool (maintains no references to borrowed objects). In any case, we need to get a pool release out ASAP since pool 1.3 introduced some bugs that are causing problems (see for example POOL-97) since dbcp started using this version. Synchronization was increased in pool 1.3 as well. The hang here is lack of volunteer time and difficulty getting into the codebase. I have only recently started working on the pool code base. The compositepool package includes an alternative impl that we have been thinking about as a pool 2.0. The plan that I proposed a while back (http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg94027.html) was to push out a pool 1.3.1 patch release fixing POOL-97 (when reviewing the patch there, remember that dbcp statement pooling can create quite a few pools) and other bugs fixed since 1.3 and have DBCP 1.3 depend on that, both fully backward compatible with current versions. I still think we should do that. I can handle the RM duty for both of these and close a couple more of the pool bugs, but what we need to speed things up is more eyeballs validating and testing and contributing - and applying - patches. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Remove primitive default values?
On 7/19/07, Dain Sundstrom [EMAIL PROTECTED] wrote: The PerUserDataSource and SharedPoolDataSource use primitives for the read only, transaction isolation and auto commit default values so there is not way to see if the value was set in the configuration. This means there is no way to allow the driver defaults to pass through like in the PoolingDataSource. In the future, should all of these default values be non-primitive so we do not set them unless explicitly set in the configuration? +1 Phil -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Back pointers
Sounds good to me. I attached my fix to DBCP-11. This patch assures that all all returned Statements, PreparedStatements, CallableStatements and ResultSets are wrapped with a delegating object, which already properly handle the back pointers for Connection and Statement. This patch includes an extensive test to assure that the *same* object used to create the statement or result set is returned from either the getConnection() or getStatementMethod(). Note we must make sure to update this test for each release of the JDBC spec we support as new ways of obtaining these objects tend to be added over time. As per your suggestion below, this patch does not fix back pointers in connections obtained from a InstanceKeyDataSource using the cpdsadapter. The cpdsadapter does not use the delegating wrapper internally, and will need a different solution. DBCP-217 should also be closed. -dain On Jul 17, 2007, at 9:39 PM, Phil Steitz wrote: On 7/17/07, Dain Sundstrom [EMAIL PROTECTED] wrote: I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217 where the Statement.getConnection() and ResultSet.getStatement() return the wrong objects. The fix is pretty simple; we just need to make sure we wrap Statements and ResultSets returned from DelegatingConnection with the matching delegating type. +1 Anyway, I have the fix mostly complete with a bunch of test cases, but there is one problem... The PerUserPoolDataSource and SharedPoolDataSource classes return the ConnectionImpl class directly. This class is a wrapper around the real connection so we need to wrap returned Statements which is easy enough. The problem is these datasources use the CPDSConnectionFactory which does not call passivate on the delegating connection when the connection is returned to the pool so the Statements owned by the DelegatingConnection aren't closed. To make matters worse, CPDSConnectionFactory can't call passivate anyway because it is in a different package and the method is protected :( At this point I'm not sure what to do. I could fix the problem for all DataSources except for these two, and in the future we could rework these two to subclass PoolingDataSource. Alternative, we could move CPDSConnectionFactory to same package as DelegatingConnection or make is a sublcass of some ConnectionFactory with access to the passivate method. I really do think these datasources should be brought in line with the main abstractions used by the other classes, but I don't think that is something for this release (maybe for 2.0?). I think we should leave this alone for now and consider refactoring for 2.0, but there is a semantic difference that we need to keep in mind. InstanceKeyDataSource (parent of PerUser and SharedPool) sources connections from a ConnectionPoolDataSource. These datasources return connection *handles* (PooledConnection impls), which are not the same as DelegatingConnections. The cpdsadapter package is just there for older jdbc drivers that do not provide ConnectionPoolDataSource implementations. See the javadoc for InstanceKeyDataSource and also the implementation of makeObject there. The key difference in the contract is that InstanceKeyDataSource implements ConnectionEventListener, so when used with a driver that correctly supports ConnectionPoolDataSource, the connection handles handed out to users notify the pool (actually the factory in dbcp) when they are closed by the user. See connectionClosed in CPDSConnectionFactory. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp][pool] Performance / load tests
On 7/16/07, Henri Yandell [EMAIL PROTECTED] wrote: On 7/15/07, Phil Steitz [EMAIL PROTECTED] wrote: I have cleaned up some of my performance / load test code for [dbcp] and [pool] and would like to commit it somewhere so others can use and improve it. There is some common load generation code that should be factored out and I don't want to clutter the component codebases, so I am hesitant to commit to either pool or dbcp trunk. Any objections to my starting a [performance] sandbox component and seeding it with [dbcp] and [pool] performance tests? Any better ideas on where to put this code? +1 on putting it in as a component in sandbox. Committed the dbcp stuff. Pool to follow. Code is rough, but works. Ant from top level kicks off a run based on config in config.xml. If the database config in config.xml and jdbc driver location in build.properties are correct, the first run will create and populate a table called test_table in the database. I have tested the core code with mysql, postgres, oracle, hsqldb and sybase; but the currently packaged version only with mysql and postgres. The Digester config and overall property management is ugly and should be cleaned up. The run parameters are a little cryptic - see nextDelay javadoc in ClientThread for how this works. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Back pointers
BTW the reason we are getting ConnectionImpls instead of raw connections from the PooledDataSource is because PooledConnectionImpl.getConnection():159 wraps the raw connection with a ConnectionImpl. The line of code is commented with the spec requires that this return a new Connection instance. If we didn't wrap, the back pointers would work, but we'd be violating the JDBC spec. Once we wrap, we need to wrap all the statements and result sets so the back pointers are valid. Another bug, is we're not tracking statements and result sets, so when the logical connection is closed the statements and result sets are not closed as required buy the spec. -dain On Jul 17, 2007, at 2:42 PM, Dain Sundstrom wrote: I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217 where the Statement.getConnection() and ResultSet.getStatement() return the wrong objects. The fix is pretty simple; we just need to make sure we wrap Statements and ResultSets returned from DelegatingConnection with the matching delegating type. Anyway, I have the fix mostly complete with a bunch of test cases, but there is one problem... The PerUserPoolDataSource and SharedPoolDataSource classes return the ConnectionImpl class directly. This class is a wrapper around the real connection so we need to wrap returned Statements which is easy enough. The problem is these datasources use the CPDSConnectionFactory which does not call passivate on the delegating connection when the connection is returned to the pool so the Statements owned by the DelegatingConnection aren't closed. To make matters worse, CPDSConnectionFactory can't call passivate anyway because it is in a different package and the method is protected :( At this point I'm not sure what to do. I could fix the problem for all DataSources except for these two, and in the future we could rework these two to subclass PoolingDataSource. Alternative, we could move CPDSConnectionFactory to same package as DelegatingConnection or make is a sublcass of some ConnectionFactory with access to the passivate method. I really do think these datasources should be brought in line with the main abstractions used by the other classes, but I don't think that is something for this release (maybe for 2.0?). Suggestion? -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Back pointers
On 7/17/07, Dain Sundstrom [EMAIL PROTECTED] wrote: I'm working on a fix for the back pointers bugs DBCP-11 and DBCP-217 where the Statement.getConnection() and ResultSet.getStatement() return the wrong objects. The fix is pretty simple; we just need to make sure we wrap Statements and ResultSets returned from DelegatingConnection with the matching delegating type. +1 Anyway, I have the fix mostly complete with a bunch of test cases, but there is one problem... The PerUserPoolDataSource and SharedPoolDataSource classes return the ConnectionImpl class directly. This class is a wrapper around the real connection so we need to wrap returned Statements which is easy enough. The problem is these datasources use the CPDSConnectionFactory which does not call passivate on the delegating connection when the connection is returned to the pool so the Statements owned by the DelegatingConnection aren't closed. To make matters worse, CPDSConnectionFactory can't call passivate anyway because it is in a different package and the method is protected :( At this point I'm not sure what to do. I could fix the problem for all DataSources except for these two, and in the future we could rework these two to subclass PoolingDataSource. Alternative, we could move CPDSConnectionFactory to same package as DelegatingConnection or make is a sublcass of some ConnectionFactory with access to the passivate method. I really do think these datasources should be brought in line with the main abstractions used by the other classes, but I don't think that is something for this release (maybe for 2.0?). I think we should leave this alone for now and consider refactoring for 2.0, but there is a semantic difference that we need to keep in mind. InstanceKeyDataSource (parent of PerUser and SharedPool) sources connections from a ConnectionPoolDataSource. These datasources return connection *handles* (PooledConnection impls), which are not the same as DelegatingConnections. The cpdsadapter package is just there for older jdbc drivers that do not provide ConnectionPoolDataSource implementations. See the javadoc for InstanceKeyDataSource and also the implementation of makeObject there. The key difference in the contract is that InstanceKeyDataSource implements ConnectionEventListener, so when used with a driver that correctly supports ConnectionPoolDataSource, the connection handles handed out to users notify the pool (actually the factory in dbcp) when they are closed by the user. See connectionClosed in CPDSConnectionFactory. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp][pool] Performance / load tests
On 7/15/07, Phil Steitz [EMAIL PROTECTED] wrote: I have cleaned up some of my performance / load test code for [dbcp] and [pool] and would like to commit it somewhere so others can use and improve it. There is some common load generation code that should be factored out and I don't want to clutter the component codebases, so I am hesitant to commit to either pool or dbcp trunk. Any objections to my starting a [performance] sandbox component and seeding it with [dbcp] and [pool] performance tests? Any better ideas on where to put this code? +1 on putting it in as a component in sandbox. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Managed Connection support
On 7/6/07, Dain Sundstrom [EMAIL PROTECTED] wrote: On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote: Thanks, Dain. I applied the patch. I also patched the m1 and ant builds to work. The Ant now fails with JDK 1.3, but unless someone screams loudly soon, we have moved the minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so this is not an issue. Sweet! That was very fast. snip/ For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. I am ambivalent on the merging into existing packages, but we should talk about this. We can figure that out as we get close to a release. If the thing isn't fully tested by then we could just mark the whole package as experimental. Thats what I was thinking, so good to leave as is for now. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. That would be greatly appreciated. We really need [dbcp] and [pool] volunteers. Given that you are an ASF committer, all you have to do is ask to get commons karma and you are certainly welcome to do that :) Excellent, I definitely like access, so I can fix any bugs in the code directly. Looks like there's a little beaurocracy to go through here, but pls keep the patches coming for now. In [dbcp] 1.3, we can fix the close semantics and other things that involve semantic changes. All suggestions and patches are welcome. I'll take a look at it when I get back in town next week. Thanks in advance. You will find that some of these bugs relate to [pool] and fixes need to either be mindful of current pool impl - most importantly the fact that the core of pool is an idle object linked list and there is no guard to protect against the same object appearing multiple times in the list, which will happen if it is returned twice, resulting in serious badness for dbcp - or we need to do something with pool to keep the changes safe. There is an alternative pool impl in the compositepool package in pool head, but the current plan is to push out one more patch release of pool and have dbcp 1.3 continue to use the GenericObjectPool. See roadmap discussion here: http://www.mail-archive.com/commons-dev@jakarta.apache.org/msg94027.html Comments welcome! Since POOL-97 is causing app server issues, it would be great to get some feedback on the proposed fix there and then bundle up a pool 1.3.1 patch release. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Managed Connection support
On Jul 5, 2007, at 7:13 AM, Phil Steitz wrote: Thanks, Dain. I applied the patch. I also patched the m1 and ant builds to work. The Ant now fails with JDK 1.3, but unless someone screams loudly soon, we have moved the minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so this is not an issue. Sweet! That was very fast. snip/ For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. I am ambivalent on the merging into existing packages, but we should talk about this. We can figure that out as we get close to a release. If the thing isn't fully tested by then we could just mark the whole package as experimental. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. That would be greatly appreciated. We really need [dbcp] and [pool] volunteers. Given that you are an ASF committer, all you have to do is ask to get commons karma and you are certainly welcome to do that :) Excellent, I definitely like access, so I can fix any bugs in the code directly. In [dbcp] 1.3, we can fix the close semantics and other things that involve semantic changes. All suggestions and patches are welcome. I'll take a look at it when I get back in town next week. Thanks again, -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Managed Connection support
I just posted a patch JIRA which adds support for container managed connections to DBCP. In an environment where you have an accessible transaction manger such as Tomcat (when installed), Geronimo or OpenEJB, this patch allows adds support for pooling managed connections to an XA or non-XA data base. There are many libraries that use DBCP for non-managed environments, but when additional resources such as a JMS provider are added to the mix, they have to replace DBCP with something else. If you search google for XA and DBCP, you will loads of painful direction on how to replace DBCP with something else. I personally want to use DBCP in Tomcat with ActiveMQ. Thanks, Dain. I applied the patch. I also patched the m1 and ant builds to work. The Ant now fails with JDK 1.3, but unless someone screams loudly soon, we have moved the minimum jdk level for dbcp 1.3 to JDK 1.4 (per earlier discussion), so this is not an issue. snip/ For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. I am ambivalent on the merging into existing packages, but we should talk about this. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. That would be greatly appreciated. We really need [dbcp] and [pool] volunteers. Given that you are an ASF committer, all you have to do is ask to get commons karma and you are certainly welcome to do that :) In [dbcp] 1.3, we can fix the close semantics and other things that involve semantic changes. All suggestions and patches are welcome. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Managed Connection support
Hi Dain, thanks a lot for this input. Can you please resend your message to the commons-dev list located at commons-dev@jakarta.apache.org ? To add some a little bit confusion: The commons have just decided to become a top-level project in their own right, so the development list will move to [EMAIL PROTECTED] at some point in the near future. Still, it would be great to follow up on your suggestions; TransactionSupport would be a real benefit to DBCP. Best regards Henning On Tue, 2007-07-03 at 18:21 -0700, Dain Sundstrom wrote: I just posted a patch JIRA which adds support for container managed connections to DBCP. In an environment where you have an accessible transaction manger such as Tomcat (when installed), Geronimo or OpenEJB, this patch allows adds support for pooling managed connections to an XA or non-XA data base. There are many libraries that use DBCP for non-managed environments, but when additional resources such as a JMS provider are added to the mix, they have to replace DBCP with something else. If you search google for XA and DBCP, you will loads of painful direction on how to replace DBCP with something else. I personally want to use DBCP in Tomcat with ActiveMQ. Anyways, enough with motivation To use the new code, you need access to a TranactionManager (this code just creates a new Geronimo one). transactionManager = new TransactionManagerImpl(); Then you either create an XADataSource and DataSourceXAConectionFactory or as this code does, create a normal DBCP ConnectionFactory and wrap it with a LocalXAConectionFactory Properties properties = new Properties(); properties.setProperty(user, username); properties.setProperty(password, password); ConnectionFactory connectionFactory = new DriverConnectionFactory( new TesterDriver(), jdbc:apache:commons:testdriver, properties); // wrap it with a LocalXAConnectionFactory XAConnectionFactory xaConnectionFactory = new LocalXAConnectionFactory( transactionManager, connectionFactory); Now you create a pool as normal (full reuse here). pool = new GenericObjectPool(); pool.setMaxActive(getMaxActive()); pool.setMaxWait(getMaxWait()); // create the pool object factory PoolableConnectionFactory factory = new PoolableConnectionFactory( xaConnectionFactory, pool, null, SELECT DUMMY FROM DUAL, true, true); pool.setFactory(factory); Finally, you create a special ManagedDataSource using the pool above and the special TransactionRegistry object obtained from the XAConnectionFactory. ds = new ManagedDataSource(pool, xaConnectionFactory.getTransactionRegistry()); ds.setAccessToUnderlyingConnectionAllowed(true); That's it. The data source and connections work as normal until you start a transaction using the TransactionManager. When you use a connection while the transaction is active, the connection is enlisted in the transaction. When the transaction is complete, the connection is committed (or rolledback) and the connection returns to normal. Most of the new code extends existing classes or uses existing classes without modification. The key to this reuse is the TransactionRegistry abstraction which maintains a map from the Connection to the XAResource for that connection. The XAResource is needed to enlist a connection in a transaction. The TransactionRegistry and associated TransationContext class encapsulate all interactions with the TransactionManager leaving the Connection implementation relatively simple (making reuse easier). For now the code is contained in the org.apache.commons.dbcp.managed package, but I would suspect we may want to spread it out amongst the existing packages instead of creating a feature specific package. I'm also not sure what additional interfaces people may want such as equivalents of the BasicDataSource or BasicDataSourceFactory. The code has tests and has javadoc, but it needs real world testing and some real docs. I'm going try hooking it into OpenEJB and running it's massive test suite with a couple of opensource DBs. Anyways, I hope you all like it and accept the patch. I'm around to help with changes or whatever. I also ran into a few bugs while working on this that are already reported in JIRA (like the close bugs) and am willing to help with those also. -dain - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] [pool] Roadmap ideas
On 6/21/07, Henri Yandell [EMAIL PROTECTED] wrote: On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: Next releases: [dbcp] - 1.3 close as many of the 1.3-marked bugs as possible without the new pool impl and add instrumentation using JDK logging, therefore increasing required JDK level to 1.4. +1. Instrumentation is strongly needed. Agreed. I have started this and will commit what I have to trunks. Resolution of some issues involving close behavior may have to be deferred to rework of pool-dbcp connection (move to CompositePools). Continue dependency on [pool]'s GOP in this release. More aggressive bug fixing, performance improvement - more testing, public beta required. Need to talk about a strategy for that. It'd be very nice to get a test suite, separate from the unit tests, that we can point at an undefined database and churn through. It could do performance testing as well as veracity testing. I have some of this and will commit it in crude state to start. [pool] - push out a 1.3.1 including fixes applied since 1.3 and if possible, fixes for POOL-97, POOL-93, with dbcp 1.3 depending on this. The idea here is the 1.3.x branches of [pool] and [dbcp] continue to support existing clients with full backward compatibility at JDK 1.4 level, providing bug fixes but no new functionality or APIs. My general thoughts on [pool] are 'whatever [dbcp] needs it to do'. After looking at this some more and the fixes that have been committed to the pool 2.0 trunk, I am now seeing Sandy's original plan as better - get a pool 2.0 out directly instead of trying to push out a 1.3.1. Some of the fixes already committed would force 1.4 at least and the new stuff in compositepool should be released. So unless I hear screams, I will continue down the pool 2.0 path, getting a release out ASAP that will work with dbcp 1.2.x. Sorry to change my mind on this. 2.0's: (Work could begin now on branches, concurrently with 1.x releases above) [dbcp]: 2.0 move to CompositePool backing and add JDBC 4 support, increasing JDK level to 1.5 Now agree with Sandy's orginal plan to leave this at 1.4 and move to 1.5 in 3.0. If 1.x-incompatible changes are necessary (not obvious at this point that they are), rename affected packages dbcp2. [pool]: 2.0 release compositepool package, resolve open pool bugs. JDK level upped to 1.5. Investigate use of JDK concurrency package to improve performance and/or resolve some open pool issues. I'd have to find time to help out with the minor releases before I probably have huge ideas here. All help appreciated. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] [pool] Roadmap ideas
On 6/20/07, Phil Steitz [EMAIL PROTECTED] wrote: Next releases: [dbcp] - 1.3 close as many of the 1.3-marked bugs as possible without the new pool impl and add instrumentation using JDK logging, therefore increasing required JDK level to 1.4. +1. Instrumentation is strongly needed. Resolution of some issues involving close behavior may have to be deferred to rework of pool-dbcp connection (move to CompositePools). Continue dependency on [pool]'s GOP in this release. More aggressive bug fixing, performance improvement - more testing, public beta required. Need to talk about a strategy for that. It'd be very nice to get a test suite, separate from the unit tests, that we can point at an undefined database and churn through. It could do performance testing as well as veracity testing. [pool] - push out a 1.3.1 including fixes applied since 1.3 and if possible, fixes for POOL-97, POOL-93, with dbcp 1.3 depending on this. The idea here is the 1.3.x branches of [pool] and [dbcp] continue to support existing clients with full backward compatibility at JDK 1.4 level, providing bug fixes but no new functionality or APIs. My general thoughts on [pool] are 'whatever [dbcp] needs it to do'. 2.0's: (Work could begin now on branches, concurrently with 1.x releases above) [dbcp]: 2.0 move to CompositePool backing and add JDBC 4 support, increasing JDK level to 1.5 and removing currently deprecated classes. If 1.x-incompatible changes are necessary (not obvious at this point that they are), rename affected packages dbcp2. [pool]: 2.0 release compositepool package, resolve open pool bugs. JDK level upped to 1.5. Investigate use of JDK concurrency package to improve performance and/or resolve some open pool issues. I'd have to find time to help out with the minor releases before I probably have huge ideas here. Comments, suggestions, *volunteers*? Definitely a volunteer. My Commons load is: CLI release ASAP. BeanUtils helping Niall. Starting to ponder an EL bugfix push. Try to get more into DBCP. Timeline for DBCP is probably a month away still - though I'm optimistic that I can lure some colleagues into it then too. A testing scaffold for DBCP should scratch a few of their itches. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp // Validation query timeout
Hi Adam,
Funny you should ask... I have recently been wondering that exact same
thing. In my case, a very, very slow validation query (approx 1.7
hours!) was causing Tomcat to crash. All 150 Tomcat worker threads were
eventually consumed, waiting for DBCP to return a connection.
Now, I have no idea why the database (Oracle 10g) was so thoroughly
wedged; I have yet to investigate that side of it. I had a look around
the DBCP code, though, and found two things: 1) there is no facility for
a validation time-out, and; 2) the validation query is executed /within
a synchronized block/ on the connection pool. This is in violation of
the design principals described in Joshua Bloch's Effective Java, Item
49, and is an excellent example of why Bloch is right on the money. In
this case, any client that wants a connection is forced to wait until
the pool validates the connections for all previous clients.
For this reason, I believe that the existing design of DBCP is flawed.
The validation query facility built into classes such as BasicDataSource
should not be used. Instead, any validation query should be executed
/after/ the connection is obtained from the connection pool.
To achieve this, I developed the ValidatingDataSource, below. This
class is a wrapper around a PoolingDataSource, that overrides
getConnection(). It also provides accessors for the validation query and
the validation query time-out. When the client calls getConnection(),
the ValidatingDataSource obtains a connection from the PoolingDataSource
and invokes the validation query on it. If the query succeeds, the
connection is return to the client. If it fails, or times-out, the
connection is removed from the pool, and another connection obtained.
This process continues indefinitely; some sort of limit would be a good
idea, and I'll implement one Real Soon Now.
I have also created a BetterDataSource class, that extends
BasicDataSource to use the ValidatingDataSource. However, the name
BetterDataSource is rather pretentious and I'm too embarrassed to list
the code here.
Regards,
Greg [EMAIL PROTECTED]
PS: I apologise for including this chunk of code in my reply. I really
should learn how to use the DBCP patch process...
/*
* ValidatingDataSource.java
*/
package com.greghhawkes.util.dbcp;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;
import javax.sql.DataSource;
import org.apache.commons.dbcp.DelegatingConnection;
import org.apache.commons.dbcp.PoolableConnection;
import org.apache.commons.dbcp.PoolingDataSource;
/**
* A data source wrapper that validates the connection returned by the
underlying PoolingDataSource.
* @author Greg Hawkes
*/
public class ValidatingDataSource implements javax.sql.DataSource {
private PoolingDataSource m_delegate;
private String m_validationQuery;
private int m_validationTimeout;
/**
* Creates a new instance of ValidatingDataSource
*/
public ValidatingDataSource(PoolingDataSource delegate) {
m_delegate = delegate;
}
/**
* Obtain and (optionally) validate a connection from the underlying
datasource.
*/
public Connection getConnection() throws SQLException {
m_delegate.setAccessToUnderlyingConnectionAllowed(true);
for ( ; ; ) {
Connection conn = m_delegate.getConnection();
if (conn == null) {
return null;
} else if (isValid(conn)) {
return conn;
}
// Validation failed; destroy the connection
DelegatingConnection dc = (DelegatingConnection) conn;
PoolableConnection c = (PoolableConnection) dc.getDelegate();
c.reallyClose();
}
}
public Connection getConnection(String username, String password)
throws SQLException {
throw new UnsupportedOperationException();
}
public PrintWriter getLogWriter() throws SQLException {
return m_delegate.getLogWriter();
}
public void setLogWriter(PrintWriter out) throws SQLException {
m_delegate.setLogWriter(out);
}
public void setLoginTimeout(int seconds) throws SQLException {
m_delegate.setLoginTimeout(seconds);
}
public int getLoginTimeout() throws SQLException {
return m_delegate.getLoginTimeout();
}
public String getValidationQuery() {
return m_validationQuery;
}
public void setValidationQuery(String validationQuery) {
m_validationQuery = validationQuery;
}
public int getValidationTimeout() {
return m_validationTimeout;
}
public void setValidationTimeout(int validationTimeout) {
if (validationTimeout 0) {
validationTimeout = 0;
}
m_validationTimeout = validationTimeout;
}
/**
* Test whether the validationQuery can be executed on the connection,
*/
Re: Dbcp // Validation query timeout
On 5/11/07, Tworkiewicz, Adam [EMAIL PROTECTED] wrote: Hi, We use dbcp for connection pooling in our application that talks to Oracle 10g RAC (2 nodes). Our dbcp config is attached below. We are seeing undesired behaviour when we test db failover. Since we use load balancing connections in the pool point to both db servers. When we shutdown one of the db nodes our ping query hangs waiting for TCP/IP traffic. Since the box is down there is no traffic and the query hangs until a TCP/IP timeout occures. Is there a way to set up a timeout on the validation query? Currently, there is no way to do that. Would you mind opening JIRA ticket requesting this feature? You can do that here: http://jakarta.apache.org/commons/dbcp/issue-tracking.html Patches welcome. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp // Validation query timeout
On 5/11/07, Greg Hawkes [EMAIL PROTECTED] wrote: Hi Adam, Funny you should ask... I have recently been wondering that exact same thing. In my case, a very, very slow validation query (approx 1.7 hours!) was causing Tomcat to crash. All 150 Tomcat worker threads were eventually consumed, waiting for DBCP to return a connection. Just so I understand the use case here, is this something that happens every n queries, or does the database just periodically slow down uniformly, so all queries are slow? Also, what versions of commons dbcp and commons pool are you running? Now, I have no idea why the database (Oracle 10g) was so thoroughly wedged; I have yet to investigate that side of it. I had a look around the DBCP code, though, and found two things: 1) there is no facility for a validation time-out, and; 2) the validation query is executed /within a synchronized block/ on the connection pool. This is in violation of the design principals described in Joshua Bloch's Effective Java, Item 49, and is an excellent example of why Bloch is right on the money. In this case, any client that wants a connection is forced to wait until the pool validates the connections for all previous clients. For this reason, I believe that the existing design of DBCP is flawed. The validation query facility built into classes such as BasicDataSource should not be used. Instead, any validation query should be executed /after/ the connection is obtained from the connection pool. These are valid points. Please open JIRA tickets and make suggestions for improvement in the tickets and discussion on commons-dev. Patches are welcome. The core design issue is in commons pool's GenericObjectPool (GOP), which arguably violates Block's principle above in order to ensure thread safety in its 1.x design. Work on a 2.0 version of pool has begun and discussion of this and other topics is welcome on the commons-dev mailing list. Version 1.3 of commons pool added synchronization to GOP to deal with thread safety issues reported in POOL-26 and some other issues resolved in the 1.3 release. Unfortunately, this may have exacerbated the problem mentioned here. If you are using dbcp 1.2.2 and pool 1.3, you could fall back to pool 1.2 (still using dbcp 1.2.2); but in this case you should review the release notes for pool 1.3 to see what other bug fixes you would be missing: http://jakarta.apache.org/commons/pool/release-notes-1.3.html To achieve this, I developed the ValidatingDataSource, below. This class is a wrapper around a PoolingDataSource, that overrides getConnection(). It also provides accessors for the validation query and the validation query time-out. When the client calls getConnection(), the ValidatingDataSource obtains a connection from the PoolingDataSource and invokes the validation query on it. If the query succeeds, the connection is return to the client. If it fails, or times-out, the connection is removed from the pool, and another connection obtained. This process continues indefinitely; some sort of limit would be a good idea, and I'll implement one Real Soon Now. I have also created a BetterDataSource class, that extends BasicDataSource to use the ValidatingDataSource. However, the name BetterDataSource is rather pretentious and I'm too embarrassed to list the code here. Regards, Greg [EMAIL PROTECTED] PS: I apologise for including this chunk of code in my reply. I really should learn how to use the DBCP patch process... Not a problem. To start, you could just add the sources for your new classes to a JIRA ticket. Make sure you can legally contribute them and for new classes its best to include the apache license header (cut and paste from any current source, or see http://www.apache.org/licenses/LICENSE-2.0.html#apply). Have a look at http://www.apache.org/dev/contributors.html http://jakarta.apache.org/commons/svninfo.html for more information about how to checkout sources from subversion and submit patches. Feel free to ask here or on commons-dev if you have problems getting set up. Thanks for the feedback and thanks in advance for your contributions. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] PerUserPoolDataSource
Thanks. I updated again and I have it. -Original Message- From: Phil Steitz [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 09, 2007 9:39 PM To: Jakarta Commons Developers List Subject: Re: [DBCP] PerUserPoolDataSource They are there in the datasources package, e.g. http://svn.apache.org/repos/asf/jakarta/commons/proper/dbcp/trunk/src/ja va/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java Phil On 5/9/07, Srinath Narasimhan [EMAIL PROTECTED] wrote: Hi, Has the PerUserPoolDataSource and its factory removed from the dbcp project? I got the latest source from subversion and it is missing. Thanks Srinath. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] PerUserPoolDataSource
They are there in the datasources package, e.g. http://svn.apache.org/repos/asf/jakarta/commons/proper/dbcp/trunk/src/java/org/apache/commons/dbcp/datasources/PerUserPoolDataSource.java Phil On 5/9/07, Srinath Narasimhan [EMAIL PROTECTED] wrote: Hi, Has the PerUserPoolDataSource and its factory removed from the dbcp project? I got the latest source from subversion and it is missing. Thanks Srinath. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Bugzilla id 33167
Srinath Narasimhan wrote: Hi, I had originally filed a bug/enhancement for Commons DBCP which I am trying to get added to the main build. http://issues.apache.org/bugzilla/show_bug.cgi?id=33167 Please see: https://issues.apache.org/jira/browse/DBCP-61 I could not find that in the new jira issue tracker. Could you tell me if there is any intention of moving this into the main build? Thanks Srinath. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [DBCP] Bugzilla id 33167
Thanks for the quick response. The next question is it going to get added in any release ? -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 4:38 PM To: Jakarta Commons Developers List Subject: Re: [DBCP] Bugzilla id 33167 Srinath Narasimhan wrote: Hi, I had originally filed a bug/enhancement for Commons DBCP which I am trying to get added to the main build. http://issues.apache.org/bugzilla/show_bug.cgi?id=33167 Please see: https://issues.apache.org/jira/browse/DBCP-61 I could not find that in the new jira issue tracker. Could you tell me if there is any intention of moving this into the main build? Thanks Srinath. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Bugzilla id 33167
In JIRA the Fix Version/s indicates which version a fix for an issue is scheduled to be included. In this case it is set to 1.3. No release date has been set for that version. Srinath Narasimhan wrote: Thanks for the quick response. The next question is it going to get added in any release ? -Original Message- From: Dennis Lundberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 08, 2007 4:38 PM To: Jakarta Commons Developers List Subject: Re: [DBCP] Bugzilla id 33167 Srinath Narasimhan wrote: Hi, I had originally filed a bug/enhancement for Commons DBCP which I am trying to get added to the main build. http://issues.apache.org/bugzilla/show_bug.cgi?id=33167 Please see: https://issues.apache.org/jira/browse/DBCP-61 I could not find that in the new jira issue tracker. Could you tell me if there is any intention of moving this into the main build? Thanks Srinath. -- Dennis Lundberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Periodic clean up of abandoned connections
On 4/3/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
Would you guys be open to a patch to implement a periodic cleanup of
abandoned connections
the following logic can cause abandoned connections to sit around
forever, just because you are not hitting the max in the pool.
Using a DB like postgres that creates a process for each connection,
this is a waste of resources, and the only way to trigger the abandoned
cleanup is to try to get to max number of connections.
if (config != null
config.getRemoveAbandoned()
(getNumIdle() 2)
(getNumActive() getMaxActive() - 3) ) {
removeAbandoned();
}
Let me know, and if yes, I will provide a patch
I agree that the above setup is not optimal. Now is a good time to
talk about what we want to do in this area. The abandoned connection
cleanup problem has sort of a rich history in [dbcp] and is a complex
problem. See for example:
http://marc.info/?t=10563341341r=1w=4
(Start with David Graham's first post on 24-Jun-2003)
My own opinion on needing to provide *something* here has not changed
-- I think we should provide a well-designed and safe capability to
remove abandoned connections - but wrestling with concurrency bugs
(e.g., the still-open DBCP-44) has made me appreciate how hard this
is. Note that the AbandonedConfig and AbandonedObjectPool that
provide the functionality above have been deprecated and we should be
thinking about how to replace / remove them (so I don't think patching
AbandonedObjectPool is the best idea), so now is a good time to open
the discussion on how to provide a better solution. Ideas /
suggestions welcome!
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Periodic clean up of abandoned connections
Phil Steitz wrote:
On 4/3/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
Would you guys be open to a patch to implement a periodic cleanup of
abandoned connections
the following logic can cause abandoned connections to sit around
forever, just because you are not hitting the max in the pool.
Using a DB like postgres that creates a process for each connection,
this is a waste of resources, and the only way to trigger the abandoned
cleanup is to try to get to max number of connections.
if (config != null
config.getRemoveAbandoned()
(getNumIdle() 2)
(getNumActive() getMaxActive() - 3) ) {
removeAbandoned();
}
Let me know, and if yes, I will provide a patch
I agree that the above setup is not optimal. Now is a good time to
talk about what we want to do in this area. The abandoned connection
cleanup problem has sort of a rich history in [dbcp] and is a complex
problem. See for example:
http://marc.info/?t=10563341341r=1w=4
(Start with David Graham's first post on 24-Jun-2003)
I actually wrote my own connection pool in 1999 that has abandoned
support and this has never been a problem.
I started reading the thread, and forgive my ignorance, the thread is
way too long for me to churn through.
The solution to a problem like this is quite simple
1. When connections are marked abandoned, the wrapper connection is
simply marked closed, and the underlying JDBC connection is closed or
returned to the pool with a new wrapper.
2. When applications are accessing their java.sql.Connection method,
it simply throws SQLException(Connection closed-abandoned);
There is 0 concurrency issues.
I will look into the DBCP code to see if there are any logistics issue
specifically to DBCP, but in my implementation it was a piece of cake.
5 seconds later
Ok, so it looks like the DBCP is not using any wrapper connection,
hence everyone worries about the connection being references all over
the placed.
Well, piece of cake, add a wrapper using a reflection.proxy, and the
mystery is solved.
Furthermore, in order to save threads, the generic pool can have a
public void tasks(){} method, that the a thread invokes.
In the GenericPool the tasks() would look like this
public void tasks() {
if (_evictor!=null) evictor.run();//of course evictor-runnable is
modified to not sleep or delay
}
The abandoned pool would then override it like this
public void tasks() {
super.tasks();
if ( getActiveCount()0) removeAbandoned();
}
Is there something apparent I am missing, since I have not know anything
like this to be an issue in the past in other pools
What I will do is work up a patch and submit, based on that you can
review it and see if is something you might be interested in.
Filip
My own opinion on needing to provide *something* here has not changed
-- I think we should provide a well-designed and safe capability to
remove abandoned connections - but wrestling with concurrency bugs
(e.g., the still-open DBCP-44) has made me appreciate how hard this
is. Note that the AbandonedConfig and AbandonedObjectPool that
provide the functionality above have been deprecated and we should be
thinking about how to replace / remove them (so I don't think patching
AbandonedObjectPool is the best idea), so now is a good time to open
the discussion on how to provide a better solution. Ideas /
suggestions welcome!
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Periodic clean up of abandoned connections
Filip Hanik - Dev Lists wrote:
Phil Steitz wrote:
On 4/3/07, Filip Hanik - Dev Lists [EMAIL PROTECTED] wrote:
Would you guys be open to a patch to implement a periodic cleanup of
abandoned connections
the following logic can cause abandoned connections to sit around
forever, just because you are not hitting the max in the pool.
Using a DB like postgres that creates a process for each connection,
this is a waste of resources, and the only way to trigger the abandoned
cleanup is to try to get to max number of connections.
if (config != null
config.getRemoveAbandoned()
(getNumIdle() 2)
(getNumActive() getMaxActive() - 3) ) {
removeAbandoned();
}
Let me know, and if yes, I will provide a patch
I agree that the above setup is not optimal. Now is a good time to
talk about what we want to do in this area. The abandoned connection
cleanup problem has sort of a rich history in [dbcp] and is a complex
problem. See for example:
http://marc.info/?t=10563341341r=1w=4
(Start with David Graham's first post on 24-Jun-2003)
I actually wrote my own connection pool in 1999 that has abandoned
support and this has never been a problem.
I started reading the thread, and forgive my ignorance, the thread is
way too long for me to churn through.
The solution to a problem like this is quite simple
1. When connections are marked abandoned, the wrapper connection is
simply marked closed, and the underlying JDBC connection is closed or
returned to the pool with a new wrapper.
2. When applications are accessing their java.sql.Connection method,
it simply throws SQLException(Connection closed-abandoned);
There is 0 concurrency issues.
I will look into the DBCP code to see if there are any logistics issue
specifically to DBCP, but in my implementation it was a piece of cake.
5 seconds later
Ok, so it looks like the DBCP is not using any wrapper connection,
hence everyone worries about the connection being references all
over the placed.
Well, piece of cake, add a wrapper using a reflection.proxy, and the
mystery is solved.
oh, it is using a wrapper, the wrapper could be better though, instead
of implementing every single java.sql.Connection method, use a proxy,
and that way support all versions of JDK, as methods do get added
between JDK versions
Filip
Furthermore, in order to save threads, the generic pool can have a
public void tasks(){} method, that the a thread invokes.
In the GenericPool the tasks() would look like this
public void tasks() {
if (_evictor!=null) evictor.run();//of course evictor-runnable is
modified to not sleep or delay
}
The abandoned pool would then override it like this
public void tasks() {
super.tasks();
if ( getActiveCount()0) removeAbandoned();
}
Is there something apparent I am missing, since I have not know
anything like this to be an issue in the past in other pools
What I will do is work up a patch and submit, based on that you can
review it and see if is something you might be interested in.
Filip
My own opinion on needing to provide *something* here has not changed
-- I think we should provide a well-designed and safe capability to
remove abandoned connections - but wrestling with concurrency bugs
(e.g., the still-open DBCP-44) has made me appreciate how hard this
is. Note that the AbandonedConfig and AbandonedObjectPool that
provide the functionality above have been deprecated and we should be
thinking about how to replace / remove them (so I don't think patching
AbandonedObjectPool is the best idea), so now is a good time to open
the discussion on how to provide a better solution. Ideas /
suggestions welcome!
Phil
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/23/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. snip/ Looks good. IMO, it'd be better if the artifacts contain the final version number when you call the vote. As nits, I'd also suggest: * Including filename in md5s * Building with JDK 1.3 This presents a challenge, which I don't know exactly how to deal with. The last release (1.2.1) was build with maven using jdk 1.4. The ant build works using 1.3, but does conditional compilation in that case to target jdbc 2.0 and also adds the jdbc 2 stdext dependency. Could be the best thing to do is to add a note in the README indicating how to build under 1.3. Is that acceptable? Phil -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/23/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. snip/ Looks good. IMO, it'd be better if the artifacts contain the final version number when you call the vote. As nits, I'd also suggest: * Including filename in md5s * Building with JDK 1.3 This presents a challenge, which I don't know exactly how to deal with. The last release (1.2.1) was build with maven using jdk 1.4. The ant build works using 1.3, but does conditional compilation in that case to target jdbc 2.0 and also adds the jdbc 2 stdext dependency. Could be the best thing to do is to add a note in the README indicating how to build under 1.3. Is that acceptable? snip/ Sure, the 1.2.1 release recipe sounds good to me. -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/23/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. snip/ Looks good. IMO, it'd be better if the artifacts contain the final version number when you call the vote. As nits, I'd also suggest: * Including filename in md5s * Building with JDK 1.3 This presents a challenge, which I don't know exactly how to deal with. The last release (1.2.1) was build with maven using jdk 1.4. The ant build works using 1.3, but does conditional compilation in that case to target jdbc 2.0 and also adds the jdbc 2 stdext dependency. Could be the best thing to do is to add a note in the README indicating how to build under 1.3. Is that acceptable? Sounds much the same as DbUtils 1.1. It was built under 1.4 and the release manager was trusted to have checked that the 1.3 build works. Just in case something odd crept in JDK wise. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/28/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: On 1/23/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. snip/ Looks good. IMO, it'd be better if the artifacts contain the final version number when you call the vote. As nits, I'd also suggest: * Including filename in md5s * Building with JDK 1.3 This presents a challenge, which I don't know exactly how to deal with. The last release (1.2.1) was build with maven using jdk 1.4. The ant build works using 1.3, but does conditional compilation in that case to target jdbc 2.0 and also adds the jdbc 2 stdext dependency. Could be the best thing to do is to add a note in the README indicating how to build under 1.3. Is that acceptable? Sounds much the same as DbUtils 1.1. It was built under 1.4 and the release manager was trusted to have checked that the 1.3 build works. Just in case something odd crept in JDK wise. I have both built and run tests on 1.3. Just so we are clear, I assume that since we can't practically build [dbcp] on 1.3, I assume it is OK to build it using 1.5, rather than 1.4 as in the previous release. I could cut the release using 1.4, but don't see the value in that. Can anyone else? Thanks for the feedback. Phil
Re: [DBCP] 1.2.2 RC1 available for review
On 1/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/28/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/28/07, Phil Steitz [EMAIL PROTECTED] wrote: On 1/23/07, Rahul Akolkar [EMAIL PROTECTED] wrote: snip/ As nits, I'd also suggest: * Including filename in md5s * Building with JDK 1.3 This presents a challenge, which I don't know exactly how to deal with. The last release (1.2.1) was build with maven using jdk 1.4. The ant build works using 1.3, but does conditional compilation in that case to target jdbc 2.0 and also adds the jdbc 2 stdext dependency. Could be the best thing to do is to add a note in the README indicating how to build under 1.3. Is that acceptable? Sounds much the same as DbUtils 1.1. It was built under 1.4 and the release manager was trusted to have checked that the 1.3 build works. Just in case something odd crept in JDK wise. I have both built and run tests on 1.3. Just so we are clear, I assume that since we can't practically build [dbcp] on 1.3, I assume it is OK to build it using 1.5, rather than 1.4 as in the previous release. I could cut the release using 1.4, but don't see the value in that. Can anyone else? Thanks for the feedback. snap/ I believe Commons libraries should take the more conservative approach, where practically possible (I wouldn't want to cut releases with JDK 1.3, for example). At the end of the day, this makes the RMs job easier. FWIW, I feel the need to go through more rigorous testing when I pick up a library (be it Commons or otherwise) that is built with a higher JDK than my platform -- or I just rebuild from source, if I can. Ultimately, this decision is upto the RM. For example, in this case, I won't be voting against *just* because you build with JDK 1.5 (though, FWIW, I may not vote in favor either). -Rahul Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
Looks good to me - the RAT report was good and it compiled and tested OK under JDK 1.3 (using ant). The only nitpick I could find is the copyright statement in the NOTICE.txt has 2006 rather than 2007 (we should probably update all of components to 2007). Niall On 1/23/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. The tarballs/zips are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/ Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/docs/ Clirr report: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/dbcp-1.2.2-RC1-clirr.txt The jar is deployed in the apache snapshot repo: http://people.apache.org/repository/commons-dbcp/jars/commons-dbcp-1.2.2-RC1.jar Thanks in advance for your comments! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
Hi Phil, Phil Steitz wrote: I have created a release candidate for DBCP 1.2.2. The tarballs/zips are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/ Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/docs/ Clirr report: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/dbcp-1.2.2-RC1-clirr.txt The jar is deployed in the apache snapshot repo: http://people.apache.org/repository/commons-dbcp/jars/commons-dbcp-1.2.2-RC1.jar Thanks in advance for your comments! tried to build from the src package, but the Ant build does not work ... it references ../pool. Shouldn't the src package be self-contained? Building with M1 in Linux using JDK 1.5 works fine though and also the site doc look good. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/23/07, Jörg Schaible [EMAIL PROTECTED] wrote: Hi Phil, Phil Steitz wrote: I have created a release candidate for DBCP 1.2.2. The tarballs/zips are here: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/ Release notes: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/RELEASE-NOTES.txt Web site: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/docs/ Clirr report: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/dbcp-1.2.2-RC1-clirr.txt The jar is deployed in the apache snapshot repo: http://people.apache.org/repository/commons-dbcp/jars/commons-dbcp-1.2.2-RC1.jar Thanks in advance for your comments! tried to build from the src package, but the Ant build does not work ... it references ../pool. Shouldn't the src package be self-contained? I built OK using ant, but you have to configure the dependencies using a build.properties (theres a build.properties.sample). Niall Building with M1 in Linux using JDK 1.5 works fine though and also the site doc look good. - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
Niall Pemberton wrote: On 1/23/07, Jörg Schaible [EMAIL PROTECTED] wrote: [snip] tried to build from the src package, but the Ant build does not work ... it references ../pool. Shouldn't the src package be self-contained? I built OK using ant, but you have to configure the dependencies using a build.properties (theres a build.properties.sample). OK, so +1 then ... - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/23/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. snip/ Looks good. IMO, it'd be better if the artifacts contain the final version number when you call the vote. As nits, I'd also suggest: * Including filename in md5s * Building with JDK 1.3 -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/22/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. No KEYS file (I got your key from Math). So this is mostly a reminder to add yourself to the DBCP one. .asc's look good once I found the key. You're using the old way of release - nowadays we're svelte and modern. We create the release as if it was the real thing - 1.2.2 rather than 1.2.2-rc1, upload to a directory with 1.2.2-rc1/ and tag it 1.2.2-rc1, and then rollback the versions in svn. jar/pom wouldn't go into the snapshot repo then though - just put them in the same directory as the rc. I suspect this still needs documenting. Shame on me (and others who've done the releases this way :) ). I wonder how Maven-2 is going to affect it. I committed a change for the build.properties.sample based on trying to use Ant. Very minor - hopefully not something that would be an inconvenience. Src builds happily with Ant and Maven. Exceptions with Ant, but I'm assuming it's okay as the build completes. MD5s pass. This page should mention 1.2.2: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/docs/downloads.html and a 1.2.2.html page is needed. The two links to javadocs in the navbar point to the same javadoc. Either they shouldn't, or one should be removed. Otherwise - looks good. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] 1.2.2 RC1 available for review
On 1/23/07, Henri Yandell [EMAIL PROTECTED] wrote: On 1/22/07, Phil Steitz [EMAIL PROTECTED] wrote: I have created a release candidate for DBCP 1.2.2. No KEYS file (I got your key from Math). So this is mostly a reminder to add yourself to the DBCP one. .asc's look good once I found the key. Yes, will do that. You're using the old way of release - nowadays we're svelte and modern. We create the release as if it was the real thing - 1.2.2 rather than 1.2.2-rc1, upload to a directory with 1.2.2-rc1/ and tag it 1.2.2-rc1 , and then rollback the versions in svn. jar/pom wouldn't go into the snapshot repo then though - just put them in the same directory as the rc. Me likes old way - I don't remember agreeing that having binaries, tars, jars, etc floating around with release names was a good thing. Even if only in home directory, I do not like this. I want people to download and *test* the RC, which is unsanitary if it has a release name. When the music has stopped and we are voting on a release package, then I am fine putting the actual bits out there to vote on, which I agree is a good thing. Could be I am just arguing about timing, but to me an RC is an RC - not a final release. I also don't like the rollback idea above. That looks like an abuse of scm to me. Of course, I may be missing some important subtlety, in which case I will revise my view of how revision history should work ;-) I suspect this still needs documenting. Shame on me (and others who've done the releases this way :) ). I wonder how Maven-2 is going to affect it. I committed a change for the build.properties.sample based on trying to use Ant. Very minor - hopefully not something that would be an inconvenience. Src builds happily with Ant and Maven. Exceptions with Ant, but I'm assuming it's okay as the build completes. MD5s pass. This page should mention 1.2.2: http://people.apache.org/~psteitz/dbcp-1.2.2-RC1/docs/downloads.html http://people.apache.org/%7Epsteitz/dbcp-1.2.2-RC1/docs/downloads.html Good catch. Yes, will fix. and a 1.2.2.html page is needed. The two links to javadocs in the navbar point to the same javadoc. Either they shouldn't, or one should be removed. OK, I can get rid of one of them. Otherwise - looks good. Thanks! Phil
Re: DBCP high performance contention point
Sorry for the late response. I have opened a ticket for this issue here: http://issues.apache.org/jira/browse/DBCP-206 The setAutoCommit hit should be diminished by the resolution to http://issues.apache.org/jira/browse/DBCP-102 but it looks to me as though there could be more to this issue than that. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] ASL 1.1 code in dbcp - upgrade license?
On 11/29/06, Henri Yandell [EMAIL PROTECTED] wrote: Any reason for src/java/org/apache/commons/dbcp/datasources/SequencedHashMap.java and src/java/org/apache/commons/dbcp/datasources/LRUMap.java having being licensed under ASL 1.1? Phil said a couple of days ago there was no reason to fix them to ASL 2: http://tinyurl.com/yfd74x I guess he just didn't get round to it yet Niall Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] ASL 1.1 code in dbcp - upgrade license?
On 11/28/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 11/29/06, Henri Yandell [EMAIL PROTECTED] wrote: Any reason for src/java/org/apache/commons/dbcp/datasources/SequencedHashMap.java and src/java/org/apache/commons/dbcp/datasources/LRUMap.java having being licensed under ASL 1.1? Phil said a couple of days ago there was no reason to fix them to ASL 2: http://tinyurl.com/yfd74x I guess he just didn't get round to it yet As I'm waiting for a big svn commit to slowly go through, I went ahead and did it. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Eliminate @author tags?
On 11/25/06, Niall Pemberton [EMAIL PROTECTED] wrote: On 11/25/06, Phil Steitz [EMAIL PROTECTED] wrote: I am getting ready to roll 1.2.2... Couple of comments (thought I'd get them in early): Thanks! 1) What version of the JDK is DBCP compatible with? If, for example, it is JDK 1.3 would be good to add soure/target values to project.properties: maven.compile.source=1.3 maven.compile.target=1.3 Done. 2) On the downloads page theres a link to the nightly builds. Given the discussion about this on members maybe it should be removed or moved elsewhere? For the validator RC I just created I moved it to the building page under the Development section on the navigation menu: http://people.apache.org/~niallp/validator-1.3.1-rc1/site/building.html +1 - will do. 3) I added some missing source file headers flagged by RAT: http://svn.apache.org/viewvc?view=revrevision=479268 Thanks, though no fair RATing early - he he I left LRUMap and SequencedHashMap (which have Apache 1.1 license headers) because I'm not sure whats going on with them. I see no reason not to change to the current license. I will do that. These are included to eliminate collections dependency. Also didn't touch the jocl files (poolingDriverExample.jocl.sample, test.jocl and testpool.jocl) because I don't know what they're about). These are just XML files, so xml headers will not cause any problems. Thanks again for having a look. I Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Eliminate @author tags?
I think it's pretty fair to zap all the email addresses but keep the names. That really takes care of the 'recommendation against @author' tags in my view and maintains the need for recognition. No one is going to hunt down a personal email address for someone when they could be mailing commons-dev. I've dropped my existing @author tags in Commons because I'd stopped adding them a few years back. Hen On 11/25/06, Phil Steitz [EMAIL PROTECTED] wrote: I am getting ready to roll 1.2.2 and would like to get rid of these. Unfortunately, most of the (many) @authors are long gone and will likely not see this post, so I am ambivalent about pulling them out. Any thoughts either way? Anyone have a script that whacks the tags? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Eliminate @author tags?
On 11/25/06, Phil Steitz [EMAIL PROTECTED] wrote: I am getting ready to roll 1.2.2 and would like to get rid of these. Unfortunately, most of the (many) @authors are long gone and will likely not see this post, so I am ambivalent about pulling them out. Any thoughts either way? Anyone have a script that whacks the tags? I don't have a script, but if you see my name on any of these classes (might be on a couple), feel free to whack away. Phil Craig
Re: [dbcp] Eliminate @author tags?
On 11/25/06, Phil Steitz [EMAIL PROTECTED] wrote: I am getting ready to roll 1.2.2... Couple of comments (thought I'd get them in early): 1) What version of the JDK is DBCP compatible with? If, for example, it is JDK 1.3 would be good to add soure/target values to project.properties: maven.compile.source=1.3 maven.compile.target=1.3 2) On the downloads page theres a link to the nightly builds. Given the discussion about this on members maybe it should be removed or moved elsewhere? For the validator RC I just created I moved it to the building page under the Development section on the navigation menu: http://people.apache.org/~niallp/validator-1.3.1-rc1/site/building.html 3) I added some missing source file headers flagged by RAT: http://svn.apache.org/viewvc?view=revrevision=479268 I left LRUMap and SequencedHashMap (which have Apache 1.1 license headers) because I'm not sure whats going on with them. Also didn't touch the jocl files (poolingDriverExample.jocl.sample, test.jocl and testpool.jocl) because I don't know what they're about). Niall Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Why Not Supported? BasicDataSource.getConnection(String username, String password)
On 10/3/06, Mark Barnes [EMAIL PROTECTED] wrote: Hi, All - I originally submitted this to Commons User some time ago, but no reply. I know that method org.apache.commons.dbcp.BasicDataSource.getConnection(String username, String password) winds up throwing an UnsuppoterdOperationException via its delegate, org.apache.commons.dbcp.PoolingDataSource. My question is, can anyone who knows why this was done please let me know? I can't speak for the original designers, but it makes sense to me that a connection pool wrapper such as BasicDataSource would not support this. BasicDataSource provides access to a pool of connections that with a common set of connection properties when it is initialized. To support getConnection(username, password), the pool would have to be recreated if the actual parameters were different. I suppose that is possible and the same thing should be possible using setUsername, setPassword, getConnection; but the latter actually does not work. If you (or anyone else) feels strongly enough about the need to be able to regen the pool with different user, pass credentials, then pls open a ticket. It looks like support for doing this after the setXxx above was planned at some point, but never implemented (cf restartNeeded instance variable). I've googled and googled for an answer, but have not been able to find one. Why the non-standard API? Why methods getUsername() and getPassword()? All config properties are exposed via javabeans properties. Is your concern about this security-related? Why store the username and password as plain text? I don't know what you mean here. These parameters are passed to the connection factory used to open the actual connections. They are not stored anywhere other than in memory. On my current project, placing the database username and password in a file on disk is not allowed, due to security concerns, so using a Container-managed DataSource is not possible. Do you mean stored in the code? If you want to store the credentials encypted somewheret and have a component decrypt and pass them to BasicDataSource at initialization time, you can do that, but there is no facility built in to [dbcp] to support the crypto, and I don't think that we be good separation of concerns. The [dbcp] component just needs the unencrypted parameters to store in memory and pass on to the driver. If having these credentials in memory as properties is a concern, that will be difficutl to address. Phil My thanks to anyone who can provide information and insight. ---Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DBCP release 1.2.2 and 1.3
On 8/14/06, Joseph Valerio [EMAIL PROTECTED] wrote: Hi, Is there a schedule when DBCP 1.2.2 and 1.3 will be released. We are currently bit by DBCP-28, the connection leak in PoolableConnection.close(). I would rather not make a local change, if I knew that something was coming. Watch this list for a release candidate notifications, votes and the 1.2.2 release over the next couple of weeks. We are close to ready to release this, but timing will depend on volunteer time and success closing the remaining issues and testing the RCs. Patches welcome! In the mean time, it would be great if you could grab one of the recent nightlies[1] and verify that the fix that was applied to resolve this issue works for you. Thanks. Phil [1] http://people.apache.org/builds/jakarta-commons/nightly/commons-dbcp/ (tarballs) http://people.apache.org/repo/m1-snapshot-repository/commons-dbcp/ (maven repo) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] A little design help please re DBCP-100
Thanks, Stephen. Great way to preserve compatibility while effectively dealing with the problem. If there are no objections, I will make this change. Phil On 8/7/06, Stephen Colebourne [EMAIL PROTECTED] wrote: You might want to look at [collections] ExtendedProperties where I just fixed a similar issue. I made the instance methods work against a new instance variable, and subclasses could still alter the static one, which now acts as a default. Stephen Phil Steitz wrote: As stated in the bug report: SharedPoolDataSource.getPooledConnectionAndInfo() is synchronized _instance_ method, but it accesses SharedPoolDataSource.userKeys which is a _static_ variable, so if you have more than one instance of SharedPoolDataSource (as we do) access to the map would not be properly synchronized. So either map should be made instance variable, or the method should be synchronized on the class, not instance. I would very much appreciate comments on the options to fix this, including WONTFIX, but I don't like that option. I have coded the change to synchronize the method on the class (or more precisely, to make its body synchronized on the class, since it can't be static), but am hesitant to make that change. Any better ideas? Any recollections / rationale for why the map is static? Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] A little design help please re DBCP-100
You might want to look at [collections] ExtendedProperties where I just fixed a similar issue. I made the instance methods work against a new instance variable, and subclasses could still alter the static one, which now acts as a default. Stephen Phil Steitz wrote: As stated in the bug report: SharedPoolDataSource.getPooledConnectionAndInfo() is synchronized _instance_ method, but it accesses SharedPoolDataSource.userKeys which is a _static_ variable, so if you have more than one instance of SharedPoolDataSource (as we do) access to the map would not be properly synchronized. So either map should be made instance variable, or the method should be synchronized on the class, not instance. I would very much appreciate comments on the options to fix this, including WONTFIX, but I don't like that option. I have coded the change to synchronize the method on the class (or more precisely, to make its body synchronized on the class, since it can't be static), but am hesitant to make that change. Any better ideas? Any recollections / rationale for why the map is static? Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[dbcp] A little design help please re DBCP-100
As stated in the bug report: SharedPoolDataSource.getPooledConnectionAndInfo() is synchronized _instance_ method, but it accesses SharedPoolDataSource.userKeys which is a _static_ variable, so if you have more than one instance of SharedPoolDataSource (as we do) access to the map would not be properly synchronized. So either map should be made instance variable, or the method should be synchronized on the class, not instance. I would very much appreciate comments on the options to fix this, including WONTFIX, but I don't like that option. I have coded the change to synchronize the method on the class (or more precisely, to make its body synchronized on the class, since it can't be static), but am hesitant to make that change. Any better ideas? Any recollections / rationale for why the map is static? Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Spring bug of interest?
It looks to me as though the passivateObject impl in [dbcp]'s PoolableConnectionFactory takes care of this. A test case to confirm would be great. Phil On 8/1/06, Henri Yandell [EMAIL PROTECTED] wrote: Came across this issue over at Spring: http://opensource.atlassian.com/projects/spring/browse/SPR-2090 Is it something DBCP has hit and fixed; or hasn't hit yet? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Build and site changes
+1 for all of these. Thanks! Phil On 7/10/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have a number of changes to the DBCP build and site which I can either commit or attach as a patch to a Jira ticket for review - whichever is preferred: 1) Remove the dependency on commons build and add Development section links as per other components and wiki instructions: http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture 2) Bring changes.xml up to date with all changes since 1.2.1 release (and remove redundant xdocs/release-notes-1.2.2.xml) 3) Change maven build to include files missing from source distro (build.properties.sample, checkstyle.xml and doc directory contents). 4) Configure the source distro to unpack to a different directory from the binary distro 5) Add page for building Commons DBCP (i.e. building.xml) as per other components. 6) Add custom csv-usage.xml as per other components. 7) Change downloads.xml page to point to DBCP's download page (i.e. downloads_commons-dbcp.cgi) 8) Change issue-tracking.xml to filter searches for DBCP project and re-enable the open, resolved and all search links. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Build and site changes
+1 On 7/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have a number of changes to the DBCP build and site which I can either commit or attach as a patch to a Jira ticket for review - whichever is preferred: 1) Remove the dependency on commons build and add Development section links as per other components and wiki instructions: http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture 2) Bring changes.xml up to date with all changes since 1.2.1 release (and remove redundant xdocs/release-notes-1.2.2.xml) 3) Change maven build to include files missing from source distro (build.properties.sample, checkstyle.xml and doc directory contents). 4) Configure the source distro to unpack to a different directory from the binary distro 5) Add page for building Commons DBCP (i.e. building.xml) as per other components. 6) Add custom csv-usage.xml as per other components. 7) Change downloads.xml page to point to DBCP's download page (i.e. downloads_commons-dbcp.cgi) 8) Change issue-tracking.xml to filter searches for DBCP project and re-enable the open, resolved and all search links. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ If you even dream of beating me you'd better wake up and apologize - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] Build and site changes
I've committed the changes and uploaded new versions of the main site pages (not javadoc, source xref etc) - available after the next resync. Niall On 7/11/06, Dion Gillard [EMAIL PROTECTED] wrote: +1 On 7/11/06, Niall Pemberton [EMAIL PROTECTED] wrote: I have a number of changes to the DBCP build and site which I can either commit or attach as a patch to a Jira ticket for review - whichever is preferred: 1) Remove the dependency on commons build and add Development section links as per other components and wiki instructions: http://wiki.apache.org/jakarta-commons/MavenWebsiteStucture 2) Bring changes.xml up to date with all changes since 1.2.1 release (and remove redundant xdocs/release-notes-1.2.2.xml) 3) Change maven build to include files missing from source distro (build.properties.sample, checkstyle.xml and doc directory contents). 4) Configure the source distro to unpack to a different directory from the binary distro 5) Add page for building Commons DBCP (i.e. building.xml) as per other components. 6) Add custom csv-usage.xml as per other components. 7) Change downloads.xml page to point to DBCP's download page (i.e. downloads_commons-dbcp.cgi) 8) Change issue-tracking.xml to filter searches for DBCP project and re-enable the open, resolved and all search links. Niall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.multitask.com.au/people/dion/ If you even dream of beating me you'd better wake up and apologize - Muhammad Ali - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] state of DBCP
On 6/21/06, Phil Steitz [EMAIL PROTECTED] wrote: On 6/21/06, jerome lacoste [EMAIL PROTECTED] wrote: Hi, I've submitted a patch some days ago and am waiting for comments (DBCP-175). In the mean time, I've had a look at the status of DBCP. Some notes: - no release since 2004 - there are 10+ issues marked UNRESOLVED but with a Resolved status in Jira. Could be cleaned up. - althought I don't have many problems with DBCP myself, I've seen issues of various types in Jira: NPEs, leaks, thread related issues, class loading issues, equals()/hashcode() issues etc... Pretty scary to me :) So I think it is time to decide what to do next... Should there be a 1.2.2 release? A 1.3? Who's involved today in DBCP ? I have been slowly plowing through the issues and have posted a release plan on the wiki here: http://wiki.apache.org/jakarta-commons/DBCP/1%2e2%2e2ReleasePlan OK I am relieved :) I can help triaging those issues, sending patches to fix some of them, but I don't want to send patches that will stay in Jira for years. Please, please keep the patches coming. I am reviewing the ones you submitted and will update Jira / apply in the next day or two. Any one else interested and knowledgeable of [dbcp] code base, pls chime in. Also, pls update the Wiki page to reflect any opinions that you have on which bugs absolutely must get fixed in 1.2.2. Your plan sounds very good. Only question is why not using Jira in the first place to target issues? DBCP-128 should probably be fixed later as it will probably require to change the implementation of equals and hashcode. You never know what this might break... DBCP-68 was committed. See http://issues.apache.org/jira/browse/DBCP-68#action_12411844 Cheers, Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] state of DBCP
On 6/21/06, jerome lacoste [EMAIL PROTECTED] wrote: On 6/21/06, Phil Steitz [EMAIL PROTECTED] wrote: On 6/21/06, jerome lacoste [EMAIL PROTECTED] wrote: Hi, I've submitted a patch some days ago and am waiting for comments (DBCP-175). In the mean time, I've had a look at the status of DBCP. Some notes: - no release since 2004 - there are 10+ issues marked UNRESOLVED but with a Resolved status in Jira. Could be cleaned up. - althought I don't have many problems with DBCP myself, I've seen issues of various types in Jira: NPEs, leaks, thread related issues, class loading issues, equals()/hashcode() issues etc... Pretty scary to me :) So I think it is time to decide what to do next... Should there be a 1.2.2 release? A 1.3? Who's involved today in DBCP ? I have been slowly plowing through the issues and have posted a release plan on the wiki here: http://wiki.apache.org/jakarta-commons/DBCP/1%2e2%2e2ReleasePlan OK I am relieved :) I can help triaging those issues, sending patches to fix some of them, but I don't want to send patches that will stay in Jira for years. Please, please keep the patches coming. I am reviewing the ones you submitted and will update Jira / apply in the next day or two. Any one else interested and knowledgeable of [dbcp] code base, pls chime in. Also, pls update the Wiki page to reflect any opinions that you have on which bugs absolutely must get fixed in 1.2.2. Your plan sounds very good. Only question is why not using Jira in the first place to target issues? Because we started planning this release before the Jira migration ;-) Probably a good idea to just do it all in Jira now. Feel free to jump in. DBCP-128 should probably be fixed later as it will probably require to change the implementation of equals and hashcode. You never know what this might break... Yes, that is really too bad, but I agree. DBCP-68 was committed. See http://issues.apache.org/jira/browse/DBCP-68#action_12411844 Good. Comments on other tickets and patches welcome! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] state of DBCP
Your plan sounds very good. Only question is why not using Jira in the first place to target issues? Because we started planning this release before the Jira migration ;-) Probably a good idea to just do it all in Jira now. Feel free to jump in. Probably can't do much with Jira in terms of editing the fix version field as I have no rights. IANAC(ommiter) :) DBCP-128 should probably be fixed later as it will probably require to change the implementation of equals and hashcode. You never know what this might break... Yes, that is really too bad, but I agree. DBCP-68 was committed. See http://issues.apache.org/jira/browse/DBCP-68#action_12411844 Good. Comments on other tickets and patches welcome! I looked at your other Recommended dispositions in the wiki page and they all seemed logical. Jerome - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] state of DBCP
On 6/21/06, jerome lacoste [EMAIL PROTECTED] wrote: Hi, I've submitted a patch some days ago and am waiting for comments (DBCP-175). In the mean time, I've had a look at the status of DBCP. Some notes: - no release since 2004 - there are 10+ issues marked UNRESOLVED but with a Resolved status in Jira. Could be cleaned up. - althought I don't have many problems with DBCP myself, I've seen issues of various types in Jira: NPEs, leaks, thread related issues, class loading issues, equals()/hashcode() issues etc... Pretty scary to me :) So I think it is time to decide what to do next... Should there be a 1.2.2 release? A 1.3? Who's involved today in DBCP ? I have been slowly plowing through the issues and have posted a release plan on the wiki here: http://wiki.apache.org/jakarta-commons/DBCP/1%2e2%2e2ReleasePlan I can help triaging those issues, sending patches to fix some of them, but I don't want to send patches that will stay in Jira for years. Please, please keep the patches coming. I am reviewing the ones you submitted and will update Jira / apply in the next day or two. Any one else interested and knowledgeable of [dbcp] code base, pls chime in. Also, pls update the Wiki page to reflect any opinions that you have on which bugs absolutely must get fixed in 1.2.2. Thanks! Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) This is an interesting idea. Would appreciate suggestions on how exactly to do this. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, Phil Steitz [EMAIL PROTECTED] wrote: On 3/28/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Mon, 2006-03-27 at 19:43 -0700, Phil Steitz wrote: snip/ * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. or replace with a mock pool implementation (if possible) This is an interesting idea. Would appreciate suggestions on how exactly to do this. I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Even if you do mock the pool, the test would be testing the behavior of the mock pool as called through Dbcp. I think any interesting interaction with the GOP would be implicitly tested by other unit tests. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Does anyone else think that this should be different? Suggestion: The next version of DBCP should allow you to specify your own implementation in a configuration file. I know that I was looking around for this feature when I first was exploring DBCP and POOL. -Pete
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, Peter Steijn [EMAIL PROTECTED] wrote: I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Does anyone else think that this should be different? Suggestion: The next version of DBCP should allow you to specify your own implementation in a configuration file. I know that I was looking around for this feature when I first was exploring DBCP and POOL. It's been a couple of years since I looked in detail, but IIRC the only place that DBCP locks down the choice of the pool implementation is when you select a specific *implementation* of DataSource (such as org.apache.commons.dbcp.BasicDataSource). If you assemble your own from scratch, you're free to do whatever you want as you build up the stack. Adding plugability inside something like BasicDataSource strikes me as an excellent way to hand a developer a loaded gun, aimed at their foot. The code in a given implementation is going to naturally make assumptions about the underlying pool implementation being used (such as what configuration parameters it accepts) -- if you want a different DBCP implementation, it's really easy to assemble your own. -Pete Craig
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
On 3/28/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/28/06, Peter Steijn [EMAIL PROTECTED] wrote: I haven't dug into Dbcp code but I think the GenericObjectPool is deep within Dbcp as an internal data structure and I'd be surprised if it let you specify a specific pool implementation. Does anyone else think that this should be different? Suggestion: The next version of DBCP should allow you to specify your own implementation in a configuration file. I know that I was looking around for this feature when I first was exploring DBCP and POOL. It's been a couple of years since I looked in detail, but IIRC the only place that DBCP locks down the choice of the pool implementation is when you select a specific *implementation* of DataSource (such as org.apache.commons.dbcp.BasicDataSource). If you assemble your own from scratch, you're free to do whatever you want as you build up the stack. Adding plugability inside something like BasicDataSource strikes me as an excellent way to hand a developer a loaded gun, aimed at their foot. The code in a given implementation is going to naturally make assumptions about the underlying pool implementation being used (such as what configuration parameters it accepts) -- if you want a different DBCP implementation, it's really easy to assemble your own. Also, my read of some of Dbcp code weeks ago is that if you use a pool with a running idle object (connection) evictor you run the risk of deadlock because of the order of how locks are acquired. synchronization of getting a new connection normally: DbcpConnection - ObjectPool - DbcpConnection.makeObject (implements PoolableObjectFactory) the same object instance on each side of the object pool instance. The idle eviction thread synchronization: ObjectPool - DbcpConnection.activateObject (implements PoolableObjectFactory) Until this is worked out it's not safe to let client code configure their own ObjectPool. Most likely this problem won't turn up in testing under light load but will fall apart in production. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
snip/ Who did it? How did it happen? Lets look at the clues. First while we are running TestJOCLed, it subclasses TestConnectionPool and that is where the failures are really happening. Yep. * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. Yes. This is bad and I agree this test case should be removed, as it depends on the implementation of the underlying pool, which is not part of [dbcp]. If there are no objections, I will remove this test case. * testConnectionsAreDistinct: This test method passes when you run it by itself. Took me a while to figure out why this fails. It fails because the GenericObjectPool backing Dbcp is configured with a maxActive of 10 but for me the test fails after borrowing 9 successful connections. I'm pretty sure somewhere two of the test methods are borrowing connections and not following the proper contracts and closing their connections. As you point out below, this is definitely true of testPooling when it fails (as it does) with the new pool impl. * testOpening, testClosing, testMaxActive, testThreaded, testPrepareStatemetnOptions, testNoRsetClose, testHashCode: all pass when run individually. They all fail because when testConnectionsAreDistinct fails it doesn't close any connection's it opened in a finally block so the shared GenericObjectPool which has a maxActive set to 10 thinks it's maxed out with 10 borrowed connections (9 were from testConnectionsAreDistinct). This whole unit test class has a problem in that each test method is not independent of the others. Each test method works when run alone because they have a fresh state that way. It's when one test leaves garbage state around after it runs that is affects other tests and triggers a cascade of failures. Yes. Better cleanup needs to be included in these tests. So where is the garbage state coming from? Like I said at the top, testPooling did it with the assertTrue, specifically lines 270 and 271 of TestConnectionPool: 270: assertTrue( underconn3 == underconn || underconn3 == underconn2 ); 271: conn3.close(); When the assertTrue throws an exception the conn3.close is never called resulting in a connection leak. The easiest fix is to just transpose those two lines and everything else but testPooling passes just fine. That still leaves testPooling as failing and I think that should be solved by removing the test method completely. I think it's fair to say that unit tests for Pool belong in the Pool component code base. Still, someone should look at the testConnectionsAreDistinct test method as it doesn't clean up after itself when it fails. Also someone should rework the unit test as a whole so when each test method is run there is no residual state left over from other test methods. Until this is fixed TestConnectionPool isn't really testing what you think it is and probably technically broken. Ack. Patches welcome! Based on above, I am +1 for pool release. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dbcp unit test failures with Pool 1.3 [was: [VOTE] Release Pool 1.3 based on 1.3-rc4]
Anyone up for a game of Clue? I think testThreading did it, with assertTrue in TestConnectionPool. On 3/26/06, Phil Steitz [EMAIL PROTECTED] wrote: -0 Could be a problem with setup or test itself, but with the 1.3-rc4 jar, I am getting failures in [dbcp] test org.apache.commons.dbcp.TestJOCLed. These tests pass with 1.2. The good news is the other [dbcp] test failures that pool 1.3 is supposed to fix succeed for me. Failures below happen on both Sun Linux JDK 1.5.0_06 and 1.4.2_10. snip/ Checked sigs and contents and everything looks good. Could be test failure is due to bad test in [dbcp]. Will change to +1 when this is resolved. Phil Test failure: Testcase: testPooling(org.apache.commons.dbcp.TestJOCLed): FAILED null junit.framework.AssertionFailedError at org.apache.commons.dbcp.TestConnectionPool.testPooling(TestConnectionPool.java:270) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Testcase: testConnectionsAreDistinct(org.apache.commons.dbcp.TestJOCLed): Caused an ERROR Cannot get a connection, pool error: Timeout waiting for idle object org.apache.commons.dbcp.SQLNestedException: Cannot get a connection, pool error: Timeout waiting for idle object at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:183) at java.sql.DriverManager.getConnection(DriverManager.java:525) at java.sql.DriverManager.getConnection(DriverManager.java:193) at org.apache.commons.dbcp.TestJOCLed.getConnection(TestJOCLed.java:42) at org.apache.commons.dbcp.TestConnectionPool.testConnectionsAreDistinct(TestConnectionPool.java:296) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) Caused by: java.util.NoSuchElementException: Timeout waiting for idle object at org.apache.commons.pool.impl.GenericObjectPool.borrowObject(GenericObjectPool.java:825) at org.apache.commons.dbcp.PoolingDriver.connect(PoolingDriver.java:175) ... 18 more This same error occurs for testOpening, testClosing, testMaxActive, testThreaded, testPrepareStatementOptions, testNoRsetClose and testHashCode. Who did it? How did it happen? Lets look at the clues. First while we are running TestJOCLed, it subclasses TestConnectionPool and that is where the failures are really happening. * testPooling: This test method passes when you run it by itself. It fails because while it looks like it's written to handle either a FIFO or a LIFO pool implementation it doesn't if the GenericObjectPool backing Dbcp has more than 2 idle connections. When the test is run after other tests the GOP contains 4 idle connections. With a LIFO the most recently returned is the first one borrowed so it doesn't matter how many idle connections already exist at the start of the test. Since GOP is now a FIFO the test fails because is incorrectly assumes that a recently returned connection will be the next one borrowed. IMO testPooling should be removed as it really testing Pool's behavior and not Dbcp's behavior. * testConnectionsAreDistinct: This test method passes when you run it by itself. Took me a while to figure out why this fails. It fails because the GenericObjectPool backing Dbcp is configured with a maxActive of 10 but for me the test fails after borrowing 9 successful connections. I'm pretty sure somewhere two of the test methods are borrowing connections and not following the proper contracts and closing their connections. * testOpening, testClosing, testMaxActive, testThreaded, testPrepareStatemetnOptions, testNoRsetClose, testHashCode: all pass when run individually. They all fail because when testConnectionsAreDistinct fails it doesn't close any connection's it opened in a finally block so the shared GenericObjectPool which has a maxActive set to 10 thinks it's maxed out with 10 borrowed connections (9 were from testConnectionsAreDistinct). This whole unit test class has a problem in that each test method is not independent of the others. Each test method works when run alone because they have a fresh state that way. It's when one test leaves garbage state around after it runs that is affects other tests and triggers a cascade of failures. So where is the garbage state coming from? Like I said at the top, testPooling did it with the assertTrue, specifically lines 270 and 271 of TestConnectionPool: 270: assertTrue( underconn3 == underconn || underconn3 == underconn2 ); 271: conn3.close(); When the assertTrue throws an exception the conn3.close is never called resulting in a connection leak. The
Re: [DBCP] and [POOL] am I in the right place?
On Sat, 2006-03-18 at 17:42 -0500, Sandy McArthur wrote: snip Also, I've implemented a new pool implementation that uses a builder pattern to compose an optimally performing pool implementations for the requested configuration. That implementation is currently working it's way through the incubator since it was written before I was an Apache committer. providing no other spanners fall into the works, everything should be sorted tomorrow. i plan to commit the source into pool/contrib/composite-pool. once it's there, feel free to go ahead and integrate it into trunk. - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] and [POOL] am I in the right place?
On 3/20/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-03-18 at 17:42 -0500, Sandy McArthur wrote: snip Also, I've implemented a new pool implementation that uses a builder pattern to compose an optimally performing pool implementations for the requested configuration. That implementation is currently working it's way through the incubator since it was written before I was an Apache committer. providing no other spanners fall into the works, everything should be sorted tomorrow. i plan to commit the source into pool/contrib/composite-pool. once it's there, feel free to go ahead and integrate it into trunk. Excellent, I appreciate you shepherding this through the process. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] and [POOL] am I in the right place?
On Mon, 2006-03-20 at 13:57 -0500, Sandy McArthur wrote: On 3/20/06, robert burrell donkin [EMAIL PROTECTED] wrote: On Sat, 2006-03-18 at 17:42 -0500, Sandy McArthur wrote: snip Also, I've implemented a new pool implementation that uses a builder pattern to compose an optimally performing pool implementations for the requested configuration. That implementation is currently working it's way through the incubator since it was written before I was an Apache committer. providing no other spanners fall into the works, everything should be sorted tomorrow. i plan to commit the source into pool/contrib/composite-pool. once it's there, feel free to go ahead and integrate it into trunk. Excellent, I appreciate you shepherding this through the process. just sorry it took so long. probably would have been quicker but i was trying to verify the documentation and process by following it naively. quite a few issues were identified which i'll document so hopefully those that follow will find things just a little easier... - robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] and [POOL] am I in the right place?
Yes, this is the right place. Welcome! Have a look at the following links for help getting started: http://www.apache.org/dev/ http://jakarta.apache.org/site/getinvolved.html http://jakarta.apache.org/commons/volunteering.html http://jakarta.apache.org/commons/patches.html Don't hesitate to ask questions if you need help gettting set up or understanding the code bases. Phil On 3/18/06, Pete Steijn [EMAIL PROTECTED] wrote: Greetings, I am looking to contribute to the DBCP and also POOL packages with some ideas that I have come up with through work at my university. I am, however, new to mailing lists. Can someone please confirm that I am in the right place? Thanks, Peter Steijn University of Delaware - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DBCP] and [POOL] am I in the right place?
On 3/18/06, Pete Steijn [EMAIL PROTECTED] wrote: I am looking to contribute to the DBCP and also POOL packages with some ideas that I have come up with through work at my university. I am, however, new to mailing lists. I'm interested in hearing what you are thinking. A lot has been done with Pool since the last release. Pool 1.3 is just about ready IMO and much of the work planed for a 2.0 release has been committed to the trunk. Also, I've implemented a new pool implementation that uses a builder pattern to compose an optimally performing pool implementations for the requested configuration. That implementation is currently working it's way through the incubator since it was written before I was an Apache committer. Dbcp depends significantly on Pool and a number of the problems with it are inherited from it using Pool which 1.2 and earlier have some really broken behavior. I haven't thought much about Dbcp yet but it's next on my personal task list after Pool 2. Pool plans: http://wiki.apache.org/jakarta-commons/PoolRoadMap 1.3 branch: http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/branches/1_3_RELEASE_BRANCH/ Pool 2.0: http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/trunk/ The composite pool impl being contributed: http://sandy.mcarthur.org/pool/ -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp][pool] Failing tests, dependent bugs
The Pool 1.3 is long over due and the 1.3 branch is where I think it should be for a release, at least code wise. The todo list for me is create a release-notes-1.3.xml and figure out maven. I've never actually used maven but it looks like I cannot put that off too longer. http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/pool/branches/1_3_RELEASE_BRANCH/ On 3/11/06, Phil Steitz [EMAIL PROTECTED] wrote: The failing tests in [dbcp] are because of BZ 29832. This appears to be caused by BZ 29863 against [pool] which is marked as FIXED. I know we are looking at some major restructuring / rewrite of [pool], but is any one willing to roll a minor release to get this and any other bug fixes out? Alternatively, we could insert a workaround for the [dbcp] problem. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] BZ 38073 - JNDI problems with SharedPoolDataSource
On 3/10/06, Phil Steitz [EMAIL PROTECTED] wrote: Any comments on this? http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 As I see it, there are two decent alternatives here. The one I first suggested in the report is too ugly. (i) Make the (incorrectly) implemenented getReference method in InstanceKeyDataSource throw, as described in the last comment on the report, and override with correct impls in the concrete subclasses. (ii) Make the (minor) backward-incompatible change to make the offending method in InstanceKeyDataSource abstract, as suggested in the original report, again providing correct impls in the subclasses. I think (ii) is cleaner (what should have been done in the first place) but is technically a backward incompatible change. Users who have subclassed will be forced to implement. Interested parties, please weigh in with opinions or better ideas about how to resolve this. (Standard disclaimer about not being familiar with Dbcp yet.) For a bug fix release it seems to me that you should override getReference() in PerUserPoolDataSource and SharedPoolDataSource. And document in InstanceKeyDataSource.getReference() that it will be going away in the next major release. Also, it seems to me that changing InstanceKeyDataSource.getReference() for the ref var to: Reference ref = new Reference(getClass().getName(), getClass().getName() + Factory, null); would work better. It's fragile but I don't think it would break anything new. Also scream now if adding test dependencies on the (ibiblio published) tomcat naming jars is not acceptable. For building and testing only right? Not for deployment of Dbcp? -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [dbcp] BZ 38073 - JNDI problems with SharedPoolDataSource
Phil Steitz wrote: Any comments on this? http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 I'd go with the cleaner solution, and document the possible problem in the release notes for anyone whom it might impact. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] BZ 38073 - JNDI problems with SharedPoolDataSource
On 3/10/06, Sandy McArthur [EMAIL PROTECTED] wrote: On 3/10/06, Phil Steitz [EMAIL PROTECTED] wrote: Any comments on this? http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 As I see it, there are two decent alternatives here. The one I first suggested in the report is too ugly. (i) Make the (incorrectly) implemenented getReference method in InstanceKeyDataSource throw, as described in the last comment on the report, and override with correct impls in the concrete subclasses. (ii) Make the (minor) backward-incompatible change to make the offending method in InstanceKeyDataSource abstract, as suggested in the original report, again providing correct impls in the subclasses. I think (ii) is cleaner (what should have been done in the first place) but is technically a backward incompatible change. Users who have subclassed will be forced to implement. Interested parties, please weigh in with opinions or better ideas about how to resolve this. (Standard disclaimer about not being familiar with Dbcp yet.) For a bug fix release it seems to me that you should override getReference() in PerUserPoolDataSource and SharedPoolDataSource. And document in InstanceKeyDataSource.getReference() that it will be going away in the next major release. Also, it seems to me that changing InstanceKeyDataSource.getReference() for the ref var to: Reference ref = new Reference(getClass().getName(), getClass().getName() + Factory, null); would work better. It's fragile but I don't think it would break anything new. Also scream now if adding test dependencies on the (ibiblio published) tomcat naming jars is not acceptable. For building and testing only right? Not for deployment of Dbcp? Yes, just a test dependency. Not required at all for dist or runtime. Phil -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] BZ 38073 - JNDI problems with SharedPoolDataSource
I've created a patch with what I think is the best fix for now: http://issues.apache.org/bugzilla/show_bug.cgi?id=38073#c8 On 3/10/06, Noel J. Bergman [EMAIL PROTECTED] wrote: Phil Steitz wrote: Any comments on this? http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 I'd go with the cleaner solution, and document the possible problem in the release notes for anyone whom it might impact. -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Connection.close() implementation issues [was: Jumping in...]
On 3/8/06, Sandy McArthur [EMAIL PROTECTED] wrote:
Sorry, ment to send this to commons-dev, not commons-user.
/me needs sleep asap.
-- Forwarded message --
From: Sandy McArthur [EMAIL PROTECTED]
Date: Mar 8, 2006 2:00 AM
Subject: [dbcp] Connection.close() implementation issues [was: Jumping in...]
To: Jakarta Commons Users List commons-user@jakarta.apache.org
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote:
There is a growing backlog of bugs open against [dbcp]. Unless other
committers object, I am going to jump in and start committing patches
and develop a maintenance release plan. I plan to start with
http://issues.apache.org/bugzilla/show_bug.cgi?id=33591
http://issues.apache.org/bugzilla/show_bug.cgi?id=38073
I would appreciate any feedback that community members have on
prioritization of open tickets. Also, as always, tickets with patches
and test cases are likely to get addressed quicker and comments /
testing / feedback are always welcome.
Any help from other commons committers, even if just in the form of
screams, will be most appreciated.
I've looked into some, as you can tell from my retracted bugzilla
comment and I think I've found a large source of the problems.
The method Connection.close() interface states: Calling the method
close on a Connection object that is already closed is a no-op.
Unless I am misunderstanding the use case in the ticket, it seems to
me that resolvoing it should lead us to qualify the above statement,
not make it true. We should search the archives for discussion on
this, as I recall there was a discussion of the no op issue. IIUC,
the problem in the ticket has to do with the corner case when the
already closed state is entered without the knowledge of the pool.
One other thing to keep in mind is that we should be aiming for a
dot-level release (need to get a plan in place), so we are going to
be constrained by backward compatibility and we have to be careful
about changing behaviors that users may be counting on. Therefore, we
should, wherever possible, apply the principle of least change when
fixing bugs. Of course, that does not mean that we ignore significant
issues or break contracts. Could be we what you are describing below
is appropriate and necessary.
Can you explain why the simple fixes in the ticket are not sufficient
to close the issue?
Thanks for looking into this.
Phil
This is violated in a number of places:
* PoolableConnection.java:77: throws an exception when close is called
and it's already closed. It should be replaced with a line similar to:
try {
if (!hasBeenReturnedToPool) {
hasBeenReturnedToPool = true;
_pool.invalidateObject(this);
}
} catch (Exception e) {
// ignored
}
* ConnectionImpl.java:115: calls assertOpen() which throws an
SQLException when it isn't open. This line should be removed.
* PoolingDataSource.java:179: the call to checkOpen() is like the call
to assertOpen() mentioned above and should be removed.
* PoolingDriver:258: another call to checkOpen(), same solution as before.
* TesterConnection.java:67: another call to checkOpen(), same solution
as before.
Someone should also audit:
* DelegatingConnection.java:184: make sure the call to passivate() is
fine being called more than once.
--
Sandy McArthur
He who dares not offend cannot be honest.
- Thomas Paine
--
Sandy McArthur
He who dares not offend cannot be honest.
- Thomas Paine
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. snip/ +1, and thanks. Fixed some obsolete/broken links on the site, as I was doing a quick site review . -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Connection.close() implementation issues [was: Jumping in...]
On 3/8/06, Phil Steitz [EMAIL PROTECTED] wrote:
On 3/8/06, Sandy McArthur [EMAIL PROTECTED] wrote:
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote:
There is a growing backlog of bugs open against [dbcp]. Unless other
committers object, I am going to jump in and start committing patches
and develop a maintenance release plan. I plan to start with
http://issues.apache.org/bugzilla/show_bug.cgi?id=33591
http://issues.apache.org/bugzilla/show_bug.cgi?id=38073
I would appreciate any feedback that community members have on
prioritization of open tickets. Also, as always, tickets with patches
and test cases are likely to get addressed quicker and comments /
testing / feedback are always welcome.
Any help from other commons committers, even if just in the form of
screams, will be most appreciated.
I've looked into some, as you can tell from my retracted bugzilla
comment and I think I've found a large source of the problems.
The method Connection.close() interface states: Calling the method
close on a Connection object that is already closed is a no-op.
Unless I am misunderstanding the use case in the ticket, it seems to
me that resolvoing it should lead us to qualify the above statement,
not make it true. We should search the archives for discussion on
this, as I recall there was a discussion of the no op issue. IIUC,
the problem in the ticket has to do with the corner case when the
already closed state is entered without the knowledge of the pool.
I would be interested in reading the no op issue for Dbcp. Right
now I've only ever looked at Dbcp source code within the last 24 hours
so I cannot claim to be an expert on it.
My position on the already closed state is that since
PoolableConnection delegates to another Connection instance which in
this case may close unexpectedly it's reasonable for
PoolableConnection to delegate it's closed state to it's delegate
Connection.
One other thing to keep in mind is that we should be aiming for a
dot-level release (need to get a plan in place), so we are going to
be constrained by backward compatibility and we have to be careful
about changing behaviors that users may be counting on. Therefore, we
should, wherever possible, apply the principle of least change when
fixing bugs. Of course, that does not mean that we ignore significant
issues or break contracts. Could be we what you are describing below
is appropriate and necessary.
I'm fine with a band-aid dot-level release. I'm not yet ready to fully
tackle the Dbcp codebase. Since it seems a significant chunk of Dbcp
functionality is based on Pool functionality I want to mature that
some more first. After that I'll dive into Dbcp, try to load the code
into my head and how it's used and see what needs sorting out.
What code I have seen looks a bit like a patch work implemented by
different people with different ideas on how things should behave. I
only listed the close() methods that don't allow a closed Connection
to be closed again but there are others that looked like they were
no-ops on the 2nd call.
Can you explain why the simple fixes in the ticket are not sufficient
to close the issue?
The patch from Huw Lewis is basically one of the suggestions I made.
It has one problem of it will try to return the same object (this) to
the ObjectPool twice which breaks the ObjectPool contracts for the
expected life cycle of a borrowed object. That's why I suggested the
if (!hasBeenReturnedToPool) logic.
I think the close() methods in general should be more robust and less
Exception prone. Since it's rather common for a Connection to delegate
to another Connection class, like PoolableConnection.close() does, I
don't think it's right to just cover up the mess at PC.close() and
ignore deeper issues. But that can wait until a more significant
release, IMO.
Thanks for looking into this.
Phil
This is violated in a number of places:
* PoolableConnection.java:77: throws an exception when close is called
and it's already closed. It should be replaced with a line similar to:
try {
if (!hasBeenReturnedToPool) {
hasBeenReturnedToPool = true;
_pool.invalidateObject(this);
}
} catch (Exception e) {
// ignored
}
* ConnectionImpl.java:115: calls assertOpen() which throws an
SQLException when it isn't open. This line should be removed.
* PoolingDataSource.java:179: the call to checkOpen() is like the call
to assertOpen() mentioned above and should be removed.
* PoolingDriver:258: another call to checkOpen(), same solution as before.
* TesterConnection.java:67: another call to checkOpen(), same solution
as before.
Someone should also audit:
* DelegatingConnection.java:184: make sure the call to passivate() is
fine being called more than once.
--
Sandy McArthur
He who dares not offend cannot be honest.
- Thomas Paine
Re: [dbcp] Jumping in...
Hi Phil, On Wednesday 08 March 2006 13:32, Phil Steitz wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 Here here! I'm not a committer, but I would really like to see some of this backlog cleared. Especially with regards to 33591, which has had a fix available for a while and which is quite a nasty one. I would appreciate any feedback that community members have on prioritization of open tickets. Also, as always, tickets with patches and test cases are likely to get addressed quicker and comments / testing / feedback are always welcome. Any help from other commons committers, even if just in the form of screams, will be most appreciated. There haven't been any code changes in over twelve months. It would be nice to fix the outstanding issues and then push out a bugfix release. Phil Thanks, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
On 3/7/06, James Ring [EMAIL PROTECTED] wrote: Hi Phil, On Wednesday 08 March 2006 13:32, Phil Steitz wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 Here here! I'm not a committer, but I would really like to see some of this backlog cleared. Especially with regards to 33591, which has had a fix available for a while and which is quite a nasty one. Thanks in advance for your help. On 33591 specifically, any comments that you have on which of the solutions in the ticket is cleanest / safest would be appreciated. I am testing your patch now, but am also evaluating Dirk's. A test case showing the leak (i.e. fails with current code) would also be great. Phil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
Hi Phil, On Wednesday 08 March 2006 14:07, Phil Steitz wrote: Thanks in advance for your help. On 33591 specifically, any comments that you have on which of the solutions in the ticket is cleanest / safest would be appreciated. I am testing your patch now, but am also evaluating Dirk's. A test case showing the leak (i.e. fails with current code) would also be great. Ok, if nobody else submits one before tonight (12 hours or so), I'll try and come up with a test case. I wish my day job would pay me to work on Commons. ;-) Phil Thanks for your time. Regards, James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
I'm not familar with the dbcp codebase yet but near the release of Pool 2.0 it is my intention to get familar with it and make sure it works well with the semantic changes. Maybe also switch dbcp to the composite pool impl if that is acceptable to everyone. In the mean go for it. On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. I plan to start with http://issues.apache.org/bugzilla/show_bug.cgi?id=33591 http://issues.apache.org/bugzilla/show_bug.cgi?id=38073 I would appreciate any feedback that community members have on prioritization of open tickets. Also, as always, tickets with patches and test cases are likely to get addressed quicker and comments / testing / feedback are always welcome. Any help from other commons committers, even if just in the form of screams, will be most appreciated. Phil -- Sandy McArthur He who dares not offend cannot be honest. - Thomas Paine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! Craig
Re: [dbcp] Jumping in...
On 3/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! +1. Let me know how I can help. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dbcp] Jumping in...
Thanks! I added the new commons std issue tracking page here: http://jakarta.apache.org/commons/dbcp/issue-tracking.html One of the links on that page will generate an open bug list. There are also instructions for entering new ones (though we are certainly not lacking in open tickets ;-) Anyone wanting to contribute who needs help getting set up with ant/maven, svn, generating patches, etc., don't hesitate to ask. We don't usually use the voting feature in Bugzilla, but I am willing to try anything once. In any case, weighing in somehow on priorities will help us decide which ones to go after first. Phil On 3/7/06, Henri Yandell [EMAIL PROTECTED] wrote: On 3/7/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 3/7/06, Phil Steitz [EMAIL PROTECTED] wrote: There is a growing backlog of bugs open against [dbcp]. Unless other committers object, I am going to jump in and start committing patches and develop a maintenance release plan. +1 (and thanks) for Phil stepping up to the plate! +1. Let me know how I can help. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
