जेएसएफ ईएल और समग्र घटकों के माध्यम से स्मृति को लीक कर रहा है

Question

नोट: मैं mojarra 2.1.20 और समृद्ध चेहरे 4.2.2 का उपयोग कर रहा हूं।

मैंने एक हेपडम्प का विश्लेषण किया है और मैंने देखा है कि सत्र में एलआरयूएमएपी में ईएल अभिव्यक्तियां रहती हैं। क्या किसी को पता है कि इससे बचने के लिए क्यों और क्या करना है? समर्थन सेम my.package.MultiComboSelection साथ

<rich:select ... valueChangeListener="#{cc.listValuesChangeListener}" 

:

समस्या मैं एक समग्र घटक निम्न पंक्ति युक्त से संबंधित है। जाहिर है my.package.MultiComboSelection में एक विधि परिभाषित सूची है ValuesChangeListener।

समस्या जो मैं देखता हूं वह यह है कि LRUMap में ContextualCompositeMethodExpression (उपरोक्त मूल्यChangeListener के लिए अभिव्यक्ति का प्रतिनिधित्व) शामिल है, जो cc विशेषता संदर्भ मल्टीकंबो चयन। मल्टीकंबो चयन यूआईएनएमिंगकंटनर को बढ़ाता है और इस तरह माता-पिता/बच्चों के गुण होते हैं - घटक पेड़ के संदर्भ हैं।

नतीजा यह है कि स्मृति के 16MB नहीं किया जा कचरा-एकत्र कर सकते हैं एक संदर्भ श्रृंखला है क्योंकि वहाँ है:

सत्र-> LRUMap-> ContextualCompositeMethodExpression-> MultiComboSelection-> माता पिता और 16MB

सवाल यह है - यह क्यों हो रहा है और इसे कैसे ठीक किया जाए या इसके आसपास काम कैसे करें?

Class Name                     | Shallow Heap | Retained Heap | Retained Heap 
-------------------------------------------------------------------------------------------------------------------------------------------- 
my.package.MultiComboSelection @ 0x78dc2bd50             |   96 | 16 466 272 | 16 466 272 
|- component javax.faces.component.UIComponentBase$FacetsMap @ 0x78dbbbd58     |   48 |   128 |    
|- parent javax.faces.component.UIPanel @ 0x78dbbbdd8          |   88 |   760 |    
|- cc com.sun.faces.facelets.el.ContextualCompositeMethodExpression @ 0x78dc2bce0   |   32 | 16 466 384 |    
| |- [0] java.lang.Object[2] @ 0x78dc2bc90             |   24 | 16 466 464 |    
| | '- [0] java.lang.Object[1] @ 0x78dc2bc78            |   24 | 16 466 488 |    
| |  '- [0] java.lang.Object[5] @ 0x78dc2bc20           |   40 | 16 466 576 |    
| |  '- [0] java.lang.Object[2] @ 0x78dc2bc08           |   24 | 16 466 600 |    
| |   '- [0] java.lang.Object[4] @ 0x78dc2bbe8          |   32 | 16 466 632 |    
| |    '- value java.util.HashMap$Entry @ 0x78dc2bb40        |   32 | 16 466 800 |    
| |     '- [1579] java.util.HashMap$Entry[2048] @ 0x78dbf61b8     |  8 208 | 33 552 536 |    
| |     '- table java.util.HashMap @ 0x78dbb6860        |   48 | 33 552 584 |    
| |      '- [1] java.lang.Object[2] @ 0x78ad95340       |   24 | 33 552 608 |    
| |       '- value java.util.LinkedHashMap$Entry @ 0x78ad952c0   |   40 | 33 552 736 |    
| |        |- after, before java.util.LinkedHashMap$Entry @ 0x78acbe6a0|   40 |   40 |    
| |        |- [0] java.util.HashMap$Entry[2] @ 0x78ad952a8    |   24 |   24 |    
| |        | '- table com.sun.faces.util.LRUMap @ 0x78ad95270   |   56 | 33 552 856 |    
-------------------------------------------------------------------------------------------------------------------------------------------- 

Answer 1

ContextualCompositeMethodExpressionissue 1462 करने के लिए एक समाधान के परिणाम के रूप में उदाहरण चर के रूप में पूरे समग्र घटक संदर्भित कर रहा है। एक उपयोगकर्ता ने इस स्मृति मेमोरी लीक समस्या के बारे में issue 1940 के बारे में बताया है। और उसके बाद बाद में उदाहरण चर पर transient को issue 1943 पर एक फिक्स के परिणामस्वरूप चिह्नित किया गया था। हालांकि, 1 9 40 को जारी करने के लिए किसी कारण से 1 9 43 के डुप्लिकेट के रूप में चिह्नित किया गया था। दो उपयोगकर्ताओं ने सही समस्या के बारे में 1 9 40 के नीचे अपनी समस्या के बारे में टिप्पणी की है कि स्मृति रिसाव मुद्दा अभी भी खुला है, लेकिन मुझे कोई नई समस्या रिपोर्ट नहीं दिखाई दे रही है उसके बाद में। समस्या वास्तव में केवल प्रकट होती है जब समग्र घटक में मूल्य परिवर्तन श्रोता की तरह कोई विधि अभिव्यक्ति होती है।

सैद्धांतिक रूप से, इस समस्या को मोजररा को दृश्य स्थिति को संदर्भित करने के बजाय सत्र में दृश्य स्थिति को क्रमबद्ध करने के लिए कहा जा सकता है। चूंकि आवृत्ति परिवर्तनीय को transient चिह्नित किया गया है, तो इसे छोड़ दिया जाएगा। फिर

<context-param> 
    <param-name>com.sun.faces.serializeServerState</param-name> 
    <param-value>true</param-value> 
</context-param> 

, सैद्धांतिक रूप से, आप निम्न संदर्भ पैरामीटर द्वारा प्राप्त कर सकते हैं कि web.xml में मैंने इसका परीक्षण नहीं किया।

आप इसके बजाय माईफैस को भी आजमा सकते हैं, मैं यह नहीं कह सकता कि यह ठीक करेगा, लेकिन मुझे पता है कि माईफेस 2.x राज्य प्रबंधन, स्मृति उपयोग और प्रदर्शन के रूप में मोजररा से आम तौर पर अधिक सावधान है।

इस बीच, मैं दृढ़ता से मोजरा के लिए एक नया मुद्दा बनाने की सिफारिश करता हूं, 1 9 40 के मुद्दे का संदर्भ देता हूं, यह स्टैक ओवरफ़्लो प्रश्न और आपके निष्कर्ष। दृश्य स्थिति में यूआई घटकों का संदर्भ देना निश्चित रूप से सही नहीं है। यूआई घटक उदाहरण निहित रूप से अनुरोध किया जाता है, स्कॉप्ड नहीं देखते हैं।

---

अद्यतन: issue 3198 जो Mojarra 2.2.8 में तय हो गई है के रूप में और प्रति issue 3544 Mojarra 2.1.29 में बैकपोर्टेड के रूप में इस फिर से सूचना मिली थी। इसलिए, यदि आप कम से कम उन संस्करणों में अपग्रेड करते हैं, तो जब आप com.sun.faces.serializeServerState=true (या javax.faces.SERIALIZE_SERVER_STATE=true जेएसएफ 2.2 के अनुसार) का उपयोग नहीं करते हैं तो यह स्मृति रिसाव तय किया जाना चाहिए।

Answer 2

हमारे पास actionListener के साथ एक समग्र-तत्व के साथ एक समान समस्या थी। कंपोजिट-एलिमेंट ने DataObjects एकत्र किया, हालांकि उन्हें कचरा होना चाहिए। हमने पाया कि सूची को पुनः लोड करने से पहले list.clear() इस मेमोरी रिसाव से बचने में मदद करता है।

Answer 3

यह शायद मोज़रारा पर https://java.net/jira/browse/JAVASERVERFACES-3544 द्वारा तय किया गया है।