Search Issue Tracker

Fixed

Fixed in 6000.0.77f1, 6000.3.17f1, 6000.4.10f1, 6000.5.0b11, 6000.6.0a6

Votes

0

Found in

6000.0.63f1

6000.0.64f1

6000.3.12f1

6000.4.7f1

6000.5.0b8

6000.6.0a6

Issue ID

UUM-142572

Regression

No

Floating License is lost for concurrent jobs

License

-

 

Note: I have not reproduced this, but the diagnosis of the customer logs is unambiguous, and the fix is also pretty clear.

Steps to reproduce:

  1. machine configured for use with floating license server
  2. two concurrent (batchmode) jobs, where one job ends gracefully, and then
  3. we kill the Licensing Client instance (we actually don't know why this is happening on-site)
  4. 2nd (un-finished) job tries to heal the connection (and re-launch the Client), but the license is lost and the job fails

 
{noformat}
[Licensing::Module] Error: The connection with the Unity Licensing Client has been lost. Attempting to reconnect.{noformat}
The Editor doesn't try to update the license (and reclaim the lease), and instead we see that it immediately requests an entitlement (once the connection is healed).

 
We re-establish the connection along 2 different codepaths in the Editor:

  • we check periodically (every 5 seconds) that the connection (and Client process) exist. Once the connection is re-established, if we are in floating license configuration, we update the license (attempt to re-assert the lease)
  • if an entitlement is requested, we 1st check and re-establish the connection (as above), but we don't try to refresh/update the license

In this case, it appears we were checking for {{com.unity.editor.platforms.ios}} and {{{}com.unity.editor.platforms.android{}}}), and so we don't call {{{}UpdateLicense{}}}.

Actual results: 

The license is lost and the Editor shows this line in its logs:
{noformat}
[Licensing::Module] Error: 'com.unity.editor.headless' was not found."
{noformat}
Expected results: 

2nd job ends gracefully and license is intact until the end of the job

Reproducible with versions:

most versions of Unity should see this (it isn't a regression)

I think we're only seeing this consistently for this customer, due to a specific circumstance where the Licensing Client is occasionally being killed, and the "configuration" causes an entitlement request to be triggered before the 5-second tick lands (which would refresh AND update).

Not reproducible with versions: None?

Can’t test with versions: 

Tested on (OS): Customer is running on MacOS 26.3.1

Notes:

  1. Resolution Note (fix version 6000.5.0b11):

    Fixed in 6000.5.0b11

  2. Resolution Note (fix version 6000.4.10f1):

    Fixed in 6000.4.10f1

  3. Resolution Note (fix version 6000.3.17f1):

    Fixed in 6000.3.17f1

  4. Resolution Note (fix version 6000.0.77f1):

    Fixed in 6000.0.77f1

Add comment

Log in to post comment