[INSTRM-415] hub actors keyword is not accurate Created: 12/Jul/18  Updated: 12/Jul/18

Status: Open
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: arnaud.lefur Assignee: cloomis
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the spsClient, I'm displaying the actor status, the idea is to know which actor is actually online.

basically, I have a callback on self.models['hub'].keyVarDict['actors'].

each time an actor is connecting or disconnecting the hub, I get noticed and I update the matching widget.

That's working well unless the actor is not disconnected properly, for instance when we power down the BEE, in that case, the hub keep thinking that the ccdActor is still connected.

alefur@PFS-WS2:~$ oneCmd.py hub status
2018-07-11T16:19:24.235 sent hub status
2018-07-11T16:19:24.242 hub i version="need_to_read_git_version"
2018-07-11T16:19:24.249 hub i actors=hub,keys,msg,ccd_r1,xcu_b1,ccd_b1,aitroom,dcb,breva,sac,spsait,sequencepanel
2018-07-11T16:19:24.249 hub i commanders=client.v5,client.v48,client.v50,client.v221,client.v739,client.v866,nclient_1397,client.v1409,client.v1418,client.v1474,client.v1790,client.v1801,client.v1803,client.v1808,client.v1825,client.v1828,client.v1829
2018-07-11T16:19:24.250 hub i users
2018-07-11T16:19:24.250 hub : 
alefur@PFS-WS2:~$ oneCmd.py ccd_r1 status
2018-07-11T16:19:38.821 sent ccd_r1 status

the hub doesn't return  a notarget and the command is stuck.

 



 Comments   
Comment by cloomis [ 12/Jul/18 ]

Agreed, that keyword must be dependable and the command should be rejected immediately. I

Unfortunately, in general this one might be hard to catch: the TCP socket will (correctly) not be immediately closed when one side is powered down. Having a proper shutdown routine would help a great deal in normal operations. I'll link to INSTRM-376 because of that

Generated at Sat Feb 10 16:24:46 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.