Bug #12697
parameter page does not show error when OAC is restarted
0%
Description
When an OAC is restarted, the associated devices on parameter page do not show any error.
The old DPM would first show (1, -34) error and then PENDING.
History
#1 Updated by Richard Neswold almost 5 years ago
- Status changed from New to Assigned
Would the old DPM ever recover? We were trying to smooth out front-end reboots so the end users wouldn't have to restart their stuff when data sources went away (unless they went away for a while. In that case, we returned a [1 -6].)
We could inject DPM_PEND statuses while we're trying to reconnect, I guess. Is that sufficient?
#2 Updated by Jianming You almost 5 years ago
The old DPM does not recover unless the page is reloaded.
Smoothing out front-end/OAC reboot makes sense. The DPM_PEND is perfect.
Thanks.
#3 Updated by Richard Neswold almost 5 years ago
- Status changed from Assigned to Feedback
- Assignee changed from Richard Neswold to Jianming You
FGATE is running a new DPM with a potential fix for this problem. Jimmy, on your CLX, type the following:
lnmctl NEWDPM_NODE=FGATE
Then start up a parameter page using the new DPM (the title bar should show FGATE.) Restart one of your OACs and see if DPM_PEND is momentarily reported.
#4 Updated by Richard Neswold almost 5 years ago
The DPM source has been modified to inject a DPM_PEND status in the reply stream whenever a corresponding front-end is rebooted. This was verified using an Erlang client on CLX39. The parameter page still doesn't see the DPM_PEND because CLIB is filtering them. Charlie King is fixing CLIB.
commit: 313664
#5 Updated by Richard Neswold almost 5 years ago
- Status changed from Feedback to Assigned
- Assignee changed from Jianming You to Charles King
Re-assigned to Charlie so we don't forget to fix CLIB.
#6 Updated by Charles King almost 5 years ago
- Status changed from Assigned to Closed
CLIB has been changed to no longer debounce DPM_PENDING status. This was keeping the newly added PENDING status from reaching the parameter page when a front-end or OAC was restarted. The debouncing was originally added back when the new DPM sent DPM_PENDING status every time a DPM list was started. This would cause all devices on a parameter page to flash the PENDING status every time a device was added. The DPM_PENDING status is no longer sent when a list is started, so the debouncing can also be removed.