nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Strange behavior of Livesite Runtime Cache???

SE123

Hi,

I have noticed some strange behaviour with Livesite Runtime Cache while using different cache options of a component:

I have a component which makes an external call (i.e. using <external>) to java to get dynamic data for it.

Scenario 1: If I set cache time to "1 minute"

I can see on the console that java is being invoked after every 1 minute regardless the number of hits made to that page,which is fine.
But if I make the changes in the component and resubmit the page after taking the latest component, the changes do not reflect until I explicitly submit the cache.**** file to invalidate cache.
Similarly, my page should render the output as per the parameter passed in the query string ,but lets say ,if I get a certain output for parameter ?q=1, I am getting the same output even when I give parameter as ?q=2 and make the hit with 1 minute time frame.( which I think should not happen as it should cache the output for each instance of query string)

Scenario 2: If I set the cache time to "untill publish"

I am facing the same problem with this option as well, that until I publish the cache.**** files, my changes do not reflect regardless I republish the page again and again. Here I found the strange thing that after republishing the page also external java doesn’t get invoked until I publish cache.**** file explicitly.

Scenario 3: If I set the cache time "No Cache"

Using this option I see that java is being invoked at every hit of page but as mentioned in point 1, if I make any changes in the component and republish the page ,the changes will get reflected only when I publish cache.**** file
In this option my dynamic functionality i.e. based on query string works fine as for each hit java is being invoked.

Please let me know is this the normal behavior of Livesite or I am missing something?

Find more posts tagged with

Comments

SE123

Could some one please suggest is this the expected behavior??

Migrateduser

It wouldn't be what I would expect, but I haven't found anything in the documentation that would say one thing or the other.

That said, I was diving through some of the example code today, and, at least in the example, the http query string which was driving the OGNL query string via the LscsClient is retrieved from the RequestContext by the external. If that's the usual model, it seems like the only options would be to cache globally (which sounds like what you are seeing), or to cache for every unique RequestContext (which would basically turn the LSDS cache into a copy of the browser cache). So, I won't be overly surprised if you find out that is the expectation. If you are able to get an answer, please let us know - I'm going to be facing that exact scenario for real in a very short time.

AlexC

What version of TeamSite and Livesite and post your cache.ccf file please.

SE123

What version of TeamSite and Livesite and post your cache.ccf file please.

I Am using Teamsite 6.7.1 and Livesite 3.0, regarding cache file it is normal txt file with name cache.456(say) where we provide the path of page starting from "/sites/dummy/en/test.page" to invalidate the cache of page.

Frederik

Similarly, my page should render the output as per the parameter passed in the query string ,but lets say ,if I get a certain output for parameter ?q=1, I am getting the same output even when I give parameter as ?q=2 and make the hit with 1 minute time frame.( which I think should not happen as it should cache the output for each instance of query string

we've used LiveSite 2.2.1 and the cache was respecting the query string params. I believe the REQUIREMENT for that was to define the params also in the component XML. The component cache will ignore querystring params that aren't defined.

AlexC

I Am using Teamsite 6.7.1 and Livesite 3.0, regarding cache file it is normal txt file with name cache.456(say) where we provide the path of page starting from "/sites/dummy/en/test.page" to invalidate the cache of page.

cache.ccf is the cache configuration file usually in WEB-INF/classes directory, it may be helpful to see if there is something there that may be an issue, but if you have not registered the query string paremeters of the components, then that could be the issue.

Migrateduser

Hey Alex -

At the risk of asking a stupid question - is there any documentation that deals with the cache in 7.1? None of the four documents available for download discuss it at all.

AlexC

The livesite cache is mostly transparent, component cache is still the same it was in the past, you set the expiration time and it will re-execute the component when that expiry occurs. There was an anomaly with TS672SP2patch1 that behaved oddly with the internal cache and there is a patch for it.

SE123

cache.ccf is the cache configuration file usually in WEB-INF/classes directory, it may be helpful to see if there is something there that may be an issue, but if you have not registered the query string paremeters of the components, then that could be the issue.

I understood the concept of parametrized cache in Livesite when I have registered query string parameters but I still don't understand that caching is saving a server hit for an external call (i.e. Java) is fine, but let's say I have given the cache time to 1 minute or until published, my component changes which I had made in XSLT should also reflect after 1 min or when I republish the page respectively which is not happening currently until I publish the cache.**** file.

Attached is the cache.ccf file which you had requested, I don't understand much in this file. Is there any documentation available to know more about this file?

Migrateduser

I found a little information about the cache that I had previously overlooked. On page 315 of the SitePublisher Developer's Guide, v.7.0, there is a brief set of bullets regarding tuning the cache. It doesn't really get into the parameterization of the cache, however.

AlexC

Are you changing component caching parameters on the actual component in page editor or to the base component in component editor? (i.e. where are you in vpath when you make this change, are you editing your site or are you in the iwconfig branch)?

Components by themselves do not reflect themselves on the pages where they are used until you do "Get Latest" on the actual page to get the latest component properties.

SE123

Are you changing component caching parameters on the actual component in page editor or to the base component in component editor? (i.e. where are you in vpath when you make this change, are you editing your site or are you in the iwconfig branch)?

Components by themselves do not reflect themselves on the pages where they are used until you do "Get Latest" on the actual page to get the latest component properties.

I am changing the component on component editor and I have also taken the latest component on page.
I can see my changes on preview but once I publish the page my changes are not getting reflected on runtime until I publish the cache.123 file.

Frederik

@SE123 : why are you talking about publishing the cache invalidation file (cache.###) explicitly. I thought this file is created and deployed completely transparently by the LiveSite WF (it's even not documented, as far as I know). Did you re-engineer the workflow?

AFAIK, the whole LiveSite cache entirely depends on this cache-invalidation-file to tell the runtime to invalidate the cache for that Page (especially in the case of "until publish" cache option.)

SE123

@SE123 : why are you talking about publishing the cache invalidation file (cache.###) explicitly. I thought this file is created and deployed completely transparently by the LiveSite WF (it's even not documented, as far as I know). Did you re-engineer the workflow?

AFAIK, the whole LiveSite cache entirely depends on this cache-invalidation-file to tell the runtime to invalidate the cache for that Page (especially in the case of "until publish" cache option.)

No Frederik, in our WF it is not created automatically we need to explicitly publish the file by entering the page name into it(explicitly). Yes, we have used customized workflow. Could you please tell me which workflow we should use to perform these actions automatically.

AlexC

Livesite out of the box creates the cache invalidation file during deployment, if you are using a custom workflow that requires a manual cache invalidation file then that is the problem. The workflow will need to be fixed or manual deployment will always be required.

vpatel

No Frederik, in our WF it is not created automatically we need to explicitly publish the file by entering the page name into it(explicitly). Yes, we have used customized workflow. Could you please tell me which workflow we should use to perform these actions automatically.

OOTB LS PLC WF does this for you automatically. If you have a custom WF then you have to create the cache.**** file and deploy it to the target location.

preview.pdf

SE123

OOTB LS PLC WF does this for you automatically. If you have a custom WF then you have to create the cache.**** file and deploy it to the target location.

I understood the problem, but can I use PLC in WFT as well because I didn't find the WFT for PLC I got the IPM file for that.
In case, I can't use PLC in WFT then I should create the cache.**** file and publish.

vpatel

I understood the problem, but can I use PLC in WFT as well because I didn't find the WFT for PLC I got the IPM file for that.
In case, I can't use PLC in WFT then I should create the cache.**** file and publish.

PLC WF is only provided as a WFM and NOT WFT. You may find ways to re-use the entire WF or parts of it via WFT -- but there is nothing OOTB for that.

What is the reason for WFT over WFM for this WF?

fabreece

The livesite cache is mostly transparent, component cache is still the same it was in the past, you set the expiration time and it will re-execute the component when that expiry occurs. There was an anomaly with TS672SP2patch1 that behaved oddly with the internal cache and there is a patch for it.

Hello, could you point me out what exactly the problem is with this patch1? Our livesite cache behaves quite strangely and we have that version installed. Where can I find information about the resolution patch you are talking about?

thanks

AlexC

If you contact support they should have the patch or you can upgrade to the latest 6.7.2 version.

Migrateduser

Hi,
were you able to solve the caching issue and did content started rendering based on query string correctly?

I am too facing problem http://devnet.interwoven.com/forums_vb/showthread.php?t=40044&forumid=66

Please guide if issue is solved.

Thanks
Manu G

Bowker

another thread for this issue was created.