For the inspiration, look here:
https://websauna.org/docs/narrative/misc/task.html
On Thu, 10 Jan 2019 at 14:27, Zsolt Ero wrote:
> So I guess the simplest possible solution is Celery + Redis (since I'm
> already using Redis for sessions), I guess?
>
> On Thu, 10 Jan 2019 at 13:55, Thierry
On Thursday, January 10, 2019 at 8:27:35 AM UTC-5, Zsolt Ero wrote:
>
> So I guess the simplest possible solution is Celery + Redis (since I'm
> already using Redis for sessions), I guess?
>
>
Yes. The performance you want requires a secondary process to handle the
event logging. Celery is
I've found dramatiq to be a better alternative to celery for these types of
tasks.
https://dramatiq.io/v1.4.3/index.html
On Thu, Jan 10, 2019 at 8:27 AM Zsolt Ero wrote:
> So I guess the simplest possible solution is Celery + Redis (since I'm
> already using Redis for sessions), I guess?
>
>
So I guess the simplest possible solution is Celery + Redis (since I'm
already using Redis for sessions), I guess?
On Thu, 10 Jan 2019 at 13:55, Thierry Florac wrote:
>
> Hi,
>
> After-commit hooks don't work in async mode!
> They allow to declare callbacks which will be called after transaction
Hi,
After-commit hooks don't work in async mode!
They allow to declare callbacks which will be called after transaction
commit, but server is waiting for these callbacks to be finished (in
synchronous mode) before sending response to client.
If you need async mode, you have (at least) to start
Actually, it doesn't result in async-like behaviour, the client is
still waiting for the function inside the commit hook. I guess I don't
understand the concept then.
On Thu, 10 Jan 2019 at 13:15, Zsolt Ero wrote:
>
> I'm just now implementing this. Are you saying that basically, by using
>
I'm just now implementing this. Are you saying that basically, by using
addAfterCommitHook, I can replace put relatively fast (say, <10 seconds),
functions into async-like behaviour, without requiring any external queue
service?
old:
# send email was an async function, via a decorator (using
On Mon, Nov 12, 2018 at 4:29 AM Mikko Ohtamaa
wrote:
>
> https://stackoverflow.com/questions/15593516/how-to-run-a-script-after-pyramids-transaction-manager-has-returned
>
> Please not that thread local `transaction.manager` might be discouraged
> nowadays, but not sure what is the best practice
> My problem is that while 99% of the views make read-only requests to the
> database, and thus are very fast, the analytics event is a writing and can
> be slow occasionally.
>
You can do post commit actions with SQLAlchemy and zope.sqlaclhemy.
1. Response gets served
2. Database transaction
I have several use cases where a request generates long operations (for
example, for doing conversion of an uploaded video file) but I want that
the end user receives the response as soon as possible (here, before
conversion ends).
In these cases, if the long operation is not impacted by the
are free to decide in which cycle, with which tools to continue.
Andi
From: on behalf of Zsolt Ero
Reply-To:
Date: Saturday, 10. November 2018 at 23:25
To: pylons-discuss
Subject: [pylons-discuss] processing after responding to client
On a fairly classic Pyramid app (sync, gunicorn
On a fairly classic Pyramid app (sync, gunicorn, SQLAlchemy / Postgresql,
like the starter template), I am storing analytics-like events in a table
for some of my views.
Like this skeleton:
@view_config(route_name='test', request_method='POST', renderer='json')
def test(request):
# body of
12 matches
Mail list logo
