मैं कुछ समय के लिए ग्लासफ़िश 4.1 में वेबसोकेट के लिए एक वेब एप्लिकेशन का उपयोग कर रहा हूं और यह तब तक अच्छा चल रहा है जब तक कि हाल ही में मुझे इस समस्या का दो बार सामना नहीं करना पड़ा। इसने मेरे आवेदन को अपेक्षित रूप से क्रैश कर दिया और मैं सटीक कारण को इंगित करने में सक्षम नहीं हूं। मुझे प्राप्त होने वाला त्रुटि ट्रेस यहां दिया गया है:

GRIZZLY0013: Exception during FilterChain execution
java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3181)
    at java.util.ArrayList.grow(ArrayList.java:261)
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
    at java.util.ArrayList.add(ArrayList.java:458)
    at org.glassfish.grizzly.filterchain.FilterChainContext.addCompletionListener(FilterChainContext.java:930)
    at org.glassfish.grizzly.utils.IdleTimeoutFilter.queueAction(IdleTimeoutFilter.java:249)
    at org.glassfish.grizzly.utils.IdleTimeoutFilter.handleRead(IdleTimeoutFilter.java:167)
    at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:284)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
    at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
    at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
    at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:561)
    at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:117)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:56)
    at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:137)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:565)
    at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:545)
    at java.lang.Thread.run(Thread.java:745)

ट्रेस से ऐसा प्रतीत होता है कि FilterChainContext.addCompletionListener को अक्सर कॉल किया जा रहा है, जिससे ArrayList आकार में बहुत बढ़ जाता है - स्मृति को खा रहा है। सर्वर को इस प्रकार के श्रोता को इतनी बार जोड़ने का क्या कारण हो सकता है? क्या सर्वर को बहुत अधिक अनुरोध प्राप्त हो रहे हैं? क्या यह एक ग्लासफ़िश बग है या क्या इसे केवल बढ़ते ढेर के आकार के साथ करना है?

फिलहाल के लिए मैंने -Xmx ध्वज द्वारा दर्शाए गए ढेर के आकार को 512MB से बढ़ाकर 2GB कर दिया है। -XX:+UseParallelGC के माध्यम से जीसी के लिए समानांतर संग्राहक को भी लागू किया।

यह बहुत अच्छा होगा यदि आप इस समस्या को हल करने में मदद करने के लिए और अंतर्दृष्टि प्रदान कर सकें।

1
ZakiMak 28 जून 2016, 22:48
हो सकता है आप इसे gf 5 में आज़माना चाहें या शायद gf 4.1.1, क्या यह एक निश्चित बग होना चाहिए
 – 
jan.supol
28 जून 2016, 23:05

1 उत्तर

सबसे बढ़िया उत्तर

मुझे इस मुद्दे को ठीक किए हुए काफी समय हो गया है, लेकिन मैं उस बदलाव को साझा करना चाहता हूं जो मुझे करना था, अगर यह उसी मुद्दे का सामना करने वाले लोगों की मदद करता है - जो वही गलती कर रहे हैं जैसे मैंने किया था।

समस्या मेरे आवेदन में थी। मेरे कोड में गहराई से एप्लिकेशन ने प्रत्येक नए क्लाइंट अनुरोध के लिए एक नई वस्तु बनाई। इस तरह:

Worker workerObj = new Worker();

प्रारंभ में, जब इसे तैनात किया गया था, तो इससे कोई समस्या नहीं हुई क्योंकि सर्वर लोड बहुत कम था, लेकिन जैसे-जैसे क्लाइंट तेजी से बढ़े, मेमोरी अधिक से अधिक खपत हुई और अंत में इसने सर्वर को क्रैश कर दिया।

समाधान एक एकल वर्कर ऑब्जेक्ट बनाना और सभी अनुरोधों के लिए थ्रेड-सुरक्षित तरीके से पुन: उपयोग करना था।

0
ZakiMak 3 जून 2017, 23:45