Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732016-08-18T11:17:59ZOpen Source Collaboration Platform
Redmine Feature #2648 (New): Setters for TimesyncStrategy optionshttps://code.cor-lab.de/issues/26482016-08-18T11:17:59ZM. Goerlichmgoerlic@techfak.uni-bielefeld.de
<p>Currently the strategies can only be configured through boost::po::variables_map s. Filling those by hand is clumsy, direct setters for time frames and buffer sizes at the time frame strategy as well as for the queue size for the approx time strategy would make usage of timesync as library a lot easier.</p> Enhancement #2563 (New): Flush indices based on combined memory consumption of all indiceshttps://code.cor-lab.de/issues/25632016-06-12T13:36:55ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>The current approach of independent flush strategies for all indices is unsuitable for controlling the maximum memory used by indices.</p> Tasks #2233 (In Progress): Wait for confirmation when joining Spread groupshttps://code.cor-lab.de/issues/22332015-04-23T15:44:40ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>When joining a Spread group, the operation cannot be assumed to have completed before the corresponding membership message has been received from the Spread daemon. As a consequence, events that a certain Spread connection must receive, cannot be sent before the connection in question received its membership message.</p>
<p>When this reasoning and our experimental implementation of a suitable waiting logic appear sound, we have to implement that logic for all languages (and create sub-issues).</p> Bug #2163 (New): Remove rsb.wire-schema property from metaData in socket transporthttps://code.cor-lab.de/issues/21632015-01-27T11:33:49ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>While in socket transport, there is a metadata key userInfos:rsb.wire-schema, it is missing in spread transport:</p>
<pre>
example: same event send over socket vs spread:
event *Event[id = *EventId[participantId = UUID[557f285a-0811-43c7-a506-8d05eed7a0c2], sequenceNumber = 0] at 0x7f1de4004e00, type = bytearray, scope = Scope[/], metaData = MetaData[senderId = UUID[557f285a-0811-43c7-a506-8d05eed7a0c2], creationTime = 1422357430672652, sendTime = 1422357430730011, receiveTime = 1422357430767356, deliverTime = 1422357430767369, userTimes = {}, userInfos = {(rsb.wire-schema, int64)}], method = , causes = {}] at 0x7f1de4004c20
event *Event[id = *EventId[participantId = UUID[4dbfdb24-1a1c-4904-a57b-1cfb7a2b4d77], sequenceNumber = 0] at 0x7f1dec002900, type = bytearray, scope = Scope[/], metaData = MetaData[senderId = UUID[4dbfdb24-1a1c-4904-a57b-1cfb7a2b4d77], creationTime = 1422357549316573, sendTime = 1422357549365453, receiveTime = 1422357549420429, deliverTime = 1422357549420432, userTimes = {}, userInfos = {}], method = , causes = {}] at 0x7f1dec004b70
</pre>
<p>How can I robustly access the wireSchema, if I want to lazily deserialize events?</p> Feature #1771 (In Progress): Add META block to TIDELog backendhttps://code.cor-lab.de/issues/17712014-02-14T11:48:57ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deFeature #1770 (In Progress): Add TYPE block to TIDELog backendhttps://code.cor-lab.de/issues/17702014-02-14T11:43:09ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.deEnhancement #1516 (New): Separate Converter selection strategies for sending and receivinghttps://code.cor-lab.de/issues/15162013-05-27T16:31:26ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Both directions differ significantly. This was already the reason why the connector infrastructure is split into two parts.</p>
<p>Also, with this split, we can register different converters for sending and receiving, which would be good, because for receiving having multiple converters is easier when the intended client data type of a handler is know. For sending this creates multiple issues.</p> Enhancement #1515 (New): Add data type to all participants, especially listenershttps://code.cor-lab.de/issues/15152013-05-27T16:29:49ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>This would automatically allows to select the correct converter for deserialization. Also, right now the situation is quite seldom that handlers with different data types can work correctly on a single listeners.</p>
<p>We should still allow the Any Type for dynamic languages and situations.</p> Tasks #885 (New): Specify scope renaminghttps://code.cor-lab.de/issues/8852012-02-16T17:00:59ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
Specify scope renaming and an associated configuration mechanism (see <a href="https://code.cor-lab.de/projects/rsb/wiki/Meetings2012-02-16" class="wiki-page">Meetings2012-02-16</a>):
<ul>
<li>Renaming semantics</li>
<li>Configuration syntax</li>
</ul>
Update:
<ul>
<li><a href="https://code.cor-lab.de/projects/rsb/wiki/Configuration" class="wiki-page">Configuration wiki page</a></li>
<li>New wiki page for scope renaming?</li>
<li>RSB manual (<a href="/projects/rsb/repository/entry/trunk/manual" class="source">source:trunk/manual</a>)</li>
</ul> Enhancement #778 (New): Move Figures to Top-Level Folderhttps://code.cor-lab.de/issues/7782011-12-21T16:20:00ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Figure shall be extracted from individual folders, e.g., specific presentations, in order to allow for inclusion in documentation and to reduce redundancy.</p> Bug #515 (New): Data handlers cannot deal with unexpected typeshttps://code.cor-lab.de/issues/5152011-08-19T21:29:32ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>See also: the first topic of <a href="https://code.cor-lab.de/projects/rsb/wiki/Meetings2011-08-02" class="wiki-page">Meetings2011-08-02</a>.</p>
<a name="Problem-Statement"></a>
<h2 >Problem Statement<a href="#Problem-Statement" class="wiki-anchor">¶</a></h2>
<p>Associated handlers of listeners basically have to expect events with payloads of any type (unless a type filter is installed on the listener). This can be a problem for handler classes like <code>DataHandler</code> or <code>DataFunctionHandler</code> in C++ that can only handle events with certain payload type, because the behavior for events with incompatible payload types has not been specified yet.</p>
Problems of the current implementation (restricted to C++ for clarity here):
<ul>
<li>Clients may get the impression that handlers like <code>DataHandler</code> cause the associated listener to only receive events that have compatible payload types</li>
<li>This is currently not true; Instead, the program will most likely crashes due to an invalid <code>static_pointer_cast</code></li>
</ul>
<a name="Potential-Solutions"></a>
<h2 >Potential Solutions<a href="#Potential-Solutions" class="wiki-anchor">¶</a></h2>
<a name="Signal-Errors-for-Incompatible-Events"></a>
<h3 >Signal Errors for Incompatible Events<a href="#Signal-Errors-for-Incompatible-Events" class="wiki-anchor">¶</a></h3>
<p>Classes like <code>DataHandler</code> could signal an error when encountering incompatible payload types.</p>
Variations include
<ul>
<li>Aborting the program</li>
<li>Displaying an error message but continuing</li>
<li>Configurable behavior</li>
</ul>
<a name="Drop-Incompatible-Events"></a>
<h3 >Drop Incompatible Events<a href="#Drop-Incompatible-Events" class="wiki-anchor">¶</a></h3>
<p><code>DataHandler</code> and friends could check the payload types of events being dispatched to them and simply ignore events with incompatible payload types.</p>
<p>This would lead to inefficient processing if a single listener with multiple handlers for different payload types was used, since the dispatching mechanism would still dispatch all events to all handlers which would then drop unsuitable events only after most of the processing already happened.</p>
<a name="General-Considerations"></a>
<h3 >General Considerations<a href="#General-Considerations" class="wiki-anchor">¶</a></h3>
Both previously mentioned solutions can be implemented in several different ways:
<ul>
<li>Introduce a common base class for <code>DataHandler</code> and friends that implements the chosen behavior (error or drop) in a <code>processable</code> method:
<ul>
<li><code>processable</code> would be called to determine whether an event should be dispatched to a handler</li>
<li>If <code>processable</code> returned <code>true</code>, the event would be dispatched in the usual way by calling <code>handle</code></li>
</ul>
</li>
<li>Integrate feedback from handlers into the dispatch logic
<ul>
<li>Dispatching could display warnings or signal errors if events are dropped because they are not handled by any handler</li>
<li>This could be achieved by adding a return value to <code>handle</code> or the above mentioned <code>processable</code> method
<ul>
<li>The downside of a return value for <code>handle</code> would be potential confusion of clients implementing the <code>Handler</code> interface</li>
</ul>
</li>
</ul>
</li>
<li>It may be necessary for efficiency reasons to communicate information regarding the desired payload types of registered handlers all the way back to the transport layer</li>
</ul> Tasks #392 (In Progress): Multi-Connector Setups lead to duplicate reception of Eventshttps://code.cor-lab.de/issues/3922011-06-24T15:04:24ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>See <a href="https://code.cor-lab.de/projects/rsb/wiki/Inter-Transport_Communication" class="wiki-page">Inter-Transport Communication</a>. The current implementation causes events to arrive at receiving clients twice as shown by the linked example programs.</p>
<p>While no nameservice, introspection or model information is available, the problem could be addressed using a simple tagging scheme:<br /><img src="https://code.cor-lab.de/attachments/download/106/multi-transport-handling.png" title="proposed short-term solution" alt="proposed short-term solution" /></p> Bug #390 (New): Handling of sendTime in Informerhttps://code.cor-lab.de/issues/3902011-06-23T19:27:18ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>An <code>Informer</code> returns an <code>Event</code> to the caller after sending it. This is especially useful if the event is created in the informer on behalf of the calling client. Currently, returned events have their <code>sendTime</code> timestamp set in some way. However, it is not quite clear, how this timestamp should be set. There are (at least) the following possibilities:</p>
<ul>
<li>The informer sets the timestamp before passing the event to connectors for sending</li>
<li>Each connector somehow locks the event and sets the timestamp. The least recent connector "wins" </li>
<li>The connector sets the timestamp only if there is just one connector</li>
<li>The informer sets the timestamp after the event has been processed by all connectors</li>
</ul>
<p>After this has been decided, update</p>
<ul>
<li>UML sequence diagrams</li>
<li><a href="https://code.cor-lab.de/projects/rsb/wiki/EventProcessing" class="wiki-page">EventProcessing</a></li>
<li>Implementations</li>
</ul> Feature #381 (New): Timestamp compatibilty to ROS and YARPhttps://code.cor-lab.de/issues/3812011-06-21T13:47:53ZAnonymous
<p>Right now, default unit of RSB timestamps seems to be microseconds. If they would be given in seconds (same precision of course), timestamp format would be compatible with both ros::Time and yarp::os::Time (both in seconds with six positions after decimal point).<br />Just as an idea to get a similar interface and therefore easier migration in both directions.</p> Bug #344 (New): C++ Spread: Transport-level errors are not handled properlyhttps://code.cor-lab.de/issues/3442011-06-05T15:37:24ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
The ReceiverTask class has (at least) two potential causes of errors
<ul>
<li>Spread errors (currently ignored)</li>
<li>Converter errors (currently not handled, ignored at call site)</li>
</ul>