launchpad-dev team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

Sorry to crash the party, but the librarian isn't using a connection
pool object at all. I remember it seeing mention of tha,  but I think
this was removed very long ago. At least ever since it uses the standard
zopeless DB code. We are simply calling deferToThread for code that
calls the DB.

We don't explicitely configure a thread pool either. So it's either
unbounded or using twisted default settings. And looking at
deferToThread it seems that as many threads as required will be created:

def deferToThread(f):
    """Run the given callable in a separate thread and return a Deferred
which
    fires when the function completes.
    """
    def decorated(*args, **kwargs):
        d = defer.Deferred()
        def runInThread():
            return threads._putResultInDeferred(d, f, args, kwargs)

        t = threading.Thread(target=runInThread)
        t.start()
        return d
    return mergeFunctionMetadata(f, decorated)


On 11-09-01 05:22 PM, Michael Hudson-Doyle wrote:
> On Thu, 1 Sep 2011 22:13:41 +0700, Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx> wrote:
>> Can anyone tell me how many database connections the Librarian will
>> open up, and where this is configured?
> 
> Not off hand.  As jml said, thread pool limits and connection pool
> limits apply.
> 
>> Assuming there is a limit n, if I issue n requests will I have tested
>> every open database connection?
> 
> If you issue n concurrect requests, sure :)  If they don't overlap, I
> would expect (hope!) that connections would be reused.
> 
> Cheers,
> mwh
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~launchpad-dev
> Post to     : launchpad-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~launchpad-dev
> More help   : https://help.launchpad.net/ListHelp

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature