forcer slf4j à imprimer les journaux en séquence


J'utilise slf4j sur log-back. Parfois, les journaux ne s'impriment pas dans l'ordre (horodatage). Pourrions-nous le forcer à se connecter dans le même ordre que le code est en cours d'exécution?

Mise à jour 1: Cela se produit lors de l'exécution de tests unitaires sur Jenkins via maven. Cela se produit régulièrement. Les premières instructions de journal du code arrivent, puis les instructions de journal du test unitaire arrivent.

Tous les fichiers de logback semblent également normaux comme ci-dessous.

  <appender name="STDOUT"
            class="ch.qos.logback.core.ConsoleAppender">
    <layout class="ch.qos.logback.classic.PatternLayout">

Mise à Jour 2: les extraits de journal sont comme ceci (j'ai édité le nom du fichier, etc..). Pendant l'exécution de test1, nous appelons le code pour inverser une transaction qui a échoué en raison d'une erreur. Mais la chose étrange est que l'exception est imprimée en premier, puis les instructions de journal des méthodes de test sont imprimées. De plus, les horodatages des instructions de journal sont comme prévu, mais leur ordre dans le fichier est différent (14:33:34.718 arrive avant 14:33: 34.449)

14:33:34.667 [869082978@qtp-1587505558-0] [] WARN  org.hibernate.ejb.Ejb3Configuration - hibernate.connection.autocommit = false break the EJB3 specification
14:33:34.718 [869082978@qtp-1587505558-0] [] WARN  o.h.impl.SessionFactoryObjectFactory - InitialContext did not implement EventContext
14:33:34.843 [869082978@qtp-1587505558-0] [] DEBUG c.r.a.exception.ExceptionMapper - <3003> can't reverse transaction. [id=10000000100120014]
.
.
.
.
.
14:33:34.158 [main] [] DEBUG c.r.a.test - ========================= test0: finished.
14:33:34.158 [main] [] DEBUG c.r.a.test - ========================= test1: started.
.
.
.
.
14:33:34.449 [main] [] DEBUG c.r.a.test - reversing transaction, id=10000000100120014
14:33:34.856 [main] [] DEBUG c.r.a.test - ========================= test2: started.

Mise à Jour 3: Notre projet utilise maven et il existe plusieurs modules. Nous avons logback-test.xml dans le dossier src/test/resources.

La structure du projet est comme ceci
codemodule/src/test/resources/logback-test.xml - ce module sera empaqueté dans le fichier jar. Le cas de test appelle le code de ce module.
parent/src/test/resources/logback-test.xml - c'est le module parent qui encapsule tous les fichiers jar et les paquets des autres modules dans une guerre. C'est là que j'ai un cas de test en cours d'exécution et il appelle au-dessus du code du module.

J'ai des instructions de journal dans le code de cas de test et le code réel. J'ai vérifié que les deux cas de test et le code utilise un motif à partir du fichier logback du parent (le motif dans codemodule est différent). Il imprime systématiquement les instructions du journal du code avant d'imprimer les journaux du scénario de test.

De plus, nous n'exécutons pas de tests en parallèle.
Concurrency config is parallel='none', perCoreThreadCount=true, threadCount=2, useUnlimitedThreads=false

Mise à Jour 4: je comprends le problème. Nous faisons une requête http et non un appel de méthode direct. Donc, les cas de test s'exécutent dans le thread main et le code réel s'exécute dans un autre thread (Merci Sebbe).

Je comprends forcer la journalisation la séquence peut être atteinte par les performances, mais pour l'exhaustivité de la question, je poserai une autre question.

Puisque les deux journaux vont à un seul appender (STDOUT), puis-je le forcer à se connecter dans l'ordre de l'horodatage?

Author: Reddy, 2012-02-21

1 answers

À partir de votre journal lui-même, vous pouvez voir que vous avez au moins 2 threads en cours d'exécution: 869082978@qtp-1587505558-0 et main.

Vous ne pouvez pas contrôler l'ordre dans lequel des threads séparés enregistrent leurs événements sur la même sortie (vous le pouvez probablement, mais ce serait une mauvaise idée).

À partir de votre thread de journal 869082978@qtp-1587505558-0 obtient d'abord un accès en écriture à votre console. Lors de l'écriture, les événements sont enregistrés à partir de main. Une fois que 869082978@qtp-1587505558-0 libère son verrou, main l'obtient et il peut vider ses journaux dans le fichier.

 2
Author: Sebbe, 2012-02-28 08:59:54