[jira] Created: (COUCHDB-1004) list_to_existing_atom is too restrictive as used by couch_rep
list_to_existing_atom is too restrictive as used by couch_rep - Key: COUCHDB-1004 URL: https://issues.apache.org/jira/browse/COUCHDB-1004 Project: CouchDB Issue Type: Bug Components: Replication Environment: erlang Reporter: Bob Dionne Priority: Minor We'd like to additional information to db_info in BigCouch, such as the Q and N constants for a given database. This causes replication to fail when replicating from BigCouch to CouchDB due to the use of list_to_existing_atom in couch_rep:dbinfo(... The claim is that list_to_atom pollutes the atoms table, however superficial testing indicates this is not the case, list_to_atom when called repeatedly seems to work fine. If this is true then consider reverting list_to_existing_atom back to list_to_atom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (COUCHDB-1004) list_to_existing_atom is too restrictive as used by couch_rep
As far as I can remember, the motivation behind list_to_existing_atom was not the fact that list_to_atom pollutes the atoms table during normal operation. However, it won't prevent atom table pollution when something goes wrong or somebody goes malicious (i.e., DoS attack). I've just looked it up for you, the exact description is here: https://issues.apache.org/jira/browse/COUCHDB-829 - Klaus On Sun, 2011-01-02 at 08:06 -0500, Bob Dionne (JIRA) wrote: list_to_existing_atom is too restrictive as used by couch_rep - Key: COUCHDB-1004 URL: https://issues.apache.org/jira/browse/COUCHDB-1004 Project: CouchDB Issue Type: Bug Components: Replication Environment: erlang Reporter: Bob Dionne Priority: Minor We'd like to additional information to db_info in BigCouch, such as the Q and N constants for a given database. This causes replication to fail when replicating from BigCouch to CouchDB due to the use of list_to_existing_atom in couch_rep:dbinfo(... The claim is that list_to_atom pollutes the atoms table, however superficial testing indicates this is not the case, list_to_atom when called repeatedly seems to work fine. If this is true then consider reverting list_to_existing_atom back to list_to_atom.
Re: [jira] Created: (COUCHDB-1004) list_to_existing_atom is too restrictive as used by couch_rep
Klaus, perhaps I just heard wrong or misinterpreted what was said in the chat room. It did seem unusual that calling list_to_atom(foo) twice would add more than one atom. So just reverting the call back in couch_rep:dbinfo should suffice to fix this as it's internal. Thanks, Bob On Jan 2, 2011, at 8:26 AM, Klaus Trainer wrote: As far as I can remember, the motivation behind list_to_existing_atom was not the fact that list_to_atom pollutes the atoms table during normal operation. However, it won't prevent atom table pollution when something goes wrong or somebody goes malicious (i.e., DoS attack). I've just looked it up for you, the exact description is here: https://issues.apache.org/jira/browse/COUCHDB-829 - Klaus On Sun, 2011-01-02 at 08:06 -0500, Bob Dionne (JIRA) wrote: list_to_existing_atom is too restrictive as used by couch_rep - Key: COUCHDB-1004 URL: https://issues.apache.org/jira/browse/COUCHDB-1004 Project: CouchDB Issue Type: Bug Components: Replication Environment: erlang Reporter: Bob Dionne Priority: Minor We'd like to additional information to db_info in BigCouch, such as the Q and N constants for a given database. This causes replication to fail when replicating from BigCouch to CouchDB due to the use of list_to_existing_atom in couch_rep:dbinfo(... The claim is that list_to_atom pollutes the atoms table, however superficial testing indicates this is not the case, list_to_atom when called repeatedly seems to work fine. If this is true then consider reverting list_to_existing_atom back to list_to_atom.
Re: [jira] Created: (COUCHDB-1004) list_to_existing_atom is too restrictive as used by couch_rep
On Sun, Jan 2, 2011 at 1:48 PM, Robert Dionne dio...@dionne-associates.com wrote: Klaus, perhaps I just heard wrong or misinterpreted what was said in the chat room. It did seem unusual that calling list_to_atom(foo) twice would add more than one atom. I was wrong about that. I had the idea that I saw or heard from someone else once that two calls to list_to_atom(foobar) would create 2 entries in the atom table. Perhaps this was true with older erlang/otp versions, but certainly not with r14 at least: Eshell V5.8.2 (abort with ^G) 1 memory(atom_used). 423042 2 list_to_atom(foobar). foobar 3 memory(atom_used). 430855 4 list_to_atom(foobar). foobar 5 memory(atom_used). 430855 Going directly to the source, confirms it as well: https://github.com/erlang/otp/blob/dev/erts/emulator/beam/atom.c#L223 On Jan 2, 2011, at 8:26 AM, Klaus Trainer wrote: As far as I can remember, the motivation behind list_to_existing_atom was not the fact that list_to_atom pollutes the atoms table during normal operation. However, it won't prevent atom table pollution when something goes wrong or somebody goes malicious (i.e., DoS attack). I've just looked it up for you, the exact description is here: https://issues.apache.org/jira/browse/COUCHDB-829 - Klaus On Sun, 2011-01-02 at 08:06 -0500, Bob Dionne (JIRA) wrote: list_to_existing_atom is too restrictive as used by couch_rep - Key: COUCHDB-1004 URL: https://issues.apache.org/jira/browse/COUCHDB-1004 Project: CouchDB Issue Type: Bug Components: Replication Environment: erlang Reporter: Bob Dionne Priority: Minor We'd like to additional information to db_info in BigCouch, such as the Q and N constants for a given database. This causes replication to fail when replicating from BigCouch to CouchDB due to the use of list_to_existing_atom in couch_rep:dbinfo(... The claim is that list_to_atom pollutes the atoms table, however superficial testing indicates this is not the case, list_to_atom when called repeatedly seems to work fine. If this is true then consider reverting list_to_existing_atom back to list_to_atom. -- Filipe David Manana, fdman...@gmail.com, fdman...@apache.org Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men.
