suche 36x36
Latest versionsfixlist
11.1.0.7 FixList
10.5.0.9 FixList
10.1.0.6 FixList
9.8.0.5 FixList
9.7.0.11 FixList
9.5.0.10 FixList
9.1.0.12 FixList
Have problems? - contact us.
Register for free anmeldung-x26
Contact form kontakt-x26

DB2 - Problem description

Problem IT26077 Status: Closed

ACR FAILOVER HANGS WHEN SERVER AFFINITY LIST IS LONG

product:
DB2 FOR LUW / DB2FORLUW / A50 - DB2
Problem description:
1.  Problem description
Essentially the customer has a situation where they want to test
ACR using db2dsdriver.cfg, but where every member in their
environment is down. They are expecting the client application
to get an error message within a couple of minutes indicating
that the connection is down. Instead the client connection
hangs.

Using the below db2dsdriver.cfg, we were able to reproduce the
problem once. Subsequent attempts did not succeed.

Essentially hotelaix14 in this case is the primary member. A
database called ORDERDB is created there and started listening
on port 47558. Then a connection to "ORDBET" is performed using
the CLP (the CLP supports the db2dsdriver.cfg so you don't have
to use a CLI application).

Once the instance is on the primary member, the client
connection hangs. You can use an arbitrary list of members for
the affinity list. Just make sure they are not actually running.
You can use invalid ports if you like. Please also ensure you
change the  under  as
that needs to match your client's hostname. If you don't do that
you can get another error.

Also if you are using CLP to test this, please ensure you use
"db2 terminate" every time you update the db2dsdriver.cfg. This
is to ensure the CLP gets a fresh copy. You can set the
environment variable DB2DSDRIVER_CFG_PATH if you want a new
location for the db2dsdriver.cfg other than sqllib/cfg.

Anyway, what we seem to be doing is isolating through each
member in the affinity list one by one by one. The customer has
120 members configured. And a short delay between members.
Things essentially look like the connection is hung. The client
is expecting that we return an error and not just loop through
all the affinity members.

In DB2 v10.1.0.4 this is what happened. An exception was
returned. In 10.5 we don't return one, until I assume every
member in the affinity list is exhausted.

It seems some logic in 10.5 was added so that we keep looping
through the affinity list instead of just stopping.

2.  Operating system and level:
osName="SunOS" osVersion="11.3" osRelease="5.11"

3.  Client, server, and gateway information
	a. Client information, if applicable
		"DB2 v10.5.0.8", "special_36362", "IP23990_36362"

	b. Server information, if applicable
		"DB2 v10.5.0.8", "special_37137", "IP23993_37137"

4.  db2dsdriver.cfg to reproduce
Problem Summary:
****************************************************************
* USERS AFFECTED:                                              *
* All operating systems potentially affected                   *
****************************************************************
* PROBLEM DESCRIPTION:                                         *
* See Error Description                                        *
****************************************************************
* RECOMMENDATION:                                              *
* Apply the fix                                                *
****************************************************************
Local Fix:
Solution
Workaround
not known / see Local fix
Timestamps
Date  - problem reported    :
Date  - problem closed      :
Date  - last modified       :
24.08.2018
13.03.2020
13.03.2020
Problem solved at the following versions (IBM BugInfos)
Problem solved according to the fixlist(s) of the following version(s)