• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

evalphobia / logrus_sentry
83%
master: 81%

Build:
Build:
LAST BUILD BRANCH: v0.8.2
DEFAULT BRANCH: master
Repo Added 07 Oct 2015 03:38AM UTC
Files 4
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

LAST BUILD ON BRANCH v0.4.0
branch: v0.4.0
CHANGE BRANCH
x
Reset
  • v0.4.0
  • feature/add-ci-badges
  • feature/add-filter
  • feature/add-license
  • feature/logrus-trace-level
  • feature/move-stacktrace-test
  • feature/sentry-error-handler
  • feature/travis-go1.10
  • feature/travis-go1.8
  • feature/travisci
  • feature/update-travis
  • issue/20
  • issue/22
  • issue/42
  • issue/69
  • master
  • revert-35-master
  • v0.2.0
  • v0.2.1
  • v0.2.10
  • v0.2.11
  • v0.2.12
  • v0.2.13
  • v0.2.14
  • v0.2.2
  • v0.2.3
  • v0.2.4
  • v0.2.5
  • v0.2.6
  • v0.2.7
  • v0.2.8
  • v0.2.9
  • v0.3.0
  • v0.4.1
  • v0.4.2
  • v0.4.3
  • v0.4.4
  • v0.4.5
  • v0.4.6
  • v0.5.0
  • v0.5.1
  • v0.7.0
  • v0.8.0
  • v0.8.1
  • v0.8.2
  • v0.9.0

pending completion
103

push

travis-ci

evalphobia
Stop double-buffering in async hook (#47)

The underlying Raven Sentry client already is asynchronous with an adjustable
buffer size. Unlike the buffer in logrus_sentry, Raven drops packets when the
buffer is filled (and calls an optional DropHandler when it does so).

The existing implementation of async hooks does not drop packets when its buffer
fills, which means that the so-called "async" hook becomes synchronous if the
buffer fills, and the Raven packet-dropping logic most likely never has a chance
to do its tricks.  In our service, we discovered that bugs that caused errors to
spew to Sentry via logrus_sentry quickly hit this buffer's limit and caused our
service to stall, despite the supposedly "async" nature of the hook.

This commit changes logrus_sentry's async mode to be truly asynchronous: it
delivers packets to Raven, which either passes them to its background worker or
drops them if its buffer is full.  It then starts a new goroutine per packet to
log any errors and coordinate with the WaitGroup for flush.

The previous version of the code set a 1 second Timeout for async mode, which
effectively just allowed the worker goroutine to send the next packet to Raven
after 1 second.  Because we no longer have a separate worker goroutine, this
is no longer necessary.  A comment also mentions how to set a timeout for the
underlying HTTP POST, which achieves a similar goal of allowing Flush to finish
in a bounded amount of time.

Note that Raven's buffer size (100) is smaller than logrus_sentry's old buffer
size (8192), so users may want to increase raven.MaxQueueBuffer before
contructing the hook to avoid dropping packets.

Also follow the normal Go style of putting mutexes before the fields they
protect in struct definitions.

298 of 357 relevant lines covered (83.47%)

82.97 hits per line

Relevant lines Covered
Build:
Build:
357 RELEVANT LINES 298 COVERED LINES
82.97 HITS PER LINE
Source Files on v0.4.0
  • List 0
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
103 v0.4.0 Stop double-buffering in async hook (#47) The underlying Raven Sentry client already is asynchronous with an adjustable buffer size. Unlike the buffer in logrus_sentry, Raven drops packets when the buffer is filled (and calls an optional DropHa... push 14 Jun 2017 01:43AM UTC evalphobia travis-ci pending completion  
See All Builds (164)
  • Repo on GitHub
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2025 Coveralls, Inc