Le module Liferay (bundle OSGi) reste à "Arrêt"

Question

Parfois, lorsque j'arrête mon module Liferay (par exemple lorsque je mets une nouvelle version de son JAR dans deploy/) le module refuse de s'arrêter.

Alors que le module devrait aller à « Résolu » état, il reste dans le « Arrêt » état pour toujours:

Habituellement, il est dû à un fil non terminé quelque part, ou une connexion réseau non correctement fermé, et c'est souvent une douleur à étudier.

Ma question: Comment savoir plus efficacement quel est le problème de ce module Liferay?

Ce que j'ai essayé:

• Dans Gogo Shell diag <module id> ne semble pas fournir des informations précieuses sur la raison pour laquelle le module refuse de quitter l'état « Arrêt ».
• jstack sort des milliers de lignes, dont la grande majorité est en dehors du module Liferay en question. S'il y avait un moyen de montrer des informations jstack pour seulement mon module ce serait merveilleux.

Answer 1

Tout d'abord, trouver le PID de votre serveur webapp:

ps aux | grep tomcat 

Adapter la commande si vous exécutez un autre serveur que tomcat, ou si vous avez plusieurs instances en cours d'exécution.

Ensuite, Vidage de tous les fils de ce serveur dans un fichier:

jstack 12345 > jstack.txt 

Où est le PID 12345 que vous avez trouvé dans la première étape.

Ensuite, regardez le code source de votre bundle et trouvez l'activateur de service. Il semble généralement comme ceci:

package fr.free.nrw; 

[import section] 

public class ServiceActivator implements BundleActivator { 

    private ServiceRegistration registration; 

    @Override 
    public void start(BundleContext context) throws Exception { 
     registration = context.registerService(
      MyService.class.getName(), new MyServiceImpl(), null); 
    } 

    @Override 
    public void stop(BundleContext context) throws Exception { 
     registration.unregister(); 
    } 
} 

Prenez note:

• l'espace de noms,
• le nom de classe,
• le nom de la méthode d'arrêt.

Par exemple, dans l'exemple ci-dessus, ils sont fr.free.nrw, ServiceActivator et stop, et de ces trois obtenir le nom complet fr.free.nrw.ServiceActivator.stop.

Maintenant, ouvrez jstack.txt et recherchez le nom complet.Même si le fichier est des milliers de lignes, il n'y aura plus probablement être un seul coup, et qui est le fil problématique:

at org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:222) 
at fr.free.nrw.ServiceActivator.stop(ServiceActivator.java:30) 
at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:830) 
at org.eclipse.osgi.internal.framework.BundleContextImpl$4.run(BundleContextImpl.java:1) 
at java.security.AccessController.doPrivileged(Native Method) 
at org.eclipse.osgi.internal.framework.BundleContextImpl.stop(BundleContextImpl.java:823) 

Dans ce fichier, allez jusqu'au début du paragraphe, qui sera quelque chose comme ceci:

"fileinstall-/home/nico/p/liferay/osgi/modules" #37 daemon prio=5 os_prio=0 tid=0x00007f39480e3000 nid=0x384f waiting on condition [0x00007f395d169000] 
    java.lang.Thread.State: WAITING (parking) 
    at sun.misc.Unsafe.park(Native Method) 
    - parking to wait for <0x00000000eb8defb8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) 
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) 

avec cette information en main, vous connu ce genre de problème de filetage se passe, et vous serez en mesure de le résoudre avec des techniques de débogage de fil habituelles Java (12).

Answer 2

L'activateur que vous avez partagé ne devrait jamais bloquer la méthode d'arrêt. Donc, je doute que cela puisse provoquer le comportement que vous avez décrit.