bin ich fürs schließen zuztändig?

[ARadauer]

ich schreib hier ein pdf in den response

  public void sendPDF(HttpServletResponse response) 
  throws InformationOnlyException, IOException {   
  ....
    ServletOutputStream ostream = null;
    
    try {
      ostream = response.getOutputStream ();
      response.setContentType("application/pdf");
      response.setHeader("Content-Disposition", "attachment;filename=xxx.pdf");
      ostream.write(datei);     
      ostream.flush();
    } catch (IOException e) {
     //e.printStackTrace(); //user hat abgebrochen         
    }finally {
       if(ostream!= null)
          ostream.close();
    }
}

genau nach dem flush, kriegt der user die meldung ob er das file öffnen oder speichern will, klickt er abbrechen, fang ich die ioexception und schließ im finally den ostream.. ist dieses close notwendig? bzw geht mich das überhaupt was an, da es ja eine resource vom response ist?

 

[ARadauer]

push... ist dringend ;-)

 

[SlaterB]

da du geantwortet hast und ich den Thread nicht aus der 'Unbeantwortete Threads'-Liste schubse,
ein kleiner Kommentar:

ist das nicht egal? wenns für den User geht und ein Lasttest von 1000 Anfragen den Server nicht zermürbt,
dann wird ein fehlendes close() wohl keinen Nachteil haben,

ich vermute, dass nach der Servlet-Bearbeitung ein automatisches close() kommt,
das kann aber vielleicht, selbst wenn aktuell vorhanden, von Framework zu Framework wechseln

 

[ARadauer]

wir haben hier ein selbstgebautes framework, dass sicher den stream nicht schließt...

aber der tomcat oder sonst was könnte es ja machen...

generell unser problem, wir haben eine große neue anwendung produktiv geschaltet und jetzt bleibt alle 2-3 stunden unser tomcat einfach stehen... keine fehler, kein out of memory... er reagiert einfach nicht mehr.... da dachte ich mir, es konnte an soetwas liegen....

 

[Murray]

Hast Du schon versucht, einen Thread-Dump zu ziehen? Möglicherweise ist das ja ein Deadlock-Problem.

 

[byte]

genau nach dem flush, kriegt der user die meldung ob er das file öffnen oder speichern will, klickt er abbrechen, fang ich die ioexception und schließ im finally den ostream..

Ich glaube, Du hast hier einen Denkfehler. Sobald im Browser das Fenster für den Dateidownload aufgeht, dann ist Request/Response auf dem Server schon beendet. Das Servlet bekommt überhaupt nichts mehr davon mit, ob der User im Browser auf OK oder Abbrechen klickt. Das ist komplett browserspezifisch und hat nichts mehr mit dem HTTP Request / Response zu tun. Folglich kann das nicht der Fehler sein.

Interessanter wäre die Frage, ob Eure Servlets zustandslos sind ober ob Ihr Member verwendet!? Für mich siehts stark danach aus, als wenn alle 2-3 Stunden der Heap voll ist und der GC aufräumt.

 

[SlaterB]

sicher?
wie ist das denn bei 100 MB großen Dateien, da muss der User doch sicher nicht warten, bis das Servlet das 10 Min. lang weggeschrieben hat,
wo sollte das auch zwischengelagert werden?

oder geht sowas nur mit anderen Technologien als Java-Servlets?

auch erinnere ich mich irgendwo was gehört zu haben im Sinne von
'wenn in den OutputStream schon HTML geschrieben wurde, dann kann im Falle eines späteren Verarbeitungsfehlers nicht mehr auf eine Fehlerseite weitergeleitet werden, weil der Client schon den ersten Schwung HTML erhalten haben kann'

 

[ARadauer]

Sobald im Browser das Fenster für den Dateidownload aufgeht, dann ist Request/Response auf dem Server schon beendet.

sicher?

mein eclipse debugger bleibt genau zwischen

ostream.flush();
und
ostream.close();
stehen..
klick ich auf ok läufts weiter, abbrechen wirft mir eine exception...

aber egal, daran kanns glaub ich eh nicht liegen... grundsätzlich läuft die ganze sache in 4 ländern, jetzt haben wir ein 5. ausgerollt und -.... problemen... das sollen sich mal die tomcat typen anschaun... aber die sind gerade nicht zu erreichen...

 

[ARadauer]

mein eclipse debugger bleibt genau zwischen

....
nein doch nicht,... ;-)

 

[byte]

Sicher bin ich nicht. Aber ich denke, das von Dir beschriebene wird über die Transportschicht geregelt. Es lässt sich aber leicht testen. Einfach einen Breakpoint in den Finally Block und debuggen.

Aber grundsätzlich gilt die Regel: Ein Stream muss nur geschlossen werden, wenn man ihn auch selbst auf macht.

 

[byte]

Wenns der GC ist:
Als schnellen Workaround könntet Ihr einen ServletFilter zwischenschalten, der zu festen Zeiten den GC aufruft (z.B. alle 15 Minuten oder - noch besser - zu Zeiten, wo Ihr wisst, dass die Last gering ist). Häufig kurz warten ist oft besser als einmal lang warten. Ihr hättet dann erstmal Zeit zu prüfen, wo das Speicherleck genau zu lokalisieren ist.