When the TurboFloat server is offline, we expected TF_RequestLease to time out, since one of its documented return codes is TA_E_INET_TIMEOUT, and this earlier forum post suggests that it now has a timeout.
https://wyday.com/forum/t/2512/function-call-to-tf_requestlease-did-not-return/
However, what we see in practice is that when the server is offline (turned off entirely), TF_RequestLease never returns. Here's an strace of about 10 minutes of waiting:
[pid 6196] 0.000074 open("/dev/shm/sem.tfs-mtx-1305-4123", O_RDWR|O_NOFOLLOW) = 9 <0.000020>[pid 6196] 0.000070 fstat(9, {st_mode=S_IFREG|0644, st_size=32, ...}) = 0 <0.000014>[pid 6196] 0.000067 mmap(NULL, 32, PROT_READ|PROT_WRITE, MAP_SHARED, 9, 0) = 0x7f94eeac0000 <0.000017>[pid 6196] 0.000064 close(9) = 0 <0.000024>[pid 6196] 0.000074 futex(0x7f94eeac0000, FUTEX_WAIT, 0, NULL <unfinished ...>[pid 6197] 300.097651 <... epoll_wait resumed> {}, 128, 300000) = 0 <300.100234>[pid 6197] 0.000064 epoll_wait(8, <unfinished ...>[pid 6196] 16.325994 <... futex resumed> ) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) <316.423657>[pid 6196] 0.000054 --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} ---[pid 6196] 0.000046 futex(0x7f94eeac0000, FUTEX_WAIT, 0, NULL <unfinished ...>[pid 6197] 283.774210 <... epoll_wait resumed> {}, 128, 300000) = 0 <300.100251>[pid 6197] 0.000063 epoll_wait(8,
TF_RequestLease works just fine when the license server is online.
We're on TurboFloat v4.0.9.7.
We havent been able to reproduce this.
Are you using the latest version of the TurboFloat Library? Older versions just waited around (for certain special special network setups) if the TFS instance wasnt running. The latest version of the TF Library correctly timeouts.
Our client version is 4.0.9.6 (I believe the server is the very latest, 4.0.9.7). Is there a change in 4.0.9.7 which addresses this?
(ping)
We're on the very latest versions of both the Linux TF client (4.0.9.6) and server (4.0.9.7) and can reproduce this consistently when the license server is offline.
If it helps, we've seen this so far using VirtualBox machines for both the client and server (which of course are using the VirtualBox networking).
Is there anything we can provide that would be helpful in diagnosing the problem?
Can you describe the setup so we can try to reproduce the environment here? Are both the client run on the same VM? Can you tell us the OSs being used? Also, tell us local IP addresses being used (I know we won't be able to use the same IPs in our tests, but it will give us a better sense of your setup)?
