Investigate refactoring vs replacing forwarder

[LowriJenkins]

Investigate and document steps to remove caproto from forwarder.
Possible routes:

• Replace caproto with pyepics and refactor to remove caproto styling throughout project. This would allow more benefitting from upstream-code, However large sections of implementation would need complete replacement.
• Rewrite forwader from scratch to use aioca as an asynchronous program.

Acceptance Criteria

• Investigate and decide on method to go forward from here.
• Document decision and any following design decisions as an ADR

[LowriJenkins]

Potential ADR:

ADR - 12 - Forwarder aioca vs PyEpics

Status

Pending

Context

The forwarder currently in use to send information from PVs to the file-writer relies on caproto to handle reading channel access PVs. caproto has a bug that prevents reconnection to a pv that has dropped and therefore needs to be replaced by a different library. This could be achieved in a couple of different ways. PyEpics is relativley similar to caproto and supports threaded operation, so a refactor to replace caproto with PyEpics and refactor any sections heavily tied to caproto could be undertaken. On the otherhand, caproto could also be replaced with aioca, unlike caproto and PyEpics, aioca is an asycnhronus system, this would require far greater changes, likley a full re-write rather than just re-factoring but async is usually better suited to IO tasks that are slow or ones that have a large number of connections (such as setting up a large number of PV monitors.) A full rewrite would also present the oppurtunity to prune some content from the forwarder which is present only for the ESS and would not be used at ISIS.

Decision

We will rewrite the forwarder to make use of async-io:

• Channel Access will be handled using aioca
• PV Access will be handled using p4p's async mode.
• Sections irrelevent to ISIS (tdct, previous versions of serializers, etc.) will not be carried forward.
• Kafka interactions will be handled by aiokafka
• The external facing interfaces such as kafka schemas, serialization, and forwarder configs will not change.

Consequences

• A new repository will be opened called async-forwarder
• An Issue/Issues will be created to begin creation of the new async-forwarder.
• async-forwarder is tested with the same inputs against forwarder to ensure same outputs.
  • async-forwarder is tested against the bug that was the initial cause for this re-write.

[rerpha]

something which i feel is missed is that the current ESS forwarder can forward both CA and PVA. Is the potential rewrite approach taking this into account, as it's something which we will probably need eventually?

ignore, covered by PV Access will be handled using p4p's async mode