parameter page does not show error when OAC is restarted
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.
#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?
#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:
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.
#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.