Concurrency / Multithreading

[TinaTiel]

Feeling like I have a rough idea of how to configure a client. However, I feel like there's a gap in my understanding in how the client will be able to receive/broadcast messages currently.

So, let's take a break and dive into concurrency and multithreading -- then if necessary dive into scheduling/queueing in Spring / how to best architect this. Questions I have:

• How will I queue message-send requests?
• How will I handle responses from OBS? How will I know how to route those requests so they go back to the requester?
• How will I respond to the client connecting/disconnecting? E.G., how could I make it possible to manually enable/disable the connection, or to automatically attempt a reconnect? Would it be through emitting an event and consuming it somewhere?

[TinaTiel]

Finally wrapped my head around this last night, it'll require me to change up my architecture a bit.

The main change and realizations I had were:

• Ultimatley it is the actions that execute. These should implement Runnable and would be passed to an Executor
• The Executor must be a key-based FIFO queue; i.e. commands can be executed in any order but actions within a command must be executed in-order. This means that actions need to have a key on them when passed to the Executor, so that it can maintain that relationship/rule
• The current implementation stores Actions on Commands via "Executors" that determine order actions execute in. This is going to be changed:
  • Commands don't execute; they merely store information about what they are. Actions implement Runnable. A service will take a Command, read it, and generate a list of Runnables to pass into an executor (this also helps check for cyclical actions)
  • "Excecutor" is being renamed to "Sequencer", as it is really only responsible for action order
  • Sequencers are stateful and can generate a newSequence on-demand; this is important for stuff like pick-and-execute-random
  • Sequencers don't execute; they merely return a new sequence of actions
• Actions have direct references to their services they use (OBS, Twitch, etc). This must be changed to refer to a factory instead, because one requirement is to be able to reload a broken service (e.g. Twitch losing connection, or needing to restart OBS); if these were hard references then the ref would be broken when the service is recreated due to it being assigned a new address.
• When executed, prior a simple list of strings were passed in as arguments. This has been abstracted to a Context of sorts that includes the command's name and requester's info; this enables two things:
  • keyed Runnables, keyed on not just command name but also arguments and requester name (e.g. two different people executing the same command with the same arguments should get their own contexts, or the same person executing the same command but with different arguments should get their own context)
  • SRP; we can add/remove bits to the context as needed. For example, a Message action could use the context to populate message variables such as username or other custom vars

[TinaTiel]

Updated sketch of architecture for reference:

[TinaTiel]

One more thing -- an example of a keyed FIFO executor is described here: https://stackoverflow.com/questions/2153663/controlling-task-execution-order-with-executorservice

In the actual implementation, I'd like to see if I can separate out those classes and the Map<Object, Queue> they reference together internally as nested static inner classes, and put them in their own class files. This should improve unit-testability, though I'm not 100% sure how I should handle this in Spring w.r.t. sharing a Map bean (that, or just put that inside the @Configuration class and wire it in as a dependency?)