Move service discovery to objectsmanager and some clean up (QC-193, QC-189)#184
Conversation
|
The application is not blocked anymore, but I can see "[30270]: bind: Address already in use" in the logs. |
|
@knopers8 Are you sure it is linked to the Service Discovery ? Do you have something running on port 7777 ? (I think that it is the default) |
|
I have checked, nothing is running on that port. |
|
I am pretty sure it is connected somehow to Service Discovery. When it was getting stuck before, it was always stuck in that place. |
|
Should I merge nevertheless ? the test failure is unrelated. |
|
I can take a look at it today. |
|
It improves the situation, so I am fine with merging this. |
Framework/src/ObjectsManager.cxx
Outdated
| mMonitorObjects.SetOwner(true); | ||
|
|
||
| // register with the discovery service | ||
| mServiceDiscovery = std::make_unique<ServiceDiscovery>("http://consul-test.cern.ch:8500", mTaskName); |
There was a problem hiding this comment.
Maybe it's better to move the URL to config file?
There was a problem hiding this comment.
yes, let me do that
|
We duplicate monitoring and consul url in all json files. We should see how to do it better. For now it will do. |
Barthelemy
changed the title
|
Sure but when I just run |
|
@awegrzyn I think that it would be better to work with the test because it excludes the DPL. |
|
@awegrzyn To run the test do It hangs (even after your commit). |
awegrzyn
force-pushed
the
fix-service-discovery
branch
from
dc06ed4 to
1a4111a
Compare
|
@awegrzyn works well! Thank you |
|
Ok, but we need to verify whether it works well in the real scenario. |
|
Yes, but the plan is to merge , then release, then let you play with it. |
Barthelemy
changed the title
3 participants
No description provided.