Also, you can change the load balancing process by defining some statistics,unavailablePenalty and stickyConnectionsFor/statistics section defines categories of files for which Dispatcher scores the responsiveness of each render. Dispatcher uses the scores to determine which render to send a request...

You can find all the schedulers at [1][1] http://<host>:<port>/system/console/status-slingscheduler

Can you go to <host>:<port>/crx/de and check if the personalization node at [1] is there?Also, check if you have an overlayed "/libs/cq/core/content/nav" under /apps. Try to remove the overlay[1] /libs/cq/core/content/nav/personalization

In your custom code, you can use the version manager[1] API to check if the node is checked in and write the logic based on that condition and wait till the node is no longer checked-in[1] VersionManager (Content Repository for Java Technology API Version 2.0)

As far as I know, there is no limit for email/users in AEM. AEM uses Day CQ Mail Server to send emails. So, whatever load the email server(defined at Day CQ Mail Service) can handle, that will be the limit.

You can look into building the CURL command for that process using the article at [1][1] Using cURL with AEM

Try using the settings file at [1][1] https://docs.adobe.com/content/help/en/experience-manager-learn/getting-started-wknd-tutorial-develop/assets/chapter-1/s…

After installing the latest version of the bundle, Go to [1] and check if the bundle is still mapped to the older jar file.If yes, there might be something wrong with the OSGI installer. You can follow the steps below:- Stop the AEM instance- Go to <AEM_Installation_Directory>crx-quickstart director...

checking the error.log will provide more details on the failure.

First Create a SAML logger and check if you get any error thereCreate a logger with the following configuration:Log Level: DebugLog File: logs/saml.logLogger: com.adobe.granite.auth.samlAlso, change dispatcher log file to DEBUG and check if POST call to saml_login is blocked