Forums

I have a 'hacker' account. I'm trying to send sign-up emails asynchronously using Flask mail. But thread that sends email stops after getting started. It continues if I start accessing the site and works till something is being requested on the site. Is this because threads are not enabled? I'm getting a message on my server log saying: *** Python threads support is disabled. You can enable it with --enable-threads *** How do I enable threads?

Hi there, threads are not supported I'm afraid.

For sending sign-up emails, you've got a couple of choices:

• you could set up a task queue, use a scheduled task that polls in a loop to see if needs to send emails. Check out this guide to long-running tasks

• or you could just send the emails synchronously. how much do you think it's delaying your requests by?

Yeah, I'm sending the emails synchronously. It works okay and doesn't take up a lot of time at the moment. I hope it doesn't become a problem in the future. I'll look into your first suggestion. Thanks for the reply!

Not having support for threads seems to be a major limitation, or in fact a deal-breaker in terms of keeping an account. I need to run threads for tasks that take 3-4 seconds - basically I am analyzing some data in the background. The server log says something about using the --enable-threading flag, but there are not suggestions on how this is done. In fact, trying "python --enable-threading" does not work. So I am stuck, but I need to have background threads to keep my web server responsive.

Have you considered doing the background processing using scheduled tasks or something like that?

What I have is a background thread that can also be regularly queried to monitor the progress of the thead. I will take a look at scheduled tasks, and see if this functionality could fulfill my needs without a major rewrite. But I am also curious why Pythonanywhere has disabled threading? Is threading something that we could see enabled in the near future? Thanks!

The main problem with threading is the way it interacts with multiple worker processes. You have a free account, so there's one worker process handling your requests. If you had a paid account, there could be multiple worker processes. None of them would really be aware of the others in any useful sense (in theory, they could even be running on different physical machines). So if you were planning on having a fixed number of background threads processing stuff, there would have to be one background thread per worker, which probably lead to coordination issues. Different hits from a specific browser session could go to any one of the worker threads, so if a task was kicked off by one user, there's no guarantee they'd ever come back to a worker process that knew anything about it.

(Of course, there are simple cases where this just isn't a problem, like the one that started this forum topic -- spinning off a short-lived thread to perform a simple task like sending an email, and not requiring anything to monitor its progress. That's something we might be able to look into.)

Are threads enabled with paid accounts? I have an analysis that takes a couple minutes to run, and really should run asynchronously. Launching these as queued tasks on an hourly basis doesn't really work for me.

Not for web apps, no. You could add a bunch of worker scheduled tasks, all running the same script, one on the hour, one at five minutes past, and so on. Alternatively, you could use the trick here to have a constantly-running task that could process the incoming tasks and put the results in a well-known place, like in the database.

Thanks. The long-running task approach could work.

spinning off a short-lived thread to perform a simple task like sending an email, and not requiring anything to monitor its progress. That's something we might be able to look into

I arrived at this thread because of a problem with exactly that. I've made it single threaded for now, but it caught me by surprise!

I have been prepping my application and my PythonAnywhere account to be used as my production environment.

As part of this preparation I recently added Sentry for error reporting and bug tracking (https://sentry.io/). While it works for the most part, I am seeing some errors popping up as the result of not having uwsgi threads enabled.

Have there been any developments on this?

If using Sentry is not supported, what method of error report gathering and logging/reporting/tracking does PythonAnywhere support?

There are no changes to our thread support, but I think you should be able to get Sentry working fine if you specify a non-threaded transport. It looks like you just need to construct your Client object using, say, the RequestsHTTPTransport

Being new to Sentry I was unaware that I could change the Transport. I've implemented your suggestion and will see how it goes. Thanks, giles.

I have been having this issue, finally got around to trying to fix it but is seems I am running into a similar block as @DukeLetoII,

The solution RequestsHTTPTransport does not work on the new Sentry Unified Python SDK.

Done a bit of googling but can't seem to find anything, and anywhere this forum is miles better than StackOverflow.... :)

This is no biggie at the moment, but if anyone has any info on how to solve this on pythonanywhere without the old raven.transport.requests I'm interested.

Do you get any specific errors if you use the new SDK as-is (for example, "please enable threads" or something along those lines)?

Hi. Yep.

Warning: We detected the use of uwsgi with disabled threads.  This will cause issues with the transport you are trying to use.  Please enable threading for uwsgi.  (Enable the "enable-threads" flag).

Sentry does work fine though - even if there is a sudden flood of errors.

Hmm, interesting -- so you're getting alerts when things go wrong despite the warning? If so, perhaps you can ignore it for now.

(We have plans to enable threading in websites, but no timeline right now.)

Yep - it's all good. I just have a.... thing... for warnings in logs....

Thanks :)

We're looking to send follow-up emails 5 days after a user submits a form on our site (which is a Flask app). We can think of two solutions:

• use AP Scheduler: really easy code-wise (https://github.com/eAbsentee/eAbsentee/commit/e0e3008a9d14bcf6983c36b4e5ffb60d85adfb64). We tried and it works locally, but not on PythonAnywhere because threads aren't supported)
• use a scheduled task: each day, query the DB to see which users submitted in the past 5 days and send emails to those users. This is less precise than the first option because emails won't be submitted exactly 5 days after submission

We prefer the first option for the reason mentioned above. Is there any timeline on when threads will be supported?

We don't have a timeline, no. I'd also be concerned with a system like AP Scheduler because your website isn't guaranteed to be running all of the time -- if it has little or no traffic, it might shut down and then be restarted the next time it gets a hit, so emails would be delayed under those circumstances. It might also be confused by the multiprocessing -- I don't know if it handles the case where you have multiple instances of your website running at the same time to handle large amounts of traffic, which can be the case on PythonAnywhere.

PYTHONANYWHERE IS SHITTTT!!!!!!!!!!!!!!

Sorry to hear you feel that way

Your server log states "2021-11-12 06:43:04 *** Python threads support is disabled. You can enable it with --enable-threads ***".....is this true or do you still disable threads?

Threads in web apps do not work on PythonAnywhere.

If I only need a limited amount of workers, is there a way to enable this? I have a limited amount of background work to do, but it is important to start it via a background task due to the processing time to lookup information.

No, there is no way to enable threading, but you could take a look at how to do background work in web apps here: https://blog.pythonanywhere.com/198/

Is there any way to have a end-ser Defined background process that will not terminate the process if the connection time-out is reached

Have a look at this help page.