ICEfaces
  1. ICEfaces
  2. ICE-4861

graphicImage: Memory leak with byte[] type

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Critical Critical
          • Resolution: Fixed
          • Affects Version/s: 1.8.1
          • Fix Version/s: 1.8.2-RC1, 1.8.2
          • Component/s: Framework, ICE-Components
          • Labels:
            None
          • Environment:
            byte[] type

            Description

            Memory leak with byte[] type

              Issue Links

              blocks

              Bug - A problem which impairs or prevents the functions of the product. ICE-7311 Working with Icefaces 1.8.2 plugin for netbeans, ice:graphicImage in ice:panelSeries tag cannot correctly display byte image

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Adnan Durrani created issue -
                Hide
                Permalink
                Adnan Durrani added a comment -

                Test case attached

                Show
                Adnan Durrani added a comment - Test case attached
                Adnan Durrani made changes -
                Field Original Value New Value
                Attachment ICE-4861.war [ 11937 ]
                Adnan Durrani made changes -
                Assignee Ken Fyten [ ken.fyten ]
                Hide
                Permalink
                Adnan Durrani added a comment -

                One of the customer noticed a memory leak with graphicImage component when using byte[]. I used JProfiler to see it. I was able to see that on each image load the byte[] array was getting doubled. The old images were not garbage collecting.

                Each file has different size, that is why bean creates a new byte array for each image, and that new byte array reference being used by the component for every new image . Seems like each reference is being held permanently.

                Then I used the ByteArrayResource with graphic image, and did see the same behaviour. FYI: The byte[] also using the ByteArrayResource internally. Mark mentioned that resource API might keeping those references.

                Show
                Adnan Durrani added a comment - One of the customer noticed a memory leak with graphicImage component when using byte[]. I used JProfiler to see it. I was able to see that on each image load the byte[] array was getting doubled. The old images were not garbage collecting. Each file has different size, that is why bean creates a new byte array for each image, and that new byte array reference being used by the component for every new image . Seems like each reference is being held permanently. Then I used the ByteArrayResource with graphic image, and did see the same behaviour. FYI: The byte[] also using the ByteArrayResource internally. Mark mentioned that resource API might keeping those references.
                Ken Fyten made changes -
                Salesforce Case []
                Fix Version/s 1.8.2 [ 10190 ]
                Assignee Priority P1
                Assignee Ken Fyten [ ken.fyten ] Mircea Toma [ mircea.toma ]
                Priority Major [ 3 ] Critical [ 2 ]
                Hide
                Permalink
                Mircea Toma added a comment -

                Yes, the dynamic resource implementation is keeping the registered resources until the session is expired.
                I believe the solution to this issue would be to create a specific Resource implementation for graphicImage component. The resource would be registered only once by the component (not the renderer). The resource digest could be derived from the clientID and the InputStream should be created dynamically (every time is requested) from the byte array.

                Show
                Mircea Toma added a comment - Yes, the dynamic resource implementation is keeping the registered resources until the session is expired. I believe the solution to this issue would be to create a specific Resource implementation for graphicImage component. The resource would be registered only once by the component (not the renderer). The resource digest could be derived from the clientID and the InputStream should be created dynamically (every time is requested) from the byte array.
                Mircea Toma made changes -
                Assignee Mircea Toma [ mircea.toma ] Adnan Durrani [ adnan.durrani ]
                Repository Revision Date User Message
                ICEsoft Public SVN Repository #19198 Fri Aug 28 08:53:17 MDT 2009 adnan.durrani Fix for ICE-4861 (Memory leak with ByteArrayResource)
                Custom resource added for byte[] type, which being registered once by the component itself.
                Files Changed
                Commit graph MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/ext/renderkit/ImageRenderer.java
                Commit graph MODIFY /icefaces/trunk/icefaces/component/src/com/icesoft/faces/component/ext/HtmlGraphicImage.java
                Adnan Durrani made changes -
                Status Open [ 1 ] In Progress [ 3 ]
                Hide
                Permalink
                Adnan Durrani added a comment -

                As per Mircea suggestion a custom resource added for byte[] type, which being registered once by the component itself.

                Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java
                Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\renderkit\ImageRenderer.java
                Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\renderkit\ImageRenderer.java
                Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java
                Completed: At revision: 19198

                Show
                Adnan Durrani added a comment - As per Mircea suggestion a custom resource added for byte[] type, which being registered once by the component itself. Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java Modified: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\renderkit\ImageRenderer.java Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\renderkit\ImageRenderer.java Sending content: D:\work\development\head\svn\ossrepo\icefaces\trunk\icefaces\component\src\com\icesoft\faces\component\ext\HtmlGraphicImage.java Completed: At revision: 19198
                Adnan Durrani made changes -
                Status In Progress [ 3 ] Resolved [ 5 ]
                Resolution Fixed [ 1 ]
                Adnan Durrani made changes -
                Summary Memory leak with ByteArrayResource graphicImage: Memory leak with byte[] type
                Salesforce Case []
                Adnan Durrani made changes -
                Environment ByteArrayResource byte[] type
                Salesforce Case []
                Description Memory leak with ByteArrayResource Memory leak with byte[] type
                Hide
                Permalink
                Deryk Sinotte added a comment -

                There was already a case for this behaviour so I am linking the current custom issue to it. We are seeing what is potentially the problem but we are still evaluating the specifics and how to fix.

                Show
                Deryk Sinotte added a comment - There was already a case for this behaviour so I am linking the current custom issue to it. We are seeing what is potentially the problem but we are still evaluating the specifics and how to fix.
                Deryk Sinotte made changes -
                Salesforce Case [5007000000A48GU]
                Hide
                Permalink
                Deryk Sinotte added a comment -

                Re-opening and re-assigning.

                Show
                Deryk Sinotte added a comment - Re-opening and re-assigning.
                Deryk Sinotte made changes -
                Resolution Fixed [ 1 ]
                Status Resolved [ 5 ] Reopened [ 4 ]
                Assignee Adnan Durrani [ adnan.durrani ] Deryk Sinotte [ deryk.sinotte ]
                Hide
                Permalink
                Deryk Sinotte added a comment -

                After checking out the latest component code and compiling - which picked up the latest fix for this issue - my testing indicates the problem has been resolved. There is no longer an endless list of resources stored in the ResourceDispatcher's collection.

                Show
                Deryk Sinotte added a comment - After checking out the latest component code and compiling - which picked up the latest fix for this issue - my testing indicates the problem has been resolved. There is no longer an endless list of resources stored in the ResourceDispatcher's collection.
                Deryk Sinotte made changes -
                Status Reopened [ 4 ] Resolved [ 5 ]
                Resolution Fixed [ 1 ]
                Ken Fyten made changes -
                Fix Version/s 1.8.2-RC1 [ 10210 ]
                Ken Fyten made changes -
                Status Resolved [ 5 ] Closed [ 6 ]
                Assignee Priority P1
                Melany Landa made changes -
                Link This issue blocks ICE-7311 [ ICE-7311 ]

                  People

                  • Assignee:
                    Deryk Sinotte
                    Reporter:
                    Adnan Durrani
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    2 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: