Problemi comuni del prodotto

Per implementare un pacchetto sono necessari i diritti di amministratore. In caso di errori, consulta il file di log di Adobe Experience Manager. Alcune ragioni per cui si verifica un errore durante l'implementazione del pacchetto sono le dipendenze che non sono su Adobe Experience Manager. Un'altra ragione è il tentativo di installare una versione precedente di un pacchetto installato. 

Assicurati di leggere il seguente argomento di Adobe Experience Manager: Come lavorare con i pacchetti.

Per scoprire come generare un pacchetto che contiene i bundle OSGi, vedi Generare pacchetti di applicazioni Adobe CQ che contengono un bundle OSGi.

Perché il server si riavvia dando un errore

Se il server Adobe Experience Manager non si avvia, il primo passo è quello di controllare il log del server. Controllare error.log, stderr.log, stdout.log (tutti i file di log si trovano nella cartella "CQX.X/crx-quickstart/logs"). Un problema potrebbe essere la poca memoria del sistema.

Altre ragioni sono le seguenti:

• Parametri JVM non validi (in questo caso non vedrai nulla nel file error.log)
• Sistema non raggiungibile dal browser (la porta è ancora occupata da un'istanza in esecuzione o da una JVM sospesa che non è stata chiusa correttamente)
• Il classico: supporto di autenticazione mancante nel browser, causata da un archivio che non si avvia (error.log).
  

Controlla questo articolo per ulteriori informazioni sulla risoluzione dei problemi CQ WCM.

Prima di installare Adobe Experience Manager, assicurati di soddisfare i requisiti tecnici. Vedi Requisiti tecnici.

La console Felix non si carica

Se non è possibile accedere alla console Felix e incontri l'errore "org.apache.sling.servlets.resolver.internal.SlingServletResolver Original error null," , procedi come segue:

1. cd /crx-quickstart/launchpad/felix
2. grep -H "org.apache.felix.webconsole" . -R
3. Cerca org.apache.felix.webconsole-.jar
4. Vai a quel bundle "cd".
5. Controlla il file bundle.location che dovrebbe contenere slinginstall:org.apache.felix.webconsole-.jar
6. Apri il file bundle.state e cambia lo stato in "attivo" da "installato".
7. Riavvia il sistema.

La gestione pacchetti non si carica

Se Adobe Experience Package Manager non si carica (ad esempio, se vedi un errore 404 mentre tenti di aprirlo), il primo passaggio è quello di controllare il log. Assicurati che i nodi JCR richiesti siano corretti. Se questi nodi non sono presenti, viene visualizzato un errore nel file di log. Ad esempio:

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

Vedi questo articolo della community per maggiori informazioni: AEM Gotchya: nessun pacchetto nella Gestione pacchetti.

Controlla quale URL vedi quando passi il mouse sul link dei pacchetti nella schermata di benvenuto. Mostra http://localhost:4502/crx/packmgr/ o http://localhost:4502/crx/packmgr.html? Se mostra .html sul link, si potrebbe avere una regola configurata sotto etc/map che potrebbe causare questo comportamento.

Infine, controlla i permessi in "/libs/cq/core/content/welcome/features/packages." Assicurati che abbia tutti i livelli di autorizzazione necessari affinché l'utente di Adobe Experience possa accedere a Gestione pacchetti. Un account non amministratore ha bisogno dei permessi necessari per installare un pacchetto.

Si prevede che un componente personalizzato non funzioni

Un componente personalizzato creato da uno sviluppatore di Adobe Experience Manager può essere costituito da una logica JavaScript front-end e una logica Java back-end, tipicamente confezionati all'interno di un bundle OSGi. Quando si sviluppa un componente personalizzato, è buona pratica eseguire il debug del componente per assicurarsi che funzioni come previsto. Per eseguire il debug del componente, imposta un punto di rottura e passa attraverso la logica dell'applicazione. 

L'esecuzione del debug dipende da come lo si genera. Vedi i seguenti link:

Esegui il debug di un'applicazione CQ5/AEM6 utilizzando Eclipse

Adobe Experience CQ 6 - Debug dei JSP AEM con IntelliJ IDEA 12

Problemi di scalabilità di AEM

Questa sezione tratta i problemi di scalabilità di AEM. 

Perché le istanze non rispondono alle richieste e sono bloccate?

Utilizza http://localhost:4502/system/console/profiler per almeno alcuni minuti durante il periodo di utilizzo lento o di uso elevato della CPU. L'output aiuta a determinare quali thread JVM stanno consumando la maggior parte dei cicli CPU e i pacchetti e le classi associate.

Questi sono alcuni passaggi che puoi seguire:

• controlla l'utilizzo della CPU
• controlla il conteggio delle sessioni
• non interrompere i processi

Per ulteriori informazioni, vedi Analizza processi lenti e bloccati.

Perché l'istanza dell'autore ha un'esecuzione estremamente lenta?

I seguenti fattori influenzano i problemi di prestazioni in AEM:

• Progettazione inappropriata
• Codice applicazione
• Configurazione I/O del disco scorretta
• Larghezza di banda e latenza di rete
• AEM installato su alcune versioni selezionate di Windows 2008 e 2012 in cui la gestione della memoria è un problema

Per ulteriori informazioni, vedi Suggerimenti per la regolazione delle prestazioni | 6.x.

Come controllare la lentezza dei dump dei thread per verificare la lentezza delle prestazioni?

Ci sono diversi modi per prendere i dump di thread da una JVM. Si raccomanda vivamente di effettuare più di 1 dump di thread. Una buona pratica è quella di prendere 10 dump di thread ad intervalli regolari (ad es. 1 dump di thread ogni 10 secondi).

Per ulteriori informazioni, vedi Come prendere i dump di thread da una JVM.

Perché l'istanza sta esaurendo lo spazio di heap?

Tali problemi possono avere molte cause.

Una possibile causa è che l’applicazione java, nel nostro caso, CRX / CQ è stata avviata dalla riga di comando con le impostazioni di memoria heap predefinite di Java. Questo significa che il parametro jvm -Xmx non è stato specificato. CRX o CQ hanno bisogno di almeno 256 MB di heap assegnati per l'esecuzione. Se questo è il problema, partendo dalla riga di comando, assicurati che le impostazioni della memoria heap siano impostate.

Per ulteriori informazioni, vedi Analisi dei problemi della memoria.

Come far funzionare il profiler CRX ed è necessario farlo funzionare durante la lentezza?

Utilizza prof.jsp
Un semplice strumento di profiling della CPU è incluso in CRX 2.x. Per avviarlo (CRX 2.0 - 2.2), apri:

http://localhost:7402/crx/diagnostic/prof.jsp
Per CRX 2.3 / CQ 5.5 lo strumento si trova qui:

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

e

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

Per ulteriori informazioni, vedi l'analisi delle prestazioni utilizzando il profiler integrato.

Perché ricevo l'errore: file non valido durante il caricamento di file zip

Se il tuo caso d'uso richiede di caricare un file ZIP, AEM lo supporta. Cioè, è possibile caricare file ZIP nella DAM AEM utilizzando l'interfaccia utente di AEM Assets. Una volta caricato il file ZIP, è possibile visualizzarlo, come mostrato nella figura seguente. 

Se si verifica un errore, assicurati di caricare lo ZIP utilizzando l'interfaccia utente di AEM Assets all'indirizzo: http://localhost:4502/damadmin#/content/dam.

Un'altra opzione è quella di scrivere un componente che consente di caricare i file nella DAM AEM. Vedi https://helpx.adobe.com/experience-manager/using/uploading-files-aem1.html. 

Perché il pacchetto hotfix non riesce/dà errore al momento dell'installazione? (Hotfix non riesce)

Se incontri problemi di installazione per le hotfix di AEM, consulta il seguente articolo KB di AEM: hotfix di Adobe Experience Manager 6.0. Nel caso di ulteriori problemi, invia una richiesta di supporto qui: https://helpx.adobe.com/marketing-cloud/experience-manager.html

Perché non c'è un nodo di contenuto dopo aver installato il pacchetto?

Se dopo l'installazione di un pacchetto AEM non c'è contenuto in /contenuto, significa che il pacchetto non è stato generato correttamente. Di solito quando si genera un pacchetto, si selezionano i nodi JCR nel /contenuto che fa parte del pacchetto. Consulta il team che ha generato il pacchetto. Per informazioni su come generare un pacchetto AEM, vedi Applicazioni per generare pacchetti di Adobe Experience Manager 6.

Problemi amministrativi in AEM

Questa sezione tratta i seguenti problemi amministrativi in AEM.

Perché non sono in grado di accedere/autenticare l'autore master o slave in un ambiente cluster?

Quelle che seguono possono essere le cause di un accesso non riuscito:

1. Controlla se l'istanza è fuori sincronia.
2. Se è fuori sincronia, segui la risoluzione dei problemi di fuori sincronia.
3. Assicurati che il nome utente e la password siano corretti.
4. Assicurati che il server LDAP risponda e funzioni correttamente.
5. Controlla le eventuali voci nei log.

Perché c'è un errore chiamato "Tentativo di risoluzione del percorso di contenuto non riuscito"?

Prova ad installare il pacchetto OSGI http://mvnrepository.com/artifact/org.apache.sling/org.apache.sling.jcr.jackrabbit.accessmanager/2.1.0 nell'istanza CQ e vedi se può essere utile.

Perché lo stato del bundle non è di aggiornamento/cambiamento nella console Felix?

L'aggiornamento di un bundle non comporta necessariamente l'immediato utilizzo delle nuove classi, ma dipende da due fattori:

1. Se le classi provengono da un pacchetto privato o da un pacchetto esportato.
   Se le classi provengono da un pacchetto esportato, indipendentemente dal fatto che siano o meno utilizzate da un altro bundle.
   Per quanto riguarda (1), se le classi provengono da un pacchetto privato (cioè non esportato), le nuove classi saranno immediatamente disponibili. Tuttavia, se provengono da un pacchetto esportato, la loro visibilità dipende dal fatto che altri pacchetti utilizzino o meno i pacchetti esportati.
2. Se nessun altro bundle utilizza i pacchetti esportati, le nuove classi saranno immediatamente disponibili, poiché la vecchia versione delle classi non è più necessaria. D'altra parte, se altri bundle utilizzano i pacchetti esportati, le nuove classi non saranno immediatamente disponibili, poiché la vecchia versione è ancora necessaria per i bundle dipendenti. In questo caso, le nuove classi non saranno rese disponibili finché non si chiama PackageAdmin.refreshPackages() (questo può essere invocato nella shell Felix usando il comando aggiorna).

C'è un'eccezione parziale a quest'ultimo caso, che si verifica quando il pacchetto esportatore non importa anche i propri pacchetti esportati (vedi "Un pacchetto dovrebbe importare i propri pacchetti esportati?" sottostante per maggiori informazioni). In questo caso, le nuove classi diventano immediatamente accessibili al bundle di esportazione aggiornato, ma non ai bundle dipendenti; i bundle dipendenti continuano a vedere la vecchia versione delle classi. Questa situazione richiede generalmente che PackageAdmin.refreshPackages() sia invocato per riportare i bundle in uno stato utile.

Questo è il normale processo di aggiornamento come definito dalla specifica OSGi. L'aggiornamento di un bundle è un processo in due fasi, dove le vecchie versioni dei pacchetti esportati sono conservate fino a quando non vengono esplicitamente aggiornate. Questo viene fatto per ridurre le interruzioni durante l'esecuzione di diversi aggiornamenti.