-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revise Shutdown and Draining section #1512
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,11 +1,18 @@ | ||
The client provides a `Flush` method that takes the time in `time.Duration` for how long it waits and will return a boolean that indicates whether everything was flushed or the timeout kicked in. | ||
To avoid unintentionally dropping events when the program terminates, arrange | ||
for `sentry.Flush` to be called, typically using `defer`. | ||
|
||
If you use multiple clients, arrange for each of them to be flushed as | ||
appropriate. | ||
|
||
`Flush` waits until any buffered events are sent to the Sentry server, blocking | ||
for at most the given timeout. It returns `false` if the timeout was reached. In | ||
that case, some events may not have been sent. | ||
|
||
```go | ||
sentry.CaptureMessage("my message") | ||
func main() { | ||
// err := sentry.Init(...) | ||
defer sentry.Flush(2 * time.Second) | ||
|
||
if sentry.Flush(time.Second * 2) { | ||
fmt.Println("All queued events delivered!") | ||
} else { | ||
fmt.Println("Flush timeout reached") | ||
Comment on lines
-6
to
-9
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I intentionally omit checking on the return value of Printing debug messages is redundant, and the same visibility can be achieved by enabling debug logging on the SDK. There's nothing useful users can do if |
||
sentry.CaptureMessage("my message") | ||
} | ||
``` |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,12 +1,15 @@ | ||
The client provides a close method that optionally takes the time in milliseconds for how long it | ||
waits and will return a promise that resolves when everything was flushed or the timeout kicked | ||
The `close` method optionally takes a timeout in milliseconds and returns a | ||
promise that resolves when all pending events are flushed, or the timeout kicks | ||
in. | ||
|
||
```javascript | ||
const client = Sentry.getCurrentHub().getClient(); | ||
if (client) { | ||
client.close(2000).then(function() { | ||
process.exit(); | ||
}); | ||
} | ||
Sentry.close(2000).then(function() { | ||
process.exit(); | ||
}); | ||
rhcarvalho marked this conversation as resolved.
Show resolved
Hide resolved
|
||
``` | ||
|
||
After a call to `close`, the current client cannot be used anymore. It's | ||
important to only call `close` immediately before shutting down the application. | ||
|
||
Alternatively, the `flush` method drains the event queue while keeping the | ||
client enabled for continued use. | ||
rhcarvalho marked this conversation as resolved.
Show resolved
Hide resolved
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,3 +8,9 @@ client = Hub.current.client | |
if client is not None: | ||
client.close(timeout=2.0) | ||
``` | ||
|
||
After a call to `close`, the client cannot be used anymore. It's important to | ||
only call `close` immediately before shutting down the application. | ||
|
||
Alternatively, the `flush` method drains the event queue while keeping the | ||
client enabled for continued use. | ||
Comment on lines
+15
to
+16
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would understand if @untitaker would rather omit this note. Thoughts? |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,11 +2,14 @@ When the Rust SDK initializes a guard is returned from the `init` function. The | |
will automatically wait `shutdown_timeout` seconds. This means you just need to hold on to | ||
the guard and make sure it disposes on shutdown. Alternatively the client can be closed: | ||
|
||
```javascript | ||
```rust | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ooops 😄 |
||
use std::time::Duration; | ||
use sentry::Hub; | ||
|
||
if let Some(client) = Hub.current().client() { | ||
client.close(Some(Duration::from_secs(2))); | ||
} | ||
``` | ||
|
||
After a call to `close`, the client cannot be used anymore. It's important to | ||
only call `close` immediately before shutting down the application. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3,15 +3,9 @@ title: 'Shutdown and Draining' | |
sidebar_order: 1 | ||
--- | ||
|
||
Most SDKs use a background queue to send out events. Because the queue sends asynchronously in the background | ||
it means that some events might be lost if the application shuts down unexpectedly. To prevent this all SDKs | ||
provide mechanisms to cope with this. | ||
Comment on lines
-6
to
-8
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Reworded. |
||
|
||
Typically SDKs provide two ways to shut down: a controlled shutdown where the system will wait up to about two | ||
seconds to flush out events (configurable) and an uncontrolled shutdown (also referred to as "killing" the | ||
client). | ||
Comment on lines
-10
to
-12
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This doesn't sound useful to me. It is a generic statement, and unclear whether it applies to the SDK the user is interested in. Each language/platform from the dropdown includes the relevant mechanisms that exist in that language/platform. |
||
The default behavior of most SDKs is to send out events over the network | ||
asynchronously in the background. This means that some events might be lost if | ||
the application shuts down unexpectedly. The SDKs provide mechanisms to cope | ||
with this. | ||
|
||
{% include components/platform_content.html content_dir='drain-example' %} | ||
|
||
After shutdown the client cannot be used any more so make sure to only do that right before you shut down | ||
the application. | ||
Comment on lines
-16
to
-17
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Moved this to the languages/platforms where it applies. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we want to add a similar note for other languages?