How to fluch Livesite 2.2.1 cache

Hi,
I have this weird problem.
My env:
TS 6.5
Livesite 2.2.1

The issue is whenever I deploy a livesite site the cache is not getting refreshed and the changes do not reflect.
I tried manually Invalidating the runtime cache using the menu option Livesite->Invalidate Runtime Cache, but that did not help either.
if I restart my IPlanet instance the cahe does get refreshed and changes are reflected well.

Earlier In livesite 2.0 I used to invoke a URL to fluch the cache manually which is no longer available now I think.

http://www.site.com/com.interwoven.livesite.flush-data

is there anything similar available?

thx.

Find more posts tagged with

Comments

tec_iwov

the methods you are using should work, can you check in your $IW_HOME/tmp
directory. there will be logfiles for your deployment task. see if there are any errors, also look at $IW_HOME/local/logs/iwui/servletd.* for errors from invalidate cache. Another thought is when you upgraded to 2.2.1 did your wft files get upgraded plus the livesite od configuration file? These file drastically changed in the 2.2.1 release also the OD deployment descriptor (livesite.xml) has an additional filelist that needs to be deployed, it should have an additional filelist section:
[HTML]

filePath="$cachefilelist^">

[/HTML]

mindy1

this didnt help either..
all the cacche files are getting generated properly in the tmp directory..
what should be their location once deployed to receiver?

tec_iwov

they get deployed to the sites dir.

they get consumed and deleted on successful processing.

you can crank up the logging for

com.interwoven.livesite.enduser.cache.InvalidatePoller
and
com.interwoven.livesite.enduser.cache.CacheManager

and see if it's processing anything.

kailash1

The issue was resolved by doing the following steps.

1. copying the livesite.xml from livsite-home/opendeplo and the updating it.

2. The external script for deployment was wrong and wd updated it from livesite-home/teamsite/local/config/wft/solutions

3. They had used the soft links on tagret. So made changes to deployment configs as follows:

1. Allowing Traversal of Target Links in File List Deployments

A target OpenDeploy server running on a UNIX host may be configured to allow traversal of target-side symbolic links. To use this feature, the listenerProperites element’s

allowTargetFollowLinks attribute in the recipient OpenDeploy server’s base server or receiver configuration file must have a value of yes, for example:

[HTML]
[/HTML]

By default, the allowTargetFollowLinks attribute value is no. If this value is set to no, or if the allowTargetFollowLinks attribute is missing from the server configuration, then

you cannot use this feature.

Note: This feature allows a deployment to bypass the allowed directories check. Therefore, use of this feature is discouraged. Refer to “Configuring File List Deployments for Traversal of Target-Side Links” on page 119 in the OpenDeploy Administration Guide for more information.

2. Configuring File List Deployments for Traversal of Target-Side Links

File list deployments to targets running on UNIX hosts can include symbolic links in the file list entries. For example, the file list entries might include the following:

[indent] dev/website/files/www/index.html

dev/website/files/www/andre/index.html

symlink1/products.html
[/indent]

where symlink1 is a symbolic link on the target host that points to another location. To

instruct OpenDeploy to follow a target-side symbolic link, the following configurations

must be made:

 The listenerProperites element’s allowTargetFollowLinks attribute in the recipient OpenDeploy server’s base server or receiver configuration file must have a value of yes, for example:

[HTML][/HTML]

Refer to “Allowing Traversal of Target Links in File List Deployments” on page 123 in the OpenDeploy Installation Guide for more information.

 The filelist element’s targetFollowLinks attribute in the deployment configuration must have a value of yes, for example:

[HTML][/HTML]

If an item in the file list is destined for a directory that is a symbolic link, such as products.html in the example file list above, this setting will instruct OpenDeploy to traverse the link on the target and deploy the item into the directory pointed to by the link. If the target directory is deployed, such as symlink1 in the example file list above, the link is overwritten on the target host. Therefore, if the goal is to deploy a new symbolic link, then the source directory must be a symbolic link and the followLinks attribute must not be set in the sourceTransferRules element. This feature allows a deployment to bypass the allowed directories check. Therefore, use of this feature is discouraged. As an alternative, consider setting the targetFilesystem element's area attribute to the symbolic link rather than the directory in the file list.

For example, rather than area="/website" and file list containing symlink1/ product.html, have area="/website/symlink1" and file list containing product.html. This will enable deployment into a target pointed to by a symbolic link and retain the allowed directories check. See “Configuring OpenDeploy when Target Area Is a Symbolic Link” on page 98 for more information.

3. Configuring OpenDeploy when Target Area Is a Symbolic Link

If the target file location is a symbolic link on a UNIX host, the actual location of the received files must also be listed as an allowed directory in the receiving OpenDeploy

server’s base server or receiver configuration file. For example, if the configured target file location is the following:

[HTML][/HTML]

where symlink1 points to the directory /alt/files, then both locations must be listed as allowed directories. Additionally, if the allowed directory is a parent of the target area, then it and the directory pointed to need to be in the allowed directories list. For example, if the target area is /website/files/images and the allowed directory is /website/files, this would

normally pass the allowed directory test. However, if /website/files is a symbolic link that points to /alt, then /alt must also be in the allowed directories list.