You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I set up AmplitudeExperiment with LocalEvaluation in a Puma environment, calling #start on the client during Rails initialization.
Expected Behavior
Each worker process is able to see updates to flag configuration or error is logged alerting you to dead polling thread and potentially stale results.
Current Behavior
No errors are raised, but the flag configurations are not updated after processes fork and so the flag configurations become stale even though logs show polling behavior happening.
It appears to be that the polling thread is dead when logging from the worker, but the thread is still active in the main process and logging updates (with the logger fix from #38) , which is misleading.
Captured below - we see a fetch of flagVersion 17 but then a few seconds later when inspecting the experiment client we see it is stuck at 16 and poller_thread shows status of dead in the inspect:
Either documentation to describe how to achieve expected behavior (you must call #start after process fork), or better handling of this case to automatically achieve desired behavior (example from Redis client watches a cached @pid variable to detect a fork: redis-rb/redis-client@bec4931 )
Environment
SDK Version: 1.1.0
Language Version: 3.1.3
The text was updated successfully, but these errors were encountered:
I set up AmplitudeExperiment with LocalEvaluation in a Puma environment, calling
#start
on the client during Rails initialization.Expected Behavior
Each worker process is able to see updates to flag configuration or error is logged alerting you to dead polling thread and potentially stale results.
Current Behavior
No errors are raised, but the flag configurations are not updated after processes fork and so the flag configurations become stale even though logs show polling behavior happening.
It appears to be that the polling thread is dead when logging from the worker, but the thread is still active in the main process and logging updates (with the logger fix from #38) , which is misleading.
Captured below - we see a fetch of flagVersion 17 but then a few seconds later when inspecting the experiment client we see it is stuck at 16 and poller_thread shows status of
dead
in the inspect:Possible Solution
Either documentation to describe how to achieve expected behavior (you must call
#start
after process fork), or better handling of this case to automatically achieve desired behavior (example from Redis client watches a cached @pid variable to detect a fork: redis-rb/redis-client@bec4931 )Environment
The text was updated successfully, but these errors were encountered: