EMail issue

[H Ding]

Hi,

Recently we are having an issue related to the password resetting. On the "Forgot Password" page, after the email address is provided, usually an email is sent to the email address instantly with the link for resetting the password. However, in out case, it took extremely long time to wait for the email or even the email is never sent. To figure out the issue, we found that after "Restart background tasks", the email request for resetting password can be received instantly again. However, after a period of time in days or weeks, this issue happens again.

Therefore, this issue seems related to the background task of the SEEK server, which might delay or block the email notification. The weird thing is:  when I tried to send an test email on the SEEK configuration page, such test email can be received instantly, even though the email request for resetting password still kept not received during the time.

Does anyone experience the same issue like us? Do you have a clue where the problem might be?

Thanks,

Huiming

[Stuart Owen]

Hi Huiming,

Almost all emails are sent asynchronously via the job queue, so it is important the background tasks are running for the emails to be sent. They have a dedicated queue and worker, so will be sent quickly once queued as long as the tasks are running. It seems that maybe the background tasks stopped working in your case. You can keep an eye on the queued and failed jobs on the admin pages, under "Status and Statistics", and select Job Queue. There is also an endpoint you can monitor to check they are running /statistics/application_status ( e.g. https://testing.sysmo-db.org/statistics/application_status  ) the number of delayed_jobs relates to the number of running workers, and varies depending upon what features are enabled.

When testing the email on the configuration page there is an option to just send immediately, just to check the settings, which doesn't get queued. There is also an option to test it via the queue, but I've just been testing this and doesn't seem to behave correctly and results in failed job which we need to look into.

There is also the problem that whenever an email is sent, there is nothing to guarantee how quickly it will be delivered as it gets passed along with way and ends up in mail spools. 2 emails sent at the same time may not arrive at the same speed. We recently had a problem where emails seemed to be arriving slowly, but looking at the mail headers I could see that they were being delayed along the way.

regards,
Stuart

--
If you have installed SEEK - please take a moment to fill out our registration form at http://www.seek4science.org/seek-registration
---
You received this message because you are subscribed to the Google Groups "SEEK" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seek4science...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/seek4science/0dd287d4-ac1f-4c53-be85-6ee05590cb30n%40googlegroups.com.

[H Ding]

Hi Stuart,

Thank you very much for your prompt response, which is very helpful. It seems in our local SEEK instance that the total delayed jobs waiting = 79 are delayed and slowly get updated. Is there any way to adjust or clean the status of those jobs to finish or cancel? Even after I restart the background processes, some of those jobs remain in the queue and not changed.

Thanks,

Huiming

To view this discussion on the web visit https://groups.google.com/d/msgid/seek4science/136ccf5d-baa0-fcbe-5710-4d6426e35e26%40manchester.ac.uk.

[Stuart Owen]

Hi Huiming,

Sorry for the delay getting back to you, I've been away for a while. Did you manage to resolve the issue?

If there are items still in the queue, it may be due to errors. When looking at the job queue in the admin area ( under Status and Statistics) they will appear with a link, which when you click will give information about the error, and there will be a red button at the top you can click to clear all jobs with errors.

If you still need to clear the jobs, and have access to the rails console, you can use:

Delayed::Job.destroy_all

a few jobs have their own queue to allow them to process items in batches - these will be listed under the job list in the admin status view described above. If you need to clear these you can use

ReindexingQueue.destroy_all

or

AuthLookupUpdateQueue.destroy_all


hope this helps, and once again apologies for the slow response.

regards,
Stuart

To view this discussion on the web visit https://groups.google.com/d/msgid/seek4science/CAJbUZXjBDzpRGMSN3NObz90%3DegEgJ3WzE9ZctJ4W0ME%3DVUGONw%40mail.gmail.com.

[H Ding]

Hi Stuart,

Sorry for my late reply. Thank you very much for your informative reply. I actually applied the approach mentioned in your email to kill bunch of reindexing jobs in the queue that were caused by stopped solr service on our SEEK server.

Regarding the delay of email notification after the new user signup,  it might be related to the Active Job adapter that has a persistent backend, in our case, it is the Resque on our SEEK server. The clue came from the discussion at https://stackoverflow.com/questions/33131927/why-is-email-not-being-sent-with-activejob. I am still keeping an eye on the email issue on our SEEK server, which seems to be working well for quite some time.

Best regards,

Huiming

You received this message because you are subscribed to a topic in the Google Groups "SEEK" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/seek4science/Luq9XscqIwA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to seek4science...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/seek4science/3471e72b-1443-9a37-f75d-cbeb33985cad%40manchester.ac.uk.