# Conflicts:
#	StackExchange.Redis/StackExchange/Redis/RawResult.cs

fix pathological case when consuming *really really* buffers (SMEMBERS on 5M rows for example) - have BufferReader keep a SequencePosition "snapshot", and compute sub-buffers using that

(also fixes bug where LoggingPipe wasn't using the right thresholds, but that's a debug tool only)

Make SetPopMultiple available on RedisFeatures; use in test; test for explicit single SPOP; add fast zero SPOP

fix #875 - string encode was failing to encode correctly (also make more consistent use of GetReference)

The Streams data type is available in release 5.0 RC1 and above.

- Implemented Sync & Async methods for all Stream related commands (minus the blocking options) as of 5.0 RC1.
- Added tests for the synchronous versions of the Streams API but the testing is a work in progress. Need to refactor for reuse within the streams tests and write a more thorough suite of tests.
- Added a NameValueEntry struct which mimicks HashEntry. Using HashEntry for the name/value pairs of stream entries seemed wrong. Perhaps refactor the usage of HashEntry to the more generic NameValueEntry and deprecate HashEntry?

This API was missing - resolves #203

This may just not make sense anymore, but let's log and look at the numbers.

Resolves #855

Twemproxy handles this internally - we were incorrectly blocking it.

This was correct before, not sure how we convinced ourselves otherwise. I added additional verification checks to the tests.

Ensure that pre-handshake backlog is completed successfully; also simplify how sent messages get the exception recorded; can massively simplify if we know we've already burned the connection

Known breaking change and intended for 2.0. See #809 for details - pretty much for unit testing.

Better handling for null an empty values to SetRemove(Async), Redis will throw here so there's no reason we can't gracefully hamdle it better.

This is interesting, and may explain some other hangs. Previously, arr was null, and the .Length call in the MultiBulk case was throwing a null ref. This doesn't throw externally through, it just runs forever. While there's a timeout guard against this on the ExecuteSync path, there's not on ExecuteAsync. This is easy to reproduce for example add this at the top of the result processor:

if (result.Type == ResultType.MultiBulk) throw new Exception("Woops");

...and we'll only see timeouts on sync and forever runs on async. I left this code in (commented) for an easy repro case.

/cc @mgravell

This isn't the source of our timeouts...as there aren't running. But cleaning up usages.

Turns out @mgravell really really liked "foo" and "hashset" years ago =P