[CDRIVER-1546] What is the expected direction for client/pool options? Created: 16/Sep/16 Updated: 11/Sep/19 Resolved: 19/Sep/16 |
|
| Status: | Closed |
| Project: | C Driver |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 1.5.0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | David Golden | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Description |
|
The current configuration approach varies:
Do you have a sense for which of these models will be more common in the future? Do you expect that options for a pool will always remain a superset of the options for a client? |
| Comments |
| Comment by David Golden [ 19/Sep/16 ] |
|
Great. I think we've got what we need to make decisions. Thank you jesse and bjori. |
| Comment by A. Jesse Jiryu Davis [ 19/Sep/16 ] |
|
No, I don't have a sense of which will be more common. As Hannes said, it depends on what the feature is: if it can be set in the URI, we'll add it to the URI. If it can't be set in the URI, we'll add a function. If it can be set in the URI but it would be useful to provide a function, we'll add it to the URI and also provide a function. Changing SSL options after you've begun opening connections is obviously a bad idea. =) Please refer again to CDRIVER-938. |
| Comment by David Golden [ 19/Sep/16 ] |
I think that's the only question not directly addressed. Saying "sometimes we also add functions for configuration" leaves it pretty wide open. We're just trying to understand if the C driver is moving generally towards "more knobs" to set things in the application since recent additions seem to favoring that approach. If the idea is that it will be handled case-by-case, that's fine, too, and we'll consider that in our own design. I'm also a bit surprised that SSL options are mutable. Does that mean that someone could change PEM files and new connections (pool or reconnect) would use the new credentials? Could there be a pool situation with some clients with old and new PEM files at the same time? (Feature or a bug?) |
| Comment by A. Jesse Jiryu Davis [ 19/Sep/16 ] |
|
Yes pool options must be a superset of client options. If we added a client option that you couldn't set on a pool, then there'd be no way to use it in pooled mode, since you shouldn't change the configuration of pooled clients (CDRIVER-938). Our philosophy is, "configuration is set in the URI unless it can't be set there, and sometimes we also add functions for configuration". In Other specific questions? |
| Comment by Hannes Magnusson [ 19/Sep/16 ] |
|
I think the same answer applies. We are very pragmatic. It is really weird being forced to tune connection pool only with a connection string. A connection string may be set by a sysadmin, containing probably only hostname and credentials. It really annoying not having a way to provide ssl options here, we maybe should do something about that in the future. ReadPreferences, ReadConcern, WriteConcern, are all examples of specs that expect being able to set things both in connection uri and at various other levels. Maybe someone finds a usecase where you should be able to set serverselectiontimeoutms or heartbeatfrequencyms per op, and we'll adapt for that. On the other hand, setting allocators for example isn't going to be a connection string option. |
| Comment by David Golden [ 18/Sep/16 ] |
|
bjori, IIRC, historically, the C driver configuration model appeared to be "configuration is set in the URI unless it can't be set there". At some point, this philosophy changed. It looks like some connection-oriented settings can't be changed after the handshake (e.g appname). But it looks like other things (e.g. SSL opts) can. So I'm asking "is there a configuration model that guides libmongoc design decisions?" Or is it a stochastic design based on how the committer de jour reacts to feature requests and specs? Should we expect other changes like The C++ driver team is trying to understand how best to model configuration with the least amount of impedance mismatch to libmongoc. Our model to date has been minimal because the C driver offered minimal knobs. To the extent you are offering more knobs, we may want to follow along – but we may also choose not to follow along if the selection of knobs is incomplete or haphazard (e.g. to forestall user requests for knobs that aren't easy or possible to translate to libmongoc.) Specifically with regard to pool configuration, we're trying to understand how to model pool options versus client options. Right now, libmongoc pool configuration more or less duplicates client duplication, except for the addition of min/max pool size. That suggests we might be able to model pool options as containing a client options model, plus pool-specific options. However, if that superset approach isn't going to be maintained by libmongoc, then we may want to model pool options directly rather than via an intermediate client options model. So we're asking "is libmongoc committing to ensure that pool configuration is a superset of client configuration" (which seems likely) so we can resolve our own configuration modeling design questions. |
| Comment by Hannes Magnusson [ 16/Sep/16 ] |
|
Certain specifications requires possibility to set values as part of the connection string. Certain specs make certain values, like appname, configurable both as part of connection string, and suggest allowing setting it on the client, as providing a value like appname would be weird in shared connection strings. Is there a specific options you are worried about support in the future? |