-
Notifications
You must be signed in to change notification settings - Fork 421
Iox #27 add client and server port to runtime, roudi and process manager [stacked PR #3] #1087
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 #27 add client and server port to runtime, roudi and process manager [stacked PR #3] #1087
Conversation
6677cc1
to
c1dbf60
Compare
053fc6e
to
8f923cd
Compare
c1dbf60
to
265ef74
Compare
8f923cd
to
47ae0ec
Compare
265ef74
to
e35218f
Compare
8132bf2
to
81f8259
Compare
e35218f
to
a9ddacd
Compare
81f8259
to
5a5212b
Compare
const popo::ClientOptions& clientOptions, | ||
const PortConfigInfo& portConfigInfo) noexcept | ||
{ | ||
searchForProcessAndThen( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side note which makes me wondering. Shouldn't searchForProcessAndThen
return an cxx::optional
? Then one can write searchForProcess(name).and_then([&](Process & process){ ...
I know it is not the task of this PR but this really bugs me. What do you think, could you make a senior happy by adjusting this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Happy weekend :)
{ | ||
searchForProcessAndThen( | ||
name, | ||
[&](Process& process) { // create a ClientPort |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not know if we had a rule to avoid generic captures? But what do you think about capturing this
, &service
, &serverOptions
and &name
? But I am not insisting only loud thinking.
This goes also for all other lambdas.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think we have the rule to explicitly capture. I think the main reason was the ensure we do not capture more than one or two references. For std::function
the small object optimization should kick in for less than three references but since we now use cxx::reference_wrapper
I'm not sure if this holds anymore. But I think there is an Autosar rule to be explicit with capturing so I will change it anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is legacy code and I already did some cleanup, would you be okay with fixing this when the tools complain and spare some fun for later?
{ | ||
if (message.getNumberOfElements() != 5) | ||
{ | ||
LogError() << "Wrong number of parameters for \"IpcMessageType::CREATE_CLIENT\" from \"" << runtimeName |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be helpful to print the message here for debugging?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no NACK send back over the UDS if any of the parameter checks fails, correct? So if a process would send wrong parameters (only possible when runtime does not match) they would be stuck waiting for a response that doesn't come. Maybe they'll get a timeout then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elfenpiff I feel this is more a topic for a refactoring for all the messages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@budrus @elfenpiff yes, this is a separate topic. We need to refactor this probably after #1133. I would propose to have something like a CmdHandler
class in RouDi which takes care of the actual communication. The ProcessManager
would then just return the port to the CmdHandler
which in turn sends it to the application. This decouples the ProcessManager
from the communication with the client and makes testing easier
std::string IpcMessage2 = receiveBuffer.getElementAtIndex(1U); | ||
if (stringToIpcMessageType(IpcMessage1.c_str()) == IpcMessageType::ERROR) | ||
{ | ||
LogError() << "Request client received no valid client port from RouDi."; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be helpful to print the received message here?
Maybe not when we serialize it later but at the moment it is human readable ...
(Applies to all occurrences)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really. The error is not because of the de-serialization failed but because the response contained the serialized representation of IpcMessageType::ERROR
. The second part of the message is the actual error and will be printed later on.
a9ddacd
to
3c9d622
Compare
5a5212b
to
e964cf2
Compare
3c9d622
to
1a53faa
Compare
41e3fd9
to
af415c1
Compare
9372d15
to
d10b138
Compare
af415c1
to
31d1487
Compare
34bc993
to
3738316
Compare
26e1326
to
4f7cb9c
Compare
3738316
to
2b7e9f4
Compare
4f7cb9c
to
80fecba
Compare
a68ff3e
to
d2c13c1
Compare
b6dea2e
to
cdafb14
Compare
Codecov Report
@@ Coverage Diff @@
## master #1087 +/- ##
==========================================
- Coverage 77.38% 76.33% -1.06%
==========================================
Files 346 346
Lines 13389 13580 +191
Branches 1917 1935 +18
==========================================
+ Hits 10361 10366 +5
- Misses 2396 2584 +188
+ Partials 632 630 -2
Flags with carried forward coverage won't be shown. Click here to find out more.
|
d2c13c1
to
4a550b8
Compare
13b57d3
to
e414830
Compare
reinterpret_cast<popo::ClientPortUser::MemberType_t*>(ptr)); | ||
} | ||
} | ||
else |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it may not be a technically error but it is somehow unclean.
Assume sendRequestToRouDi
fails and returns false but the method changed already parts of the receiveBuffer
. So we have somehow a receiveBuffer
with crap content and go here into the else branch and check if this crap buffer has 2 elements. This could be successful but would somehow mean undefined behavior.
To fix this possible issue, could you please do an early return
if ( sendRequestToRouDi(sendBuffer, receiveBuffer) ) {
// here we require an additional error code we can return when we are unable to send requests to roudi.
}
```
and rework the `if` `else` a bit so that you handle explicitly `numberOfElements` `2U` and `3U`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elfenpiff done with this commit 2a1280d on #1137
PoshRuntimeImpl::requestServerFromRoudi(const IpcMessage& sendBuffer) noexcept | ||
{ | ||
IpcMessage receiveBuffer; | ||
if (sendRequestToRouDi(sendBuffer, receiveBuffer) && (3U == receiveBuffer.getNumberOfElements())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have here the same problem like in requestClientFromRoudi
could you do here an early return as well.
Pre-Review Checklist for the PR Author
iox-#123-this-is-a-branch
)iox-#123 commit text
)git commit -s
)task-list-completed
)Notes for Reviewer
This PR adds the client and server to the
Runtime
,RouDi
andProcessManager
.The changelog will be updated once the feature is finished.
Test will be added in PR #1137
Checklist for the PR Reviewer
Post-review Checklist for the PR Author
References