|
| Re: How to manage org.eclipse.oomph.p2/cache? [message #1750562 is a reply to message #1750553] |
Thu, 22 December 2016 16:30  |
 Ed Merks
Messages: 33264
Registered: July 2009 |
Senior Member |
|
|
Note that the timestamp you see on the cache file is the timestamp of the file on the server. Also the file will only be downloaded again only if the server indicates that the file has a new timestamp. It may well be that there a sites with metadata that hasn't changed in years.
1) You can delete the Oomph's cache (~/.eclipse/org.eclipse.oomph.p2/cache); I see 6 year old files in mine but my machine is only been used for several months. Note that p2 also keeps a cache in <agent-location>/org.eclipse.equinox.p2.repository/cache but that caches fewer things (and you can't tell from the names where they came from); I also find 4 year old files in this cache. So if you want to be sure you download all new metadata, you must clear both.
2) First p2 does a HEAD request to determine the timestamp. If the modification stamp of the cache file is different from the timestamp from the server, the file is downloaded. Otherwise, the cache is considered current. Both p2 and Oomph use this same mechanism. If you believe such a problem occurs again, you can inspect how org.eclipse.oomph.p2.internal.core.CachingTransport.delegateGetLastModified(URI, IProgressMonitor) handles the problematic URI. It's pretty straight forward:
private long delegateGetLastModified(URI uri, IProgressMonitor monitor) throws CoreException, FileNotFoundException, AuthenticationFailedException
{
long lastModified = delegate.getLastModified(uri, monitor);
File cacheFile = getCacheFile(uri);
if (cacheFile.length() == 0)
{
return lastModified - 1;
}
if (cacheFile.lastModified() != lastModified || lastModified == 0)
{
synchronized (getLock(uri))
{
cacheFile.delete();
}
return lastModified - 1;
}
return lastModified;
}
3) I think you're mistaking the modification stamp on the cache file as indicating that the cache is necessarily stale. More likely you're seeing a problem with a server that's returning bogus timestamps. I know there was a bug with servers that serve no timestamp at all, but that case the timestamp is 0 and any cache files with that timestamp are downloaded each time.
Note also that if people don't properly manage the versions of IUs, i.e., if they produce a new IU with exactly the same version as an old one but with different contents, you will likely end up with the one from the pool being used.
We know of no general problem with respect to cache file consistency, so more likely there is a problem with the server's timestamp as reported via a HEAD request. Of course I assume you haven't enabled Offline mode on the Confirmation page.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Powered by
FUDForum. Page generated in 0.02633 seconds
] 
Search
Help
Register
Login
Home
