Packages

object resources extends Helpful

Annotations
@Summary(s = "Functionality for managing resources", flag = console.this.Help.Summary.<init>$default$2) @Group(name = "Resource Management")
Linear Supertypes
Helpful, AnyRef, Any
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. resources
  2. Helpful
  3. AnyRef
  4. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Value Members

  1. def help(methodName: String)(implicit consoleEnvironment: ConsoleEnvironment): Unit
    Definition Classes
    Helpful
    Annotations
    @Summary(s = "Help for specific commands (use help() or help(\"method\") for more information)", flag = console.this.Help.Summary.<init>$default$2) @Topic(t = Seq("Top-level Commands"))
  2. def help()(implicit consoleEnvironment: ConsoleEnvironment): Unit
    Definition Classes
    Helpful
  3. def resource_limits(): ResourceLimits
    Annotations
    @Summary(s = "Get the resource limits of the participant.", flag = console.this.Help.Summary.<init>$default$2)
  4. def set_resource_limits(limits: ResourceLimits): Unit
    Annotations
    @Summary(s = "Set resource limits for the participant.", flag = console.this.Help.Summary.<init>$default$2) @Description(s = """While a resource limit is attained or exceeded, the participant will reject any additional submission with GRPC status ABORTED.
    |Most importantly, a submission will be rejected **before** it consumes a significant amount of resources.
    |
    |There are three kinds of limits: `maxDirtyRequests`, `maxRate` and `maxBurstFactor`.
    |The number of dirty requests of a participant P covers (1) requests initiated by P as well as
    |(2) requests initiated by participants other than P that need to be validated by P.
    |Compared to the maximum rate, the maximum number of dirty requests reflects the load on the participant more accurately.
    |However, the maximum number of dirty requests alone does not protect the system from "bursts":
    |If an application submits a huge number of commands at once, the maximum number of dirty requests will likely
    |be exceeded, as the system is registering dirty requests only during validation and not already during
    |submission.
    |
    |The maximum rate is a hard limit on the rate of commands submitted to this participant through the ledger API.
    |As the rate of commands is checked and updated immediately after receiving a new command submission,
    |an application cannot exceed the maximum rate.
    |
    |The `maxBurstFactor` parameter (positive, default 0.5) allows to configure how permissive the rate limitation should be
    |with respect to bursts. The rate limiting will be enforced strictly after having observed `max_burst` * `max_rate` commands.
    |
    |For the sake of illustration, let's assume the configured rate limit is ``100 commands/s`` with a burst ratio of 0.5.
    |If an application submits 100 commands within a single second, waiting exactly 10 milliseconds between consecutive commands,
    |then the participant will accept all commands.
    |With a `maxBurstFactor` of 0.5, the participant will accept the first 50 commands and reject the remaining 50.
    |If the application then waits another 500 ms, it may submit another burst of 50 commands. If it waits 250 ms,
    |it may submit only a burst of 25 commands.
    |
    |Resource limits can only be changed, if the server runs Canton enterprise.
    |In the community edition, the server uses fixed limits that cannot be changed."""    )