|
Evidence suggests that for dbsrv11.exe 11.0.1.2661 running on Windows 7 the value returned by PROPERTY ( 'TcpIpAddresses' ) is cached at server startup, since after a network change it continued to return an IP value that now no longer existed (can't be pinged, etcetera) The dbsrv11 server continued to function through the network change, and when the dbsrv11 server was subsequently restarted calls to PROPERTY ( 'TcpIpAddresses' ) began returning a new (correct) value. This is an important question because it is difficult to determine with perfect accuracy the answer to the question "Am I connected to the right server?" in a complex and ever-changing network with a whackload of engines running. Until now, the PROPERTY ( 'TcpIpAddresses' ) value was regarded as an important piece of evidence, but... apparently not. Is the behavior the same for V16? PS: Feel free to propose solutions to the "Am I connected to the right server?" problem... it is possible that one of them has NOT been tried in the past and shown to fail, and regardless, NO proposal will be mocked :) |
|
In version 11, yes. When the server starts up, it creates a list of IP addresses it is listening on. This list never changes throughout the life of the server, and this list is where we get the addresses for this property. After a networking change, the server may continue to function normally and things like TCP and HTTP will probably work fine in most cases. However it's likely that certain features (finding the server through UDP broadcasting, for example) may not work depending on the network configuration. In version 12, we changed the server to recognize network changes (i.e. changes to the list of available IP addresses) and so in v12 and later, the value of the property will change as IP addresses change. How fast the values are updated is dependent on the value of the "IP Address monitoring period" as set with the server's -xm switch. 1
According to the docs, -xm is disabled for servers running on non-portable devices, but you can still activate the monitoring on a running server without need to shut down via CALL sa_server_option('IPAddressMonitorPeriod', n); @Breck: That feature does sound like that old Watcom rule, doesn't it? Well done, guys:)
(05 Jul '13, 11:20)
Volker Barth
Replies hidden
1
oh, yes, well done! For the benefit of others, the "old rule" of which Volker speaks goes thusly: "Watcom does things the way they should be done". ...Watcom being the original name, then Powersoft, then iAnywhere Solutions, then Sybase and now SAP. The rule uses the name Watcom because it only applies to that part of the larger entities... one could never argue the truth of a saying like, for example, "Sybase does things the way they should be done"... that sounds ridiculous, doesn't it? Think page-level locking. Case closed :)
(08 Jul '13, 09:49)
Breck Carter
What a pity! I'd bet you'd love to tell about several other samples why the more general rule would sound ridiculous to you (e.g. moderated communities)...
(08 Jul '13, 10:00)
Volker Barth
|
Proposal: use MachineName instead, because the server might have multiple TCP addresses
Like TCP/IP address, machine name is an "important piece of evidence" but it is not sufficient to uniquely identify a server. Arguably, there is no perfectly reliable way to identify a server in the face of arbitrary network changes. The point of this post is not that the "TcpIpAddresses" property is perfect (it isn't) but it was completely useless, like after rain washes fingerprints away. In my particular (feeble) solution, several properties are displayed (including machine name), and a human being checks to make sure they all look OK... even the slightest discrepancy is investigated because the penalty for connecting to the wrong server goes something like this...