1. 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.
  2. 18 Dec, 2013 1 commit
    • Steven Murray's avatar
      Added the following write call to the API of the CASTOR logging system, the · 17500645
      Steven Murray authored
      idea being you might simply want to log a message with no parameters.
         * Writes a message into the CASTOR logging system. Note that no exception
         * will ever be thrown in case of failure. Failures will actually be
         * silently ignored in order to not impact the processing.
         * Note that this version of writeMsg() implicitly uses the current time as
         * the time stamp of the message.
         * @param priority the priority of the message as defined by the syslog API.
         * @param msg the message.
        virtual void writeMsg(
          const int priority,
          const std::string &msg) throw() = 0;
  3. 16 Dec, 2013 2 commits
  4. 12 Dec, 2013 4 commits
    • Steven Murray's avatar
      Attempt to fix a compilation bug surrounding the uninitialized local variable... · a924aa28
      Steven Murray authored
      Attempt to fix a compilation bug surrounding the uninitialized local variable named len of the method castor::log::Log::writeMsg
    • Steven Murray's avatar
      After discussions with Eric I have removed the singleton pattern from the · d5717e3e
      Steven Murray authored
      implementation of the proposal for a new CASTOR logging system API.
      The new API provides a Log class which contains a mutex that mirrors the
      previous locking strategy of Sebastien and Denis.  My additional singleton mutex
      and functionality should not be in the logging API.  Giuseppe and Sebastien
      should decide how the logging API is exposed to subclasses of CASTOR classes
      such as Server and Daemon.  The loggin API should concentrate on logging.
      By the way, instantiating two Log objects is not actually a problem, they will
      simply have separate connections to syslog, that's all.
    • Steven Murray's avatar
      After discussion with Giuseppe I have added two improvements that he has · a32794c0
      Steven Murray authored
      kindly suggested.
      Firstly the instance() method assumes that destroyInstance() is not called
      concurrently with it so it can assume that in a multi-threaded scenario there is
      a single transition from s_instance being NULL to s_instance pointing to a newly
      created Log object.  This means the following mutex-less if statement can be at
      the beginning of the instance() method to increase performance:
        if(NULL != s_instance) {
          return *s_instance;
      Secondly the destructor of the Log class should be private in order to prevent
      clients from being able to directly delete the Log singleton.
    • Steven Murray's avatar
      I have changed the design of the proposed new CASTOR logging API, from a C like · 2a48875a
      Steven Murray authored
      collection of functions within a castor::log namespace to a more object
      oriented Singleton pattern.  Pleae note that the code is still far from
      finished, I am commit (compiling) code early in an attempt to increase feedback.
  5. 09 Dec, 2013 2 commits
  6. 04 Dec, 2013 3 commits
  7. 03 Dec, 2013 2 commits
  8. 02 Dec, 2013 2 commits
    • Steven Murray's avatar
      In an attempt not to re-ivent the wheel I have added the following three · 9effe700
      Steven Murray authored
      static (hidden) methods to the castor/log/Log.cpp file:
      These three methods are copies of the dlf_openlog(), dlf_closelog() and
      dlf_syslog() functions defined in the file CASTOR/dlf/dlf_lib.c.  I have
      renamed the associated static global variables using the "s_" naming convention.
      Please note that this commit does not finish the implementation of the new
      logging API (I here a groan from the back).  Again I'm looking for feedback
      (again another groan from the back).
    • Steven Murray's avatar
      First attempt at the replacment for the current DLF logging API. · 9aa97861
      Steven Murray authored
      This commit provides an empty implementation.  It's goal it to agree upon the
      API which is basically a cut down rip-off of the orginal DLF API.
      Isn't DLF already dead? I here you cry, well in line with good CASTOR tradition
      I reply both yes and no.  The server side of the Distributed Logging Facility,
      effectionately known as the Denis Logging Facility, has been gone for a while.
      However both the C and C++ APIs have remained, with the code implementing them
      simply sending CASTOR logs to rsyslog.
  9. 06 Jun, 2012 1 commit
  10. 09 Aug, 2011 1 commit
  11. 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.
  12. 24 Jun, 2011 1 commit
  13. 13 May, 2011 1 commit
  14. 12 May, 2004 1 commit