[CDRIVER-1001] Keep SDAM status (and connections to servers) in between multiple invocations to mongoc_client_new_from_uri Created: 17/Nov/15 Updated: 03/May/17 Resolved: 28/Jan/16 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Critical - P2 |
| Reporter: | Derick Rethans | Assignee: | A. Jesse Jiryu Davis |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
I would like to request functionality that keeps SDAM status and connections in between calls to mongoc_client_new_from_uri. A PHP request is basically a request for an URL. Because PHP shares nothing among requests (not even the mongoc_client_t), the SDAM state is also not kept in between requests. Right now, PHPC only keeps connections in between PHP requests through persistent connections, a feature of PHP, where as HHVM does not do that either. My request is that the CDRIVER has a mode (or something else), where SDAM states for equivalent mongoc_client_t structures are kept even though the mongoc_client_t gets destroyed and created. And, in addition to keeping the SDAM state around, also connections that are managed by the CDRIVER itself. This is what the legacy PHP driver does as well, as to optimise checking server states, and not reconnecting to i.e. every replicaset member on each request. |
| Comments |
| Comment by Jeremy Mikola [ 29/Aug/16 ] | |
Just to follow-up, HHVM-123 ended up persisting individual mongoc_client_t objects between requests (hashed by the URI and other options used to create it) instead of using the pool API. | |
| Comment by A. Jesse Jiryu Davis [ 28/Jan/16 ] | |
|
Closing this for now, feel free to reopen if there's anything the C Driver needs to do to support the HHVM driver. | |
| Comment by A. Jesse Jiryu Davis [ 26/Jan/16 ] | |
|
HHVM driver will use mongoc_client_pool_new to create a pool on demand: http://api.mongodb.org/c/current/mongoc_client_pool_new.html ... then pop a client from the pool, use it, and return it. The pool maintains topology info and keeps it up to date with a background pthread. (More info about monitoring implementation here.) The pool's max size (default 100) counts clients in the pool and clients currently checked out. Derick is concerned that PHP workers can die from errors without returning clients to the pool. Setting maxPoolSize=INT32_MAX will prevent leaks from eventually deadlocking the application, something like:
(That's 2 to the 31st, minus 1.) If we're very concerned that a buggy applicaiton could leak more than INT32_MAX clients before restarting, we can create a new feature for pools with unlimited max size. | |
| Comment by Derick Rethans [ 26/Jan/16 ] | |
|
jesse and I just had this meeting. It seems we could use a pool, and link it through a hash with a "connection string + options" together. | |
| Comment by Derick Rethans [ 18/Nov/15 ] | |
|
No, because I don't know which URI / connection string people are going to use. Per PHP request, this URL can be totally different, and I can't keep a mongoc_client_pool_t between requests I believe - I would need to construct them up front... which I can't do as I don't know what to construct it for. Happy to chat about this if you'd like! | |
| Comment by A. Jesse Jiryu Davis [ 17/Nov/15 ] | |
|
Can you use a mongoc_client_pool_t? The pool implements this behavior. |