Spring Boot Embedded Tomcat Anwendung Sitzung nicht ungültig

Question

Kürzlich haben wir unsere Anwendung von der Web-Anwendung in Tomcat ausgeführt, um Spring-Boot-Anwendung mit Embedded Tomcat.

Nachdem die App mehrere Tage ausgeführt wurde, haben Arbeitsspeicher und CPU-Auslastung 100% erreicht. In Heap-Dump-Analyse kommt heraus, dass es eine Reihe von http-Session-Objekten gab, die nicht zerstört wurden.

Ich kann im debug sehen, dass Sitzungen mit konfigurierten Timeout-Wert, sagen wir, 5 Minuten erstellt. Aber nach dieser Zeit wird die Ungültigkeitserklärung nicht ausgelöst. Es wird nur aufgerufen, wenn ich nach der Zeitüberschreitung erneut anfordere.

ich dieses Verhalten mit app in tomcat verglichen habe laufen und ich, dass Sitzung Entwertung durch ContainerBackgroungProcessor Thread [Norm (ManagerBase) .processExpires()]

ich im Frühjahr Boot diesen Hintergrund-Thread nicht sehen ausgelöst sehen Anwendung.

Was wurde nach einigen Vorschlägen gefunden getan:

1. Sitzung Timeout in application.properties: server.session.timout = 300 oder in EmbeddedServletContainerCustomizer @Bean: factory.setSessionTimout (5, Timeunit .MINUTES)

2. Added HttpSessionEventPublisher und SessionRegistry Bohnen

Nichts hilft, Sitzungen werden zum Ablaufzeitpunkt nicht ungültig.

Ein Hinweis darauf?

Answer 1

Nachdem einige weitere Fehlersuche und Dokumentation der Lektüre dieses ist der Grund und Lösung:

In Katers gibt es einen Thread im Namen des Stammcontainer hervorgebracht, die durchsucht regelmäßig Container und seine Session-Pools untergeordneten Container und entkräftet sie. Jeder Container/Kind-Container kann so konfiguriert sein, dass er seinen eigenen Hintergrundprozessor hat, um die Aufgabe zu erledigen oder sich auf den Hintergrundprozessor seines Hosts zu verlassen. Diese kontrollierte durch Conext.backgroundProcessorDelay

Apache Tomcat 8 Configuration Reference

backgroundProcessorDelay -
Dieser Wert an diesem Motor und seine untergeordneten Container die Verzögerung in Sekunden zwischen der Aufruf der Methode backgroundProcess darstellt, einschließlich aller Hosts und Kontexte. Untergeordnete Container werden nicht aufgerufen, wenn ihr Verzögerungswert nicht negativ ist (was bedeutet, dass sie ihren eigenen Verarbeitungsthread verwenden). Wenn Sie dies auf einen positiven Wert setzen, wird ein Thread erzeugt. Nach dem Warten auf den angegebenen Zeitraum ruft der Thread die Methode backgroundProcess für diese Engine und alle untergeordneten Container auf. Wenn nicht angegeben, ist der Standardwert für dieses Attribut 10, was eine Verzögerung von 10 Sekunden darstellt.

Im Frühjahr Boot-Anwendung mit eingebettetem tomcat gibt es TomcatEmbeddedServletContainerFactory.configureEngine(), die diese Eigenschaft setzt -1 für die StandardEngine [Tomcat], die der Stammcontainer in tomcat Hierarchie ist, wie ich sie verstehe. Alle untergeordneten Container einschließlich der Web-App haben diesen Parameter auch auf -1 gesetzt. Und das bedeutet, dass sie alle auf jemand anderen angewiesen sind, um die Aufgabe zu erledigen. Spring mach es nicht, niemand macht es.

Die Lösung für mich war, diesen Parameter für den App Kontext zu setzen:

@Bean 
public EmbeddedServletContainerCustomizer servletContainerCustomizer() { 
    return new EmbeddedServletContainerCustomizer() { 

     @Override 
     public void customize(ConfigurableEmbeddedServletContainer container) { 
      if (container instanceof TomcatEmbeddedServletContainerFactory) { 
       TomcatEmbeddedServletContainerFactory factory = (TomcatEmbeddedServletContainerFactory) container; 
       TomcatContextCustomizer contextCustomizer = new TomcatContextCustomizer() { 

        @Override 
        public void customize(Context context) { 
         context.setBackgroundProcessorDelay(10); 
        } 
       }; 
       List<TomcatContextCustomizer> contextCustomizers = new ArrayList<TomcatContextCustomizer>(); 
       contextCustomizers.add(contextCustomizer); 
       factory.setTomcatContextCustomizers(contextCustomizers); 
       customizeTomcat(factory); 
      } 
     }