Independent of the protocol specification all integer fields in the
result table are signed. For instance, if I store a kernel IP (e.g.
0xf1....) the value in the database is 0x7fffffff because of the wrong
type.
Therefore, the data fields of the result table should have the same
types as specified in the protocol.
Change-Id: I9154251e4ad67ba70fe86155ebda378c4a9982c2
This change fixes the Protobuf->MySQL bridge for strings, which were
corrupted in rare cases, especially with debug builds of the
DatabaseCampaign. String columns in result tables from any campaign
up to this point may contain corrupted data.
The core reason for the corruption was that the TypeBridge_string
bound a temporary (a nameless local variable) to the prepared
statement. This temporary is destroyed before the subsequent call to
mysql_stmt_bind_param(), and the string within can only be referenced
successfully if it has not been overwritten yet. The solution is to
copy the string to a bridge-internal variable.
Although it might seem that TypeBridge_enum has the same problem, the
protobuf library seems to return references to internal string
constants when retrieving the enum values.
Change-Id: Id127e6b3333d7c304d688e45de9bea44bbc610b0
According to
<http://dev.mysql.com/doc/refman/5.5/en/c-api-threaded-clients.html>,
a MySQL connection handle must not be used concurrently with an open
result set and mysql_use_result() in one thread
(DatabaseCampaign::run()), and mysql_query() in another
(DatabaseCampaign::collect_result_thread()). This indeed leads to
crashes when bounding the outgoing job queue (SERVER_OUT_QUEUE_SIZE),
and maybe even more insidous effects in other cases. The solution is
to create separate connections for both threads.
Additionally, call mysql_library_init() before spawning any threads.
Change-Id: I2981f2fdc67c9a2cbe8781f1a21654418f621aeb
The DatabaseCampaign interacts with the MySQL tables that are created
by the import-trace and prune-trace tools. It does offer all
unfinished experiment pilots from the database to the
fail-clients. Those clients send back a (by the experiment) defined
protobuf message as a result. The custom protobuf message does have to
need the form:
import "DatabaseCampaignMessage.proto";
message ExperimentMsg {
required DatabaseCampaignMessage fsppilot = 1;
repeated group Result = 2 {
// custom fields
required int32 bitoffset = 1;
optional int32 result = 2;
}
}
The DatabaseCampaignMessage is the pilot identifier from the
database. For each of the repeated result entries a row in a table is
allocated. The structure of this table is constructed (by protobuf
reflection) from the description of the message. Each field in the
Result group becomes a column in the result table. For the given
example it would be:
CREATE TABLE result_ExperimentMessage(
pilot_id INT,
bitoffset INT NOT NULL,
result INT,
PRIMARY_KEY(pilot_id)
)
Change-Id: I28fb5488e739d4098b823b42426c5760331027f8
