By changing the model to a state-based FSM, we've broken the previous strategy for associating log lines with an edge when the edge is clicked. Previously, log lines for events within the source and destination nodes of the edge were highlighted. Now, only log lines for events within the source node that follow this transition should be highlighted, since the event is actually associated with the source node in the code even if the label is now on the edge.
[Issue created by ohmann: 2015-10-27]
[Last updated on bitbucket: 2015-10-28]
[Comment created by stanleyrya: 2015-10-27]
@ohmann
Update: 4703a2bf9d99
Should be good now.
[Comment created by stanleyrya: 2015-10-27]
@ohmann
6654fee62f4a
Edges are fixed, do we need to worry about nodes, or can they stay the same?
[Comment created by stanleyrya: 2015-10-27]
Actually we may need to wait on this one - the edge labels are still broken. Working on it now.
[Comment created by ohmann: 2015-10-28]
Merged in: 70d3b671bd65
[Comment created by stanleyrya: 2015-10-28]
Finally fixed it! In the end you were completely right. While my way did work for most of the edges, comparing the source events to the target events and looking for any events that continued into the next one gave the correct highlighting.
Here is the last push for the fix: add59765b421
[Comment created by stanleyrya: 2015-10-28]
Update: got the terminal edges to work now. Still stuck on the beginning edges.
[Comment created by ohmann: 2015-10-28]
I did look, and yes, it's highlighting only the correct lines for (seemingly) all edges except, as you say, those that begin a trace---those immediately after INITIAL.
[Comment created by ohmann: 2015-10-28]
Oh, edges to TERMINAL seem to be only partially working as well. Perhaps you already knew that, though.
[Comment created by stanleyrya: 2015-10-28]
Thanks. I'll keep you posted as I work through it.
[Comment created by stanleyrya: 2015-10-28]
Can you check out 1cb0ec5689ca and see if this is on the right track? Try clicking an edge (not the label, those still do the old logs). Unfortunately it looks like the first few edges might not be working, but the middle ones might be correct.
[Comment created by ohmann: 2015-10-28]
My "immediately followed by" term again means what I described above w.r.t. traceID and eventIndex fields. Looking at the very next line in the log is not enough, since logs can be ordered arbitrarily.
[Comment created by ohmann: 2015-10-28]
I said node/partition only because you mentioned the word partition, when in fact they are the same thing. Unfortunately, looking only at the source node and the edge (which gets its event info strictly from the source node already, right?) isn't enough as far as I'm aware, although this may be false if more info than I realize is stored in the edges. Somewhere in the frontend code, the edges are made by looking at every event within some partition A (the word "partition" is from the backend... exclusively called "nodes" in the frontend after the JSON is parsed I believe) and adding an edge between partition A and partition B if at least one event in partition A is immediately followed within the same trace by an event in partition B. If this information were (or already is) stored in the edge after initial creation, then it would be easy for you to leverage it.
[Comment created by stanleyrya: 2015-10-28]
Ok. I'm a bit confused on what a "node/partition" is. Shouldn't I only have to take the source node and compare it to the edge?
[Comment created by ohmann: 2015-10-28]
It will be a strict subset of what's being highlighted now: events in the edge's source node/partition that are immediately followed in the log by an event in the edge's destination node/partition. Immediately followed in the log means that in the JSON, they're in the same trace (have the same traceID) and differ in eventIndex by 1 (the event in the source node's eventIndex is 1 less than any event in the destination node's eventIndex).
[Comment created by stanleyrya: 2015-10-28]
I have time right now to look into it, however I am confused on how I am supposed to figure out which log lines are correct. Would they be the set of logs that are in both the source node and the partition?
[Comment created by ohmann: 2015-10-28]
I didn't realize until playing around with the new version that I over-simplified my explanations of what log lines should be highlighted. Highlighting log lines for all events in the source node can highlight too much. For example, infer the connection tester example model, and try clicking on one test-bandwidth edge and then the other. Each should highlight only a portion of the source node's events. I hadn't thought of this before.
Is this still something possible to explore tonight, or is it too late at this point?
By changing the model to a state-based FSM, we've broken the previous strategy for associating log lines with an edge when the edge is clicked. Previously, log lines for events within the source and destination nodes of the edge were highlighted. Now, only log lines for events within the source node that follow this transition should be highlighted, since the event is actually associated with the source node in the code even if the label is now on the edge.
[Issue created by ohmann: 2015-10-27] [Last updated on bitbucket: 2015-10-28]
[Comment created by stanleyrya: 2015-10-27] @ohmann
Update: 4703a2bf9d99
Should be good now.
[Comment created by stanleyrya: 2015-10-27] @ohmann
6654fee62f4a
Edges are fixed, do we need to worry about nodes, or can they stay the same?
[Comment created by stanleyrya: 2015-10-27] Actually we may need to wait on this one - the edge labels are still broken. Working on it now.
[Comment created by ohmann: 2015-10-28] Merged in: 70d3b671bd65
[Comment created by stanleyrya: 2015-10-28] Finally fixed it! In the end you were completely right. While my way did work for most of the edges, comparing the source events to the target events and looking for any events that continued into the next one gave the correct highlighting.
Here is the last push for the fix: add59765b421
[Comment created by stanleyrya: 2015-10-28] Update: got the terminal edges to work now. Still stuck on the beginning edges.
[Comment created by ohmann: 2015-10-28] I did look, and yes, it's highlighting only the correct lines for (seemingly) all edges except, as you say, those that begin a trace---those immediately after INITIAL.
[Comment created by ohmann: 2015-10-28] Oh, edges to TERMINAL seem to be only partially working as well. Perhaps you already knew that, though.
[Comment created by stanleyrya: 2015-10-28] Thanks. I'll keep you posted as I work through it.
[Comment created by stanleyrya: 2015-10-28] Can you check out 1cb0ec5689ca and see if this is on the right track? Try clicking an edge (not the label, those still do the old logs). Unfortunately it looks like the first few edges might not be working, but the middle ones might be correct.
[Comment created by ohmann: 2015-10-28] My "immediately followed by" term again means what I described above w.r.t. traceID and eventIndex fields. Looking at the very next line in the log is not enough, since logs can be ordered arbitrarily.
[Comment created by ohmann: 2015-10-28] I said node/partition only because you mentioned the word partition, when in fact they are the same thing. Unfortunately, looking only at the source node and the edge (which gets its event info strictly from the source node already, right?) isn't enough as far as I'm aware, although this may be false if more info than I realize is stored in the edges. Somewhere in the frontend code, the edges are made by looking at every event within some partition A (the word "partition" is from the backend... exclusively called "nodes" in the frontend after the JSON is parsed I believe) and adding an edge between partition A and partition B if at least one event in partition A is immediately followed within the same trace by an event in partition B. If this information were (or already is) stored in the edge after initial creation, then it would be easy for you to leverage it.
[Comment created by stanleyrya: 2015-10-28] Ok. I'm a bit confused on what a "node/partition" is. Shouldn't I only have to take the source node and compare it to the edge?
[Comment created by ohmann: 2015-10-28] It will be a strict subset of what's being highlighted now: events in the edge's source node/partition that are immediately followed in the log by an event in the edge's destination node/partition. Immediately followed in the log means that in the JSON, they're in the same trace (have the same traceID) and differ in eventIndex by 1 (the event in the source node's eventIndex is 1 less than any event in the destination node's eventIndex).
[Comment created by stanleyrya: 2015-10-28] I have time right now to look into it, however I am confused on how I am supposed to figure out which log lines are correct. Would they be the set of logs that are in both the source node and the partition?
[Comment created by ohmann: 2015-10-28] I didn't realize until playing around with the new version that I over-simplified my explanations of what log lines should be highlighted. Highlighting log lines for all events in the source node can highlight too much. For example, infer the connection tester example model, and try clicking on one test-bandwidth edge and then the other. Each should highlight only a portion of the source node's events. I hadn't thought of this before.
Is this still something possible to explore tonight, or is it too late at this point?