nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

manage maximum number of sessions per user

nadja

in this ArcGIS Pro Question https://community.esri.com/t5/arcgis-pro-questions/arcgis-pro-exceeded-maximum-number-of-sessions/td-p/236300 a maximal number of three sessions is allowed and that it cannot be overriden.

I'd like to suggest exactly that: please add an option to bump the number of maximal sessions up. If esri doesn't want to give the possibility for more than three sessions per license, you could add a clause, that it can be bumped up, but there needs to be one unused organization-license per another 3 sessions. If no more organisation-license are available, the number of active sessions cannot be increased even when the maximal number of sessions is bumped up to 10 (as an example).

best,

Trouver plus de publications taguées avec

Licensing

Closed

Status: Closed

Réponses

Valeria Chavez

Hi @MarcoBoeringa, thank you for your feedback. You are correct in that ArcGIS Pro is able of running processes/threads in parallel. I wasn't sure if "workflows" was the right word to encapsulate the-whole-universe-of-possible-GIS-activities but we'll go with that! I edited my response above for clarity's sake.

Thanks again.

MarcoBoeringa

Using a single user type to actively run ArcGIS Pro in parallel on multiple machines (e.g., virtual desktop running a ModelBuilder job while the same user edits data on a laptop) is not permitted.
If you and your organization require running processes in parallel, I encourage you to get in touch with your account team to explore alternative ways to license ArcGIS such as ArcGIS Enterprise/ArcGIS Server and/or ArcGIS Pro Single Use.

@ValeriaChavez Just a minor refinement to your response, but I think with:

"If you and your organization require running processes in parallel"

you meant to say:

"If you and your organization require running workflows in parallel"

Any modern software designed for high throughput computations is / should be capable of running threads or processes in parallel. ArcGIS Pro does that too, with geoprocessing tools like Pairwise Buffer/Dissolve and quite a few others spreading out computation over many CPU cores to significantly enhance performance. This is an integral part of modern software and ArcGIS Pro.

Valeria Chavez

Hi @nadja!

I will be closing this thread as what you're describing here is a violation of the licensing agreement.

ArcGIS Pro allows users to sign-in across multiple machines to reduce friction when switching devices or forgetting to sign out after each session. For example, if someone is still signed in on their work laptop and needs to sign in elsewhere, that convenience is within the intent of the policy.

Using a single user type to actively run ArcGIS Pro in parallel on multiple machines (e.g., virtual desktop running a ModelBuilder job while the same user edits data on a laptop) is not permitted.

If you and your organization require running workflows in parallel, I encourage you to get in touch with your account team to explore alternative ways to license ArcGIS such as ArcGIS Enterprise/ArcGIS Server and/or ArcGIS Pro Single Use.

Thank you for being an active member of Esri Community!

SimonSchütte_ct

For organisations with an ArcGIS Enterprise license, publishing the GP tool to the Server and running processes there could be an option.

nadja

@PeterKnoop thank you for your workaround idea. we had the same idea, but it's still not really userfriendly as one needs to keep in mind all the usernames, passwords and where one uses which user, etc.

We'd really appreciate it if esri would provide a "clean" and userfriendly solution.

PeterKnoop

Our current workaround is to provide a person with multiple Named User identities. This comes with its own challenges, however, as users need to keep close track of which identity they are using to login where.

nadja

@MarcoBoeringa thanks for your reply, that might be interesting for some other use cases. behind my posted idea are multiple projects (mapping, processing, etc.) on different computers or virtual environments which are integrated in our organisation's infrastructure. thus the multiprocessing workflow unfortunately won't help in our setting. thank you nevertheless 🙂

MarcoBoeringa

Not a direct answer to your question, but referring to the link you posted where the user talks about a "very large processing task" that requires him to have more than 3 sessions open, if you have similar questions, you may consider using Python's multi-threading and multi-processing options in combination with chunking up the dataset (e.g. by record ranges selections) to overcome limitations.

I have successfully used Python's 'concurrent.futures.ThreadPoolExecutor' and 'concurrent.futures.ProcessPoolExecutor' as part of ArcPy scripting in ArcGIS Pro and called from toolboxes to process a more than > 2B(!, yes, I am using 64bit ObjectIDs...) record table updating all of its records in chunks with > 40 threads / processes performing concurrent work.

Note that if you would like to call geoprocessing tools in a concurrent environment, the 'concurrent.futures.ProcessPoolExecutor' may be the better choice, as it isolates the environment and may overcome issues with geoprocessing tools not being thread safe, and additionally is more suited to CPU bound work where you truly need extra processing power.

By the way, to overcome the issue with ProcessPoolExecutor opening up new Pro sessions or other windows, use the 'pythonw.exe' executable instead of 'python.exe' from within a script. This will launch any additional python sessions silently in the background without any extra annoying Pro sessions or windows being opened, just like multi-processing happens with e.g. the ArcGIS "Pairwise" tools (e.g. Pairwise Dissolve/Buffer etc.)

The latter issue is specific to the ProcessPoolExecutor, using the ThreadPoolExecutor won't ever open extra windows, but ThreadPoolExecutor is less suited for heavy CPU based tasks, as it won't actually be able to efficiently use multiple cores due to the Global Interpreter Lock (unless the compute in the background is actually done by a e.g. an enterprise database like PostgreSQL, and the threads are only used to send out the SQL, in which case the ThreadPoolExecutor may result in heavy and efficient multi-core processing on the database server even with GIL limitations on the client).

import multiprocessing
import sys

multiprocessing.set_executable(os.path.join(sys.exec_prefix,'pythonw.exe'))

with concurrent.futures.ProcessPoolExecutor() as executor:

Rejoindre la conversation

Connectez-vous pour publier, suivre le contenu, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.