Project

General

Profile

Necessary Maintenance #1014

some parameter sets in the ServicesManager do not have service_type defined

Added by Jim Kowalkowski almost 9 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
Infrastructure
Target version:
Start date:
02/25/2011
Due date:
09/30/2013
% Done:

100%

Estimated time:
2.00 h
Spent time:
Scope:
Internal
Experiment:
-
SSI Package:
Duration: 949

Description

The ServicesManager holds a list of parameter sets, one parameter set per service that can be present in the system. Each parameter set is the configuration for a service, which is identified in each parameter set by a string parameter named "service_type". The value of this parameter is the name of the class that implements the service.

Some of the entries in the parameter set list do not have the service_type defined. Someone needs to investigate this issue to see if this what is really intended and how they are introduced. It is possible that these are some of the fixed services that are not available through the plugin mechanism.

Dump of service_types from a standard configuration:

service name = Reconfigurable
service name = TFileService
service name = none
service name = SimpleMemoryCheck
service name = none
service name = none
service name = none
service name = Timing
service name = Tracer

Here is the information from the fcl configuration file for this job:

scheduler:
  {
wantSummary: true
wantTracer: true
}
floating_point_control: { }
Timing: { }
SimpleMemoryCheck: { }
TFileService: { fileName: "tfile_output.root" }
user:
   {
Reconfigurable: { other_value:5 }
}

It just so happens that there are four manually added services in the EventProcessor:

serviceToken_.add(std::auto_ptr<CurrentModule>(new CurrentModule(*actReg_)));
// special construction
serviceToken_.add(std::auto_ptr<CPR>(new CPR(preg_)));
serviceToken_.add(std::auto_ptr<TNS>(new TNS(pset)));
serviceToken_.add(std::auto_ptr<FloatingPointControl>(new FloatingPointControl(fpc_pset,*actReg_)));

These manually added services are the ones without the "service_type".
It is likely that we will want to hide these (not make them available for reconfiguration) or add the service_type so that they look like the rest.


Related issues

Related to art - Bug #6801: Possible failure of config_dumper to dump services configuration.Closed08/14/2014

History

#1 Updated by Walter E Brown about 8 years ago

  • Status changed from New to Accepted

Needs investigation to determine whether solution is still necessary.

#2 Updated by Christopher Green over 6 years ago

  • Due date set to 09/30/2013
  • Category set to Infrastructure
  • Target version set to 1.09.00
  • Estimated time set to 24.00 h
  • Scope set to Internal
  • Experiment - added
  • SSI Package art added

Analysis may be necessary to ensure that the obvious solution (make sure service_type is defined for all services) does not have unintended consequences respecting the use of the ServiceRegistry for e.g. automatic service construction and destruction.

#3 Updated by Marc Paterno over 6 years ago

  • Tracker changed from Bug to Nova Simulation Problem

#4 Updated by Christopher Green over 6 years ago

  • Estimated time changed from 24.00 h to 2.00 h

Fixing the problem of missing service_type should be trivially fixable by passing a string representing the name of the service via ServiceToken::add() to the overload set member ServiceCacheEntry(WrapperBase_ptr premade_service, ...) and in the body of said constructor, inserting the value of the provided string into the stored parameter set config_.

#5 Updated by Christopher Green over 6 years ago

  • Tracker changed from Nova Simulation Problem to Necessary Maintenance

#6 Updated by Christopher Green about 6 years ago

  • Target version changed from 1.09.00 to 521

#7 Updated by Christopher Green almost 6 years ago

  • Target version changed from 521 to 1.10.00

#8 Updated by Christopher Green almost 6 years ago

  • Target version changed from 1.10.00 to 1.14.00

#9 Updated by Christopher Green almost 6 years ago

  • Target version changed from 1.14.00 to 1.13.00

#10 Updated by Christopher Green over 5 years ago

  • Assignee set to Christopher Green
  • Target version changed from 1.13.00 to 1.11.00
  • % Done changed from 0 to 100

Resolved as part of the fix for issue #6801.

#11 Updated by Christopher Green over 5 years ago

  • Status changed from Accepted to Resolved

#12 Updated by Christopher Green over 5 years ago

  • Status changed from Resolved to Closed


Also available in: Atom PDF