Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iox #415 remove InvalidIdString and isValid() from ServiceDescription #1047

Conversation

FerdinandSpitzschnueffler
Copy link
Contributor

@FerdinandSpitzschnueffler FerdinandSpitzschnueffler commented Jan 26, 2022

Pre-Review Checklist for the PR Author

  1. Code follows the coding style of CONTRIBUTING.md
  2. Tests follow the best practice for testing
  3. Changelog updated in the unreleased section including API breaking changes
  4. Branch follows the naming format (iox-#123-this-is-a-branch)
  5. Commits messages are according to this guideline
    • Commit messages have the issue ID (iox-#123 commit text)
    • Commit messages are signed (git commit -s)
    • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
  6. Update the PR title
    • Follow the same conventions as for commit messages
    • Link to the relevant issue
  7. Relevant issues are linked
  8. Add sensible notes for the reviewer
  9. All checks have passed (except task-list-completed)
  10. Assign PR to reviewer

Notes for Reviewer

This PR removes InvalidIdString and isValid() from ServiceDescription and replaces the Wildcard string with a nullopt. With this, the ServiceDescription can contain any string, empty strings by default.

Checklist for the PR Reviewer

  • Commits are properly organized and messages are according to the guideline
  • Code according to our coding style and naming conventions
  • Unit tests have been written for new behavior
    • Each unit test case has a unique UUID
  • Public API changes are documented via doxygen
  • Copyright owner are updated in the changed files
  • PR title describes the changes

Post-review Checklist for the PR Author

  1. All open points are addressed and tracked via issues

References

@FerdinandSpitzschnueffler FerdinandSpitzschnueffler added the refactoring Refactor code without adding features label Jan 26, 2022
@codecov
Copy link

codecov bot commented Jan 26, 2022

Codecov Report

Merging #1047 (2d372eb) into master (da830c1) will decrease coverage by 0.00%.
The diff coverage is 50.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1047      +/-   ##
==========================================
- Coverage   77.55%   77.54%   -0.01%     
==========================================
  Files         340      340              
  Lines       12827    12815      -12     
  Branches     1847     1838       -9     
==========================================
- Hits         9948     9938      -10     
- Misses       2260     2263       +3     
+ Partials      619      614       -5     
Flag Coverage Δ
unittests 76.76% <50.00%> (+<0.01%) ⬆️
unittests_timing 12.71% <6.81%> (+0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
...eoryx_hoofs/include/iceoryx_hoofs/cxx/helplets.hpp 88.37% <ø> (ø)
...include/iceoryx_posh/capro/service_description.hpp 100.00% <ø> (ø)
...clude/iceoryx_posh/internal/roudi/port_manager.hpp 100.00% <ø> (ø)
...de/iceoryx_posh/internal/roudi/process_manager.hpp 100.00% <ø> (ø)
...oryx_posh/include/iceoryx_posh/roudi/port_pool.hpp 100.00% <ø> (ø)
...posh/include/iceoryx_posh/runtime/posh_runtime.hpp 100.00% <ø> (ø)
...include/iceoryx_posh/runtime/service_discovery.hpp 0.00% <ø> (ø)
iceoryx_posh/source/roudi/port_manager.cpp 78.38% <0.00%> (+1.19%) ⬆️
iceoryx_posh/source/roudi/process_manager.cpp 57.26% <ø> (ø)
iceoryx_posh/source/roudi/roudi.cpp 57.71% <0.00%> (-0.59%) ⬇️
... and 9 more

@dkroenke dkroenke self-requested a review January 26, 2022 12:38
/// @param[in] searchResult, reference to the vector which will be filled with the results
/// @param[in] service, string or wildcard to search for
/// @param[in] instance, string or wildcard to search for
void find(ServiceDescriptionVector_t& searchResult,
const capro::IdString_t& service = Wildcard,
const capro::IdString_t& instance = Wildcard) const noexcept;
const cxx::variant<cxx::Wildcard_t, capro::IdString_t>& service,
Copy link
Contributor

@mossmaurice mossmaurice Jan 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could think about keeping the default argument Wildcard

Copy link
Contributor

@MatthiasKillat MatthiasKillat Jan 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure this is possible with variant without wrapping it, i.e. constructing a variant with Wildcard. In any case I prefer overloads in theory, i.e. have a call with service, one with instance, one with both and one without arguments. This improves dispatching as well and internally the cases are implemented in a switch statement otherwise anyway.

The reasoning is to prefer early dispatching mechanisms if possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mossmaurice I decided against because it was not used anywhere, not even tested, and as @MatthiasKillat wrote, it's not that easy with a variant.

@@ -41,8 +42,8 @@ class ServiceDiscovery
/// ServiceContainer: on success, container that is filled with all matching instances
/// FindServiceError: if any, encountered during the operation
cxx::expected<ServiceContainer, FindServiceError>
findService(const cxx::variant<Wildcard_t, capro::IdString_t> service,
const cxx::variant<Wildcard_t, capro::IdString_t> instance) noexcept;
findService(const cxx::variant<cxx::Wildcard_t, capro::IdString_t>& service,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because that's part of the user API it should be IMHO in runtime.

Suggested change
findService(const cxx::variant<cxx::Wildcard_t, capro::IdString_t>& service,
findService(const cxx::variant<runtime::Wildcard_t, capro::IdString_t>& service,

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the Wildcard belongs to the same namespace as the ServiceDescription but we may change some of those later, so I am not sure yet and until we know it is not important.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @MatthiasKillat and moved the Wildcard (now a nullopt) to the ServiceDescription, so the namespace is now capro.

Comment on lines -552 to -574
// send find to all interfaces
capro::CaproMessage caproMessage(capro::CaproMessageType::FIND, {service, instance, roudi::Wildcard});

for (auto interfacePortData : m_portPool->getInterfacePortDataList())
{
iox::popo::InterfacePort interfacePort(interfacePortData);
interfacePort.dispatchCaProMessage(caproMessage);
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this part removed?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also do not understand this, but I suspect it has something to do with the FIND message being changed and interface ports not being used properly (in the sense that they will not answer the request anyway).

But that is just a guess and requires clarification. @FerdinandSpitzschnueffler

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After changing the findService parameters, this code had to be adapted since the CaproMessage c'tor requires a ServiceDescription. I discussed several ideas with @elfenpiff, but then we came to the conclusion that the CaproMessage itself could need some refactoring and that we can send the find here but there will be no answer anyway as @MatthiasKillat stated.

iceoryx_posh/source/roudi/service_registry.cpp Outdated Show resolved Hide resolved
iceoryx_posh/source/roudi/service_registry.cpp Outdated Show resolved Hide resolved
Copy link
Contributor

@MatthiasKillat MatthiasKillat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK, minor clarifications needed and I consider the variant interface problematic in the long-term but this PR is not the place to change that.

iceoryx_posh/source/capro/service_description.cpp Outdated Show resolved Hide resolved
iceoryx_posh/source/roudi/roudi.cpp Show resolved Hide resolved
iceoryx_posh/source/roudi/roudi.cpp Show resolved Hide resolved
iceoryx_posh/source/roudi/roudi.cpp Show resolved Hide resolved
iceoryx_posh/source/roudi/service_registry.cpp Outdated Show resolved Hide resolved
iceoryx_posh/source/roudi/service_registry.cpp Outdated Show resolved Hide resolved
{
/// @todo #415 remove the string mapping, once the find call is done via shared memory
capro::IdString_t serviceString;
capro::IdString_t instanceString;
bool isServiceWildcard = false;
bool isInstanceWildcard = false;

if (service.index() == 0U)
Copy link
Contributor

@MatthiasKillat MatthiasKillat Jan 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could maybe also introduce a helper function

bool isWildCard(const cxx::variant< ... >& value) {
return value.index() == 0U;
}

This will be inlined and make the code more expressive.

Comment on lines -552 to -574
// send find to all interfaces
capro::CaproMessage caproMessage(capro::CaproMessageType::FIND, {service, instance, roudi::Wildcard});

for (auto interfacePortData : m_portPool->getInterfacePortDataList())
{
iox::popo::InterfacePort interfacePort(interfacePortData);
interfacePort.dispatchCaProMessage(caproMessage);
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also do not understand this, but I suspect it has something to do with the FIND message being changed and interface ports not being used properly (in the sense that they will not answer the request anyway).

But that is just a guess and requires clarification. @FerdinandSpitzschnueffler

@dkroenke dkroenke removed their request for review January 27, 2022 12:54
@FerdinandSpitzschnueffler FerdinandSpitzschnueffler force-pushed the iox-#415-remove-is-valid-from-service-description branch 2 times, most recently from aae8eae to 4fe9b1d Compare January 28, 2022 13:14
MatthiasKillat
MatthiasKillat previously approved these changes Jan 28, 2022
…istry

Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
Signed-off-by: Marika Lehmann <marika.lehmann@apex.ai>
@FerdinandSpitzschnueffler FerdinandSpitzschnueffler merged commit 58f17f2 into eclipse-iceoryx:master Jan 31, 2022
@FerdinandSpitzschnueffler FerdinandSpitzschnueffler deleted the iox-#415-remove-is-valid-from-service-description branch January 31, 2022 10:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
refactoring Refactor code without adding features
Projects
None yet
Development

Successfully merging this pull request may close these issues.

service registry as a built-in topic
4 participants