Brief service outage recently?

I am trying to track down what caused a recent issue with the TurboActivate.isGenuine() call. Yesterday (July 10), a computer that had a valid license on it suddenly failed the isGenuine() test, returning IsGenuineResult.InternetError (Java). This happened consistently and across multiple versions of our software. This morning (July 11), the same machine is working fine.

We are checking isGenuine() with the following parameters:

TurboActivate.isGenuine(60, 14, true, false)

I'm having trouble tracking down the meaning of the last two parameters, but I take this to mean that it checks once every 60 days and retries for up to 14 days before it fails out. Given that it did eventually fail out, I'd like to understand why. I expect there are two possibilities:

1) The remote server was unable to complete the request for 14 days, or2) The local machine was not sending the request properly.

I've investigated (2) and found that the machine was online; I could log in to our LimeLM account from it so it was connected to the Internet and able to reach a server potentially in proximity to the license server; and I temporarily disabled the firewall (McAfee) to see if that was eating the requests. None of this seemed to indicate that the local machine was the issue. This morning, when it started working again, I didn't take any special steps like disabling the firewall again. This suggests that the problem was external to the computer in question.

So -- was there a service interruption that might have caused this? Did this really last more than 14 days? I'd just like to know whether to keep tracking this down on my end or if the problem was really out of our hands.

The way our software reacted to having isGenuine() fail was not the most, shall we say, graceful -- so we are going to make things a little more forgiving and informative for our users. I just want to know if there's anything else I should know about before revisiting this part of the license enforcement, such as whether we're just using isGenuine() wrong.

We haven't had any downtime in the last week. It might have been a routing problem near to the customer (meaning either the customer was down, or a local node to the customer was down preventing them from accessing some parts of the internet).

returning IsGenuineResult.InternetError (Java).

Our example code and our tutorials tell you to treat this as a warning that you tell the user about. Never treat it as an error.

I'm having trouble tracking down the meaning of the last two parameters, but I take this to mean that it checks once every 60 days and retries for up to 14 days before it fails out.

Yes, that's correct.

Given that it did eventually fail out, I'd like to understand why. I expect there are two possibilities:

1) The remote server was unable to complete the request for 14 days, or2) The local machine was not sending the request properly.

No, neither. Everything was working correctly. TurboActivate told you that it couldn't contact the servers (InternetError), and you're supposed to treat that as a warning.

So, the solution to this problem is to treat InternetError as a warning that the user is still activated but sometime in the future you software will stop working if it can't eventually contact the servers. Look at our example Java source code for help.

I think what may have happened is that the laptop in question was used without being connected to the network a couple of times about two weeks apart. This would have started the first IsGenuine test without connectivity, and then tried it again after the 14 day grace period had expired, causing an immediate failure. Our warning for that failure suggests that the network connection is needed; this probably prompted the user to plug it in and re-run the software. However, since we only use the four-argument version of IsGenuine(), there was a five hour delay before it would really try to contact the servers again (we were not providing an option to immediately retry as suggested in the tutorials). When I tried it again today, the five hours had elapsed, the test went all the way to the server, and it all worked.

This is the only way I can explain all that I've seen.

You are correct that we need to handle the error differently and we're in the process of doing that. Thank you for confirming that there was no downtime on your end.

Reply
Discard post