Exception in TF_DropLeaseSolved

One customer is reporting errors, the configuration is as follows:Server: 4.0.9.7 (on Windows Server 2003)Client: 4.0.9.7 (on Windows 7)

Internal debug logging in our app shows TF_RequestLease() returned TF_OKImmediately after that we call TF_DropLease() and get the below exception:

Exception Details:

Verifide.Licensing.NoLeaseException: There's no lease. Your must first have a lease before you can drop it or get information on it.

This is strange because we got a lease ok (TF_OK) just before dropping it (this is in a license setup form that sets up the license server and then releases the lease)

Could this be a timing issue?

We are not able to reproduce the issue on our local systems running Win7 and Win10 and have tried with both 32bit and 64bit float servers.

FYI, we are using TF_BOTH_DLL and it is a combined dll for license key and license float licensing.

Another thing we noticed in the logs that may be helpful:

LicenseLeaseCallback() is getting a TF_CB_EXPIRED status after acquiring the lease.

Hmmm.. it sounds like his server and client clocks are significantly skewed. He should adjust both to match and real internet source (ntp ). Then restart both the client and server.

Also, this isnt a bug in TurboFloat. A license lease can be dropped in that separate thread. Your app shouldnt attempt to drop a lease that has already been dropped (or else youll get an Exception that tells you as much). You can of course catch the exception (theres not much point of letting it go uncaught)

Thanks,The customer reported that the clock was skewed by 7 minutes.What is the tolerance for skew?Some of these are ad-hoc systems so are not connected to an NTP server.

We have modified our code to use the HasLease() to check before dropping the lease, but still would like to know the tolerance so we can advise customers and update our documentation.

A 7 minute skew is significant. More than a normal, well functioning, computer would drift over several years.

>> "Some of these are ad-hoc systems so are not connected to an NTP server."

Presumably they're updating the systems (if not, they're opening themselves up to a world of hurt). They should host a local NTP server on the same server that delivers these closed-off systems updates.

>> "What is the tolerance for skew?"

It depends on the situation. But less than 7 minutes. You'd be safest within a minute of "real" time. So, when they install and update their machines update the time with a good "source of truth".

If the clock is off 7 minutes, we get an expired event and can handle that.

When the clock on the server is off by approximately minute, the entire app crashes on the call to TF_HasLease(). Cannot trap that in a .NET exception.

Is there another way to test the lease without it crashing in this case?

TF_HasLease() should never crash. Do you have more details? A crash report, a way to reproduce, etc.

So it doesn't seem particularly related to HasLease(). It just happened that our last log message was in that method. The crash seems to not be synchronous and is happening asynchronously.

Here's what I found:

Delta computed as (Time on Server - Time on Client)-ve time means server clock is behind client

Delta = -1 minutes, lease acquiredDelta = -3 minutes, CRASH (process killed, no exceptions caught anywhere)Delta = -4 minutes, CRASHDelta = -6 minutes, WrongTimeException caught and handledDelta = -10 minutes, WrongTimeException caught and handledDelta = +1 minute, lease acquiredDelta = +3 minutes, lease acquiredDelta = +6 minutes, WrongTimeException caught and handledDelta = +10 minutes, WrongTimeException caught and handled

In the CRASH cases:

- TF_RequestLease() returns 0 when app starts. - LicenseLeaseCallback() is being called with status TF_CB_EXPIRED, and _operation.PostOperationCompleted(RaiseLicenseLeaseCallback, e); is being called. - LicenseLeaseCallback() is called again with status TF_CB_EXPIRED - The application then crashes (process killed, cannot trap exception in Visual Studio with all exceptions enabled)

It seems like it is designed to tolerate 5 minutes of skew, but the .NET sample or asynch mechanisms are not handling it when the server is behind the client by 1-5 minutes.

Please advise on any steps to take with the .NET Float API to handle this.

Any update on this?

We have not been able to reproduce this yet.

We've been able to reproduce this and fix it. It will be out with TF 4.1. (Out soon -- no hard date).

This is fixed in the latest version of the TF (4.1.3). Get it here: https://wyday.com/limelm/api/#turbofloat