This problem is specific to pureScale instances and JCC clients.
The DB2 server keeps on returning the same server list which
have both the good and bad servers even after one of the member
is powered off suddenly by some unexpecting incidents(can be
simulated by running "halt -q"). As a result, the client will
keep on testing the bad server within each transaction in turn
results in a latency. Here is a sample trace from a JCC client:
[jcc]findBestSysplexMember
[time:2014-06-16-21:09:46.896][Thread:Thread-14][tracepoint:200]
findBextSysplexMember, test and select -
[Lcom.ibm.db2.jcc.t4.rb;@4ea74ea7
[jcc][t4]
[time:2014-06-16-21:09:46.896][Thread:Thread-14][tracepoint:111]
Connection isClosed: false. getApplicableTimeout (false)
returning: 5000
[jcc]findBestSysplexMember
[time:2014-06-16-21:09:46.896][Thread:Thread-14][tracepoint:211]
Testing member - {SWLBN@4eb14eb1: MEMB1/192.168.1.40 50000 0
NaN false 10 4 0 43 0 true member: 0 timeToDeadLine: 5000
[jcc][t4]
[time:2014-06-16-21:09:51.896][Thread:Thread-14][tracepoint:111]
Connection isClosed: false. getApplicableTimeout (false)
returning: 5000
[jcc]findBestSysplexMember
[time:2014-06-16-21:09:51.896][Thread:Thread-14][tracepoint:211]
Testing member - {SWLBN@4ebf4ebf: MEMB2/192.168.1.41 50000 0
NaN false 10 4 1 2 0 true member: 1 timeToDeadLine: 5000
The length of the latency depends on the JCC property
memberConnectTimeout / loginTimeout.
This problem can happen in following scenario:
1. Setup a Java application with following parameters:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++
Class.forName("com.ibm.db2.jcc.DB2Driver");
properties.setProperty("user", userName);
properties.setProperty("password", password);
properties.setProperty("enableSeamlessFailover", "true");
properties.setProperty("enableSysplexWLB", "yes");
properties.setProperty("loginTimeout", "5");
Connection conn = (DB2Connection)
DriverManager.getConnection(
URL, properties);
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++
2. The java application firstly connects to member 0
3. Prepare statements
4. Calls executeQuery() to execute the statements => all works
fine
5. Run "halt -q" on member 0
6. The java application calls executeQuery() to execute an
statement
7. Java applicaton gets java.net.SocketTimeoutException: Read
timed out ==> delays for loginTimeout seconds
8. Java applicaton calls executeQuery() to execute an statement
again
8.1 JCC tests member 0 ==> failed, results in latency of
loginTimeout seconds
8.2 JCC tests member 1 ==> succeeds
9. call executeQuery() to execute an statement again, delays
for loginTimeout seconds because of testing member 0.
10. All subsequent executeQuery() delays for loginTimeout
seconds because of testing member 0. |
