Have Workers for the same module use the same ModuleDescription #636
Conversation
The Service system used to guarantee that the address for a module's ModuleDescription would be unique. When we allowed multiple Workers per module that guarantee was broken. We now have the Workers use the ModuleDescription from the module rather than one they hold.
|
+1 Compiled 'core' packages and ran their unit tests. A 'runTheMatrix' should be done. |
|
This pull request is fully signed and it will be integrated in one of the next IBs unless changes or unless it breaks tests. |
ghost
assigned 
|
Hi @Dr15Jones Here you can see a run on top of CMSSW_7_0_X_2013-08-28-0200 with the short matrix tests: And you can see the artifacts of the run here: https://cmssdt.cern.ch/SDT/jenkins-artifacts/pull-request-integration/300 |
Have Workers for the same module use the same ModuleDescription
|
It turns out that there is one more change needed to make FastTimerService happy. The fake EDProducer which makes the TriggerResults is at the moment not getting a 'beginJob' signal since it doesn't needed it. But FastTimerService needs to see all modules at the 'beginJob' transition. So I'll re-connect the unneeded beginJob call to the TriggerResults so the present FastTimerService will be happy. However, one optimization the new framework will do is to only send transition calls if the module actually requests them. I'm in the process of making a new pull request for this. |
Port to 80X the 76X fix about energy fraction methods of Jet class (see PR cms-sw#635)
do not attempt calib for zeropt subjets
The Service system used to guarantee that the address for a module's ModuleDescription would be unique. When we allowed multiple Workers per module that guarantee was broken. We now have the Workers use the ModuleDescription from the module rather than one they hold.
This fixes the problem of the FastTimerService flooding the IB with error messages