JEB Todo List

The list of items to address and implement for the JEB system prior to completion.

1. "Plan A" release to Pole (Late September)
   1. Implementing the same filtering as Plan B.
2. Move JEB/trunk development to new "V2" icetray offline software (mid October)
   1. Make use of new "interfaces" project, include stuff from JEB in interfaces
   2. Reorganize JEB projects somewhat, make dependencies clean
   3. Evaluate performance impacts of v2 goodies
      1. Lazy frame stuff
3. I3Outlet (Nov/Dec?)
   1. cleanup code
   2. use lazy frame stuff
   3. Handle GCD frames as well
      1. Will allow server to make single DB query and distribute to clients
   4. Include in offline once finished?
4. jebserver module performance (Nov/Dec?)
   1. input/output queues to have independent mutexes.
5. PDAQ interfaces (Gent meeting)
   1. Trigger enumerations in daq-decode (persuade DAQ group to never reuse integers!)
6. Status/monitoring
   1. Finalize list of items to check and report to ExpCont? for Operator monitoring.
   2. Collect system monitoring information by using subcomponents, the component control and the remote control. Possible subcomponents are
      1. DAQDispatchReaderService (file name, events and bytes read from file, event rate, byte rate)
      2. I3Outlet (name, #connected queues, #mandatory queues, #missing mandatory queues plus names)
      3. I3InletService (name, status of connection)
      4. JEBEventService (run, subrun and event ID, merging mode, error messages, last flush, last autoflush)
      5. JEBServer (#clients, size, #idle frames, #not client filtered frames)
      6. I3PFFilterModule (filter mode, rate to pot and crop, rates of all filter streams, trigger rate)
      7. I3JEBWriter (file name)
      8. tba (run, subrun and event ID, frame rate, started at, running since)
   3. Reduce full system monitoring information within jebsystem script and report a subset to EC only.
7. Analysis and monitoring clients
   1. Would include online CnV, realtime data analysis clients (TOO, GRB/burst notification, event displays etc)
      1. Anything that need access to all events post reconstruction and filtering
   2. Idea to reuse the jebserver module only this time to post filtered frames.
      1. In std jebserver (could block jebserver from processing based filtering)
      2. Separate post-filtering, separate server
         1. Would pick up files from local disk cache from PFRaw hardlink directory.
8. Persistency needed?
   1. Likely depends on frequency and causes of crashes
   2. Dispatches? Or just read entire file and if a few seconds of data is lost at crash time, C'est la vie.
   3. JEB server system: Dump all frame contents to disk at "crash" time, and reload at startup?
9. Modes of operation
   1. Filtering modes: PhysicsFiltering?, RandomFiltering?, NoFiltAllToTape?, NoFiltAllToSat?
   2. Merging modes: MergeEvents?, I3DAQOnly, TWRDAQOnly, ReadBothNoMerge?
   3. Are these lists complete?
10. Non-standard filtering
    1. Use case: Filtering of calibration-type data
    2. Possible: always run calibration filters in std filtering suite and control filter on/off per run?
    3. Possible: Branch to a second server (talking to second set of Calibration filter clients) based on run type.
11. Watchdog.
    1. Possible: Each component has a built in "no activity" watchdog which kills hanging processes
    2. Possible: Single, central watchdog. Uses control infrastructure to kill/restart hung processes
       1. Serve double duty as central monitoring collection point?
12. Check TWR keys while decoding file/system header
13. Documentation
    1. Better end-user documentation with:
       1. General starting/stopping instructions
       2. Subsystem overview
       3. Troubleshooting information