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; } } }

Branch version takes too long to post edits

samshrma998

We are editing a utility network data and having issues while reconciling and posting branch version.

It is posting what is too much of time and edits are also limited (max 50 edits).

The process used to smooth earlier and no changes have been to configuration or database.

Find more posts tagged with

Accepted answers

All comments

SStopyak_BruceHarris

Here are some basic things I always do to troubleshoot poor performance for services in general:

Look at the ArcGIS Server logs and see what (if anything) is being logged as Warning or Severe.
Open the performance monitor and observe the CPU and RAM utilization of the Enterprise servers and the SQL Server machine (or whichever RDBMS you run).
Look at the CPU and RAM specs for the same machines above. 9 out of 10 times if you're noticing poor service performance of any sort, one or more of these machines will be under-provisioned. For production use I provision at 8-core 32GB RAM and increase as needed. That is my bare minimum for all production machines except a DMZ web server which can be 4-core 16GB RAM usually.
On the ArcGIS Server machine, open the service in Pro while watching the performance monitor to gauge what your interaction with it is doing to the ArcGIS Server. Some of the performance hit will be Pro itself but if you're seeing a drastic impact to performance just zooming and panning around, you are likely under-provisioned.
If you aren't under-provisioned, go ahead and bump up the min max dedicated instances incrementally (within reason) until the desired performance is achieved. make sure it is dedicated, not shared, as well.
Optimize your feature services. Be frugal with layers and display scales. If it isn't absolutely needed, take it out. Minimize or remove anno especially. Turn off every layer but one by default. The one you leave on should be a basic layer with few features that can be use as a visual for locating your AOI. Something like a County boundary is good.
Make sure you aren't publishing any layers that have no features. Make sure the spatial extent for layers is calced ok. If not, recalc them. Empty layers can't calc an extent so at least add one dummy feature within your AOI and recalculate the spatial extent.
Make sure you aren't running overzealous security software on the servers

Maybe some of these general things can help too. Good luck!

ducroix_magis

In a branch versioning environment, only one user is allowed to edit in a version at a time, so there should not be issues about parallel active sessions. Additionally, Default is protected.

I can sometimes see exclusive locks on named versions, but they should be managed by the system.

The only thing I think about is having multiple users with version management administration capacity and editing Default, or posting at the same time... But disconnecting everyone in order to post versions should not be necessary.

Also, there should be separate capacities for posting and for Default editing and administrative right...

RPGIS

Do you have users actively editing and either not closing their sessions or have hanging edits? That can sometimes create locks which may be a reason. Try asking everyone to disconnect and then reconcile and post.

RPGIS

I didn't think to suspect that at all. You might be right and that could be causing the issue. If there are some attribute rules designed for feature to feature edits in conjunction with multiple users editing then that may be the cause.

ducroix_magis

Hello,

here is the log file from Pro, from the starting of the version posting to the error message :

and AGS log :

SEVERE

30 juil. 2025, 14:55:59

StopServiceEditing failure (sessionID: {AF268C58-99C5-4DAB-A4CD-0511979B0103}) (User session application lock in progress - operation not allowed) Session Application lock in progress [Session application lock in progress - operation not allowed]

--> exactly 10 minutes between Post and Error : this is why I think of a client-side timeout in this case, but running the Post in REST will succeed after 15 minutes or more.

log_Pro_Post_error.txt

Hayden Welch

Would you be able to possibly share some of the logs from Pro? You can get them from the diagnostic monitor under the help tab. That would help pinpoint if it's a network issue or if it's some crazy circular rule triggering that's happening due to asynchronous edits coming in and locking up attribute rules.

I've seen interdependent attribute rules absolutely kill performance when every edit cascades to 10 different feature classes, and that's when it's all in a local file database. Doing that over the network can seriously cripple Pro.

ducroix_magis

I'm not sure the version tree / delta table apply to branch versioning, since only Default version is the parent of all named versions. It is more like a big archiving, then there is no need to compress, but instead we can prune records with the new Prune branch History toolbox

RPGIS

So versions follow what's called a version tree, if you didn't know that already. What that breaks down to is that more versions equate to more delta tables. Delta tables are transactional states from the main parent table. You basically create a new state every time a version is created. With that being said, this can greatly increase the size of the database hence why it is recommended to compress the database nightly the more versions you have.

The other thing is if you have multiple branch versions trying to apply edits then that can cause issues with reconciling data because to many edits can be applied at any given moment.

The only other thing I can recommend is to set your rules to "Exclude from application evaluation" so they trigger server side and not in the application.

If problems persist then try going traditional over branch and see if that makes a difference or try using vector tiles.

ducroix_magis

Thank you for your answer.

I will try to give more context :

We are using a Utility Network (UN) feature service that is edited in ArcGIS Pro. --> There is no cellular network or any other network quality issue as far as I know.

Working with UN requires that the feature service used in Pro maps contains all feature classes and all attributes. They are only filtered in each subtype layer's field view. Additionally, we worked a lot on improving the drawing, scales and display of the layers in the map. I note that reducing the number of records returned by the service can help too.

The main latency issue we have, is when reconciling and posting a named version, that contains a bunch of edits, to the Default version.

--> You are talking about reducing the number of editable version, what do you mean ?

I don't know if it may be related to the reconcile/post process of ArcGIS Enterprise, the database tuning, or related to a UN thing (like having subnetworks triggering attribute rules in the named versions...).

RPGIS

If you're experiencing latency issues then you might need to try the following:

Reduce the number of records returned by the service, as @MarceloMarques has mentioned. Too many records can result in poor performance.
Set the display scale to a reduced scale. Too large of a scale can impact drawing as well as editing. You can try to publish the editing feature service to a reduced scale and publish a vector tile service at a greater scale.
Reduce the number of editable versions. Recommendation is no more than 3.
If cellular strength is a common issue, try publishing a traditional version. Branch versioning can work but is typically limited to the strength of a cellular network.
In conjunction with publishing both an editable feature service and vector tile service, publish the feature service with only required fields and filtered values. Publish the vector tile service as needed.

The methods mentioned above are the few methods that I'm familiar with regarding services in general. I can ask a few others for their take as well.

@jcarlson @ChristopherCounsell @HaydenWelch @DanPatterson

ducroix_magis

Hello,

Do you have any solutions or suggestions to share?

We're experiencing the same latency issue when posting a limited number of changes. It can take 10 to 15 minutes to post a minor network edit, which can cause a client-side (AGPro) timeout.

We've rebuilt the indexes and recalculated the statistics.

We've also ensured that the SOC count and performance are correct.

The same posting delay occurs when we try to post via the REST endpoint.

Marcelo Marques

@samshrma998 - Branch version takes too long to post edits

The branch version feature service that you are using might be too busy, so you might need to adjust the minimum and maximum number of SOC processes. Also, consider changing the service type from polling to dedicated; this way, the service will have dedicated SOC processes.

Also, you need to perform regular maintenance of the ArcSDE Enterprise Geodatabase often, you need to gather new statistics weekly and rebuild indexes monthly.

If you continue to experience performance issues, then please open a ticket with esri tech support to investigate further.

RPGIS

Hi @samshrma998

Can you possible break down the rough details and workflow, starting from the generated service to editing in the field? Things such as:

Number of layers/datasets
symbology type
imagery used
layer drawing scales
number of editors
portal (enterprise vs AGO )
service type ( hosted vs reference )
Applications used ( field maps , survey123, workforce, etc )

The more information the better so that either I or someone else can help possibly pinpoint the exact issue.

samshrma998

Thanks @RPGIS for recommendations.

1. For weak service, there is no issue or latency while editing. Though we reduced sample size with no luck.

2. Offline data collection is not part of our current workflow.

3. We tried using multiple version. Some version having just 5-6 edits which also have same latency while posting. For less than 10 edits, it takes around 7-8 mints to post edits.

RPGIS

Hi @samshrma998,

Here are some things that need to be taken into consideration when editing from the field that you may or may not have thought about.

Cell service - if there are instances of weak or no cell service then this can cause issues when editing in the field. If the service is too weak then you may need to try and reconfigure the service by testing these parameters:
1. Reducing sample size than what the default sample size is.
2. Decreasing when the layers draw when zooming out
Using offline data collection - if you are using offline data collection but the field crews are not regularly pushing updates then that could be causing problems. When there is too much data being collected in the field that isn't regularly updated then the amount of data is too large to send. You may need to reconsider what kind of versioning to use in this instance.
Too many edits being done at once - if there are too many edits happening simultaneously then that could potentially cause issues as well. If branch isn't working, then try using traditional versioning to see if that makes a difference.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.