- **status**: review --> fixed
---
** [tickets:#2228] amfd: incorrect presence and readiness state**
**Status:** fixed
**Milestone:** 5.0.2
**Created:** Wed Dec 14, 2016 12:51 AM UTC by Gary Lee
**Last Updated:** Mon Jan 09, 2017 03:00 AM UTC
**Owner:** Gary Lee
fm2 is shutting down while
changeset: 8503:121329984ff0
branch: opensaf-5.1.x
tag: tip
parent: 8499:c3fd1f88bca1
user:Gary Lee
date:Mon Jan 09 11:39:47 2017 +1100
summary: amfd: increase max job queue size at standby [#2228]
changeset: 8502:7d45e754bceb
- **status**: unassigned --> accepted
- **assigned_to**: Gary Lee
---
** [tickets:#2228] amfd: incorrect presence and readiness state**
**Status:** accepted
**Milestone:** 5.0.2
**Created:** Wed Dec 14, 2016 12:51 AM UTC by Gary Lee
**Last Updated:** Wed Dec 21, 2016 12:34 AM UTC
**Owner:**
Hi Praveen
I'm guessing the cold sync was encoded before the SU states were updated. So
even though the standby completed sync, it still has the old info?
---
** [tickets:#2228] amfd: incorrect presence and readiness state**
**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Wed Dec
Hi,
Standby AMFD ignores it. if that reo_type has not synched as it will get
updated before the cold sync. Why it got missed when whole reo_type is getting
snycned before the completion of cold sync?
If standby AMFD queues it then, active amfd will increments it counters. In the
end of cold
In avsv_mbcsv_process_dec_cb(), the code seems to ignore / throw away any async
update if the relevant type hasn't been cold synced yet. This could have been
the case here.
Would it be better to queue the async updates instead?
---
** [tickets:#2228] amfd: incorrect presence and readiness
---
** [tickets:#2228] amfd: incorrect presence and readiness state**
**Status:** unassigned
**Milestone:** 5.0.2
**Created:** Wed Dec 14, 2016 12:51 AM UTC by Gary Lee
**Last Updated:** Wed Dec 14, 2016 12:51 AM UTC
**Owner:** nobody
fm2 is shutting down while fm1 starting up. After the