in the context of the sib.msgstore.jdbcFailoverOnDBConnectionLoss custom property. This defaults to true in recent versions of WAS, meaning: -
The high availability manager stops the messaging engine and its hosting application server when the next core group service Is alive check takes place (the default value is 120 seconds). If a node agent is monitoring the server, and you have enabled automatic restart in the monitoring policy for the server, the server restarts. The messaging engine starts when an appropriate server is available.
whereas I've set it to false meaning: -
The messaging engine continues to run and accept work, and periodically attempts to regain the connection to the data store. If work continues to be submitted to the messaging engine while the data store is unavailable, the results can be unpredictable, and the messaging engine can be in an inconsistent state when the data store connection is restored.
plus this: -
in the context of this: -
/etc/sysctl.conf
...
# Added to support WAS > DB2 keepalives etc.
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_retries2 = 2
...
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_intvl = 10
net.ipv4.tcp_keepalive_probes = 3
net.ipv4.tcp_retries2 = 2
...
Plus these: -
in the context of the JDBC client parameter db2.jcc.outputDirectory which controls the location/creation of a cache file - jccServerListCache.bin - which is used by JDBC client applications ( in my case, Cognos Business Intelligence ) to know where to go when the primary ( and configured ) DB2 server goes down.
I'll be blogging more about the latter shortly ....
No comments:
Post a Comment