[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:
Depends
is depended on by CXX-1009 mongocxx::pool should take options::p... Closed
Related

 Description   

The current configuration approach varies:

  • Some configuration options may only be set in the URI; e.g. sockettimeoutms
  • Some configuration options may only be set via code; e.g. SSL options
  • Some configuration options may be set either way: e.g. appname, minimum pool size

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 ]

Do you have a sense for which of these models will be more common in the future?

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 CDRIVER-809 we added pool size URI options as well as functions. Notice that the functions can change configuration while a pool is in use. In CDRIVER-1326 we added an "appname" URI option, but no URI option for mongoc_set_client_metadata since you shouldn't set the system metadata in your URI.

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.
Other things are really annoying only being able to set on the uri and needing therefore to manipulate connection string to tweak things.

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. CDRIVER-809 appears to be one case in point and CDRIVER-1326 followed similarly. Opening up non URI-base configuration then opens up questions of timing and immutability questions.

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 CDRIVER-809 where convenience of setting things outside the URI is taken as a reason to add configuration functions? If so, are you taking suggestions or do you already have a list of likely and unlikely candidates (or would you be willing to produce one)?

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.
There is no standard way of setting SSL options across drivers, and there is no spec that defines SSL options. Currently, our connection string parsing mostly only supports options that specs declare, and things that other drivers generally support I guess.

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?

Generated at Wed Feb 07 21:12:51 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.