Skip to content

sentry-ruby-v4.1.0

Choose a tag to compare

@HazAT HazAT released this 18 Dec 10:21
· 1209 commits to master since this release
  • Separate rack integration #1138
  • Fix event sampling #1144
  • Merge & rename 2 Rack middlewares #1147
    • Fixes #1153
    • Removed Sentry::Rack::Tracing middleware and renamed Sentry::Rack::CaptureException to Sentry::Rack::CaptureExceptions.
  • Deep-copy spans #1148
  • Move span recorder related code from Span to Transaction #1149
  • Check SDK initialization before running integrations #1151
  • Refactor transport #1154
  • Implement non-blocking event sending #1155
    • Added background_worker_threads configuration option.

Noticeable Changes

Middleware Changes

Sentry::Rack::Tracing is now removed. And Sentry::Rack::CaptureException has been renamed to Sentry::Rack::CaptureExceptions.

Events Are Sent Asynchronously

sentry-ruby now sends events asynchronously by default. The functionality works like this:

  1. When the SDK is initialized, a Sentry::BackgroundWorker will be initialized too.
  2. When an event is passed to Client#capture_event, instead of sending it directly with Client#send_event, we'll let the worker do it.
  3. The worker will have a number of threads. And the one of the idle threads will pick the job and call Client#send_event.
    • If all the threads are busy, new jobs will be put into a queue, which has a limit of 30.
    • If the queue size is exceeded, new events will be dropped.

However, if you still prefer to use your own async approach, that's totally fine. If you have config.async set, the worker won't initialize a thread pool and won't be used either.

This functionality also introduces a new background_worker_threads config option. It allows you to decide how many threads should the worker hold. By default, the value will be the number of the processors your machine has. For example, if your machine has 4 processors, the value would be 4.

Of course, you can always override the value to fit your use cases, like

config.background_worker_threads = 5 # the worker will have 5 threads for sending events

You can also disable this new non-blocking behaviour by giving a 0 value:

config.background_worker_threads = 0 # all events will be sent synchronously