[
https://issues.apache.org/jira/browse/TRAFODION-2551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15947390#comment-15947390
]
ASF GitHub Bot commented on TRAFODION-2551:
-------------------------------------------
Github user kevinxu021 commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/1024#discussion_r108715726
--- Diff:
core/conn/jdbcT4/src/main/java/org/trafodion/jdbc/t4/TrafT4PooledConnectionManager.java
---
@@ -137,12 +137,18 @@ public Connection getConnection() throws SQLException
{
}
} else {
pc = (PooledConnection) free_.get(0);
- if (removeFreeConnection(pc, true)) {
- TrafT4Connection c = (TrafT4Connection)
pc.getConnection();
- try {
-
c.ic_.enforceT4ConnectionTimeout(c);
+ TrafT4Connection c = (TrafT4Connection)
pc.getConnection();
+ try {
+ c.ic_.enforceT4ConnectionTimeout(c);
+ if (removeFreeConnection(pc, true)) {
validConnection = true;
- } catch (SQLException sqlEx) {
+ }
+ } catch (Exception e) {
+ //ignore errors
+ } finally {
+ if (!validConnection) {
+ if (free_.remove(0) != null)
--- End diff --
@selvaganesang Thanks for you comments. i don't quit understand. It gets
0th entry first, then remove it in removeFreeConnection( here it still in 0th).
If it cannot be removed, that means the connection is not in free_ which is not
reasonable( unless memory issue or something else, rarely happens but doesn't
matter to remove again and throw exception, then the program exit). It should
be fine to remove 0th here.
In standard doc for free_.remove: true if this list contained the specified
element. it might not be represent PRESENT.
> exception is thrown, when using traT4DataSource in jdbcT4
> ---------------------------------------------------------
>
> Key: TRAFODION-2551
> URL: https://issues.apache.org/jira/browse/TRAFODION-2551
> Project: Apache Trafodion
> Issue Type: Bug
> Components: client-jdbc-t4
> Environment: clien evn: windows
> jdbc4
> centos version: 7.2
> Reporter: luoyunpeng
> Assignee: kai-hua.xu
>
> when i was running the following test code with jdbcT4 driver
> ####
> @Test
> public void testDataSource() throws SQLException, InterruptedException {
> dataSource = new TrafT4DataSource();
> int MaxPoolSize = 4;
> dataSource.setUrl(url);
> dataSource.setUser(usr);
> dataSource.setPassword(pwd);
> dataSource.setMaxPoolSize(MaxPoolSize);
> dataSource.setMinPoolSize(1);
> dataSource.setInitialPoolSize(1);
> System.out.println("start TrafT4DataSource test, the url is : "
> + url);
> for (int i = 0; i < MaxPoolSize + 3; i++) {
> System.out.println(i + " times");
> getConnection();
> connNew.close();
> connNew = null;
> Thread.currentThread().sleep(1000 * 60 * 20);
> }
> }
> private void getConnection() throws SQLException {
> connNew = dataSource.getConnection();
> }
> ####
> when about 4800 seconds, there is a exceptoin message as follows:
> ####
> org.trafodion.jdbc.t4.TrafT4Exception: The message id: max_pool_size_reached
> at
> org.trafodion.jdbc.t4.TrafT4Messages.createSQLException(TrafT4Messages.java:304)
> at
> org.trafodion.jdbc.t4.TrafT4PooledConnectionManager.getConnection(TrafT4PooledConnectionManager.java:136)
> at
> org.trafodion.jdbc.t4.TrafT4DataSource.getConnection(TrafT4DataSource.java:135)
> at
> org.jdbctest.DataSource.DataSourceTest.getConnection(DataSourceTest.java:37)
> at
> org.jdbctest.DataSource.DataSourceTest.testDataSource(DataSourceTest.java:29)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
