Messages d’erreur généraux

Il existe un grand nombre de types de thread. Cependant, ils entrent le plus souvent dans deux catégories : les threads Java et les threads natifs. Toutes les threads qui fonctionnent dans une machine JVM sont des threads Java (classe java.lang.Thread dans Java). Le code natif (C++/C) crée des threads natifs gérés et synchronisés par le système d’exploitation. Principales différences entre ces deux types de threads :

• Les threads Java sont créés et gérés par du code LiveCycle, le serveur d’applications ou la JVM elle-même.

• Les outils de système d’exploitation (perfmon ou le Gestionnaire des tâches) ne « voient » que les threads natifs.

Comme le système d’exploitation n’a aucune visibilité sur les threads Java, lorsque vous les analysez à l’aide des outils du système d’exploitation tels que perfmon, seuls les threads natifs sont pris en compte. Le seul moyen d’obtenir des informations sur les threads Java consiste à effectuer un vidage des threads Java. Le moyen d’y parvenir varie en fonction de votre serveur d’applications et de la JVM. Consultez la documentation du fabricant.

De plus, la JVM étant implémentée en code C/C++, ce code mappe les threads Java à des threads natifs. Ce mappage peut être de type un pour un (1 thread Java pour 1 thread natif) ou plusieurs pour un (plusieurs threads Java pour 1 thread natif). Le fonctionnement précis de ce mappage est spécifique à la JVM utilisée, mais de manière générale, il s’agit d’une relation de type 1:1. Il y aura donc un thread natif pour chaque thread Java. Il n’y a aucune limitation sur le nombre de threads Java ; toutefois, comme de manière générale la relation est du type un pour un et qu’il existe une limitation au nombre de threads natifs, vous pouvez vous retrouver à court de threads Java. Cette limitation dépend des processus (la JVM étant un processus unique) et varie en fonction de chaque système d’exploitation. De manière générale, le nombre de threads par processus ne doit pas dépasser quelques milliers (mais être inférieur à 10 000). Dans tous les cas, avoir plusieurs centaines de threads en cours d’exécution pose des problèmes de performances car le système d’exploitation doit tous les synchroniser.

Un autre problème courant concernant les threads est la quantité de mémoire affectée. Lorsqu’un nouveau thread Java est affecté, un montant fixe de mémoire est nécessaire pour la pile du thread. Cet espace de pile de threads est une option de paramètre -Xss pour la JVM Sun™), et sa valeur par défaut est d’environ 512 Ko. Par conséquent, si vous disposez de 1 000 threads, 500 Mo de mémoire sont requis simplement pour les piles des threads. Cette mémoire sera en concurrence avec toutes les autres allocations de mémoire réalisées dans la JVM, par exemple celles qui sont allouées par LiveCycle et entraîne des problèmes d’allocation de mémoire.

En pratique, lorsque la JVM ne peut pas affecter de mémoire ni créer de threads, elle renvoie une exception OutOfMemory à l’appelant, ainsi qu’une trace de pile et une explication de l’exception. Il est très important de noter ces informations pour déterminer d’où vient le problème.

Exemple de message signalant deux erreurs et le code explicatif correspondant :

"unable to create new native thread: java.lang.OutOfMemoryError: unable to create new native thread java.lang.OutOfMemoryError: Java heap space"

Ces erreurs signifient que la JVM n’a pas pu créer de threads supplémentaires pour l’une des raisons suivantes :

• la limite du nombre de threads par processus a été atteinte ;

• la pile de threads n’a pas pu être affectée.

Pour déterminer la cause exacte, vous devez procéder à un vidage des threads (également appelé vidage Java). Les informations générées par un vidage de thread sont généralement stockées dans le fichier javacore.xxxx.txt, qui se trouve dans l’un des répertoires des journaux du serveur d’applications. De nombreuses informations se trouvent dans le vidage de thread, mais vous pouvez déterminer rapidement le nombre de threads en comptant les occurrences du jeton TID: dans la liste. Une entrée type a le format suivant :

"Thread-1227" (TID:0x106948F0, sys_thread_t:0x78996DA0, state:R, native ID:0x191C) prio=5 
4XESTACKTRACE at java.net.SocketInputStream.socketRead0(Native Method) 
4XESTACKTRACE at java.net.SocketInputStream.read(SocketInputStream.java(Compiled Code)) 
4XESTACKTRACE at java.io.BufferedInputStream.fill(BufferedInputStream.java(Compiled Code)) 
4XESTACKTRACE at java.io.BufferedInputStream.read1(BufferedInputStream.java(Compiled Code)) 
4XESTACKTRACE at java.io.BufferedInputStream.read(BufferedInputStream.java(Compiled Code)) 
4XESTACKTRACE at com.sun.jndi.ldap.Connection.run(Connection.java(Compiled Code)) 
4XESTACKTRACE at java.lang.Thread.run(Thread.java:567)

Si vous constatez qu’il y a des milliers de threads, il est très probable que la limite du nombre de threads soit atteinte. Un développeur devrait pouvoir identifier les éléments fautifs en analysant la trace de pile de ces threads.

S’il n’y a que quelques centaines de threads, l’exception java.lang.OutOfMemory n’est pas provoquée par la limitation du nombre de threads. Réduisez la taille des piles de threads (option -Xss mentionnée ci-dessus), réexécutez LiveCycle, puis voyez si le problème disparaît.

Content Services (obsolète) est doté de différentes mémoires cache permettant d’améliorer considérablement les performances, mais qui consomment une quantité très importante de mémoire du tas Java. Vous pouvez rencontrer des exceptions OutOfMemory si vous exécutez le service Document Management pour Content Services sur un matériel qui répond seulement à la configuration minimale requise.

Il est possible de contrôler l’utilisation de la mémoire en définissant les arguments JVM -Dhibernate.cache.use_second_level_cache=false et -Dhibernate.cache.use_query_cache=false.

1. Vérifiez l’arborescence JNDI sur le serveur d’applications LiveCycle. Le nom utilisé apparaît-il dans l’arborescence ?

   • Si tel est le cas, il est fort probable que votre code n’ait pas configuré correctement l’objet InitialContext actuellement utilisé pour la recherche et que la recherche est en cours sur une arborescence JNDI qui n’est pas celle dans laquelle la ressource est répertoriée. Pour les valeurs de propriété à utiliser, voir le document Installation et déploiement de LiveCyclecorrespondant à votre serveur d’applications.

   • Si tel n’est pas le cas, passez à l’étape 2.

2. La ressource apparaît-elle dans l’arborescence JNDI sous un nom différent de celui figurant dans la recherche ?

   • Si tel est le cas, vous utilisez un nom de recherche incorrect. Indiquez le nom approprié.

   • Si tel n’est pas le cas, passez à l’étape 3.

3. Vérifiez les fichiers journaux du serveur d’applications lors du démarrage. Si le serveur d’applications a été configuré pour que cette ressource soit disponible mais que tout ne fonctionne pas correctement, une exception sera indiquée ici. Une exception est-elle survenue ?

   • Si tel est le cas, vérifiez la trace de l’exception et de la pile. Si, d’après vos recherches dans les fichiers journaux, NameNotFoundException s’avère être le symptôme d’un autre problème, accédez aux étapes de dépannage correspondant à ce problème.

   • Si tel n’est pas le cas, passez à l’étape 4.

4. Si la ressource n’est pas présente dans l’arborescence JNDI et qu’aucune exception au démarrage n’explique pourquoi elle n’est pas disponible, il se peut que le serveur d’applications n’ait pas été configuré correctement. Vérifiez la configuration du serveur d’applications. A-t-il été configuré pour rendre cette ressource disponible ?

   • Si ce n’est pas le cas, voir le guide Installation et déploiement de LiveCycle correspondant à votre serveur d’applications.

   • Si tel est le cas, il ne s’agit pas d’un problème courant. Contactez le support aux entreprises d’Adobe.

(Problème connu) Si ECM Connector for EMC Documentum est inclus dans votre installation de LiveCycle pour JBoss, le message d’erreur suivant apparaît dans les journaux du serveur chaque fois que vous redémarrez le serveur :

An org.jboss.logging.appender.FileAppender object is not assignable to an org.apache.log4j.Appender variable

Pour arrêter l’apparition des messages ERREUR et AVERTISSEMENT inutiles des journaux générés par IBM FileNet, dans le fichier journal du serveur d’applications JBoss, apportez la modification suivante au fichier log4j.xml situé dans [jboss_racine]/server/all/conf.

1. Recherchez le fichier log4j.xml puis ouvrez-le dans un éditeur.

2. Ajoutez le texte suivant à la section [Catégorie] :

        <category name="com.filenet"> 
            <priority value="FATAL"/> 
        </category>

1. Enregistrez le fichier, puis fermez-le.

2. Redémarrez le serveur d’applications.

Il existe une erreur de délai d’expiration WebLogic si vous recevez le message d’erreur suivant :

<Warning> <com.adobe.workflow.AWS> <ap-sun4> <Server_127> <[ACTIVE] ExecuteThread: '17' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-58E59A31956BB0D8F0AB> <> <1178316054656> <000000> <javax.ejb.TransactionRolledbackLocalException: EJB Exception: ; nested exception is: javax.ejb.TransactionRolledbackLocalException: EJB Exception: ; nested exception is: weblogic.transaction.internal.TimedOutException: Transaction timed out after 299 seconds 

Pour corriger ce problème, affectez une valeur supérieure à 300 secondes au délai d’expiration JTA de WebLogic (Voir Configuration du délai d’expiration des transactions WebLogic du document Préparation à l’installation de LiveCycle.

Il existe une erreur de déploiement EAR de WebLogic si vous recevez le message d’erreur suivant :

    Could not start application adobe-livecycle-weblogic. 
    com.adobe.livecycle.cdv.CDVException[ALC-LCM-030-113]: Failed to deploy EAR.

Pour résoudre ce problème, vérifiez WebLogic Server Administration Console pour vous assurer qu’elle n’est pas verrouillée, ce qui est indiqué par la sélection du bouton Lock & Edit. Si elle est verrouillée, Configuration Manager indique que le processus de déploiement est terminé à 16 % et WebLogic Server Administration Console indique que le fichier EAR est déployé, mais pas installé. Si la console WebLogic Server Administration Console n’est pas verrouillée, Configuration Manager peut déployer les fichiers EAR.

Pour résoudre ce problème, accédez à WebLogic Server Administration Console, assurez-vous qu’elle est déverrouillée, puis redéployez les fichiers EAR.

Il existe une erreur de déploiement EAR de WebLogic (Solaris) si vous recevez le message d’erreur suivant :

    java.lang.OutOfMemoryError: PermGen space

Pour résoudre ce problème, augmentez la valeur MaxPermSize de 256 à 512. Vous pouvez modifier cette valeur à partir de WebLogic Server Administration Console.

Le problème est connu : le serveur WebLogic s’exécutant sous Windows ne déploie pas les modules LiveCycle car le paramètre d’expiration du délai des transactions de 5 secondes est trop court. Vous pouvez configurer manuellement ce paramètre de la façon suivante :

• Accédez à [domaine du serveur d’applications] et ouvrez startWeblogic.cmd dans un éditeur.

• Ajoutez les paramètres suivants :

        -Dweblogic.client.socket.ConnectTimeout = <timeout value>

Si votre processus LiveCycle utilise un point de fin de courrier électronique, il est possible que vous receviez un message d’erreur semblable au message ci-dessous au moment de l’appel du point de fin de courrier électronique.

SECJ0305I: The role-based authorization check failed for naming-authz operation NameServer:bind_java_object. The user UNAUTHENTICATED (unique ID: unauthenticated) was not granted any of the following required roles: CosNamingCreate, CosNamingDelete, CosNamingWrite.

Cette erreur survient lorsque des autorisations sont manquantes pour les groupes de service de nommage CORBA dans WebSphere.

Suivez la procédure suivante afin de résoudre ce problème :

1. Dans la console d’administration WebSphere, sélectionnez Environment > Naming > CORBA Naming service groups.

2. Ajoutez les privilèges suivants :

   • Cos Naming Write

   • Cos Naming Delete

   • Cos Naming Create

3. Redémarrez WebSphere Application Server.

Dans le cas d’un déploiement en grappe WebSphere, il est possible que plusieurs entrées similaires à la suivante apparaissent dans les journaux d’erreur :

org.hibernate.event.def.AbstractFlushingEventListener performExecutions Could not synchronize database state with session 
org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.alfresco.repo.domain.hibernate.NodeImpl#10] 
at org.hibernate.persister.entity.AbstractEntityPersister.check(AbstractEntityPersister.java:1769)at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2412) 
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2312) 
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2612)

Ces erreurs n’ont pas d’incidence sur le fonctionnement. Toutefois, pour supprimer ces entrées, vous devez modifier les niveaux de journalisation à l’aide de WebSphere Administration Console. Pour modifier les niveaux de journalisation :

1. Connectez-vous à la console d’administration WebSphere.

2. Cliquez sur Troubleshooting > Logs and Trace.

3. Dans le volet de droite, cliquez sur le nom du serveur d’applications.

4. Cliquez sur Change Log Detail Levels.

5. Dans l’onglet de configuration, développez All Components > org.hibernate.event.* > org.hibernate.event.def.*.

6. Cliquez sur org.hibernate.event.def.AbstractFlushingEventListener. Un menu contextuel s’affiche.

7. Dans ce menu, cliquez sur Message and Trace Levels > Fatal.

8. Cliquez sur OK, puis sur Save directly to the master configuration.

Cette section explique la procédure à suivre si vous recevez le message d’erreur suivant lors du déploiement du fichier adobe-livecycle-websphere.ear :

Could not deploy adobe-livecycle-websphere.ear. com.adobe.livecycle.cdv.CDVException[ALC-LCM-030-112]: Failed to deploy EAR. Could not deploy adobe-livecycle-websphere.ear.

Pour éviter de recevoir des messages d’avertissement dans le fichier SystemOut.log en relation avec l’utilisation déconseillée de la recherche JNDI directe, vous pouvez modifier le niveau de journalisation WebSphere.

Pour supprimer le message d’avertissement J2CA0294W dans SystemOut.log, vous pouvez redéfinir le niveau de consignation sur *=info:com.ibm.ejs.j2c.ConnectionFactoryBuilderImpl=severe.

Pour éviter que l’installation de WebSphere entraîne l’enregistrement de plusieurs messages de journal superflus, vous pouvez élever le niveau de journalisation à « Warning » de façon à ce que les messages de niveau inférieur ne soient pas consignés.

1. Connectez-vous à la console d’administration WebSphere à l’aide de l’URL http://[nom d’hôte]:9060/admin et

2. Dans l’arborescence de navigation, cliquez sur Troubleshooting et sélectionnez Logs and Trace.

3. Dans le volet droit, cliquez sur le nom du serveur d’applications, puis cliquez sur Change Log Detail Levels.

4. Sélectionnez Runtime et entrez org.apache.xml.security.*

5. Cliquez sur Message And Trace Levels, puis sélectionnez Warning.

6. Sélectionnez le champ Save runtime changes to configuration.

7. Cliquez sur OK.

Votre serveur WebSphere Application Server peut produire des exceptions similaires à celles décrites ci-dessous.

         Could not connect to Inbox. Error message: com.ibm.jsse2.util.h: 
            No trusted certificate found; nested exception is: 
                javax.net.ssl.SSLHandshakeException: 
        com.ibm.jsse2.util.h: No trusted certificate found

        [5/28/08 13:15:30:283 CDT] 00000025 SystemOut     O 
        CWPKI0022E: SSL HANDSHAKE FAILURE:  A signer with SubjectDN 
        "CN=imap.gmail.com, O=Google Inc, L=Mountain View, ST=California, C=US" 
        was sent from target host:port "null:null". The signer may need to be 
        added to local trust store "D:/servers/websphere6.1/profiles/AppSrv01 
        /config/cells/MN-TOBIKONode01Cell/nodes/MN-TOBIKONode01/trust.p12" 
        located in SSL configuration alias "NodeDefaultSSLSettings" loaded from 
        SSL configuration file "security.xml".  The extended error message from 
        the SSL handshake exception is: "No trusted certificate found". 
        [5/28/08 13:15:30:283 CDT] 00000025 SystemOut     O  
        [5/28/08 13:15:30:283 CDT] 00000025 ExceptionUtil E    
        CNTR0020E: EJB threw an unexpected (non-declared) exception during 
        invocation of method "doSupports" on bean "BeanId(adobe-core-websphere 
        #adobe-dscf.jar#EjbTransactionCMTAdapter, null)". Exception data: 
        java.lang.RuntimeException: Could not connect to Inbox. Error message: 
        com.ibm.jsse2.util.h: No trusted certificate found; 
            nested exception is: 
                javax.net.ssl.SSLHandshakeException:  
        com.ibm.jsse2.util.h: No trusted certificate found

Lors de l’amorçage des composants User Manager sur WebSphere Application Server, le message d’exception suivant apparaît une seule fois après le démarrage de l’application :

00000043 javaURLContex E   NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. Exception stack trace: 
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/env/ejb not found in context "java:".]

Vous pouvez ignorer cette erreur sans risque.

Lorsqu’un DSC est appelé depuis une transaction démarrée par une autre application déployée en tant que fichier EAR sur la même instance de WebSphere sur laquelle LiveCycle est déployé, le DSC échoue avec le message d’erreur suivant :

LocalException E   CNTR0020E: EJB threw an unexpected (non-declared) exception during invocation of method "getObjectType" on bean

Cette erreur est rencontrée uniquement dans WebSphere lorsque le fichier adobe-utilities.jar est utilisé et Platform.UTIL.getTransactionManager() est l’utilisateur qui lance le gestionnaire de transactions.

Pour résoudre ce problème, n’utilisez pas le fichier adobe-utilities.jar pour lancer le gestionnaire de transactions. Utilisez plutôt le code suivant pour créer UserTransaction :

InitialContext initialContext = new InitialContext(); 
UserTransaction ut = (UserTransaction)initialContext.lookup("java:comp/UserTransaction"); 
ut.begin();