1. 18 Mar, 2015 1 commit
  2. 04 Dec, 2014 2 commits
  3. 03 Jul, 2014 2 commits
  4. 15 May, 2014 1 commit
  5. 14 May, 2014 1 commit
  6. 16 Jan, 2014 1 commit
  7. 15 Jan, 2014 1 commit
  8. 28 Mar, 2013 1 commit
  9. 22 Aug, 2012 1 commit
  10. 17 Aug, 2012 1 commit
  11. 16 Aug, 2012 1 commit
  12. 24 Jul, 2012 1 commit
  13. 27 Feb, 2012 1 commit
  14. 12 Aug, 2011 1 commit
  15. 22 Jul, 2011 1 commit
  16. 18 May, 2011 2 commits
  17. 13 May, 2011 1 commit
  18. 12 May, 2011 1 commit
    • Sebastien Ponce's avatar
      Fixed ownership of converters. They are now completely owned by their... · 34f5905f
      Sebastien Ponce authored
      Fixed ownership of converters. They are now completely owned by their conversion service and a reset of the conversion service will drop any converter it holds. On the way, dependency between services was implemented, where a service can register itself to any other one(s) and a reset call on one of these will trigger a reset of the registered service
      
      34f5905f
  19. 08 Oct, 2010 3 commits
  20. 23 Mar, 2010 1 commit
  21. 09 Nov, 2009 1 commit
  22. 12 Oct, 2009 1 commit
  23. 02 Nov, 2008 2 commits
  24. 30 Oct, 2008 1 commit
  25. 17 Sep, 2008 1 commit
  26. 15 Sep, 2008 1 commit
    • Steven Murray's avatar
      Improved the memory management of the vdqm::handler::TapeDriveHandler class: · 150ff7d5
      Steven Murray authored
      * Added auto pointers (std::autor_ptr and home brew TapeDriveAutoPtr) to the
        method castor::vdqm::handler::TapeDriveHandler::newTapeDriveRequest.
      
      * Modified castor::vdqm::IVdqmSvc::selectCompatibilitiesForDriveModel so that
        it no longer allocates a vector of TapeDriveCompatibility on the heap, but
        directly adds the compatibilities it retrieves to the tape drive in question.
      150ff7d5
  27. 30 Jun, 2008 1 commit
  28. 27 Jun, 2008 2 commits
  29. 24 Jun, 2008 1 commit
  30. 23 Jun, 2008 3 commits
    • Steven Murray's avatar
      Modified castor::vdqm::handler::TapeRequestHandler::deleteTapeRequest to avoid · 0e6b7b24
      Steven Murray authored
      a possible deadlock.
      
      My previous commits stopped a double delete of a tape request by modifying
      castor::vdqm::handler::TapeRequestHandler::deleteTapeRequest so that it took
      a lock on the corresponding tape request.  Simply taking this lock introduces
      the risk of a deadlock.  The tape request may be associated with a drive, and
      if so a lock will be required on both the request and the drive.  Care must be
      taken as locks are to be taken first on a drive and then on its associated tape
      request, otherwise a deadlock may occur.
      
      My modification has been to first get the tape request from its id without
      taking a lock on its row, but taking one on the associated tape drive if there
      is one.  Once I have a lock on the tape drive, I try to take a lock on the
      tape request.
      0e6b7b24
    • Steven Murray's avatar
      VDQM2 now grabs a lock on a tape request before trying to delete it in reponse · 01db0312
      Steven Murray authored
      to a "delete tape request" request.  This is slightly paranoid, but one cannot
      trust that two or more  clients don't try to delete the same request at the
      same time.
      01db0312
    • Steven Murray's avatar
      Changed the following local variable from an auto_ptr to simply an object on · b518793b
      Steven Murray authored
      the stack.  The auto_ptr was completely redundant:
      
          std::auto_ptr<TapeRequest> newTapeReq(new TapeRequest());
      
      is now:
      
          TapeRequest newTapeReq;
      b518793b
  31. 19 Jun, 2008 1 commit