Class MassiveStreamServiceCollectionExtensions

Namespace

Microsoft.Extensions.DependencyInjection

Assembly

MassiveDotNet.Extensions.DependencyInjection.dll

Registers the Massive streaming client.

public static class MassiveStreamServiceCollectionExtensions

Inheritance

object

MassiveStreamServiceCollectionExtensions

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Methods

AddMassiveStream(IServiceCollection, Action<MassiveStreamOptions>)

Registers MassiveStreamClient as a singleton, configured by configure.

public static IServiceCollection AddMassiveStream(this IServiceCollection services, Action<MassiveStreamOptions> configure)

Parameters

services IServiceCollection

The service collection.

configure Action<MassiveStreamOptions>

Configures the options. The API key is required.

Returns

IServiceCollection

The service collection, for chaining.

Remarks

There is no IConfiguration overload, for D27's reason: the options carry NodaTime Duration values the configuration binder silently leaves at their defaults. Read the values yourself — options.ApiKey = configuration["Massive:ApiKey"].

Exceptions

ArgumentNullException

services or configure is null.

LogStreamHealth(MassiveStockStream, ILogger)

Reports drops and reconnects on the application's logger.

public static void LogStreamHealth(this MassiveStockStream stream, ILogger logger)

Parameters

stream MassiveStockStream

The stream to watch.

logger ILogger

The logger.

Remarks

D-W4's accepted cost is that a consumer who never reads a subscription's own DroppedCount loses data quietly. This is what narrows it: rule 8 confines Microsoft.Extensions.* to this package, so the bridge lives here and core never learns that logging exists.

F7 (Task 12 review round 1): this used to take one MassiveTopicSubscription<T> and read its DroppedCount directly, which had no correct calling pattern for a consumer streaming more than one topic -- calling it once per subscription registered a separate Reconnected handler each time, so every reconnect was logged once per topic; calling it once covered only the one topic it was given, so every other topic's drops went unreported. DropObserved now carries the topic code and that topic's own running count, so one subscription here, regardless of how many topics the stream ever opens, reports every one of them honestly.

Exceptions

ArgumentNullException

stream or logger is null.