java.io.IOException: Error replacing existing cache for repository deleteme.txt. Cache restore aborted.

Atlassian JIRA | Jakub Botwicz | 6 years ago
  1. 0

    The toPageException(Throwable) method in railo.runtime.op.Caster is losing the cause of my IOExceptions for the code in my Cache extension. For instance, when there is an error in the init() method for my cache, I am catching it and rethrowing wrapped in an IOException like so: {code} try { // Init cache here } catch (Throwable e) { throw( new IOException("Error initializing Cache.",e)); } {code} I would expect the error that's reported to the user and output in the logs to be something along these lines: java.io.IOException: Error initializing Cache. at ortus.extension.cache.couchbase.CouchbaseCache.init(Unknown Source) ... Caused by: ACTUAL USEFUL CAUSE ... However, what is actually logged and displayed looks like so: Error initializing Cache. at ortus.extension.cache.couchbase.CouchbaseCache.init(Unknown Source) ... From that, it is impossible to tell what actually happened. It appears that many places in Railo's source (CachePut.java is one example), a checked exception is rethrown like so: {code} try { // Do something } catch (Exception e) { throw Caster.toPageException(e); } {code} I don't understand everything in the toPageException() method, but if the incoming Throwable is not of type PageException, PageExceptionBox, InvocationTargetException, ExceptionInInitializerError, or ExecutionException, a new NativeException is created which is stripping off the useful cause from my exception and the top-level exception is all that makes it to the user and into the logs. Interestingly enough, the following code is there but commented out: {code} //Throwable cause = t.getCause(); //if(cause!=null && cause!=t) return toPageException(cause); {code} Is there a reason the current behavior loses the cause, or is it just an oversight? The expectation is that when I throw an exception that is created with a cause, the cause will be in tact when my Exception is presented to the user/application error/handling.

    JIRA | 1 year ago | Brad Wood
    java.io.IOException: Error initializing Cache.
  2. Speed up your debug routine!

    Automated exception search integrated into your IDE

  3. 0

    Error during apply orbit file - Problem Reports - STEP Forum

    esa.int | 8 months ago
    java.io.IOException: No memory left for cache!
  4. 0

    dcm4chee-arc-light no memory left in cache error

    Google Groups | 6 months ago | Matt
    java.io.IOException: No memory left for cache!

    Not finding the right solution?
    Take a tour to get the most out of Samebug.

    Tired of useless tips?

    Automated exception search integrated into your IDE

    Root Cause Analysis

    1. java.io.IOException

      Error replacing existing cache for repository deleteme.txt. Cache restore aborted.

      at com.atlassian.crucible.migration.item.FishEyeCacheBackup$1.restore()
    2. com.atlassian.crucible
      FishEyeCacheBackup$1.restore
      1. com.atlassian.crucible.migration.item.FishEyeCacheBackup$1.restore(FishEyeCacheBackup.java:185)
      1 frame
    3. com.cenqua.fisheye
      Restore.main
      1. com.cenqua.fisheye.ctl.Restore.run(Restore.java:157)
      2. com.cenqua.fisheye.ctl.Restore.main(Restore.java:212)
      2 frames
    4. Java RT
      Method.invoke
      1. sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      2. sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      3. sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      4. java.lang.reflect.Method.invoke(Method.java:597)
      4 frames
    5. com.cenqua.fisheye
      FishEyeCtl.main
      1. com.cenqua.fisheye.FishEyeCtl.mainImpl(FishEyeCtl.java:113)
      2. com.cenqua.fisheye.FishEyeCtl.main(FishEyeCtl.java:41)
      2 frames