Search before asking
What happened
When using the JDBC registry , stale EPHEMERAL registry data may be removed from the database without correctly notifying running services.
This can cause running Master instances to keep stale in-memory registry state.
What you expected to happen
How to reproduce
Use JDBC registry.
1.Start a Master or Alert Server instance with address A.
2.Start a replacement instance with address B before address A is considered expired.
3.Stop or kill the old instance A.
4.Wait for JDBC registry cleanup.
For Master:
Check DB and confirm only one Master registry data row exists:
select *
from t_ds_jdbc_registry_data
where data_key like '%/nodes/master/%';
Debug or log MasterSlotManager and observe:
currentSlotIndex = 0
totalSlot = 2
Check t_ds_command and observe commands that never get fetched because they belong to the missing slot.
Anything else
No response
Version
3.4.1
Are you willing to submit PR?
Code of Conduct
Search before asking
What happened
When using the JDBC registry , stale EPHEMERAL registry data may be removed from the database without correctly notifying running services.
This can cause running Master instances to keep stale in-memory registry state.
What you expected to happen
How to reproduce
Use JDBC registry.
1.Start a Master or Alert Server instance with address A.
2.Start a replacement instance with address B before address A is considered expired.
3.Stop or kill the old instance A.
4.Wait for JDBC registry cleanup.
For Master:
Check DB and confirm only one Master registry data row exists:
select *
from t_ds_jdbc_registry_data
where data_key like '%/nodes/master/%';
Debug or log MasterSlotManager and observe:
currentSlotIndex = 0
totalSlot = 2
Check t_ds_command and observe commands that never get fetched because they belong to the missing slot.
Anything else
No response
Version
3.4.1
Are you willing to submit PR?
Code of Conduct