Problems using a RuleCacheProvider

Splash Forums PrettyFaces Users Problems using a RuleCacheProvider

This topic contains 3 replies, has 2 voices, and was last updated by  Christian Kaltepoth 6 years, 2 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
  • #27287



    We’re working on some quite big projects using DeltaSpike and PrettyFaces and today I ran into some problems configuring a so-called “RuleCacheProvider”.
    Actually I was doing some performance-testing and I started some CPU-sampling performing a few thousand page loads.
    The results were quite interesting, as most of the time was spent in com.ocpsoft.pretty.faces.url.QueryString.addParameteres(String) – see attached screenshot.
    So I started to dig into this and found out, that each URL is checked hundred of times over and over again leading to this performance-issue.
    Then I found a place which looked promising: There is a place in org.ocpsoft.rewrite.servlet.impl.DefaultHttpRewriteProvider where Rules are created and the url is checked against. This happens for evey rule that exists, so this explains the multiple checks of the same url.
    Then I found out there is also the possibility to define a “RuleCacheProvider”, so I implemented a very basic Cache and configured the service in META-INF/services, according to the docs.
    But this did not change anything, as the DefaultHttpRewriteProvider seems to just ignore the cached results. This is the code where the cached results should be used:

    RuleCacheProvider provider = ruleCacheProviders.get(i);
    cacheKey = provider.createKey(event, context);
    final List<Rule> list = provider.get(cacheKey);
    if (list != null && !list.isEmpty())
    log.debug(“Using cached ruleset for event [” + event + “] from provider [” + provider + “].”);
    for (int j = 0; j < rules.size(); j++)

    So the cached List<Rule> of name “list” (with 1 result – this is OK, cache works!) is not used in the following loop, instead the “rules” property is used which contains all rules and not just the one in the “list”. Another problem seems to be that, in line 202, the results are not cached if no rules were found (this happens for urls like “/javax.faces.resource/primefaces.js.xhtml?ln=primefaces”, and so on) – so for these the performance will also be quite poor. I think an empty list might also be cached and handled accordingly.

    I guess this is a bug but before filing a JIRA I wanted to ask if this is somewhat a desired behaviour or can I do anything else here?
    Maybe there is another way to optimize performance, which I have not encountered yet?

    Best regards,


    Hey. Thanks for sharing your observations.

    Which version do you use? I’m asking because the latest code looks a bit different from what you posted.





    Thanks for the Hint, but according to my Maven-Setup I’m using 2.0.12.Final, as described here:

    Maybe there’s something wrong with the Nexus-Cache or should I use another version instead?
    EDIT: Ok I see there is the 3.0.0.Alpha10, when do you think a final release will be ready (probably not going to use an alpha-version in production)?

    The code on gitgub seems to be corrected, although I think there is still the case when no rule has been found the cache is not used, potentially leading to this performance-issue.

    Kinds regards,

    • This reply was modified 6 years, 2 months ago by  bernhard.

    I know that the latest version is called “Alpha”. But actually there was only one major change between 2.0.x and 3.0.0 which is that outbound rules are now evaluated in reverse order, which is much more consistent. However, as we thought that people _may_ run into issues because of that, we started to call the latest releases 3.0.0.Alpha.

    So IMO 3.0.0.Alpha10 is actually more stable than 2.0.12.Final, because it contains more bug fixes.

    But I really thin that we should release Rewrite 3.0.0.Final soon.

    @lincoln: Do you agree?

Viewing 4 posts - 1 through 4 (of 4 total)

The forum ‘PrettyFaces Users’ is closed to new topics and replies.

Comments are closed.