RtpsUdpInst does not use ConfigStore
#4162
Conversation
jrw972
force-pushed
the
transport-inst-refactoring
branch
from
adcb957
to
46f9254
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
10 times, most recently
from
9aa8321
to
77adcef
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
from
77adcef
to
56c2390
Compare
|
Safety profile issues caused by DOCGroup/ACE_TAO#2080 |
jrw972
force-pushed
the
transport-inst-refactoring
branch
from
56c2390
to
7d58c1f
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
3 times, most recently
from
519fcfb
to
42054e5
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
5 times, most recently
from
aa07818
to
4658d47
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
from
4658d47
to
1037da1
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
8 times, most recently
from
ba9c1da
to
f08732e
Compare
dds/DCPS/Time_Helper.inl
Outdated
| return to_dds_string(duration.sec) + '.' + left_pad(to_dds_string(duration.nanosec), '0', 9); | ||
| } | ||
|
|
||
| ACE_INLINE OpenDDS_Dcps_Export | ||
| bool from_dds_string(const String& str, DDS::Duration_t& duration) | ||
| { | ||
| if (str == "DDS::INFINITE_DURATION") { |
There was a problem hiding this comment.
I like the idea, but this isn't a constant that exists anywhere as far as I know, so does it have to be phrased like this? Even if it was, could it just be something shorter like infinity, inf, or forever?
There was a problem hiding this comment.
The JSON spec puts forth DURATION_INFINITY. Do you think that's an acceptable option?
There was a problem hiding this comment.
Yes, I think it's alright.
|
|
||
| store1.set("PREFIX1_key", "value"); | ||
| EXPECT_TRUE(take_has_prefix(reader, "PREFIX1")); | ||
| EXPECT_FALSE(take_has_prefix(reader, "PREFIX1")); |
There was a problem hiding this comment.
This isn't really related to this code, but reading it made me think of it. Does the config store warn if a value wasn't used? If not, would it be possible? There's different things grabbing things from the key store, so I assume that could be tracked as bool on ConfigPair and at some point you'd know if something was used or not. If someone misunderstood how to make a key value or mistyped one, which could happen to a user or one of us, then it seems like it would be good for some sort of feedback.
There was a problem hiding this comment.
Good question. The InternalDataReader keeps the view state and sample state. So, if everything accesses the config through the same reader, then those states would reflect if a value was accessed or not. Writing the function to do the scan would be easy. The challenge would be when to invoke it.
jrw972
force-pushed
the
transport-inst-refactoring
branch
2 times, most recently
from
3e9f3ca
to
58b8253
Compare
jrw972
force-pushed
the
transport-inst-refactoring
branch
from
58b8253
to
373ba19
Compare
Problem ------- `RtpsUdpInst` does not use `ConfigStore`. See OpenDDS#4134. Solution -------- Convert `RtpsUdpInst` to use `ConfigStore`. * Member access has been replaced with getters and setters. * Dynamic configuration related to the RtpsRelay is handled via a listener. * The `RtpsUdpCore` caches dynamic configuration values and values that are used frequently. Notes ----- This fixes a bug in `ConfigStoreImpl` where the last valid value was returned instead of the provided default in the event of an error.
jrw972
force-pushed
the
transport-inst-refactoring
branch
from
373ba19
to
790c948
Compare
Problem
RtpsUdpInstdoes not useConfigStore. See #4134.Solution
Convert
RtpsUdpInstto useConfigStore.Member access has been replaced with getters and setters.
Dynamic configuration related to the RtpsRelay is handled via a listener.
The
RtpsUdpCorecaches dynamic configuration values and values that are used frequently.Notes
This fixes a bug in
ConfigStoreImplwhere the last valid value was returned instead of the provided default in the event of an error.