Re: connection lost with concurrent transactions

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(at)light42(dot)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(dot)vazquez(at)gmail(dot)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(at)postgresql(dot)org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/psycopg
>>
>>
>>
>
>