Common product issues

You require administrator rights to deploy a package. If you encounter errors, consult with the Adobe Experience Manager log file. Some reasons why an error occurs during package deployment is if there are dependencies that are not on Adobe Experience Manager. Another reason is you may attempt to install an older version of an installed package. 

Be sure to read the following Adobe Experience Manager topic: How to Work With Packages.

To learn how to build a package that contains OSGi bundles, see Packaging Adobe CQ applications that contain an OSGi bundle. 

If the Adobe Experience Manager server is not starting, the first step is to check the server log. Check the error.log, stderr.log, stdout.log (all log files are located in the "CQX.X/crx-quickstart/logs" folder). One issue could be that the system is low on memory.

Other reasons are as follows:

• Invalid JVM parameters (then you don’t see anything in the error.log)
• System not reachable by the browser (port is still claimed by a running instance or by a hanging JVM which wasn’t shut down properly)
• The classic one: authentication support missing“ in browser, which a non-starting repository (error.log) causes.
  

Check this article for more troubleshooting information Troubleshooting CQ WCM.

Before installing Adobe Experience Manager, ensure that you meet the technical requirements. See Technical Requirements.

If you can't access the felix console and encounter the error "org.apache.sling.servlets.resolver.internal.SlingServletResolver Original error null," take these steps:

1. cd /crx-quickstart/launchpad/felix
2. grep -H "org.apache.felix.webconsole" . -R
3. Look for org.apache.felix.webconsole-.jar
4. Go to that bundle "cd."
5. Check bundle.location file it should contain slinginstall:org.apache.felix.webconsole-.jar
6. Open bundle.state file and change state to "active" from "installed."
7. Restart your system.

If Adobe Experience Package Manager does not load (for example, if you encounter a 404 error while attempting to open it), the first step is to check the log. Ensure that the required JCR nodes are correct. If these nodes are not present, you see an error in the log file. For example:

log: 27.06.2014 13:16:53.845 *ERROR* [127.0.0.1 [1402543013788] GET /crx/packmgr/list.jsp?_dc=1402543013769&_charset_=utf-8&includeVersions=true HTTP/1.1] com.day.crx.packmgr.impl.servlets.ListServlet Error while retrieving infos: javax.jcr.RepositoryException: Invalid path:/etc/packages/my_packages/.snapshot/My Packagename

See this community article for more information: AEM Gotchya: No packages in Package Manager.

Check what URL you see when you hover over the packages link on Welcome screen. Does it show http://localhost:4502/crx/packmgr/ or http://localhost:4502/crx/packmgr.html? If it shows .html on the link, you could have a rule configured under etc/map that could be causing this behavior.

Finally, check the permissions in "/libs/cq/core/content/welcome/features/packages." Ensure that it has all the required permission levels for the Adobe Experience user to access Package Manager. A non-admin account needs the required permissions to install a package. 

A custom component that an Adobe Experience Manager developer created can consist of front-end JavaScript logic and back-end Java logic, typically packaged within an OSGi bundle. When developing a custom component, it is best practice to debug the component to ensure that it functions as expected. To debug the component, set a breakpoint and step through the application logic. 

How you debug it depends on how you build it. See the following links:

Debug a CQ5/AEM6 app using eclipse

Adobe Experience CQ 6 - Debugging AEM JSPs with IntelliJ IDEA 12

This section discusses AEM scalability issues. 

Use http://localhost:4502/system/console/profiler for at least a few minutes during the period of slowness or high CPU usage. The output helps you determine which JVM threads are consuming most CPU cycles, and their associated packages and classes.

There are a couple of steps that can be followed:

• check CPU usage
• check session count
• do not kill processes

For more information, see Analyze slow and blocked processes.

The following factors influence performance problems in AEM:

• Improper design
• Application code
• Bad disk I/O configuration
• Network bandwidth and latency
• AEM installed on some select windows 2008 and 2012 version where memory management is an issue

For more information, see Performance tuning tips | 6.x.
 

There are several ways to take thread dumps from a JVM. It is highly recommended to take more than 1 thread dump. A good practice is to take 10 thread dumps at a regular interval (eg. 1 thread dump every 10 seconds).

For more information, see How to take Thread Dumps from a JVM.

Such problems can have many causes.

One possible cause is that the java application, in our case, CRX / CQ was started from the command line with the default heap memory settings of Java. This means that the jvm parameter -Xmx was not specified. CRX or CQ need at least 256 MB of heap allocated to run. If this is the problem, then starting from the command line,ensure that the heap memory settings are set.

For more information, see Analyze Memory Problems. 

Using prof.jsp
A simple CPU profiling tool is included in CRX 2.x. To start it (CRX 2.0 - 2.2), open:

http://localhost:7402/crx/diagnostic/prof.jsp
As of CRX 2.3 / CQ 5.5 the tool is located here:

http://localhost:4502/crx/explorer/diagnostic/prof.jsp

and

http://localhost:4502/system/console/profiler

For more information, see Performance analysis using built in profiler.

If your use case requires you to upload a ZIP file, AEM supports this. That is, you can upload ZIP files to the AEM DAM using the AEM assets user interface. Once you upload the ZIP file, you can view it, as shown in the following illustration. 

If you encounter an error, ensure that you are uploading the ZIP using the AEM Assets user interface at: http://localhost:4502/damadmin#/content/dam.

Another option that you have is to write a component that lets you upload files to the AEM DAM. See https://helpx.adobe.com/experience-manager/using/uploading-files-aem1.html. 

If you are encounter issues installing AEM hotfix, then refer to the following AEM KB article: Adobe Experience Manager 6.0 hot fixes. If you are still encountering issues, please open a support ticket here: https://helpx.adobe.com/marketing-cloud/experience-manager.html.

After you install an AEM package and if there is no content under /content, this means that the package was not built properly. Typically when you build a package, you select the JCR nodes under /content that is part of the package. Consult the team that built the package. For information about how to build an AEM package, see Packaging Adobe Experience Manager 6 applications. 

This section talks about the following administrative issues in AEM.

The following points can be reasons for not being able to login:

1. Check if the instance is Out of Sync.
2. If out of sync then please follow the out of sync troubleshooting.
3. Make sure the username and password are correct.
4. Make sure the LDAP server is responding and working fine.
5. Check logs for any entries.

Try installing the OSGI package http://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.jcr.jackrabbit.accessmanager/2.1.0 in the CQ instance and sse if it helps.

Updating a bundle does not necessarily cause the new classes to be used immediately, it depends on two factors:

1. If the classes are from a private package or an exported package.
   If the classes are from an exported package, whether or not they are being used by another bundle.
   Regarding (1), if the classes come from a private package (i.e., it is not exported), then the new classes will become available immediately. However, if they are from an exported package, then their visibility depends on whether any other bundles are using the exported packages.
2. If no other bundles are using the exported packages, then the new classes will become available immediately since the old version of the classes are no longer needed. On the other hand, if any other bundles are using the exported packages, then the new classes will not become available immediately since the old version is still required by any dependent bundles. In this case, the new classes will not be made available until PackageAdmin.refreshPackages() is called (this can be invoked in the Felix shell using the refresh command).

There is one partial exception to this latter case, it occurs when the exporting bundle does not also import its own exported packages (see "Should a bundle import its own exported packages?" below for more information on this commonic). In this case, the new classes become immediately accessible to the updated exporting bundle, but not to the dependent bundles; the dependent bundles continue to see the old version of the classes. This situation generally requires PackageAdmin.refreshPackages() to be invoked to bring the bundles back to a useful state.

This is the normal update process as defined by the OSGi specification. Updating a bundle is a two-step process, where older versions of exported packages are kept around until explicitly refreshed. This is done to reduce disruption when performing several updates.