couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1495) Allow the UUID algorithm to vary by database
Date Mon, 11 Jun 2012 17:26:42 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13292899#comment-13292899
] 

Paul Joseph Davis commented on COUCHDB-1495:
--------------------------------------------

There've been enough requests I remember people having asked for things before. But I can't
say its been a super pressing issue.

The comment about the gen_server blowing up isn't due to space. The general break down happens
when you have clients making more requests than a single process can handle. Ie, consider
a node under high load. If there's enough clients requesting UUID's it can get to the point
where that single gen_server can't process messages as fast as they arrive. And if you let
that go on long enough then that server's mailbox will eventually exhaust system memory and
reboot the entire VM. Not to mention that lots of requests will be basically halted which
causes user visible errors due to timeouts waiting for a new uuid. But don't worry too much
about those details. If you get around to writing code we'll take care of that during a review.
                
> Allow the UUID algorithm to vary by database
> --------------------------------------------
>
>                 Key: COUCHDB-1495
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1495
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: Database Core
>    Affects Versions: 1.2
>            Reporter: Nick North
>            Priority: Minor
>              Labels: uuid
>
> The UUID algorithm for generating document ids is currently a global setting, affecting
all databases. When returning to https://issues.apache.org/jira/browse/COUCHDB-1373 after
a long hiatus, I realised it might be useful to allow a default algorithm, with per-database
overrides.
> I propose that the uuids section of the config be of the following form, modelled somewhat
on the compactions section:
> algorithm = AlgorithmName
> overrides = [ {DatabaseName, AlgorithmName, [ { ParamName, ParamValue}, {ParamName, ParamValue},
...]},
>                    {DatabaseName, AlgorithmName, [ { ParamName, ParamValue}, {ParamName,
ParamValue}, ...]}, ...]
> The "algorithm" element is exactly as it now is, specifying the default UUID algorithm,
to be used when the algorithm is not overridden and for responding to the _uuids HTTP request.
It also gives backwards compatibility.
> The optional "overrides" element specifies algorithms for named databases, each with
a list of algorithm-specific parameters. The list may be empty (or potentially absent altogether,
which would have the same meaning as an empty list).
> The special database name _default is used to specify a default algorithm that needs
parameters or instead or the "algorithm" element.
> Implementation would be by giving the couch_uuids gen_server a state consisting of a
dictionary mapping database names to an {AlgorithmName, AlgorithmState} pair, where AlgorithmState
is an algorithm-dependent value and the default algorithm is associated with database name
_default. Requests for a UUID for a specific database would pass in the database name for
use in determining the right algorithm. [This gives rise to a potential objection to the proposal,
as there is a performance hit: every new document id requires a dictionary lookup of the database
name, and possibly a second lookup of the _default entry if the name is not found; there may
also be a dictionary insertion of the new AlgorithmState value. However, I suggest that is
small compared to everything else that goes on when creating a document.]
> If people like this idea, I am happy to put forward some code, and wrap in the implementation
of https://issues.apache.org/jira/browse/COUCHDB-1373, which I have neglected for far too
long. The two proposals are not necessarily tied together, but implementing this one changes
the implementation of the other so it is more convenient to do both together.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message