- 1.53.0 (latest)
- 1.52.0
- 1.51.0
- 1.49.0
- 1.48.0
- 1.47.0
- 1.46.0
- 1.45.0
- 1.44.0
- 1.43.0
- 1.42.0
- 1.41.0
- 1.40.0
- 1.39.0
- 1.37.0
- 1.36.0
- 1.35.0
- 1.34.0
- 1.33.0
- 1.32.0
- 1.31.0
- 1.30.0
- 1.29.0
- 1.28.0
- 1.27.0
- 1.24.0
- 1.23.0
- 1.22.0
- 1.21.0
- 1.20.0
- 1.19.0
- 1.18.0
- 1.17.0
- 1.16.0
- 1.15.0
- 1.14.0
- 1.13.0
- 1.12.0
- 1.11.0
- 1.9.0
- 1.8.0
- 1.7.0
- 1.6.0
- 1.5.0
- 1.4.0
- 1.1.10
The interfaces provided are listed below, along with usage samples.
Controller2Client
Service Description: The Controller service provides the API for orchestrating a collection of debugger agents to perform debugging tasks. These agents are each attached to a process of an application which may include one or more replicas.
The debugger agents register with the Controller to identify the application being debugged,
the Debuggee. All agents that register with the same data, represent the same Debuggee, and are
assigned the same debuggee_id
.
The debugger agents call the Controller to retrieve the list of active Breakpoints. Agents
with the same debuggee_id
get the same breakpoints list. An agent that can fulfill the
breakpoint request updates the Controller with the breakpoint result. The controller selects the
first result received and discards the rest of the results. Agents that poll again for active
breakpoints will no longer have the completed breakpoint in the list and should remove that
breakpoint from their attached process.
The Controller service does not provide a way to retrieve the results of a completed breakpoint. This functionality is available using the Debugger service.
Sample for Controller2Client:
try (Controller2Client controller2Client = Controller2Client.create()) {
Debuggee debuggee = Debuggee.newBuilder().build();
RegisterDebuggeeResponse response = controller2Client.registerDebuggee(debuggee);
}
Debugger2Client
Service Description: The Debugger service provides the API that allows users to collect run-time information from a running application, without stopping or slowing it down and without modifying its state. An application may include one or more replicated processes performing the same work.
A debugged application is represented using the Debuggee concept. The Debugger service provides a way to query for available debuggees, but does not provide a way to create one. A debuggee is created using the Controller service, usually by running a debugger agent with the application.
The Debugger service enables the client to set one or more Breakpoints on a Debuggee and collect the results of the set Breakpoints.
Sample for Debugger2Client:
try (Debugger2Client debugger2Client = Debugger2Client.create()) {
String debuggeeId = "debuggeeId-1833285553";
Breakpoint breakpoint = Breakpoint.newBuilder().build();
String clientVersion = "clientVersion771880589";
SetBreakpointResponse response =
debugger2Client.setBreakpoint(debuggeeId, breakpoint, clientVersion);
}
Classes
Controller2Client
Service Description: The Controller service provides the API for orchestrating a collection of debugger agents to perform debugging tasks. These agents are each attached to a process of an application which may include one or more replicas.
The debugger agents register with the Controller to identify the application being debugged,
the Debuggee. All agents that register with the same data, represent the same Debuggee, and are
assigned the same debuggee_id
.
The debugger agents call the Controller to retrieve the list of active Breakpoints. Agents
with the same debuggee_id
get the same breakpoints list. An agent that can fulfill the
breakpoint request updates the Controller with the breakpoint result. The controller selects the
first result received and discards the rest of the results. Agents that poll again for active
breakpoints will no longer have the completed breakpoint in the list and should remove that
breakpoint from their attached process.
The Controller service does not provide a way to retrieve the results of a completed breakpoint. This functionality is available using the Debugger service.
This class provides the ability to make remote calls to the backing service through method calls that map to API methods. Sample code to get started:
try (Controller2Client controller2Client = Controller2Client.create()) {
Debuggee debuggee = Debuggee.newBuilder().build();
RegisterDebuggeeResponse response = controller2Client.registerDebuggee(debuggee);
}
Note: close() needs to be called on the Controller2Client object to clean up resources such as threads. In the example above, try-with-resources is used, which automatically calls close().
The surface of this class includes several types of Java methods for each of the API's methods:
- A "flattened" method. With this type of method, the fields of the request type have been converted into function parameters. It may be the case that not all fields are available as parameters, and not every API method will have a flattened method entry point.
- A "request object" method. This type of method only takes one parameter, a request object, which must be constructed before the call. Not every API method will have a request object method.
- A "callable" method. This type of method takes no parameters and returns an immutable API callable object, which can be used to initiate calls to the service.
See the individual methods for example code.
Many parameters require resource names to be formatted in a particular way. To assist with these names, this class includes a format method for each type of name, and additionally a parse method to extract the individual identifiers contained within names that are returned.
This class can be customized by passing in a custom instance of Controller2Settings to create(). For example:
To customize credentials:
Controller2Settings controller2Settings =
Controller2Settings.newBuilder()
.setCredentialsProvider(FixedCredentialsProvider.create(myCredentials))
.build();
Controller2Client controller2Client = Controller2Client.create(controller2Settings);
To customize the endpoint:
Controller2Settings controller2Settings =
Controller2Settings.newBuilder().setEndpoint(myEndpoint).build();
Controller2Client controller2Client = Controller2Client.create(controller2Settings);
Please refer to the GitHub repository's samples for more quickstart code snippets.
Controller2Settings
Settings class to configure an instance of Controller2Client.
The default instance has everything set to sensible defaults:
- The default service address (clouddebugger.googleapis.com) and default port (443) are used.
- Credentials are acquired automatically through Application Default Credentials.
- Retries are configured for idempotent methods but not for non-idempotent methods.
The builder of this class is recursive, so contained classes are themselves builders. When build() is called, the tree of builders is called to create the complete settings object.
For example, to set the total timeout of registerDebuggee to 30 seconds:
Controller2Settings.Builder controller2SettingsBuilder = Controller2Settings.newBuilder();
controller2SettingsBuilder
.registerDebuggeeSettings()
.setRetrySettings(
controller2SettingsBuilder
.registerDebuggeeSettings()
.getRetrySettings()
.toBuilder()
.setTotalTimeout(Duration.ofSeconds(30))
.build());
Controller2Settings controller2Settings = controller2SettingsBuilder.build();
Controller2Settings.Builder
Builder for Controller2Settings.
Debugger2Client
Service Description: The Debugger service provides the API that allows users to collect run-time information from a running application, without stopping or slowing it down and without modifying its state. An application may include one or more replicated processes performing the same work.
A debugged application is represented using the Debuggee concept. The Debugger service provides a way to query for available debuggees, but does not provide a way to create one. A debuggee is created using the Controller service, usually by running a debugger agent with the application.
The Debugger service enables the client to set one or more Breakpoints on a Debuggee and collect the results of the set Breakpoints.
This class provides the ability to make remote calls to the backing service through method calls that map to API methods. Sample code to get started:
try (Debugger2Client debugger2Client = Debugger2Client.create()) {
String debuggeeId = "debuggeeId-1833285553";
Breakpoint breakpoint = Breakpoint.newBuilder().build();
String clientVersion = "clientVersion771880589";
SetBreakpointResponse response =
debugger2Client.setBreakpoint(debuggeeId, breakpoint, clientVersion);
}
Note: close() needs to be called on the Debugger2Client object to clean up resources such as threads. In the example above, try-with-resources is used, which automatically calls close().
The surface of this class includes several types of Java methods for each of the API's methods:
- A "flattened" method. With this type of method, the fields of the request type have been converted into function parameters. It may be the case that not all fields are available as parameters, and not every API method will have a flattened method entry point.
- A "request object" method. This type of method only takes one parameter, a request object, which must be constructed before the call. Not every API method will have a request object method.
- A "callable" method. This type of method takes no parameters and returns an immutable API callable object, which can be used to initiate calls to the service.
See the individual methods for example code.
Many parameters require resource names to be formatted in a particular way. To assist with these names, this class includes a format method for each type of name, and additionally a parse method to extract the individual identifiers contained within names that are returned.
This class can be customized by passing in a custom instance of Debugger2Settings to create(). For example:
To customize credentials:
Debugger2Settings debugger2Settings =
Debugger2Settings.newBuilder()
.setCredentialsProvider(FixedCredentialsProvider.create(myCredentials))
.build();
Debugger2Client debugger2Client = Debugger2Client.create(debugger2Settings);
To customize the endpoint:
Debugger2Settings debugger2Settings =
Debugger2Settings.newBuilder().setEndpoint(myEndpoint).build();
Debugger2Client debugger2Client = Debugger2Client.create(debugger2Settings);
Please refer to the GitHub repository's samples for more quickstart code snippets.
Debugger2Settings
Settings class to configure an instance of Debugger2Client.
The default instance has everything set to sensible defaults:
- The default service address (clouddebugger.googleapis.com) and default port (443) are used.
- Credentials are acquired automatically through Application Default Credentials.
- Retries are configured for idempotent methods but not for non-idempotent methods.
The builder of this class is recursive, so contained classes are themselves builders. When build() is called, the tree of builders is called to create the complete settings object.
For example, to set the total timeout of setBreakpoint to 30 seconds:
Debugger2Settings.Builder debugger2SettingsBuilder = Debugger2Settings.newBuilder();
debugger2SettingsBuilder
.setBreakpointSettings()
.setRetrySettings(
debugger2SettingsBuilder
.setBreakpointSettings()
.getRetrySettings()
.toBuilder()
.setTotalTimeout(Duration.ofSeconds(30))
.build());
Debugger2Settings debugger2Settings = debugger2SettingsBuilder.build();
Debugger2Settings.Builder
Builder for Debugger2Settings.