Re: [PR] Bump org.slf4j:slf4j-simple from 2.0.9 to 2.0.12 [commons-dbcp]
garydgregory merged PR #349: URL: https://github.com/apache/commons-dbcp/pull/349 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (DBCP-596) PoolingConnection.toString() causes StackOverflowError
[
https://issues.apache.org/jira/browse/DBCP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817012#comment-17817012
]
Gary D. Gregory edited comment on DBCP-596 at 2/13/24 8:41 PM:
---
[~aapo.haapanen]
Thank you for your report.
A fix is in git master and 2.11.1-SNAPSHOT builds in
[https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2]
Please report if you encounter SO's in other classes with this build.
I'd like to cut a release candidate to push this out if I hear all is well.
was (Author: garydgregory):
A fix is in git master and 2.11.1-SNAPSHOT builds in
[https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2]
> PoolingConnection.toString() causes StackOverflowError
> --
>
> Key: DBCP-596
> URL: https://issues.apache.org/jira/browse/DBCP-596
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Aapo Haapanen
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.11.1
>
>
> {{{}PoolingConnection{}}}, as it is constructed by
> {{PoolableConnectionFactory.makeObject()}} method, causes StackOverflowError
> in its {{toString()}} method.
> {{PoolingConnection}} acts as the object factory for the statement pool,
> while {{GenericKeyedObjectPool}} implements the statement pool.
> {{PoolingConnection.toString()}} calls the pool's {{toString()}} method,
> while {{GenericKeyedObjectPool.toStringAppendFields()}} calls the factory's
> {{{}toString(){}}}.
> Here is small test application that causes StackOverflowError:
> {code:java}
> import org.apache.commons.dbcp2.DelegatingPreparedStatement;
> import org.apache.commons.dbcp2.PoolingConnection;
> import org.apache.commons.pool2.impl.GenericKeyedObjectPool;
> import org.apache.commons.pool2.impl.GenericKeyedObjectPoolConfig;
> public class Main {
> public static void main(String[] args) {
> final var conn = new PoolingConnection(null);
> final var config = new
> GenericKeyedObjectPoolConfig();
> final var stmtPool = new GenericKeyedObjectPool<>(conn, config);
> conn.setStatementPool(stmtPool);
> conn.toString();
> }
> } {code}
> In normal use cases this doesn't cause a problem, but we've encountered this
> bug in some situations with network connectivity problems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (DBCP-595) Connection pool can be exhausted when connections are killed on the DB side
[
https://issues.apache.org/jira/browse/DBCP-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817059#comment-17817059
]
Dénes Bodó commented on DBCP-595:
-
Thank you Phil for your inputs.
I'll go back testing your suggestions and will provide answers for your
questions in one-two days.
> Connection pool can be exhausted when connections are killed on the DB side
> ---
>
> Key: DBCP-595
> URL: https://issues.apache.org/jira/browse/DBCP-595
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Dénes Bodó
>Priority: Critical
> Labels: deadlock, robustness
>
> Apache Oozie 5.2.1 uses OpenJPA 2.4.2 and commons-dbcp 1.4 and commons-pool
> 1.5.4. These are ancient versions, I know.
> h1. Description
> The issue is that when due to some network issues or "maintenance work" on
> the DB side (especially PostgreSQL) which causes the DB connection to be
> closed, it results exhausted Pool on the client side. Many threads are
> waiting at this point:
> {noformat}
> "pool-2-thread-4" #20 prio=5 os_prio=31 tid=0x7faf7903b800 nid=0x8603
> waiting on condition [0x00030f3e7000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00066aca8e70> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> org.apache.commons.pool2.impl.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:1324)
> {noformat}
> According to my observation this is because the JDBC driver does not get
> closed on the client side, nor the abstract DBCP connection
> _org.apache.commons.dbcp2.PoolableConnection_ .
> h1. Repro
> (Un)Fortunately I can reproduce the issue using the latest and greatest
> commons-dbcp 2.11.0 and commons-pool 2.12.0 along with OpenJPA 3.2.2.
> I've just created a Java application to reproduce the issue:
> [https://github.com/dionusos/pool_exhausted_repro] . See README.md for
> detailed repro steps.
> h1. Kind of solution?
> To be honest I am not really familiar with DBCP but with this change I
> managed to make my application more robust:
> {code:java}
> diff --git a/src/main/java/org/apache/commons/dbcp2/PoolableConnection.java
> b/src/main/java/org/apache/commons/dbcp2/PoolableConnection.java
> index 440cb756..678550bf 100644
> --- a/src/main/java/org/apache/commons/dbcp2/PoolableConnection.java
> +++ b/src/main/java/org/apache/commons/dbcp2/PoolableConnection.java
> @@ -214,6 +214,10 @@ public class PoolableConnection extends
> DelegatingConnection impleme
> @Override
> protected void handleException(final SQLException e) throws SQLException
> {
> fatalSqlExceptionThrown |= isFatalException(e);
> + if (fatalSqlExceptionThrown && getDelegate() != null) {
> + getDelegate().close();
> + this.close();
> + }
> super.handleException(e);
> }{code}
> What do you think about this approach?
> Is it a completely dead-end or we can start working on it in this direction?
> Do you agree that the reported and reproduced issue is a real one and nut
> just some kind of misconfiguration?
>
> I am lost at this point and I need to move forward so I am asking for
> guidance here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Bump org.apache.commons:commons-parent from 64 to 66 [commons-dbcp]
garydgregory closed pull request #343: Bump org.apache.commons:commons-parent from 64 to 66 URL: https://github.com/apache/commons-dbcp/pull/343 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Bump org.apache.commons:commons-parent from 64 to 66 [commons-dbcp]
garydgregory commented on PR #343: URL: https://github.com/apache/commons-dbcp/pull/343#issuecomment-1941696528 Closing: Bumped to 66 in git master. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] DBCP-595: Connection pool can be exhausted when connections are killed on the DB side [commons-dbcp]
garydgregory commented on PR #348: URL: https://github.com/apache/commons-dbcp/pull/348#issuecomment-1941694878 The discussion thread is here: https://lists.apache.org/thread/n4y348prj0nkf1owqohzhtr65j0ps2lo -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (DBCP-596) PoolingConnection.toString() causes StackOverflowError
[
https://issues.apache.org/jira/browse/DBCP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved DBCP-596.
--
Fix Version/s: 2.11.1
Resolution: Fixed
A fix is in git master and 2.11.1-SNAPSHOT builds in
[https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-dbcp2]
> PoolingConnection.toString() causes StackOverflowError
> --
>
> Key: DBCP-596
> URL: https://issues.apache.org/jira/browse/DBCP-596
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Aapo Haapanen
>Assignee: Gary D. Gregory
>Priority: Major
> Fix For: 2.11.1
>
>
> {{{}PoolingConnection{}}}, as it is constructed by
> {{PoolableConnectionFactory.makeObject()}} method, causes StackOverflowError
> in its {{toString()}} method.
> {{PoolingConnection}} acts as the object factory for the statement pool,
> while {{GenericKeyedObjectPool}} implements the statement pool.
> {{PoolingConnection.toString()}} calls the pool's {{toString()}} method,
> while {{GenericKeyedObjectPool.toStringAppendFields()}} calls the factory's
> {{{}toString(){}}}.
> Here is small test application that causes StackOverflowError:
> {code:java}
> import org.apache.commons.dbcp2.DelegatingPreparedStatement;
> import org.apache.commons.dbcp2.PoolingConnection;
> import org.apache.commons.pool2.impl.GenericKeyedObjectPool;
> import org.apache.commons.pool2.impl.GenericKeyedObjectPoolConfig;
> public class Main {
> public static void main(String[] args) {
> final var conn = new PoolingConnection(null);
> final var config = new
> GenericKeyedObjectPoolConfig();
> final var stmtPool = new GenericKeyedObjectPool<>(conn, config);
> conn.setStatementPool(stmtPool);
> conn.toString();
> }
> } {code}
> In normal use cases this doesn't cause a problem, but we've encountered this
> bug in some situations with network connectivity problems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (DBCP-596) PoolingConnection.toString() causes StackOverflowError
[
https://issues.apache.org/jira/browse/DBCP-596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated DBCP-596:
-
Assignee: Gary D. Gregory
> PoolingConnection.toString() causes StackOverflowError
> --
>
> Key: DBCP-596
> URL: https://issues.apache.org/jira/browse/DBCP-596
> Project: Commons DBCP
> Issue Type: Bug
>Affects Versions: 2.11.0
>Reporter: Aapo Haapanen
>Assignee: Gary D. Gregory
>Priority: Major
>
> {{{}PoolingConnection{}}}, as it is constructed by
> {{PoolableConnectionFactory.makeObject()}} method, causes StackOverflowError
> in its {{toString()}} method.
> {{PoolingConnection}} acts as the object factory for the statement pool,
> while {{GenericKeyedObjectPool}} implements the statement pool.
> {{PoolingConnection.toString()}} calls the pool's {{toString()}} method,
> while {{GenericKeyedObjectPool.toStringAppendFields()}} calls the factory's
> {{{}toString(){}}}.
> Here is small test application that causes StackOverflowError:
> {code:java}
> import org.apache.commons.dbcp2.DelegatingPreparedStatement;
> import org.apache.commons.dbcp2.PoolingConnection;
> import org.apache.commons.pool2.impl.GenericKeyedObjectPool;
> import org.apache.commons.pool2.impl.GenericKeyedObjectPoolConfig;
> public class Main {
> public static void main(String[] args) {
> final var conn = new PoolingConnection(null);
> final var config = new
> GenericKeyedObjectPoolConfig();
> final var stmtPool = new GenericKeyedObjectPool<>(conn, config);
> conn.setStatementPool(stmtPool);
> conn.toString();
> }
> } {code}
> In normal use cases this doesn't cause a problem, but we've encountered this
> bug in some situations with network connectivity problems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (DBCP-596) PoolingConnection.toString() causes StackOverflowError
Aapo Haapanen created DBCP-596:
--
Summary: PoolingConnection.toString() causes StackOverflowError
Key: DBCP-596
URL: https://issues.apache.org/jira/browse/DBCP-596
Project: Commons DBCP
Issue Type: Bug
Affects Versions: 2.11.0
Reporter: Aapo Haapanen
{{{}PoolingConnection{}}}, as it is constructed by
{{PoolableConnectionFactory.makeObject()}} method, causes StackOverflowError in
its {{toString()}} method.
{{PoolingConnection}} acts as the object factory for the statement pool, while
{{GenericKeyedObjectPool}} implements the statement pool.
{{PoolingConnection.toString()}} calls the pool's {{toString()}} method, while
{{GenericKeyedObjectPool.toStringAppendFields()}} calls the factory's
{{{}toString(){}}}.
Here is small test application that causes StackOverflowError:
{code:java}
import org.apache.commons.dbcp2.DelegatingPreparedStatement;
import org.apache.commons.dbcp2.PoolingConnection;
import org.apache.commons.pool2.impl.GenericKeyedObjectPool;
import org.apache.commons.pool2.impl.GenericKeyedObjectPoolConfig;
public class Main {
public static void main(String[] args) {
final var conn = new PoolingConnection(null);
final var config = new
GenericKeyedObjectPoolConfig();
final var stmtPool = new GenericKeyedObjectPool<>(conn, config);
conn.setStatementPool(stmtPool);
conn.toString();
}
} {code}
In normal use cases this doesn't cause a problem, but we've encountered this
bug in some situations with network connectivity problems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[PR] Don't fail if retry succeeds; log instead [commons-net]
sebbASF opened a new pull request, #218: URL: https://github.com/apache/commons-net/pull/218 At present, the deleteFile method always throws the original error, even if the retry succeeds. This seems wrong -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Wrong location for EOL [commons-net]
sebbASF commented on PR #217: URL: https://github.com/apache/commons-net/pull/217#issuecomment-1941106487 > The `CRLF` being added in the other line is still needed though. Agreed, but that should be a separate PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Wrong location for EOL [commons-net]
thc202 commented on PR #217: URL: https://github.com/apache/commons-net/pull/217#issuecomment-1941084689 The `CRLF` being added in the other line is still needed though. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Wrong location for EOL [commons-net]
sebbASF commented on PR #217: URL: https://github.com/apache/commons-net/pull/217#issuecomment-1941074836 Good point. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Wrong location for EOL [commons-net]
sebbASF closed pull request #217: Wrong location for EOL URL: https://github.com/apache/commons-net/pull/217 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] Wrong location for EOL [commons-net]
thc202 commented on code in PR #217: URL: https://github.com/apache/commons-net/pull/217#discussion_r1487544841 ## src/main/java/org/apache/commons/net/ftp/FTPHTTPClient.java: ## @@ -194,8 +194,8 @@ private BufferedReader tunnelHandshake(final String host, final int port, final final String auth = proxyUserName + ":" + proxyPassword; final String header = "Proxy-Authorization: Basic " + Base64.getEncoder().encodeToString(auth.getBytes(charset)); output.write(header.getBytes(charset)); +output.write(CRLF); } -output.write(CRLF); Review Comment: This one should be kept, https://datatracker.ietf.org/doc/html/rfc7230#autoid-15 > an empty line indicating the end of the header section -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
