1. 30 Oct, 2014 2 commits
  2. 29 Oct, 2014 2 commits
  3. 28 Oct, 2014 2 commits
  4. 24 Oct, 2014 4 commits
  5. 22 Oct, 2014 2 commits
  6. 20 Oct, 2014 3 commits
  7. 17 Oct, 2014 3 commits
    • Eric Cano's avatar
      CASTOR-4801: Failed recall mount of tapeserverd is not propagated to disk IO threads · 82f9fcbc
      Eric Cano authored
      Created a new unit test to try and reproduce the problem seen here. It did not.
      The best explanation we have is a stuck file client. As we totally fail to read data
      from the tape, it makes no sense to open a file for which we have no data. So we deferred
      the file opening when the first memory block arrives from the tape thread. The outputs of the
      unit test showed that the file opening has been successfully deferred.
      82f9fcbc
    • Eric Cano's avatar
      CASTOR-4751: tapeserverd does not report drive as empty and does not finish... · 2f97f2af
      Eric Cano authored
      CASTOR-4751: tapeserverd does not report drive as empty and does not finish client session if user does not have migration access-rights
      
      The error situation was already generating an exception, which went all the way to the caller
      of the data transfer session. It is now intercepted and the client is notified synchronously.
      The session now ends successfully (the drive was not touched).
      2f97f2af
    • Eric Cano's avatar
      CASTOR-4800: failed migration mount of tapeserverd is not propagted to disk IO threads · 3e668815
      Eric Cano authored
      We had a session ending mechanism for the tape and disk tasks in migrations, but it did not cover all the aspects of the tape thread (like in this ticket, mounting). In this case the disk thread was happily reading the data from disk, which the tape thread was putting to the bin.
      
      The signalling mechanism, attached to the task injector has now been passed to tape write thread itself, which signals the error condition when receiving any exception. If this came from a task as before, this is a no-op, but if we had a problem mounting, then the session will and immediately and disk threads will stop reading (also immediately).
      3e668815
  8. 16 Oct, 2014 4 commits
  9. 15 Oct, 2014 5 commits
  10. 13 Oct, 2014 4 commits
  11. 12 Oct, 2014 4 commits
    • Eric Cano's avatar
    • Eric Cano's avatar
      CASTOR-4739: tapeserverd should support localfile, rfio, xroot and rados... · e1d444b1
      Eric Cano authored
      CASTOR-4739: tapeserverd should support localfile, rfio, xroot and rados striper access for disk files
      
      Moved the call to getConfEntString(XROOT, PrivateKey, /opt/xrootd/keys/key.pem one step up to allow
      unit testing in environments without a castor.conf
      e1d444b1
    • Eric Cano's avatar
      CASTOR-4739: tapeserverd should support localfile, rfio, xroot and rados... · 9d1f9f2b
      Eric Cano authored
      CASTOR-4739: tapeserverd should support localfile, rfio, xroot and rados striper access for disk files
      
      Removed all OpenSSL support from tapeserverd as we opted for CryptoPP. This restores the passing of
      memory leaks and race conditions detection.
      9d1f9f2b
    • Eric Cano's avatar
      CASTOR-4739: tapeserverd should support localfile, rfio, xroot and rados... · 623e11df
      Eric Cano authored
      CASTOR-4739: tapeserverd should support localfile, rfio, xroot and rados striper access for disk files
      
      After testing Xroot access, realised that we need to add a signature in the opaque data of the
      Xroot URL. A signature using OpenSSL, as used in other places of the project was implemented,
      but did not pass the memory leak and race condition tests. As discussed with the rest of the team,
      OpenSSL is not to be trusted and has poor quality memory managment. The CryptoPP library, also part
      of the SLC6 distribution has been tested as well, and it output validated (on a few example) with
      OpenSSL's. CryptoPP can be used instead of OpenSSL, and has been put in place. This commit still contains
      the OpenSSL for reference. The next commit will remove it.
      623e11df
  12. 09 Oct, 2014 1 commit
  13. 08 Oct, 2014 3 commits
  14. 07 Oct, 2014 1 commit