Robotics Service Bus: Issueshttps://code.cor-lab.de/https://code.cor-lab.de/favicon.ico?14019720732015-02-17T11:52:54ZOpen Source Collaboration Platform
Redmine Bug #2183 (New): Compilation of RSB Tools fails on MacOS 10.10https://code.cor-lab.de/issues/21832015-02-17T11:52:54ZS. Wredeswrede@cor-lab.uni-bielefeld.de
<p>Applies for rsb 0.10 and 0.11. Boost version is 1.57.</p>
<pre>
[ 90%] Building CXX object test/timesync/CMakeFiles/rsbtimesynctest.dir/rsb/tools/timesync/rsbtimesynctest.cpp.o
cd /tmp/rsb-tools-cpp-IQpiod/test/timesync && /usr/bin/clang++ -DRSB_PROTOCOL_EXPORT="" -Os -w -pipe -march=native -mmacosx-version-min=10.10 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.10 -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0 -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/gtest/include -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/gtest -I/tmp/rsb-tools-cpp-IQpiod/src/timesync -I/tmp/rsb-tools-cpp-IQpiod/test/timesync -I/usr/local/include -I/usr/local/share/rsc0.11/../../include/rsc0.11 -I/usr/local/share/rsb0.11/../../include/rsb0.11 -pipe -Wall -Wextra -fdiagnostics-show-option -o CMakeFiles/rsbtimesynctest.dir/rsb/tools/timesync/rsbtimesynctest.cpp.o -c /tmp/rsb-tools-cpp-IQpiod/test/timesync/rsb/tools/timesync/rsbtimesynctest.cpp
In file included from /tmp/rsb-tools-cpp-IQpiod/test/timesync/rsb/tools/timesync/rsbtimesynctest.cpp:22:
In file included from /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/gmock.h:58:
In file included from /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/gmock-actions.h:46:
In file included from /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-internal-utils.h:45:
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:72:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:72:40: error: expected expression
struct MatcherTuple< ::std::tr1::tuple<> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:77:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:77:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:76:20: note: declared here
template <typename A1>
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:82:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:82:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:81:20: note: declared here
template <typename A1, typename A2>
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:87:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:87:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:86:20: note: declared here
template <typename A1, typename A2, typename A3>
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:92:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:92:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:91:20: note: declared here
template <typename A1, typename A2, typename A3, typename A4>
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:98:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:98:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:97:20: note: declared here
template <typename A1, typename A2, typename A3, typename A4, typename A5>
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:105:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:105:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:103:20: note: declared here
template <typename A1, typename A2, typename A3, typename A4, typename A5,
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:112:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:112:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:110:20: note: declared here
template <typename A1, typename A2, typename A3, typename A4, typename A5,
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:119:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8> > {
~~~~~~~^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:119:40: error: 'A1' does not refer to a value
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8> > {
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:117:20: note: declared here
template <typename A1, typename A2, typename A3, typename A4, typename A5,
^
/tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include/gmock/internal/gmock-generated-internal-utils.h:126:29: error: no member named 'tr1' in namespace 'std'
struct MatcherTuple< ::std::tr1::tuple<A1, A2, A3, A4, A5, A6, A7, A8, A9> > {
~~~~~~~^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
/usr/local/Cellar/cmake/3.1.2/bin/cmake -E cmake_progress_report /tmp/rsb-tools-cpp-IQpiod/CMakeFiles 15
[ 93%] Building CXX object src/logger/CMakeFiles/logger.dir/rsb/tools/logger/StatisticsEventFormatter.cpp.o
cd /tmp/rsb-tools-cpp-IQpiod/src/logger && /usr/bin/clang++ -DRSB_PROTOCOL_EXPORT="" -Os -w -pipe -march=native -mmacosx-version-min=10.10 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.10 -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/include -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0 -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/gtest/include -isystem /tmp/rsb-tools-cpp-IQpiod/gmock-1.7.0/gtest -I/usr/local/include -I/usr/local/share/rsc0.11/../../include/rsc0.11 -I/usr/local/share/rsb0.11/../../include/rsb0.11 -pipe -Wall -Wextra -fdiagnostics-show-option -o CMakeFiles/logger.dir/rsb/tools/logger/StatisticsEventFormatter.cpp.o -c /tmp/rsb-tools-cpp-IQpiod/src/logger/rsb/tools/logger/StatisticsEventFormatter.cpp
20 errors generated.
make[2]: *** [test/timesync/CMakeFiles/rsbtimesynctest.dir/rsb/tools/timesync/rsbtimesynctest.cpp.o] Error 1
make[1]: *** [test/timesync/CMakeFiles/rsbtimesynctest.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
</pre>
<p>Brew config:</p>
<pre>
HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/Homebrew/homebrew
HEAD: 526e145b20c1ea96f557cd1336871c242716ef32
Last commit: 81 minutes ago
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: quad-core 64-bit haswell
OS X: 10.10.2-x86_64
Xcode: 6.1.1
CLT: 6.1.1.0.1.1416017670
Clang: 6.0 build 600
X11: 2.7.7 => /opt/X11
System Ruby: 2.0.0-p481
Perl: /usr/bin/perl
Python: /usr/local/bin/python => /usr/local/Cellar/python/2.7.9/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/bin/ruby
Java: 1.7.0_21
</pre> Bug #2167 (New): Check that RemoteServer instances delete EventId instances in case of RPC timeoutshttps://code.cor-lab.de/issues/21672015-02-04T16:08:22ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>I have observed that EventId instances are collected in a java process in case frequent RPC calls time out. This might be due to the association of responses with requests.</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> Bug #2150 (New): Specification of preferred converters should be reconsideredhttps://code.cor-lab.de/issues/21502015-01-04T08:53:22ZR. Haschkerhaschke@techfak.uni-bielefeld.de
<p>From my point of view, the specification of preferred converters may be conceptually at the wrong level (currently at the level of transports).</p>
<p>Considering Listeners, they should receive the same data type, irrespective of the used transport. If there are several converters for a specific wire-schema, a preference needs to be given at the level of the Participant.<br />Considering Informers, there might be different wire-schemas to be used for different connectors. Hence, here the configuration at the transport level is sensible.</p>
<p>Hence, there is a need to handle in and out connectors differently!</p>
<p>Also, there should be an application-wide (default) converter preference, which should be used as args to rsb::converter::Repository::getConvertersForDeserialization and getConvertersForSerialization instead of the undecided default. The mentioned methods are used all over the framework and will fail if ambiguous converters are registered.</p>
<p>This application-wide default should be initialized from the rsc config system before the plugin system can register converters. This will allow meta converters (that use other converters to extract stuff, e.g. EventsByScopeMapConverter) to be correctly registered when ambiguous converters already exist. Otherwise success depends on load order!</p> Bug #2117 (New): Listener state changes are not synchronized, informer one's arehttps://code.cor-lab.de/issues/21172014-11-28T16:05:02ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>There is a mismatch in threading safety between Listener and Informer in java wrt the activation / deactivation. This needs to be unified.</p> Bug #1914 (New): Reader does not work with multi-connector setuphttps://code.cor-lab.de/issues/19142014-07-04T11:44:13ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Originally reported from Timo Korthals on the mailing list:</p>
<blockquote>
<p>wie gestern angekündigt, will ich nun ein seltsames Verhalten des<br />"readers" mitteilen:<br />Situation:<br />1x Informer<br />1x Reader</p>
<p>Wenn der Reader sowohl auf inprocess, als auch auf socket hört, empfängt<br />er keine socket-Nachrichten vom Informer. rsb.conf:<br />[transport.inprocess]<br />enabled = 1<br />[transport.socket]<br />enabled = 1<br />host = localhost<br />server = auto<br />port = 55555</p>
<p>Wenn der Reader nur auf socket hört, dann empfängt er auch Nachrichten<br />vom Informer. rsb.conf:<br />[transport.inprocess]<br />enabled = 0<br />[transport.socket]<br />enabled = 1<br />host = localhost<br />server = auto<br />port = 55555</p>
</blockquote> Bug #1665 (New): Support common installations (to simlify cross compiliation)https://code.cor-lab.de/issues/16652013-12-03T10:46:15ZS. Herbrechtsmeiersherbrec@cit-ec.uni-bielefeld.de
<p>The current rsb projects contains many functions which are only needed for the local deployment. As most of this functions are not optional they don't allow a common installation and make the installation unusable in cross compiler environments. The main reason is that cmake and pkg-config files are not relocatable because they contain full paths from the installation or build time.</p>
<p>In common installation the following should not be needed: <br />- Add the release version to project and library names (example: rsb0.9 in rst-converters0.9.pc)<br />- Decode the so version in pkg-config files (example: librsb.so.0.9 in rsb.pc)<br />- Use so files instead of <del>l{libname} in pkg-config files (example: ${libdir}/librsb.so.0.9 in rsb.pc)<br /></del> Set full paths in cmake files (example: RSC_DIR in RSBConfig.cmake)</p>
<p>Additionally cmake files should save the dependency projects and use FIND_PACKAGE to detect the paths.</p> Bug #1642 (New): pkg-config test fails in integration testhttps://code.cor-lab.de/issues/16422013-10-03T22:23:22ZJ. Moringenjmoringe@cor-lab.uni-bielefeld.de
<p>See e.g. <a class="external" href="https://ci.cor-lab.org/view/rsb-trunk/job/rsb-cpp-trunk/label=ubuntu_precise_64bit/1196/consoleFull">https://ci.cor-lab.org/view/rsb-trunk/job/rsb-cpp-trunk/label=ubuntu_precise_64bit/1196/consoleFull</a></p> Bug #1620 (New): Configurator can't check if connector is activehttps://code.cor-lab.de/issues/16202013-09-09T17:00:48ZAnonymous
<p>The InRouteConfiguration can't check if a connector is active and therefore might deactivate an already inactive connector, which leads to an error.</p>
<p>Connectors should therefore make their activation state public and provide a consistent handling of their activation state.</p> Bug #1441 (New): Better handling of dependencies without pc file, e. g. boost, in our pkgconfighttps://code.cor-lab.de/issues/14412013-02-27T10:02:26ZAnonymous
<p>Boost for example doesn't provide a pkg-config file (<a class="external" href="https://svn.boost.org/trac/boost/ticket/1094">https://svn.boost.org/trac/boost/ticket/1094</a>). So in order to provide a working pkgconfig for rsb, we need to insert boost include pathes and libs directly into our pc file (see <a href="https://code.cor-lab.de/issues/1439" class="issue tracker-1 status-3 priority-5 priority-high3 closed" title="pkgconfig is anvalid (Resolved)">#1439</a>). However, this doesn't work with cross-compiling (see <a href="https://code.cor-lab.de/issues/1292" class="issue tracker-1 status-4 priority-4 priority-default" title="Do not set EXTERNAL_INCLUDE_COMMANDS in rsc/rst.pc.in by default (Feedback)">#1292</a>), so we need to find a better solution.</p> Bug #1410 (New): Python socket transport swallows missing converter errors silently so that clien...https://code.cor-lab.de/issues/14102013-02-13T13:01:45ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>The current implementation of the socket transport only defines the following error hook on the connection:<br /><pre>
connection.errorHook = lambda exception: self.removeConnection(connection)
</pre><br />This doesn't notify clients in any error case, nor does it print a warning message (without specifically configured logging) or crashes the program.</p>
This is the warning code:<br /><pre>
self.__logger.warn('Receive error: %s', e)
</pre><br />At least:
<ul>
<li>use a more serious warning level</li>
<li>use a method signature that prints a complete exception stacktrace</li>
</ul> 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> 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> 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> Bug #52 (New): State model/checking for modifications on InRouteConfigurators requiredhttps://code.cor-lab.de/issues/522010-08-19T12:03:33ZJ. Wienkejwienke@techfak.uni-bielefeld.de
<p>Right now subscriptions on the router are passed to the port even if both are not activated. For the spread port this e.g. results on a call on the uninitialized connection right now and would need complex caching.</p>