Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Oomph » How to manage org.eclipse.oomph.p2/cache?
icon5.gif  How to manage org.eclipse.oomph.p2/cache? [message #1750553] Thu, 22 December 2016 14:18 Go to next message
Andrey Loskutov is currently offline Andrey LoskutovFriend
Messages: 89
Registered: July 2009
Member
I've spent half a day trying to debug Oomph installer which insisted to load not existing features from our internal update site. At the end I've discovered that for whatever reason Oomph/p2 cached and used two weeks old update site.xml copy in ~/.eclipse/org.eclipse.oomph.p2/cache directory. I've even found there files created 3 years ago! OMG why ? Sad

Few questions:
1) How I can enforce p2/Oomph to use the latest greatest update site state if I'm running it from inside debugger?
2) Is there any logical explanation - which criteria are used to decide if to use the cached update site or not?
3) How I can make sure that provisioned IDE does NOT use caches with 2 week old entries for update sites? My plan is to use intranet local update sites to maintain the IDE, and I cannot afford a 2 weeks delays for critical plugin updates. A cache limit of 1 day is the highest value I can accept for that.

Re: How to manage org.eclipse.oomph.p2/cache? [message #1750562 is a reply to message #1750553] Thu, 22 December 2016 16:30 Go to previous message
Ed Merks is currently offline Ed MerksFriend
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/
Previous Topic:Problems with the installed version
Next Topic:Checksum for eclipse installer Mac OS 64b not valid
Goto Forum:
  


Current Time: Sat Dec 14 13:43:22 GMT 2024

Powered by FUDForum. Page generated in 0.02633 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top