twitter/finagle

Problem

The choice of wording to describe stack module orientation is not fully
explained and is inconsistent.

Solution

Clarify the terminology and fix the inconsistencies.

JIRA Issues: CSL-6591

Differential Revision: https://phabricator.twitter.biz/D208799

Problem

finagle-toggle/src/main/scala/BUILD defines sources
with a recursive `rglobs` which ends up including
the `com.twitter.finagle.server` package which defines
it's own BUILD configuration thus causing confusion
and havoc for IntelliJ.

Solution

Don't use rglobs here and list out the sources
accordingly. Remove the BUILD under finagle/finagle-toggle/src/main/scala/com/twitter/finagle/toggle
as it is redundant, add finagle/finagle-toggle/src/main/scala/com/twitter/finagle/server
as an exported dependency. This should be equivalent
but without the overlapping sources.

Differential Revision: https://phabricator.twitter.biz/D209023

Problem

We're seeing a race condition in travisci where we close the reftransport and
then try to update it.

Solution

Simplify the model so that it's OK to close the reftransport and continue using
it, but we make sure to call close on every subsequent transport that it's
updated with.

JIRA Issues: CSL-6925

Differential Revision: https://phabricator.twitter.biz/D209440

Signed-off-by: Moses Nakamura <mnakamura@twitter.com>

Differential Revision: https://phabricator.twitter.biz/D208865

# Problem / Solution

We've been running push-based memcached clients since the beginning of 2018. We're now ready to remove both
the toggle and the non-push implementation.

JIRA Issues: CSL-6911

Differential Revision: https://phabricator.twitter.biz/D208047

Problem

We're on a version of jackson from October 2016, and it has a [CVE][0] against it.
Furthermore, there are bugfixes and feature improvements in new jackson, which
we would like to use.

Solution

Upgrade to the latest and greatest version of jackson.

[0]: https://nvd.nist.gov/vuln/detail/CVE-2017-7525

JIRA Issues: CSL-6599

Differential Revision: https://phabricator.twitter.biz/D204133

Problem/Solution:

The metric `srv/thrift/buffer/resetCount` was removed,
remove the doc as well.

JIRA Issues: CSL-6571

Differential Revision: https://phabricator.twitter.biz/D208352

Problem / Solution

It's been enabled for a long time and is now fundamental to how we
operate so we should remove the toggle.

JIRA Issues: CSL-6900

Differential Revision: https://phabricator.twitter.biz/D206419

…ingle executor pattern

Problem

The serial executor concurrency pattern is great for managing
concurrency but it can be tough to know what state is safe to modify
when.

Solution

Introduce some conventions for using the serial executor. First, methods
that are intended to be called from within the serial executor are
prefixed with the word `handle`. Second, fields that should only be used
from within the serial executor is prefixed with `h_`.

Example:
`def handleMutateSomeState(): Unit = { h_counter += 1 }`

Add a README.md

JIRA Issues: CSL-6784

Differential Revision: https://phabricator.twitter.biz/D203680

Problem / Solution

CHANGES got moved to CHANGELOG.rst. By leaving a symlink
we keep existing posts and whatnot working.

JIRA Issues: CSL-6799

Differential Revision: https://phabricator.twitter.biz/D207399

Problem

The CHANGELOGs display with block quotes which is not intended.

Solution

Dedent the bullet points. Also, add the changelogs to user guides
where missing.

Result

Nicer looking changelogs.

JIRA Issues: CSL-6799

Differential Revision: https://phabricator.twitter.biz/D207427

Problem:

When using the ForkJoinScheduler, in certain (rare) circumstances,
using Await can cause a deadlock.

Solution:

Like the Bridged and Local schedulers, flush() needs to be implemented
to empty the local scheduler before blocking.

JIRA Issues: CSL-6902

Differential Revision: https://phabricator.twitter.biz/D206881

Problem

`Transport`s which use `LegacyContext` prevent the removal of
deprecated methods on `Transport`. Finagle-Netty3's `ChannelTransport`
is one of those `Transport`s.

Solution

Add a `ChannelTransport` specific `ChannelTransportContext`.

Result

One less `Transport` that prevents removal of `Transport`s deprecated methods.

Differential Revision: https://phabricator.twitter.biz/D205473

…text`

Problem

`Transport`s which use `TransportContext`s which delegate
back to the original `Transport` prevent deprecated methods
from being removed from `Transport` entirely. Finagle-Netty4's
`ChannelTransport` is one of those.

Solution

Rename `Netty4Context` to `ChannelTransportContext` and change
the methods on it to stop delegating back to a `Transport`.

Result

One more `Transport` is using a proper `TransportContext` and is
no longer blocking the removal of deprecated methods on `Transport`.

Differential Revision: https://phabricator.twitter.biz/D205794

Problem

The integration tests live in `src/it` instead of `src/test` and do not have
a Pants target or a README, so it's unclear how to run them.

Solution

- Add a Pants target and add a README explaining how to run them.
- Clean up the tests by removing unnecessary imports.
- Mark failing tests as `ignore`.
- Since the tests now have a Pants target and will run in CI, we ensure that
  they run only if the `redis-server` binary exists.

JIRA Issues: CSL-6203

TBR=true

Differential Revision: https://phabricator.twitter.biz/D206380

Problem

Github renders reStructuredText (rst) files. While our changelog
is written in rst, because it does not have that as its file type
it is rendered as plain text.

Solution

Rename to CHANGELOG.rst. This uses changelog instead of changes,
which seems to be the more canonical name.

Result

Changelogs are rendered nicely in the Github UI.

Differential Revision: https://phabricator.twitter.biz/D206432

Problem

There isn't a way to see the handshake latency for tls for all protocols.

Solution
Add a stat that will measure the handshake latency

Result
It's there.

JIRA Issues: CSL-5685

Differential Revision: https://phabricator.twitter.biz/D205123

Problem / Solution

Document buffer lifecycle test for redis.

JIRA Issues: CSL-3889

Differential Revision: https://phabricator.twitter.biz/D206162

Problem

`InMemoryStatsReceiver` lazily creates the mappings for Counters and
Stats which is misleading. They would not be created until the first
`incr` and `add`, respectively.

Solution

Eagerly create the Counters and Stats at creation time.

Result

Test code now closer matches production behavior.

JIRA Issues: CSL-6751

TBR=true

Differential Revision: https://phabricator.twitter.biz/D205760

Problem

SingletonPool guards an underlying shared resource. However, it allows
interrupts to propagate directly to the underlying service acquisition
requests which can cause one interrupt (e.g. a timeout) to kill the
acquisition for others waiting on the same resource.

Solution

Instead, this behavior should be configurable and up to the discretion
of the protocol implementation to determine. We introduce a parameter
for this which is passed into the constructor for `SingletonPool`.

Differential Revision: https://phabricator.twitter.biz/D205433

…d on maxWaiters

Problem

RequestSemaphoreFilter is configured with a semaphore that's
commonly constructed with a maxWaiters of zero (e.g, configuring
maxConcurrentRequests on a server creates an AsyncSemaphore
with a maxWaiters of zero). In this case, we pay the unnecessary cost
of lock synchronization and submitting a future callback to the scheduler.

Solution

If maxWaiters is zero, create a PendingRequestFilter, which performs better.
Otherwise, create a RequestSemaphoreFilter.

Differential Revision: https://phabricator.twitter.biz/D194207

…option

Problem

Would like to be able to build servers that open sockets with the
SO_REUSEPORT option on Linux. SO_REUSEPORT allows multiple processes
to bind and accept connections from the same address and port.

Our particular use-case involves being able to support near
zero-downtime restarts with finagle servers. We'd like to be able to
start a new, simultaneously-running finagle process, listen on the
same interface and port and then gracefully shutdown the old PID when
the new process is healthy.

Solution

Support for SO_REUSEPORT is available when using the native-epoll
transport in netty4 (netty/netty@d1d8a6b). Allow this option to be
configured using Transport.Options.

Signed-off-by: Kevin Oliver <koliver@twitter.com>

JIRA Issues: CSL-6895

Differential Revision: https://phabricator.twitter.biz/D205535

Problem / Solution

There is no documentation on how interrupts are handled by the client
dispatcher. Add documentation.

JIRA Issues: CSL-6205

Differential Revision: https://phabricator.twitter.biz/D204747

Problem / Solution

Methods such as 'status' on `Transport` are deprecated in favor of the
`TransportContext` versions. However, there are certain subtle pieces
of functionality incorporated into existing Transports, which are not
being tested and make migration more difficult. `HttpTransport.status`
is one of those. Let's add a portion of a test that will fail if that
functionality is not adequately migrated.

Differential Revision: https://phabricator.twitter.biz/D205285

Problem / Solution

We need to be able to identify the various `TimeoutFactory`
modules inserted into `StackClient`. It's not possible to do
this if they have the same role, so we give them unique roles.

Differential Revision: https://phabricator.twitter.biz/D204647

Problem / Solution

We flakied a test that would infrequently show channel closed
exceptions in response to a client streaming an excessive
amount of data. It turns out that hanging up is valid server
behavior so we update the test to reflect this.

JIRA Issues: CSL-2753

Differential Revision: https://phabricator.twitter.biz/D205140

Problem

MetricBuilder's metrics were only documented on the Method Builder
page while not included on the standalone Metrics page.

Solution

Factor them out and include them in both pages. While here, there were
some RST warnings on the changelog that also got addressed.

JIRA Issues: CSL-6753

Differential Revision: https://phabricator.twitter.biz/D204782

Problem / Solution

Property tests will give up if they reject to many samples due to a
`whenever` clause in order to avoid wasting resources. Instead of
rejecting invalid values we instead only generated valid values.

JIRA Issues: CSL-6884

Differential Revision: https://phabricator.twitter.biz/D205072

Problem

There was no TLS info for clients in the generated Registry.Json.

Solution

Add the export module.

JIRA Issues: CSL-4832

Differential Revision: https://phabricator.twitter.biz/D202381

Problem

Historically, d-aperture rotated the peer ring in an attempt to avoid
hotspots on the server ring when the algorithm was based on discrete
ring coordinates. However, when we moved to a continous coordinate space,
we guarantee that the server ring is equally loaded for any given peer ring.
The peer ring rotation lives as a vestigial artifact which we rationalized
as adding some entropy to any given peer/server ring pair. This form of
entropy is poor as it generally has more chances of collisions across
peer rings.

Solution

Introduce shuffle based entropy in which each peer ring uses a well distributed
seed to shuffle its server ring. This simplifies the `PeerCoordinate` implementation
significantly and instead allows each peer ring to pass a seed to the ordering used
to sort a given server ring.

Result

More entropy in the system – each peer ring orders its target server rings
with a relatively unique seed. Concretely, this means that when nodes on the
server ring go down, load is spread more randomly across the remainder of the
apertures. For example, given the following topology (see attached), we can
construct the following scenarios:

Rotational Entropy
----------------------

PeerRingA#0 @ 100rps
(ServerRing#0, 1.0: 42rps), (ServerRing#1, 1.0: 42rps), (ServerRing#2, 1/3: 16rps)

PeerRingB#0 @ 100rps
(ServerRing#6, 1/3: 16rps), (ServerRing#0, 1.0: 42rps), (ServerRing#1, 1.0: 42rps)

ServerRing#1 goes down
ServerRing#0: 140rps
ServerRing#1: 0rps
ServerRing#2: 30rps
ServerRing#6: 30rps

Shuffle Entropy
------------------

PeerRingA#2 @ 100rps
(ServerRing#1, 1.0: 42rps), (ServerRing#4, 1.0: 42rps), (ServerRing#3, 1/3: 16rps)

PeerRingB#2 @ 100rps
(ServerRing#1, 1.0: 42rps), (ServerRing#5, 1.0: 42rps), (ServerRing#6, 1/3: 16rps)

ServerRing#1 goes down
ServerRing#1: 0rps
ServerRing#3: 30rps
ServerRing#4: 60rps
ServerRing#5: 60rps
ServerRing#6: 30rps

{F10852727}

JIRA Issues: CSL-6769

TBR=true

Differential Revision: https://phabricator.twitter.biz/D199545

Problem

Scrooge generated Thrift exceptions are part of the Finagle ecosystem.
As such, there is a desire for them to carry failure metadata.

Solution

Change the generators for Java and Scala to have exceptions implement
`c.t.finagle.FailureFlags`.

Result

Scrooge exceptions work better in the Finagle ecosystem.

JIRA Issues: CSL-6845

TBR=true

Differential Revision: https://phabricator.twitter.biz/D204132

Problem

We've seen some failures in Travis that only say that a Future was
defined but we don't know if it failed or succeeded, so it's not very
informative.

Solution

Check the structure of the result so that we can see if it failed,
succeeded, or wasn't yet defined.

JIRA Issues: CSL-6860

Differential Revision: https://phabricator.twitter.biz/D204799

Problem / Solution

The test for prepared statements handling empty strings was a no-op. Convert it
to an actual test. Also, clean up some finagle-mysql documentation.

Differential Revision: https://phabricator.twitter.biz/D204706

Problem

We would like the `newSession` promise handed back to the
user to encompass tls handshaking so that service acquisition
timeouts properly represent both the mux and tls handshake.

Solution

Wire up the `OnSslHandshakeComplete` callback into `newSession`.

Result

The `negotiatedSession` promise inside `MuxClientNegotiatingSession`
now also represent tls handshaking. It will close the session when
it is interrupted, but the behavior is gated behind a flag for now.

Differential Revision: https://phabricator.twitter.biz/D202820

Problem

A new `CursorStats` instance is created every time a MySQL client is created.
Calling `transact` creates a new service and therefore a new `CursorStats`
instance, which is unnecessary.

Solution

Move `CursorStats` creation to the `cursor` method.

JIRA Issues: CSL-6828

Differential Revision: https://phabricator.twitter.biz/D204023