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
That's the reason why sometimes we get inconsistent numbers in the logs. For example, sometimes we see that the process time is greater than the process time plus the time in the queue. In many deployments, those two timestamps always come from different machines (listeners vs background workers) so comparing them is not reliable.
The text was updated successfully, but these errors were encountered:
This causes problems when using the async mode because all the fibers
share that @Args class var. Luckily, with the current code, the only
attribute affected is "enqueue_time", which is not
accurate anyway (see #18).
Even without taking the async mode into consideration using a class var
is counter-intuitive. The arguments of a particular job (service ID, app
ID, etc.) should belong to an instance, they shouldn't be stored in a class var.
For each processed job, the workers log some information like the process time, the total time (process time + time in the queue), etc.
The second is not correct. The reason is that the enqueue time is stored in Redis by a listener when it enqueues a job:
apisonator/lib/3scale/backend/transactor.rb
Line 204 in 18edf5c
Whereas the total time is calculated by the worker when it finished processing a job:
apisonator/lib/3scale/backend/background_job.rb
Line 43 in 18edf5c
That's the reason why sometimes we get inconsistent numbers in the logs. For example, sometimes we see that the process time is greater than the process time plus the time in the queue. In many deployments, those two timestamps always come from different machines (listeners vs background workers) so comparing them is not reliable.
The text was updated successfully, but these errors were encountered: