ICEfaces
  1. ICEfaces
  2. ICE-11452

ace:dynamicResource, multiple instances on the same page serve the same resource

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.3.0.GA_P06
    • Fix Version/s: EE-3.3.0.GA_P07
    • Component/s: ACE-Components
    • Labels:
      None
    • Environment:
      Any

      Description

      When there are two or more instances of ace:dynamicResource (each meant to serve a different resource) all of them end up serving the same resource, which is the resource specified in the last ace:dynamicResource instance on the page.

      When the attribute `attachment` is set to true, this is not an issue, and all instances serve their intended resources. However, this component should work as expected with `attachment` set to false, as well.

        Activity

        Arturo Zambrano created issue -
        Arturo Zambrano made changes -
        Field Original Value New Value
        Assignee Arturo Zambrano [ artzambrano ]
        Arturo Zambrano made changes -
        Fix Version/s EE-3.3.0.GA_P07 [ 13118 ]
        Hide
        Arturo Zambrano added a comment -

        r52897: added a distinct hash code to the calculation of the random string used as resource name, in order to ensure that these strings are distinct between other ace:dynamicResource instances on the same page

        Show
        Arturo Zambrano added a comment - r52897: added a distinct hash code to the calculation of the random string used as resource name, in order to ensure that these strings are distinct between other ace:dynamicResource instances on the same page
        Arturo Zambrano made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Judy Guglielmin made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee Priority P1 [ 10010 ]
        Security Private [ 10001 ]
        Arturo Zambrano made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Judy Guglielmin made changes -
        Security Private [ 10001 ]
        Hide
        Judy Guglielmin added a comment -

        investigate for memory leak.

        Show
        Judy Guglielmin added a comment - investigate for memory leak.
        Judy Guglielmin made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Hide
        Arturo Zambrano added a comment -

        r53028: modified the hash string used for the resource name and resource URL to ensure that unique URLs are produced for a session, view, component, while avoiding generating multiple, unnecessary copies of the same resource across lifecycles; corrected TLD documentation

        r53029: committed fix to P07 tag

        Show
        Arturo Zambrano added a comment - r53028: modified the hash string used for the resource name and resource URL to ensure that unique URLs are produced for a session, view, component, while avoiding generating multiple, unnecessary copies of the same resource across lifecycles; corrected TLD documentation r53029: committed fix to P07 tag
        Arturo Zambrano made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Arturo Zambrano added a comment - - edited

        The various tests I carried out went according to expectations. Indeed, there was a memory usage issue, but it didn't seem related to garbage collection. The issue was due to the previous strategy to provide a resource name in the ProxyResource implementation within the component. It was causing the creation of a new resource at every lifecycle. This was changed to something that will produce unique resource names/URLs within a session, without producing multiple instances of said resource. After letting enough time pass after a test for the sessions to expire, the memory usage was reduced considerably, which indicates that there's no garbage collection issue.

        Here are some more tips to make the memory usage more efficient when dealing with in-memory dynamic resources:

        • The bean scope must match the scope specified in the component (the default is session scope, if unspecified).
        • If a resource is the same for all users, then put it in an application-scoped bean and specify the application scope in the component, so that there are no multiple copies of the same resource per user.
        • This component is geared towards session-scoped resources, and that's what is recommended to use for more efficient memory usage (if the resources are generated differently per user). For example, for in-memory resources that are in a window-scoped bean, a new instance of them will be loaded into memory for each new window open, even within the same session. This is simply because a new window-scoped bean will be created per window, loading its own set of properties to memory.
        Show
        Arturo Zambrano added a comment - - edited The various tests I carried out went according to expectations. Indeed, there was a memory usage issue, but it didn't seem related to garbage collection. The issue was due to the previous strategy to provide a resource name in the ProxyResource implementation within the component. It was causing the creation of a new resource at every lifecycle. This was changed to something that will produce unique resource names/URLs within a session, without producing multiple instances of said resource. After letting enough time pass after a test for the sessions to expire, the memory usage was reduced considerably, which indicates that there's no garbage collection issue. Here are some more tips to make the memory usage more efficient when dealing with in-memory dynamic resources: The bean scope must match the scope specified in the component (the default is session scope, if unspecified). If a resource is the same for all users, then put it in an application-scoped bean and specify the application scope in the component, so that there are no multiple copies of the same resource per user. This component is geared towards session-scoped resources, and that's what is recommended to use for more efficient memory usage (if the resources are generated differently per user). For example, for in-memory resources that are in a window-scoped bean, a new instance of them will be loaded into memory for each new window open, even within the same session. This is simply because a new window-scoped bean will be created per window, loading its own set of properties to memory.
        Hide
        Markus Guenther added a comment -

        Is this supposed to be corrected in IceFaces 4.3.0
        I assume not because it is still reproducible there.
        The description above doesn't help really how to make this work with IceFaces 4.3.0. Any help would be appreciated.

        It works well if a filename is given (and thus it performs a download). But if no filename is given, it uses always the last resource of the last ace:dynamicResource on the page if there are multiple ones.

        Show
        Markus Guenther added a comment - Is this supposed to be corrected in IceFaces 4.3.0 I assume not because it is still reproducible there. The description above doesn't help really how to make this work with IceFaces 4.3.0. Any help would be appreciated. It works well if a filename is given (and thus it performs a download). But if no filename is given, it uses always the last resource of the last ace:dynamicResource on the page if there are multiple ones.
        Hide
        Markus Guenther added a comment -

        Ok, the trick is that one MUST override the getResourceName() method if there is no fileame given. I assume that this is not treated correctly yet in this case.

        @Override
        public String getResourceName()

        { return RandomHelper.randomString(); }

        This makes the Resources again unique.

        Show
        Markus Guenther added a comment - Ok, the trick is that one MUST override the getResourceName() method if there is no fileame given. I assume that this is not treated correctly yet in this case. @Override public String getResourceName() { return RandomHelper.randomString(); } This makes the Resources again unique.
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Arturo Zambrano
            Reporter:
            Arturo Zambrano
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: