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

          Activity

          Hide
          Adnan Durrani added a comment -

          Test case attached

          Show
          Adnan Durrani added a comment - Test case attached
          Hide
          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.
          Hide
          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.
          Hide
          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
          Hide
          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.
          Hide
          Deryk Sinotte added a comment -

          Re-opening and re-assigning.

          Show
          Deryk Sinotte added a comment - Re-opening and re-assigning.
          Hide
          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.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: