Skip to content

fix(config): allow concurrent access to pyrevit_config.ini#2516

Merged
jmcouffin merged 2 commits intopyrevitlabs:developfrom
sanzoghenzo:fix-concurrent-config-access
Jan 13, 2025
Merged

fix(config): allow concurrent access to pyrevit_config.ini#2516
jmcouffin merged 2 commits intopyrevitlabs:developfrom
sanzoghenzo:fix-concurrent-config-access

Conversation

@sanzoghenzo
Copy link
Copy Markdown
Contributor

fixes #2463 #2512

It seems to work on my machine, I ran 3 instances of revit 2023 one after another, and then 2 instances of revit 2025.

@jmcouffin jmcouffin merged commit 1dd083f into pyrevitlabs:develop Jan 13, 2025
@jmcouffin
Copy link
Copy Markdown
Contributor

I will try it with the installers tomorrow morning
Thanks @sanzoghenzo Keep them coming 🤖

@jmcouffin jmcouffin added the Runtime Issues related to loading pyRevit runtime [subsystem] label Jan 13, 2025
@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25013+1857-wip

@sanzoghenzo sanzoghenzo deleted the fix-concurrent-config-access branch January 13, 2025 19:37
@jmcouffin
Copy link
Copy Markdown
Contributor

I launched 3x2024 within seconds, no issues
3x2023, 1 out of 3 greeted me with
image
This is a great improvement

@jmcouffin
Copy link
Copy Markdown
Contributor

@jmcouffin
Copy link
Copy Markdown
Contributor

Me and my friend ChatG got this working using an ugly retry mechanism:

        using System.IO;
        
        //...


        // save config file to standard location
        public void SaveConfigFile()
        {
            if (_adminMode)
            {
                logger.Debug("Config is in admin mode. Skipping save");
                return;
            }

            logger.Debug("Saving config file \"{0}\"", PyRevitConsts.ConfigFilePath);

            int retryCount = 5;            // Number of retry attempts
            int delayMilliseconds = 100;   // Delay between retries

            while (retryCount > 0)
            {
                try
                {
                    _config.Save(PyRevitConsts.ConfigFilePath);
                    return; // Exit method if successful
                }
                catch (IOException ex) // Catch only IO exceptions related to file locking
                {
                    retryCount--;
                    if (retryCount == 0)
                    {
                        throw new PyRevitException(string.Format("Failed to save config to \"{0}\" after multiple attempts. | {1}",
                                                                 PyRevitConsts.ConfigFilePath, ex.Message));
                    }

                    logger.Debug("Retrying to save config file \"{0}\"... Remaining retries: {1}", 
                                 PyRevitConsts.ConfigFilePath, retryCount);

                    System.Threading.Thread.Sleep(delayMilliseconds); // Wait before retrying
                }
                catch (Exception ex)
                {
                    throw new PyRevitException(string.Format("Failed to save config to \"{0}\". | {1}",
                                                             PyRevitConsts.ConfigFilePath, ex.Message));
                }
            }
        }

Thoughts @sanzoghenzo, except that it is a crappy way of doing it ;p

@sanzoghenzo
Copy link
Copy Markdown
Contributor Author

Why does the "get current attachments" need to save the file? This clones and attachments thing starts to driving me mad 🤯

From a quick look at it, I believe this is the culprit:

SaveRegisteredClones(validatedClones);

We need to write back only if the list of attachments have changed.

But in any case yes, we need to add some checks in the save method to handle this kind of concurrency.
But anyway, who's the crazy person that starts multiple revit instances at the same time?? 🤣

@jmcouffin
Copy link
Copy Markdown
Contributor

But anyway, who's the crazy person that starts multiple revit instances at the same time?? 🤣

Trust me, plenty of BIM Managers do when they review files in Revit!

From a quick look at it, I believe this is the culprit:

SaveRegisteredClones(validatedClones);

We need to write back only if the list of attachments have changed.

Want to do it @sanzoghenzo ?

@sanzoghenzo
Copy link
Copy Markdown
Contributor Author

I'll try it, not sure if I can do this today;

For the retry solution you proposed, this mitigates the problem but doesn't solve the root issue: what to do when multiple instances try to write on the same file? It's the whole git/cloud storage problem again and again...
Let's see if we can reduce the problem as much as possible.

@jmcouffin
Copy link
Copy Markdown
Contributor

but doesn't solve the root issue:

Agree 💯

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25015+1341-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25015+1357-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25024+1520-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25024+1957-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25025+1310-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25030+1056-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25030+1130-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25030+1138-wip

@github-actions
Copy link
Copy Markdown
Contributor

📦 New work-in-progress (wip) builds are available for 5.0.0.25031+1700-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 1, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25032+1615-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 1, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25032+1635-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 1, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25032+1841-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 2, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25033+1337-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 2, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25033+1402-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 3, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25034+1241-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 3, 2025

📦 New work-in-progress (wip) builds are available for 5.0.0.25034+1511-wip

@github-actions
Copy link
Copy Markdown
Contributor

github-actions bot commented Feb 3, 2025

📦 New public release are available for 5.0.0.24174+2300

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Runtime Issues related to loading pyRevit runtime [subsystem]

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Bug]: manage access to pyrevit-config.ini at startup

2 participants