1. 25 Jun, 2014 1 commit
  2. 21 Jun, 2014 1 commit
    • Steven Murray's avatar
      Moved reactor code from castor::io to castor::tape::reactor · d7790b6f
      Steven Murray authored
      The reactor code is currently being re-implemented using zeromq.  All zeromq
      work needs to be isolated from as much of CASTOR as possible.  For the time
      being this means the reactor code should stay within the scope of tape
      developements where zeromq is being investigated.
  3. 19 Jun, 2014 1 commit
  4. 17 Jun, 2014 1 commit
  5. 26 May, 2014 1 commit
    • Steven Murray's avatar
      Moved runAsStagerSuperuser to daemonizeIfNotRunInForeground() · b2b09a37
      Steven Murray authored
      Before this commit the boolean member Daemon::m_runAsStagerSuperuser was
      being set by calling Daemon::runAsStagerSuperuser() and was used by
      calling Daemon::daemonizeIfNotRunInForeground().  There was no benefit
      gain from this two step approach.  I have therefore effectively moved
      the member variable Daemon::m_runAsStagerSuperuser to be a parameter to
  6. 15 May, 2014 1 commit
  7. 14 May, 2014 1 commit
  8. 29 Apr, 2014 1 commit
  9. 28 Apr, 2014 1 commit
  10. 18 Mar, 2014 8 commits
  11. 18 Feb, 2014 1 commit
    • Steven Murray's avatar
      Replaced Logger::logMsg() by Logger::operator(). · f7ba07e0
      Steven Murray authored
      This modification was made in order to preserve our sanity.  After this
      modification one does not have to type the following statement to log:
          m_logger.logMsg(..... )
      Instead one has to just type:
          m_log(.... )
  12. 15 Feb, 2014 1 commit
    • Steven Murray's avatar
      I have made m_foreground and m_commandLineHasBeenParsed private member variables · 1a8d0371
      Steven Murray authored
      of the following class:
      Subclasses now have a more explicit API for parsing the command-line.  They
      can delegate the task to the above Daemon class or they can implement there own
      parsing logic.  In the latter case the subclass must call the following
      Daemon method:
          castor::server::Daemon::setCommandLineParsed(bool foreground);
      This method makes it clear what the Daemon class needs to know from a parse of
      the command-line.  If a client subclass calls the getForeground() method of the
      Daemon class before callng setCommandLineParsed() then a CommandLineNotParsed
      exception shall be raised.
  13. 14 Feb, 2014 1 commit
  14. 14 Jan, 2014 1 commit
  15. 19 Dec, 2013 2 commits
    • Steven Murray's avatar
      Renamed the Log class to Logger and likewise the LogImplementation to · b09a3af3
      Steven Murray authored
      LoggerImplementation.  This then allowed me to rename the writeMsg()
      suit of functions to logMsg() which is much more clear.
    • Steven Murray's avatar
      The constructor of each C++ CASTOR daemon now takes a reference to Log object · a80c0bf1
      Steven Murray authored
      as a parameter.  The functions that create the CASTOR daemon objects all
      create a castor::log::LogImplementation object and pass it to the constructor
      of their corresponding CASTOR daemon object.  When unit testting, one now has
      the posibility to develop a dummy Log object that implements the interface
      with dummy or mock routines so that the unit tests can run without having to
      write to syslog or rsyslog which is a bit heavy for unit tests.  The
      castor::log::LogImplementation basically contains the logging code centered
      around syslog that was developed by Sebastien and Dennis.
      Please note that I now have to add one or more log functions to the base
      class of the CASTOR daemon objects, namely castor::server::BaseServer.
  16. 15 Aug, 2012 1 commit
  17. 14 Aug, 2012 1 commit
  18. 24 Apr, 2012 1 commit
    • Steven Murray's avatar
      bug #92460: tapebridged should gracefully shutdown a migration tape-session... · 78d241db
      Steven Murray authored
      bug #92460: tapebridged should gracefully shutdown a migration tape-session when tapegatewayd reports a disabled tape
      Refactored the tapebridged daemon and created the following unit-test that
      recreates this bug:
      The refactoring was necessary in order to create the unit-test.  During the
      refactoring I modified the logging of the tapebridged daemon so that the very
      first session error detected is always logged immediately.  This will help
      debug problems in the future if need be.
  19. 10 Feb, 2012 1 commit
  20. 10 Jan, 2012 1 commit
    • Steven Murray's avatar
      bug #90313: RFE: tapebridged should request more files to transfer in bulk · 8aa7b55d
      Steven Murray authored
      The implementation of this RFE is going to take a relatively long period of
      time in that there will be several commits to SVN before it is completed.
      This commit adds some helper classes to the tapebridged source-code base.
      These classes are tested by the unit-tests of the test/unittest directory but
      are not actively used by the tapebridged daemon and so will not effect any
      release that may need to be made of the trunk.
  21. 09 Aug, 2011 1 commit
  22. 01 Aug, 2011 1 commit
    • Steven Murray's avatar
      bug #82673: RFE: Tapebridged and rtcpd should support buffered tape-marks over multiple files · 7aeaa7cc
      Steven Murray authored
      After further reverse engineering rtcpd it became apparent that there should
      only be one configuration parameter to specify which of the following 3 possible
      tape-flush behaviours the tapebridged and rtcpd daemons should follow:
      This commit adds the following tapebridge configuration parameter, which today
      is ignored:
      More importantly and the real reason for this commit is the value of this
      configuration parameter is now passed from the tapebridged daemon to the rtcpd
      daemon via the tapeFlushMode member of the newly updated TAPEBRIDGE_CLIENTINFO2
      typedef struct {
        uint32_t volReqId;
        uint32_t bridgeCallbackPort;
        uint32_t bridgeClientCallbackPort;
        uint32_t clientUID;
        uint32_t clientGID;
        uint32_t tapeFlushMode;
        uint64_t maxBytesBeforeFlush;
        uint64_t maxFilesBeforeFlush;
        char     bridgeHost[CA_MAXHOSTNAMELEN+1];
        char     bridgeClientHost[CA_MAXHOSTNAMELEN+1];
        char     dgn[CA_MAXDGNLEN+1];
        char     drive[CA_MAXUNMLEN+1];
        char     clientName[CA_MAXUSRNAMELEN+1];
      } tapeBridgeClientInfo2MsgBody_t;
      Please note that the TAPEBRIDGE_CLIENTINFO2 has not been released in any version
      of CASTOR and is therefore subject to change until the next release where it
      will be frozen.
  23. 13 Jul, 2011 1 commit
  24. 19 May, 2011 1 commit
  25. 25 Mar, 2010 2 commits
    • Steven Murray's avatar
      Simple code refactoring and improvement of log messages which was triggered by · 6746cd47
      Steven Murray authored
      the fixing of the bug fix:
          bug #50008: Incorrect logging of nsfileid and nshost
    • Steven Murray's avatar
      This commit works towards fixing the following bug: · dbad1f6a
      Steven Murray authored
          bug #50008: Incorrect logging of nsfileid and nshost
      The TapeBridgeDaemon has been refactorised to help test the Dlf client API.
      The tapebridge::LogHelper continues to log nshost and fileid as extra DLF
      parameters because it is responsible for logging the contents of legacy
      messages preserving the contained fields and their order.  To help towards
      fixing bug bug #50008, the tapebridge::LogHelper now passes the fileid and
      nshost as parameters to the appropriate dlf_writep function so that the DLF
      system can efficiently catalogue the logs in question via fileid and nshost.
  26. 25 Feb, 2010 3 commits
  27. 24 Feb, 2010 3 commits