1. 23 Aug, 2016 1 commit
  2. 16 Jul, 2015 2 commits
  3. 15 Jul, 2015 2 commits
  4. 03 Jul, 2014 2 commits
  5. 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.
  6. 15 May, 2014 1 commit
  7. 04 Apr, 2014 1 commit
  8. 03 Apr, 2014 1 commit
    • Steven Murray's avatar
      PollEventHandler::handleEvent() now returns bool · 1d9cb1ad
      Steven Murray authored
      PollReactorImpl objects own their handlers and therefore need to delete
      them where appropriate.  A handler knows when it should be removed from
      its reactor and deleted from the heap.  The
      PollEventHandler::handleEvent() method a handler now returns true if the
      handler wants its reactor to remove and delete it.
  9. 05 Mar, 2014 1 commit
  10. 19 Jul, 2013 1 commit
  11. 09 Aug, 2011 1 commit
  12. 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.
  13. 24 Jun, 2011 1 commit
  14. 13 May, 2011 1 commit
  15. 12 May, 2004 1 commit