Re: connection lost with concurrent transactions
От | Otto Vazquez |
---|---|
Тема | Re: connection lost with concurrent transactions |
Дата | |
Msg-id | BANLkTin_vs9Mz-j_wQG1Pe4SQ=SxKsG6Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: connection lost with concurrent transactions (maplabs@light42.com) |
Ответы |
Re: connection lost with concurrent transactions
|
Список | psycopg |
I just installed RabbitMQ in my local machine (ubuntu 10.10, postgres 8.4.8 and rabbitmq 1.8.0, other stuff is the same version) and everything worked fine.
So I tried to do the same with the dev environment (centos 5.0 final, rabbitmq 1.7.2 from epel repo). We have 6 machines: 2 cds (where tasks are executed), 2 cms and 2 db (master/slave, so only master accessible).
I have tried different RabbitMQ configuration: just in db master host, in both cds hosts, in all hosts... no way. Always getting same error:
[2011-05-16 14:20:12,084: WARNING/PoolWorker-1] /usr/lib/python2.6/site-packages/celery-2.2.4-py2.6.egg/celery/worker/job.py:114: UserWarning: Exception outside body: <class 'psycopg2.InterfaceError'>: connection already closed
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/celery-2.2.4-py2.6.egg/celery/worker/job.py", line 108, in execute_safe
return self.execute(*args, **kwargs)
File "/usr/lib/python2.6/site-packages/celery-2.2.4-py2.6.egg/celery/worker/job.py", line 129, in execute
self.loader.on_process_cleanup()
File "/usr/lib/python2.6/site-packages/django_celery-2.2.4-py2.6.egg/djcelery/loaders.py", line 67, in on_process_cleanup
self.close_database()
File "/usr/lib/python2.6/site-packages/django_celery-2.2.4-py2.6.egg/djcelery/loaders.py", line 47, in close_database
return django.db.close_connection()
File "/usr/lib/python2.6/site-packages/django/db/__init__.py", line 85, in close_connection
conn.close()
File "/usr/lib/python2.6/site-packages/django/db/backends/__init__.py", line 244, in close
self.connection.close()
InterfaceError: connection already closed
None
So now, I'm not sure if this is a matter of architecture, version bug or the connector is not working properly.
BTW, we are not using any db middleware (pgpool or pgbouncer)
Any hint before moving to MySQL?
Otto.
On Fri, May 13, 2011 at 6:49 PM, <maplabs@light42.com> wrote:
I am not an expert in django, but I can say anecdotally that my colleague did not have good luck with Celery
==
Brian Hamlin
planetwork.net
OSGeo California Chapter
(415) 717-4462 cell
On Fri, 13 May 2011 17:46:50 +0100, Daniele Varrazzo wrote:-- Sent via psycopg mailing list (psycopg@postgresql.org)
> OperationalError: no connection to the server
> We believe it's a connector problem, just google a little and you will find
> lots a posts with same/similar problem. > Some other useful info/samples:
> http://stackoverflow.com/questions/1303654/threaded-django-task-doesnt-automatically-handle-transactions-or-db-connections
> http://groups.google.com/group/django-developers/browse_frm/thread/5249b9ba993431ca/4d1b9d65329c8b75
> http://code.djangoproject.com/ticket/9964
Actually it doesn't seem the same issue to me. IIRC with the django
issue you get long running transactions. A possible consequence may be
getting errors like "current transaction is aborted...". But "no
connection to the server" is an error message I have never seen. I
wouldn't even know how to reproduce it just using psycopg: if you
issue a rollback() on a closed connection you don't get that error,
but rather a clean "InterfaceError: connection already closed".
Do you have any middleware software (pgpool etc.) handling the
connection used by psycopg? Anything interfering with the socket?
-- Daniele
To make changes to your subscription:
http://www.postgresql.org/mailpref/psycopg
В списке psycopg по дате отправления: