You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm not convinced that the messaging between the various components currently works in the way it's supposed to. For instance, at https://github.com/sky-uk/mite#recorder the readme says "by defaul this will read off of the duplicators other outbound socket tcp://127.0.0.1:14303". But looking at the code, here and here, it doesn't look like any socket on 14303 is ever established.
The text was updated successfully, but these errors were encountered:
OK, I've been talking more with Davide about this. (And also reading the part of the readme higher up the document where the 14303 port is discussed 😳)
I think that what we want is an improvement to the CLI in the following way: make the duplicator understand its out socket arguments in the same way that the stats/collector/recorder understand their in socket arguments. So rather than
mite duplicator --message-socket=X Y Z
mite stats --stats-in-socket=Y
mite collector --collector-socket=Z
That way, it's manifest that the arguments must be identical for it to work. An additional step would be to make the CLI programs ignore irrelevant arguments, so that it would be possible to do:
Then our script is typo-proof. (This makes things simple for the case that's common for us, which is running the duplicator/collector/recorder all on the same box, with only the runners on separate boxes. The situation where each component is on a separate box will be more complicated, but that would always be true...)
I'm not convinced that the messaging between the various components currently works in the way it's supposed to. For instance, at https://github.com/sky-uk/mite#recorder the readme says "by defaul this will read off of the duplicators other outbound socket tcp://127.0.0.1:14303". But looking at the code, here and here, it doesn't look like any socket on 14303 is ever established.
The text was updated successfully, but these errors were encountered: