2012-03-29 10 views
6

पर फ्लश नहीं करता है, मैंने नीचे HttpResponse#flushBuffer और PrintWriter#flush पर Tomcat 7 पर परीक्षण किया है, लेकिन ऐसा लगता है कि प्रतिक्रिया ने उन्हें अपेक्षित तार के रूप में सामग्री को फ़्लश करने की बजाय उन्हें अनदेखा किया।टॉमकैट प्रतिक्रिया बफर

import java.io.IOException; 
import java.io.PrintWriter; 

import javax.servlet.ServletException; 
import javax.servlet.annotation.WebServlet; 
import javax.servlet.http.HttpServlet; 
import javax.servlet.http.HttpServletRequest; 
import javax.servlet.http.HttpServletResponse; 

@WebServlet("/HelloServlet") 
public class HelloServlet extends HttpServlet { 

    private static final long serialVersionUID = 1L; 

    protected void doGet(HttpServletRequest request, 
      HttpServletResponse response) throws ServletException, IOException { 

     PrintWriter pw = response.getWriter(); 
     pw.println("say hi now"); 
     pw.flush(); 
     response.flushBuffer(); 
     try { 
      Thread.sleep(5000); 
     } catch (Exception e) { 
     } 
     pw.println("say bye in 5 seconds"); 

    } 

} 

ब्रोवर देरी के बाद "हाय" और "अलविदा" प्रदर्शित करता है। क्या यह एक दुर्व्यवहार है या इरादा है?

@EDIT

@Tomasz Nurkiewicz के सुझाव के अनुसार, मैं curl तो इस मुद्दे को चला गया था के साथ फिर से परीक्षण किया गया। ऐसा लगता है कि एक ही http प्रतिक्रिया से मानक ब्राउज़र और tcp/ip monitor पैक small pieces of contents पैक करें।

@EDIT 2

यह भी है कि दोनों HttpResponse#flushBuffer और PrintWriter#flush ड्राइव Tomcat 7 ग्राहक chunked data भेजने के लिए मनाया जाता है।

+0

मुझे विश्वास है कि यह एक ऐप-सर्वर कॉन्फ़िगरेशन है। कृपया, [मेरी पोस्ट] देखें (http://stackoverflow.com/questions/43453508/end-to-end-reactive- स्ट्रीमिंग-restful- सेवा)। –

उत्तर

2

flushBuffer() के लिए एपीआई बहुत ही सटीक है:

बलों बफर में किसी भी सामग्री को ग्राहक को लिखे जाने की। इस विधि को एक कॉल स्वचालित रूप से प्रतिक्रिया करता है, जिसका अर्थ है स्टेटस कोड और हेडर लिखे जाएंगे।

तो या तो बिलाव कल्पना (अधिक आक्रामक तरीके से बफ़र्स और flushes रखती है अगर वे बहुत छोटे हैं) या क्लाइंट (ब्राउज़र) वास्तव में यह प्रतिपादन से पहले और अधिक निवेश के लिए इंतजार कर रहा है के अनुसार लागू नहीं है।

क्या आप इसके बजाय या nc के साथ प्रयास कर सकते हैं?

+0

मैंने तार पर snooped, यह tomcat पर एक कार्यान्वयन मुद्दा है। – sof

+0

'curl' के साथ प्रयास करते समय समस्या समाप्त हो गई है। यह टोमकैट के लिए 'असंबंधित' होना चाहिए। – sof

5

मुझे बस यही समस्या थी।

response.setContentType("text/html;charset=UTF-8"); 
2

मुझे लगता है कि इस मुद्दे को था भी,: इससे पहले कि यह किसी भी प्रतिपादन आप के साथ शुरू करने की आवश्यकता तक पृष्ठ के लोड हो इंतज़ार कर ब्राउज़रों को रोकने के लिए। और मुझे यह भी पता चला कि मुद्दा कर्ल से दूर चला गया है। कुछ स्नीफिंग के साथ, यह पता चला कि अपराधी gzip एन्कोडिंग है। प्रतिक्रिया को संपीड़ित करने के लिए, gzip अंतर्निहित प्रिंटवाइटर बंद होने तक प्रतीक्षा करता है (यानी, पूर्ण प्रतिक्रिया लिखे जाने तक) और फिर संकुचित आउटपुट उत्पन्न करता है। ग्राहक पक्ष पर, इसका मतलब है कि पूर्ण प्रतिक्रिया तैयार होने तक आपको कुछ भी वापस नहीं मिलता है। दूसरी ओर, कर्ल एक स्वीकार्य-एन्कोडिंग जारी नहीं करता है: सर्वर पर gzip, और यही कारण है कि चीज काम करती है, और आप आमतौर पर इच्छित रूप से खंडित आउटपुट प्राप्त कर सकते हैं।

0

इस घटना के लिए अभी तक एक अनिवार्य संभावित कारण एंटी-वायरस सॉफ़्टवेयर है। मैंने अपनी मशीन पर एक ही व्यवहार का निरीक्षण किया: सर्वर चंकित डेटा भेज रहा है, कर्ल काम करता है, सामान्य ब्राउज़र नहीं करता है, और फिडलर ने पुष्टि की है कि यह अवरुद्ध सर्वर नहीं था। तो थोड़ी देर बाद मुझे सोफोस (एंटी-वायरस सॉफ़्टवेयर जो मेरे नियोक्ता का उपयोग करता है) में हस्तक्षेप करने के लिए वेब सुरक्षा की संदेह है, और वास्तव में वे https://community.sophos.com/kb/en-us/115656 पर पुष्टि करते हैं कि प्रतिक्रिया पूरी होने तक वे खंडित डेटा को अवरुद्ध करते हैं, कुछ निश्चित माइम-प्रकारों को छोड़कर अक्सर मीडिया डेटा स्ट्रीमिंग के लिए प्रयोग किया जाता है।

एक त्वरित जांच के रूप में कोई HTTP-पुश डेमो http://www.pushlets.com पर चला सकता है।यदि यह काम नहीं करता है तो यह काफी संभावना है कि ग्राहक को टाइप टेक्स्ट/एचटीएमएल प्रकार के चुस्त डेटा को संभालने के साथ एक सामान्य समस्या है।