lanto03 / couchdb-python

Automatically exported from code.google.com/p/couchdb-python
Other
0 stars 0 forks source link

Couchdb connection lost without error #213

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
My code contains lots of query in a remote couchdb database. The code begins to 
run. After a while, it is just frozen. Any output or error are not given. When 
I check the connection, I observe that the couchdb database connection has been 
lost. It still busies the cpu without doing anything(it seems so). What may be 
the reason of connection loss? Can I check the connection status in python so 
that I can open new one if the current one is closed? My related code is:

def addNewDnsRecord(self, record):
     if self.checkHashValue(record['hashValue']):
         ....                           #some code to generate an id
         record['_id'] = tempid
         self.bulk.append(record)       #add record at the end of the bulk

         if len(self.bulk) == 1000:     #bulk with 1000 records are inserted
              self.dns_db.update(self.bulk)
              self.bulk = []

def checkHashValue(self, hashValue):
    result = self.dns_db.view('records/hashcheck', None, key=hashValue)
    if len(result) == 0:
          return True
    else:
          return False

Couchdb :  1.0.1
Python : 2.6.5
Operating system of server which code runs: Ubuntu 10.04
Operating System of server which couchdb runs: Ubuntu 12.04

Any help is appreciated

Original issue reported on code.google.com by shn...@gmail.com on 20 Jul 2012 at 11:51

GoogleCodeExporter commented 8 years ago
Which version of couchdb-python you're using? Is there something in CouchDB 
logs 
about? Could you reproduce problem on current tip revision from repository?

If you're still got this problem, could you provide full version of test script 
that could reproduce it? Actually, your code is quite common - I'm using same 
approach to upload millions documents without any problems and at least now 
connection is autoopening on request if it got "outdated". That's why your 
problem sounds strange for me. Thanks!

Original comment by kxepal on 21 Jul 2012 at 4:23

GoogleCodeExporter commented 8 years ago
In couch.log file, this lines are written:
[Mon, 23 Jul 2012 21:33:01 GMT] [error] [<0.63.0>] {error_report,<0.24.0>,
              {<0.63.0>,crash_report,
               [[{initial_call,{mochiweb_socket_server,init,['Argument__1']}},
                 {pid,<0.63.0>},
                 {registered_name,[]},
                 {error_info,{exit,eaddrinuse,
                                   [{gen_server,init_it,6},
                                    {proc_lib,init_p_do_apply,3}]}},
                 {ancestors,[couch_secondary_services,couch_server_sup,
                             <0.2.0>]},
                 {messages,[]},
                 {links,[<0.53.0>]},
                 {dictionary,[]},
                 {trap_exit,true},
                 {status,running},
                 {heap_size,1597},
                 {stack_size,24},
                 {reductions,446}],
                []]}}

I also updated the python version to 2.7.3. Anything hasn't changed. 
Couchdb-python version is 0.8.0

Original comment by shn...@gmail.com on 23 Jul 2012 at 9:38

GoogleCodeExporter commented 8 years ago
> eaddrinuse
It looks like CouchDB couldn't open socket for your ip:port pair because some 
another application is already done it or because there are too much opened 
connections to CouchDB so you have exhaust all available ports for new 
connections.

Could you play with lsof or netstat utility to track down how much connections 
are opened from couchdb-python to your server? Also, please try to reproduce 
situation on latest tip from repo, because since 0.8 release there was major 
changes in http client module that may eventually get fixed some negative 
behavior - I've failed to do it by myself for synthetic tests.

Original comment by kxepal on 24 Jul 2012 at 12:00

GoogleCodeExporter commented 8 years ago
Closing as WORKSFORME.

Original comment by djc.ochtman on 21 Sep 2012 at 8:07