Springboot Embedded Tomcat Classloader Langsamkeit

9

Ich habe eine Webanwendung erstellt, die verwendet SpringBoot v1.3.6.RELEASE Kater 8.0.36 Java 1.8u101 auf CentOS 7.2

Die Webanwendung ist auch ein SOAP-Client, der zu einer anderen Webanwendung aufruft. (JAX-WS RI 2.2.9) Wenn die Anwendungen 15 Sekunden lang inaktiv sind, wird der erste Webservice-Aufruf fast 2 Sekunden lang angehalten. Es scheint, dass der Stall in o.a.c.loader.WebappClassLoaderBase passiert.

Nach 15 Sekunden Leerlauf

  

16: 02: 36.165: Delegieren an übergeordneten Klassenloader [email protected]

     

16: 02: 36.170: Suche nach lokalen Repositories

     

16: 02: 36.170: findResource (META-INF / services / javax.xml.soap.MetaFactory)

     

16: 02: 38.533: - & gt; Ressource wurde nicht gefunden und gibt null zurück

     

16: 02: 38.533: - & gt; Ressource wurde nicht gefunden und gibt null zurück

Nächste Anfrage keine Leerlaufzeit

  

16: 07: 09.981: Delegieren an übergeordneten Klassenloader [email protected]

     

16: 07: 09.984: Lokale Repositorys suchen

     

16: 07: 09.985: findResource (META-INF / services / javax.xml.soap.MetaFactory)

     

16: 07: 09.986: - & gt; Ressource wurde nicht gefunden und gibt null zurück

     

16: 07: 09.986: - & gt; Ressource wurde nicht gefunden und gibt null zurück

     

16: 07: 09.988: findResources (META-INF / Dienste

Alle obigen Nachrichten, die von o.a.c.loader.WebappClassLoaderBase erzeugt wurden und anscheinend von ClientSOAPHandlerTube.processRequest verursacht wurden, welches von JAX-WS RI stammt.

Sie werden bemerken, dass der erste Anruf mehr als 2 Sekunden dauert, aber nachfolgende Anrufe nur Millisekunden dauern. Ich frage mich, ob jemand dieses Verhalten erfahren hat?

Mögliche Lösungen: Ist es möglich, den von Tomcat im Springboot verwendeten Classloader zu ändern, um ParallelWebappClassLoader zu verwenden

Oder vielleicht ist das ein Produkt des nachladbaren Flags auf dem Klassenlader, aber ich sehe nicht, wie ich dieses Flag im Springboot ändern kann.

Bei Verwendung von Jetty als Container tritt dies nicht auf.

Endlösung: (Danke an Gergely Bacso)

%Vor%     
cyberoblivion 30.08.2016, 17:58
quelle

1 Antwort

2

Tatsächlich sind deine Ergebnisse ziemlich gut und du hast 90% deine Frage schon beantwortet. Diese zwei Fakten:

  1. "Es scheint, dass der Stall in o.a.c.loader.WebappClassLoaderBase"
  2. passiert
  3. "Wenn dies mit Jetty als Container ausgeführt wird, tritt dies nicht auf."

zeigt, dass es ein Tomcat-Problem sein wird, weil:

  1. o.a.c. steht für org.apache.catalina
  2. Ihr Code funktioniert auf einem anderen Container gut. (Anlegesteg)

Sie haben auch festgestellt, dass das Problem nach 15 Sekunden Leerlaufzeit auftritt. Dies entspricht vollkommen Tomcat's Standard checkInterval Einstellung, welche ist:

  

Die Anzahl der Sekunden zwischen Prüfungen für modifizierte Klassen und   Ressourcen, wenn reloadable auf true gesetzt wurde. Der Standardwert ist 15   Sekunden.

Kurz gesagt: Momentan ist Ihr reloadable -Flag eingeschaltet, und Tomcat versucht, Ihre Klassen neu zu laden, was während der Entwicklung praktisch ist, aber in jedem anderen Fall inakzeptabel ist. Die Möglichkeit, es auszuschalten, erfolgt jedoch nicht über Spring-Boot.

LÖSUNG:
Sie müssen Ihre context.xml / server.xml finden, wo Sie Ihre Context wie folgt definiert finden:

%Vor%

Entfernen Sie das reloadable -Flag, und Sie haben das Problem gelöst. Die Datei selbst kann entweder in $ CATALINA_BASE / conf von $ CATALINE_HOME / conf sein, aber in Wirklichkeit können diese Stellen ein wenig schwierig zu finden sein, wenn Sie eine IDE verwenden, um Tomcat für Sie zu verwalten.

Bei eingebettetem Tomcat mit Spring-boot:

Die Klasse, die Sie verwenden können manipulieren Tomcat Einstellungen ist: EmbeddedServletContainerCustomizer .

Dadurch können Sie TomcatContextCustomizer ( addContextCustomizers ) hinzufügen, so dass Sie setReloadable für den Kontext selbst aufrufen können.

Ich sehe keinen Grund für Spring-boot, das dieses Flag auf true braucht.

    
Gergely Bacso 16.09.2016, 22:30
quelle