A bug in writing log file

[samira-t]

Hi,

It seems that there is a bug in the program that causes the result of running a scenario which is written in the log file to be incorrect. For example, in the log file the Start action may appear after End action or some other actions in the log file. The reason is that the messages sent from actions to the data writer may be received in different orders since they are sent from different actors. In Akka, there is no guarantee that for example the messages sent from actor a and b to actor c to be received in some specific order. Therefore, there is not guarantee that the message sent from UserStart to be received before EndUser or other actions between start and end actions in the scenario.

[slandelle]

Hi Samira,

The records in the file are indeed not sorted and one shouldn't assume they are.

Regarding FileDataWriter, it just dumps records as soon ass they arrive. FileDataReader is the component in charge of parsing the file and computing the stats and it doesn't expect records to be sorted (in 2.X, as the group computation algorithm in 1.X is indeed a bit flawed). Also note that in 2.X, the End records contains both start and end timestamps.

Real time DataWriters such as ConsoleDataWriter and GraphiteDataWriter do make approximations and just compute counters, so yes, there's a slight chance the stats they produce are not perfectly equals to the ones in the reports, but that's a known limitation.

Do you have a better design to propose?

Cheers,

Stéphane

[samira-t]

I think you can assign a unique sequence number to each action as an attribute of that action in the scenario. Then, in the DataWriter, keep a buffer of current received reports and instead of appending any upcoming message to the current content of reports, use the sequence number of the action and insert the upcoming message in the right place in the content of reports. The sequence number can be initialized to zero in the start action and transferred to the next action in the execution. The next action assigns its sequence number by increasing the sequence number it received from the previous action.
I hope that helps.

Cheers,
Samira

[slandelle]

Damn, I was hoping you come up with a funky actor based design I couldn't find out myself... ;)

The current strategy is to defer this tracking/buffering and perform it offline during reports generation. We might someday re-implement some DataWriters this way if we realize that the current implementation is indeed a problem (which I'm 100% sure it's not for the FileDataWriter/FileDataReader couple).

Anyway, DataWriters are a pluggable API, so one can write his own if he wants a different behavior.

Time will tell.

[samira-t]

I just posted an issue (issue #1116) related to this.