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:

On Fri, May 13, 2011 at 5:12 PM, Otto Vazquez <otto.vazquez@gmail.com> wrote:

> 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

-- Sent via psycopg mailing list (psycopg@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/psycopg





В списке psycopg по дате отправления:

Предыдущее
От: Joe Abbate
Дата:
Сообщение: Re: python to postgresql crud application example needed
Следующее
От: Daniele Varrazzo
Дата:
Сообщение: Re: connection lost with concurrent transactions