No, I am a liar.
We can run the both and more DAQs with the same EXPID, take data until one component is crashed. Then one kill this component, restart this component, but the container has no response. So we cannot take data anymore. In one of my scenarios, I kill the ET/EB/ER on cdaql4, not platform and its container, while the injector DAQ is taking DATA. The injector DAQ is working fine, but I cannot restart the tracking run, because the container on cdaql4 has the following error message.
Jdp_Error: JDP IO Exception
org.jlab.coda.afecs.system.AException: JDP IO Exception
Connection refused
at org.jlab.coda.afecs.plugin.dp.ADp.sendCmd(ADp.java:146)
at org.jlab.coda.afecs.plugin.dp.ADp.setChannel(ADp.java:339)
at org.jlab.coda.afecs.system.process.ProcessManager.sync_execProcUsingPlugin(ProcessManager.java:354)
at org.jlab.coda.afecs.system.process.ProcessManager.executeProcess(ProcessManager.java:446)
at org.jlab.coda.afecs.agent.AAParent.moveToState(AAParent.java:270)
at org.jlab.coda.afecs.codarc.CodaRCAgent.aL_moveToState(CodaRCAgent.java:130)
at org.jlab.coda.afecs.codarc.CodaRCAgent.aL_reset(CodaRCAgent.java:169)
at org.jlab.coda.afecs.agent.ARAgent.reconnect2Client(ARAgent.java:142)
at org.jlab.coda.afecs.agent.ARAgent$AgentControlThread.run(ARAgent.java:290)
CODA legacy communication protocol set channel failure.
Thus, the solution which I had yesterday after long discussions with the JLab DAQ group is not correct. I will contact him later if I have some spare time. I revert the CODAMASTER to the old one that can execute its platform on each host. Therefore, tonight, even more, or until the JLab DAQ group fix this issue, only one DAQ is available.
Of course, we can use the both DAQs if we want... until one component is crashed, and restart from scratch on cdaql4 and cdaql5.
A very quick and dirty solution for this, simply use the different EXPID. Then the platform on cdaql5 is independent of the one on cdaql4.