Skip to content

Commit 0cde8fa

Browse files
Update docs/using-the-python-driver/using-plugins/UsingTheLimitlessPlugin.md
Co-authored-by: Aaron <[email protected]>
1 parent 2e3b78b commit 0cde8fa

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

docs/using-the-python-driver/using-plugins/UsingTheLimitlessPlugin.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ The URL used to connect to a limitless database is the DB shard group URL.
2828
| `limitless_transaction_router_monitor_interval_ms` | Integer | No | This property is the interval in milliseconds, that the plugin polls the database for available transaction routers and their load metrics. A lower value will increase the frequency of polling, and a higher value will decrease the frequency of polling. <br><br>Note that there will always be a delay between when the database updates its load metric info and when the Limitless Plugin polls for it. If your Limitlessdatabase experiences fluctuating load between transaction routers, you may want to consider lowering `limitlessTransactionRouterMonitorIntervalMs` to reduce this delay and ensure the Limitless Plugin load balancing has fresher info to work with. <br><br>The default value of this property is 7.5 seconds. This is half the interval that the database updates its load metric metadata. This value was chosen as a compromise between having fresher load metric info, but also being conscious of the associated overhead. | `7500` | `30000` |
2929
| `limitless_transaction_router_monitor_disposal_time_ms` | Integer | No | This property is the time in milliseconds that a Limitlesstransaction router monitor can remain unused before it is disposed. This ensures that in periods of long inactivity, the database isn't being needlessly polled and the resources associated with the monitor can be cleaned up. Note that when a new connection is created, a new Limitlesstransaction router monitor will also be created to resume polling the database. | `600000` | `300000` |
3030
| `limitless_max_retries_ms` | Integer | No | This property is the max number of retries the Limitless Plugin will attempt when failing to connect to the database. During these retries, the plugin will attempt to connect to the least loaded transaction router that is available. If the max number of connection retries is exceeded, then the plugin will throw a `AwsWrapperError`. In this scenario, it is likely that the database is in an unhealthy state, and the `AwsWrapperError` should be caught and handled by your application. | `5` | `13` |
31-
| `limitless_wait_for_transaction_router_info` | Boolean | No | In scenarios such as application start-up, the cache of available transaction routers and their load metric info will be empty. If `limitlessWaitForTransactionRouterInfo` is set to `true`, the plugin will wait until the cache is populated before selecting a transaction router and connecting to it. This may be beneficial for applications that create a large number of connections on start-up, since these connections will be load-balanced. <br><br>Alternatively, if this property set to `false` and the cache is empty, the plugin will not wait for the cache to be populated and default to using the DB Shard Group endpoint to connect to until the cache is populated. This will result in connections being routed to a transaction router via Route 53 until the cache is populated. This may be beneficial for applications that prioritize quicker start-up times at the expense of some early connections not being load-balanced by the Limitless Plugin. | True | False |
31+
| `limitless_wait_for_transaction_router_info` | Boolean | No | In scenarios such as application start-up, the cache of available transaction routers and their load metric info will be empty. If `limitlessWaitForTransactionRouterInfo` is set to `True`, the plugin will wait until the cache is populated before selecting a transaction router and connecting to it. This may be beneficial for applications that create a large number of connections on start-up, since these connections will be load-balanced. <br><br>Alternatively, if this property set to `False` and the cache is empty, the plugin will not wait for the cache to be populated and default to using the DB Shard Group endpoint to connect to until the cache is populated. This will result in connections being routed to a transaction router via Route 53 until the cache is populated. This may be beneficial for applications that prioritize quicker start-up times at the expense of some early connections not being load-balanced by the Limitless Plugin. | True | False |
3232
| `limitless_get_transaction_router_max_retries` | Integer | No | This property is the max number of times the Limitless Plugin will retry fetching available transaction routers and their load metrics. These retries will occur if the fetched transaction router information is `None` or empty. If this max is reached, a `AwsWrapperError` will be thrown. In this scenario, it is likely that the database is in an unhealthy state, and the thrown `AwsWrapperError` should be caught and handled by your application. <br><br>If your application prioritizes failing fast, then consider a lower value for this property. However, if your application prioritizes durability, then consider a higher value. | `5` | `10` |
3333
| `limitless_get_transaction_router_retry_interval_ms` | Integer | No | This property is the interval in milliseconds between retries of fetching available transaction routers and their load metrics. <br><br>If your application prioritizes failing fast, then consider a lower value for this property. However, if your application prioritizes durability, then consider a higher value. | `300` | `1000` |
3434

0 commit comments

Comments
 (0)