2016-08-25 1 views
1

Ich habe eine Java-Webanwendung, die ich in Wildfly 10 Webserver bereitgestellt habe. Die Anwendung funktioniert die meiste Zeit gut, aber sehr unerwartet erreichen die Aufrufe des Java-Servlets niemals das Servlet.Die Java-Servlet-Aufrufe erreichen nie das Servlet

Ich wurde neugierig und analysierte den Thread-Dump des Wildfly-Servers in Visualvm. Obwohl ich kein Experte in der Analyse von Thread-Dumps bin, erwarte ich, dass einige Thread-Sperren auftreten, aufgrund derer der Task-Thread für diesen Servlet-Aufruf nie ausgeführt wird; bleibt ewig warten.

Im Moment weiß ich nicht, ob dies ein Problem von der Anwendungsseite ist. Ich vermute, dass dies ein Problem mit der Servlet-Container-Konfiguration ist, die ich als Standard eingestellt habe, oder ist das ein Wildfly-Bug? .., was ich nicht hoffe. Bitte antworte.

Dies ist die Anmeldungs ​​Servlet-Code:

response.setContentType("application/json"); 
    UserInfo user = null; 
    boolean authenticated = false; 
    String message = ""; 
    String ipAddress = request.getHeader("X-FORWARDED-FOR"); 
    if (ipAddress == null) { 
     ipAddress = request.getRemoteAddr(); 
    } 

    try { 
     ApplicationHelper.clearSession(request); 
     String body = request.getReader().lines().reduce("", (accumulator, actual) -> accumulator + actual); 
     HashMap inputDataMap = new ObjectMapper().readValue(body, HashMap.class); 
     String userName = (String) inputDataMap.get("username"); 
     String password = (String) inputDataMap.get("password"); 
     user = UserDataProvider.verifyEncryptedAccount(userName, password); 

     if (user != null) { 
      UserDataProvider.updateLoginStatus(user.getIdKey(), request.getSession().getId(), ipAddress, true); 
      request.getSession(true).setAttribute("userInfo", user); 
      authenticated = true; 
      message = MPHLTHConstants.Success; 
     } else { 
      throw new InsufficientAccessException("Insufficient access"); 
     } 

    } catch (Exception ex) { 
     authenticated = false; 
     if (ex instanceof ApplicationException) { 
      message = ex.getMessage(); 
     } 
     ExceptionDataProvider.logException(ex, request, user); 
    } finally { 
     try { 
      Response objResponse = new Response(user, message, authenticated, 1); 
      Map<String, String[]> jsonFilters = new HashMap<>(); 
      jsonFilters.put("ResponseFilter", new String[0]); 
      jsonFilters.put("UserInfoFilter", new String[0]); 
      JSONHelper.writeJSONResponse(objResponse, response, jsonFilters); 
     } catch (Exception ex) { 
      ExceptionDataProvider.logException(ex, request, user); 
     } 
    } 

Dies sind die Themen, wo ich die Schlösser sah, und ich mehrere von ihnen zu verschiedenen Zeiten und diese im Laufe der Zeit nicht ändern:

"default task-64" #206 prio=5 os_prio=0 tid=0x000000001c59b800 nid=0x5608 waiting for monitor entry [0x000000001f8bd000] java.lang.Thread.State: BLOCKED (on object monitor) 
    at java.io.PrintStream.println(PrintStream.java:805) 
    - waiting to lock <0x00000000e0058f58> (a java.io.PrintStream) 
    at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474 

und diese:

> "default task-61" #203 prio=5 os_prio=0 tid=0x000000001c599000 nid=0x4934 runnable [0x000000001f5bd000] 
    java.lang.Thread.State: RUNNABLE 
    at java.io.FileOutputStream.writeBytes(Native Method) 
    at java.io.FileOutputStream.write(FileOutputStream.java:326) 
    at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) 
    at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) 
    - locked <0x00000000e0aeb790> (a java.io.BufferedOutputStream) 
    at java.io.PrintStream.write(PrintStream.java:482) 
    - locked <0x00000000e0aeb770> (a java.io.PrintStream) 
    at org.jboss.logmanager.handlers.UncloseableOutputStream.write(UncloseableOutputStream.java:44) 
    at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84) 
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) 
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) 
    at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) 
    at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) 
    - locked <0x00000000e0aeb738> (a java.io.OutputStreamWriter) 
    at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) 
    at java.io.BufferedWriter.flush(BufferedWriter.java:254) 
    - locked <0x00000000e0aeb738> (a java.io.OutputStreamWriter) 
    at org.jboss.logmanager.handlers.WriterHandler.safeFlush(WriterHandler.java:170) 
    at org.jboss.logmanager.handlers.WriterHandler.flush(WriterHandler.java:139) 
    - locked <0x00000000e0aeb700> (a java.lang.Object) 
    at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104) 
    at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:67) 
    - locked <0x00000000e0aeb700> (a java.lang.Object) 
    at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) 
    at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314) 
    at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322) 
    at org.jboss.logmanager.Logger.logRaw(Logger.java:850) 
    at org.jboss.logmanager.Logger.log(Logger.java:596) 
    at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71) 
    - locked <0x00000000e0058fb8> (a java.lang.StringBuilder) 
    at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143) 
    at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164) 
    - locked <0x00000000e0059128> (a sun.nio.cs.SingleByte$Decoder) 
    at java.io.PrintStream.write(PrintStream.java:482) 
    - locked <0x00000000e0058f58> (a java.io.PrintStream) 
    at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) 
    at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) 
    at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) 
    - locked <0x00000000e00579c0> (a java.io.OutputStreamWriter) 
    at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) 
    at java.io.PrintStream.newLine(PrintStream.java:546) 
    - locked <0x00000000e0058f58> (a java.io.PrintStream) 
    at java.io.PrintStream.println(PrintStream.java:807) 
    - locked <0x00000000e0058f58> (a java.io.PrintStream) 
    at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474) 
+0

Können Sie einen Code mit uns teilen? –

+0

Was bedeutet es, dass "Anruf den Server nicht erreicht?" Was geschieht? HTTP-Status 403? Kann 500 sein? – AlexR

+0

Meinst du das * manchmal * das Servlet erhält die Anfrage nicht? Ansonsten kann ich nicht sehen, wie man sagen kann, dass die Anwendung "die meiste Zeit gut funktioniert". – RealSkeptic

Antwort

0

Dieses Problem schließlich behoben ist. Es wurde festgestellt, dass die Thread-Sperren aufgrund von println() -Anweisungen auftreten, die an mehreren Stellen in der Anwendung vorhanden waren. Der Logging-Subsytem in WildFly 10 und die println() -Anweisungen erzeugten Sperren für den Druckausgabe-Stream und kamen schließlich in einen Deadlock.

+0

Warum behandelt Wildfly das nicht richtig? – Vishnu

+0

Weil es System.out und System.err einbindet, die PrintStreams ausschütten, die 2 Dinge ausführen: 1) Schreiben auf den ursprünglichen jvm-Stream 2) Schreiben in stdout/stderr-Logger (Standard-Konsolenappender in wildfly). –

Verwandte Themen