on 2013 Jul 05 6:52 AM
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?
Request clarification before answering.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
as set with the server's -xm switch
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:)
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 🙂
User | Count |
---|---|
52 | |
8 | |
5 | |
5 | |
5 | |
5 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.