Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Official 5.4 Beta Discussion Thread
And yet another massively brain frying couple days. But I'm now really honing in on something solid I think. Coming up with a good way to create a pool of in/out msgs (which requires sorting them by their current buffer size and finding the best sized one to meet the need when a new one is need) is that it's not practical to know the size of out msgs until they are already built, which is too late, and it requires partly parsing in msgs to get the remaining bytes before then getting out a msg from the queue and letting it parse itself the rest of the way.

That sort of was pushing me around in mental circles, partly because of the changes to the pool system I made a couple weeks ago and this was the most unusual scheme I've used it for yet. So I was a bit diffused.

And I also was originally just spinning off one thread to do all the work. But ultimately I ended up splitting it out into an I/O thread that purely sends/ receives msgs (queuing them in both directions) and an MQTT thread that does the actual MQTT client logic, which now has to be completely async since it can't directly send/receive msgs.

That required a lot of reswizzling and trial and error to really get it flowing well and of course how to work out the least amount of synchronization required and such. The I/O thread now just has two states: trying to connect the socket, and read/writing messages. The MQTT thread deals with the states related to MQTT logic of connecting, subscribing, deal with acks and retries and timeouts, etc... All queued for transmission msgs that need a response are adding to a pending pending in the MQTT thread to await any required acknowledgements and retries.

These kinds of completely state driven, async things are always messier to set up, but ultimately handle a two way msg flow a lot better.
Dean Roddey
Explorans limites defectum
Reply
I renamed my Windows 10 system from 'Beachfield-T570' to 'T570'. I ran the .927 installer and unchecked the 'use current configuration'. CQC comes up and runs and CQCNetTest shows everything OK. However every single device driver is offline (red) in the admin interface. When I attempt a reconfigure I get an error message of
"01/01 00:00:00-T570, CQCAdmin, MainThread
{
CQCKit, CQCKit_ThisFacility.cpp.3738, Failed/Not Found, Error: 6009/0/0
No CQCServer was found on host 'Beachfield-T570'
/CQC/CQCServer/Admins/Beachfield-T570
<CQCAdmin> CQCTreeBrws_DevicesBrws.cpp - 2451

}"

Three issues:

The error message does not fit in the popup dialog
The old system name is being used in the reconfigure.
Even if you delete the driver and readd the old system name is used.
Mark Stega
Reply
Right click on the server in the browser tree and select the option to move the drivers to another machine. Select the new machine name (which should show up because it does have a CQCServer running on it) and it should magically move them all to the new machine.

BTW, you COULD move them to another machine one at a time, but you can't do it by clicking on the server itself, you have to click on the overall drivers item in the broswer tree, which lets you add to a new server that you select. I think that's correct. I don't have it up right now. If you click on the server itself you are always just dealing with that server.

It doesn't work like it used to, where drivers were configured on each machine that they ran on. So, if you changed the name of the machine they would just show up under that new machine. The config is on the master server now and each CQCServer looks for things assigned to him in that master server config. So if you change the machine name it doesn't find any for itself anymore. That's also why clicking on that server in the list doesn't get you anything new. It's just configuring drivers that are marked with that server name in the master driver config. It doesn't care if they still exist or not (they may just be down.) This also means you can recover drivers, unlike before, if the old machine goes bye-bye, because the config isn't on that machine anymore.

When you do the move to a new machine thing, it just updates the configured entries to use the new machine name. Suddenly the new machine sees drivers for it and loads them up.
Dean Roddey
Explorans limites defectum
Reply
(02-15-2019, 09:47 AM)Dean Roddey Wrote: Right click on the server in the browser tree and select the option to move the drivers to another machine. Select the new machine name (which should show up because it does have a CQCServer running on it) and it should magically move them all to the new machine.

BTW, you COULD move them to another machine one at a time, but you can't do it by clicking on the server itself, you have to click on the overall drivers item in the broswer tree, which lets you add to a new server that you select. I think that's correct. I don't have it up right now. If you click on the server itself you are always just dealing with that server.

It doesn't work like it used to, where drivers were configured on each machine that they ran on. So, if you changed the name of the machine they would just show up under that new machine. The config is on the master server now and each CQCServer looks for things assigned to him in that master server config. So if you change the machine name it doesn't find any for itself anymore. That's also why clicking on that server in the list doesn't get you anything new. It's just configuring drivers that are marked with that server name in the master driver config. It doesn't care if they still exist or not (they may just be down.) This also means you can recover drivers, unlike before, if the old machine goes bye-bye, because the config isn't on that machine anymore.

When you do the move to a new machine thing, it just updates the configured entries to use the new machine name. Suddenly the new machine sees drivers for it and loads them up.

It works & I guess that makes sense. However it would be nice to know that the server name changed ans migrate automatically. OTOH, it might just be too much work for the benefit.
Mark Stega
Reply
I don't think that there would be any way to know for sure. It could just be a new machine with a different name. There isn't any unique id associated with the machines, just the host name is what we have to go with.. And all the configuration on the MS knows is what host name the drivers were configured for.
Dean Roddey
Explorans limites defectum
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  MQTT support discussion Dean Roddey 29 336 Yesterday, 10:09 PM
Last Post: Dean Roddey
  Official 5.4 Beta Release Thread Dean Roddey 34 3,252 01-27-2019, 03:43 PM
Last Post: Dean Roddey
  Official 5.3 Beta Discussion Thread Dean Roddey 815 119,215 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.3 Release Thread Dean Roddey 27 6,193 07-05-2018, 12:44 PM
Last Post: Dean Roddey
  Official 5.2 Beta Discussion Thread Dean Roddey 244 77,405 10-14-2017, 07:57 PM
Last Post: Dean Roddey
  Official 5.2 Beta Release Thread Dean Roddey 13 7,649 10-09-2017, 06:49 PM
Last Post: Dean Roddey
  Official 5.1 Beta Discussion Thread Dean Roddey 453 176,218 05-16-2017, 03:45 PM
Last Post: Dean Roddey
  Official 5.1 Beta Release Thread Dean Roddey 28 17,518 05-12-2017, 05:44 PM
Last Post: Dean Roddey
  Official 5.0 Beta Discussions Dean Roddey 2,019 453,903 11-09-2016, 04:34 PM
Last Post: Dean Roddey
  Official 5.0 Beta Release Thread Dean Roddey 15 12,370 11-01-2016, 10:32 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)