v1.8.0-rc.3

Enhancements

• Consumer connected only to the followers by @Gsantomaggio in #352
• Check the entity status during the close by @Gsantomaggio in #353
• Add Chunk info consumer side by @Gsantomaggio in #355
• Remove code duplication to handle the pool by @Gsantomaggio in #356

Full Changelog: v1.8.0-rc.2...v1.8.0-rc.3

What's new in 1.8

The 1.8 focus are:

• Multiple Consumers and Producers per connection
• Improve the reconnection for stream and super stream.

The high-level classes Consumer and Producer don't introduce breaking changes.
The RawSuperStream* classes change the default behaviour. Please take a look at the section 3.

1. Multiple Consumers and Producers per connection

The RabbitMQ stream protocol supports multi-producers and multi-consumers per TCP Connection.
This version introduces the connection pool for Consumers and Producers.

There is a new ConnectionPoolConfig setting:

new StreamSystemConfig {
  ConnectionPoolConfig = new ConnectionPoolConfig()
 {
  ConsumersPerConnection = 10, 
   ProducersPerConnection = 10, 
 }
};

ConsumersPerConnection == The number of consumers per connection min 1 max 200 default is 1
ProducersPerConnection == The number of producers per connection min 1 max 200 default is 1

Each connection can handle different streams; see the image:

Performances

Sharing the same connection for multiple streams reduces the number of connections, but it could impact the performances:

• Consumer side. If one consumer is slow, it can also affect the other consumers
• Producer side: If all the producers are at full rate, it can reduce the performances

The proper parameter depends on your environment.

Tip

You can use different StreamSystemConfig like:

configToReduceTheConnections = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
    ConsumersPerConnection = 50, // high value 
    ProducersPerConnection = 50,  // high value
  }
}

configToIncreaseThePerformances = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
		ConsumersPerConnection = 1, // low value 
		ProducersPerConnection = 1,  // low value
  }
}

There are many combinations from 1 to 200.

2. Improve the reconnections

Handle streamNotAvailable, Add disconnection Info: #343

Improve the super stream reconnection: #344

Increase the backoff strategy time: #345

Please follow this document If you want to know more about what happens during a broker restart.

The focus is to improve the reconnection during the cluster restart.

3. Raw Super stream events

Removed the auto-reconnect. The RawSuperStreamProducer and RawSuperStreamConsumer classes now expose two events:

#344

**NOTE: If you are using these classes, the auto-reconnect is removed to be compliant with all the Raw* classes. **

You should use Consumer and Producer unless for a specific use case.

For Raw* users:

• Super Stream: during the disconnection, it is possible to understand the disconnection cause and reconnect the stream like:

var consumer = await system.CreateSuperStreamConsumer(configuration);
        var completed = new TaskCompletionSource<bool>();
        configuration.ConnectionClosedHandler = async (reason, stream) =>
        {
            if (reason == ConnectionClosedReason.Unexpected)
            {
                await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false)
                );
                completed.SetResult(true);
            }
        };

The same is true for the standard consumer.

• Metadata update

 MetadataHandler = async update =>
 {
    await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false));
                        
 }   

4. Add events to Producer and Consumer classes

See: #349

See also: https://github.com/rabbitmq/rabbitmq-stream-dotnet-client/tree/main/docs/ReliableClient
where you can find an example of how to use StatusChanged

 producerConfig.StatusChanged += (status) =>
  {
   var streamInfo = status.Partition is not null
      ? $" Partition {status.Partition} of super stream: {status.Stream}"
      : $"Stream: {status.Stream}";

       lp.LogInformation("Producer: {Id} - status changed from {From} to {To}. {Info}",
                              status.Identifier,
                              status.From,
                              status.To, streamInfo);

       if (status.To == ReliableEntityStatus.Open)
       {
          publishEvent.Set();
       }
       else
       {
          publishEvent.Reset();
         }};

5. Update Secret

See #342

v1.8.0-rc.2

Enhancements

• Update secret functionality by @simone-fariselli in #342

Full Changelog: v1.8.0-rc.1...v1.8.0-rc.2

What's new in 1.8

The 1.8 focus are:

• Multiple Consumers and Producers per connection
• Improve the reconnection for stream and super stream.

The high-level classes Consumer and Producer don't introduce breaking changes.
The RawSuperStream* classes change the default behaviour. Please take a look at the section 3.

1. Multiple Consumers and Producers per connection

The RabbitMQ stream protocol supports multi-producers and multi-consumers per TCP Connection.
This version introduces the connection pool for Consumers and Producers.

There is a new ConnectionPoolConfig setting:

new StreamSystemConfig {
  ConnectionPoolConfig = new ConnectionPoolConfig()
 {
  ConsumersPerConnection = 10, 
   ProducersPerConnection = 10, 
 }
};

ConsumersPerConnection == The number of consumers per connection min 1 max 200 default is 1
ProducersPerConnection == The number of producers per connection min 1 max 200 default is 1

Each connection can handle different streams; see the image:

Performances

Sharing the same connection for multiple streams reduces the number of connections, but it could impact the performances:

• Consumer side. If one consumer is slow, it can also affect the other consumers
• Producer side: If all the producers are at full rate, it can reduce the performances

The proper parameter depends on your environment.

Tip

You can use different StreamSystemConfig like:

configToReduceTheConnections = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
    ConsumersPerConnection = 50, // high value 
    ProducersPerConnection = 50,  // high value
  }
}

configToIncreaseThePerformances = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
		ConsumersPerConnection = 1, // low value 
		ProducersPerConnection = 1,  // low value
  }
}

There are many combinations from 1 to 200.

2. Improve the reconnections

Handle streamNotAvailable, Add disconnection Info: #343

Improve the super stream reconnection: #344

Increase the backoff strategy time: #345

Please follow this document If you want to know more about what happens during a broker restart.

The focus is to improve the reconnection during the cluster restart.

3. Raw Super stream events

Removed the auto-reconnect. The RawSuperStreamProducer and RawSuperStreamConsumer classes now expose two events:

#344

**NOTE: If you are using these classes, the auto-reconnect is removed to be compliant with all the Raw* classes. **

You should use Consumer and Producer unless for a specific use case.

For Raw* users:

• Super Stream: during the disconnection, it is possible to understand the disconnection cause and reconnect the stream like:

var consumer = await system.CreateSuperStreamConsumer(configuration);
        var completed = new TaskCompletionSource<bool>();
        configuration.ConnectionClosedHandler = async (reason, stream) =>
        {
            if (reason == ConnectionClosedReason.Unexpected)
            {
                await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false)
                );
                completed.SetResult(true);
            }
        };

The same is true for the standard consumer.

• Metadata update

 MetadataHandler = async update =>
 {
    await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false));
                        
 }   

4. Add events to Producer and Consumer classes

See: #349

See also: https://github.com/rabbitmq/rabbitmq-stream-dotnet-client/tree/main/docs/ReliableClient
where you can find an example of how to use StatusChanged

 producerConfig.StatusChanged += (status) =>
  {
   var streamInfo = status.Partition is not null
      ? $" Partition {status.Partition} of super stream: {status.Stream}"
      : $"Stream: {status.Stream}";

       lp.LogInformation("Producer: {Id} - status changed from {From} to {To}. {Info}",
                              status.Identifier,
                              status.From,
                              status.To, streamInfo);

       if (status.To == ReliableEntityStatus.Open)
       {
          publishEvent.Set();
       }
       else
       {
          publishEvent.Reset();
         }};

5. Update Secret

See #342

v1.8.0-rc.1

Enhancements

• Add Producer/Consumer Identifier by @Gsantomaggio in #348
• Add event status changed by @Gsantomaggio in #349

Full Changelog: v1.8.0-beta.2...v1.8.0-rc.1

What's new in 1.8

The 1.8 focus are:

• Multiple Consumers and Producers per connection
• Improve the reconnection for stream and super stream.

The high-level classes Consumer and Producer don't introduce breaking changes.
The RawSuperStream* classes change the default behaviour. Please take a look at the section 3.

1. Multiple Consumers and Producers per connection

The RabbitMQ stream protocol supports multi-producers and multi-consumers per TCP Connection.
This version introduces the connection pool for Consumers and Producers.

There is a new ConnectionPoolConfig setting:

new StreamSystemConfig {
  ConnectionPoolConfig = new ConnectionPoolConfig()
 {
  ConsumersPerConnection = 10, 
   ProducersPerConnection = 10, 
 }
};

ConsumersPerConnection == The number of consumers per connection min 1 max 200 default is 1
ProducersPerConnection == The number of producers per connection min 1 max 200 default is 1

Each connection can handle different streams; see the image:

Performances

Sharing the same connection for multiple streams reduces the number of connections, but it could impact the performances:

• Consumer side. If one consumer is slow, it can also affect the other consumers
• Producer side: If all the producers are at full rate, it can reduce the performances

The proper parameter depends on your environment.

Tip

You can use different StreamSystemConfig like:

configToReduceTheConnections = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
    ConsumersPerConnection = 50, // high value 
    ProducersPerConnection = 50,  // high value
  }
}

configToIncreaseThePerformances = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
		ConsumersPerConnection = 1, // low value 
		ProducersPerConnection = 1,  // low value
  }
}

There are many combinations from 1 to 200.

2. Improve the reconnections

Handle streamNotAvailable, Add disconnection Info: #343

Improve the super stream reconnection: #344

Increase the backoff strategy time: #345

Please follow this document If you want to know more about what happens during a broker restart.

The focus is to improve the reconnection during the cluster restart.

3. Raw Super stream events

Removed the auto-reconnect. The RawSuperStreamProducer and RawSuperStreamConsumer classes now expose two events:

#344

**NOTE: If you are using these classes, the auto-reconnect is removed to be compliant with all the Raw* classes. **

You should use Consumer and Producer unless for a specific use case.

For Raw* users:

• Super Stream: during the disconnection, it is possible to understand the disconnection cause and reconnect the stream like:

var consumer = await system.CreateSuperStreamConsumer(configuration);
        var completed = new TaskCompletionSource<bool>();
        configuration.ConnectionClosedHandler = async (reason, stream) =>
        {
            if (reason == ConnectionClosedReason.Unexpected)
            {
                await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false)
                );
                completed.SetResult(true);
            }
        };

The same is true for the standard consumer.

• Metadata update

 MetadataHandler = async update =>
 {
    await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false));
                        
 }   

4. Add events to Producer and Consumer classes

See: #349

See also: https://github.com/rabbitmq/rabbitmq-stream-dotnet-client/tree/main/docs/ReliableClient
where you can find an example of how to use StatusChanged

 producerConfig.StatusChanged += (status) =>
  {
   var streamInfo = status.Partition is not null
      ? $" Partition {status.Partition} of super stream: {status.Stream}"
      : $"Stream: {status.Stream}";

       lp.LogInformation("Producer: {Id} - status changed from {From} to {To}. {Info}",
                              status.Identifier,
                              status.From,
                              status.To, streamInfo);

       if (status.To == ReliableEntityStatus.Open)
       {
          publishEvent.Set();
       }
       else
       {
          publishEvent.Reset();
         }};

v.1.8.0-beta.2

Enhancements

• Improve the rawProducer and rawSuperStreamProducer status by @Gsantomaggio in #337
• Handle cancellation token during the consumer close by @Gsantomaggio in #339
• Update license to Broadcom by @Gsantomaggio in #341
• Improve Reconnection by @Gsantomaggio in #343
• Improve the super stream reconnection by @Gsantomaggio in #344
• Increase the backoff strategy time by @Gsantomaggio in #345

Full Changelog: v1.8.0-beta.1...v1.8.0-beta.2

What's new in 1.8

The 1.8 focus are:

• Multiple Consumers and Producers per connection
• Improve the reconnection for stream and super stream.

The high-level classes Consumer and Producer don't introduce breaking changes.
The RawSuperStream* classes change the default behaviour. Please take a look at the section 3.

1. Multiple Consumers and Producers per connection

The RabbitMQ stream protocol supports multi-producers and multi-consumers per TCP Connection.
This version introduces the connection pool for Consumers and Producers.

There is a new ConnectionPoolConfig setting:

new StreamSystemConfig {
  ConnectionPoolConfig = new ConnectionPoolConfig()
 {
		ConsumersPerConnection = 10, 
		ProducersPerConnection = 10, 
 }
};

ConsumersPerConnection == The number of consumers per connection min 1 max 200 default is 1
ProducersPerConnection == The number of producers per connection min 1 max 200 default is 1

Each connection can handle different streams; see the image:

Performances

Sharing the same connection for multiple streams reduces the number of connections, but it could impact the performances:

• Consumer side. If one consumer is slow, it can also affect the other consumers
• Producer side: If all the producers are at full rate, it can reduce the performances

The proper parameter depends on your environment.

Tip

You can use different StreamSystemConfig like:

configToReduceTheConnections = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
    ConsumersPerConnection = 50, // high value 
    ProducersPerConnection = 50,  // high value
  }
}

configToIncreaseThePerformances = new StreamSystemConfig{
 ConnectionPoolConfig = new ConnectionPoolConfig() {
		ConsumersPerConnection = 1, // low value 
		ProducersPerConnection = 1,  // low value
  }
}

There are many combinations from 1 to 200.

2. Improve the reconnections

Handle streamNotAvailable, Add disconnection Info: #343

Improve the super stream reconnection: #344

Increase the backoff strategy time: #345

Please follow this document If you want to know more about what happens during a broker restart.

The focus is to improve the reconnection during the cluster restart.

3. Raw Super stream events

Removed the auto-reconnect. The RawSuperStreamProducer and RawSuperStreamConsumer classes now expose two events:

#344

**NOTE: If you are using these classes, the auto-reconnect is removed to be compliant with all the Raw* classes. **

You should use Consumer and Producer unless for a specific use case.

For Raw* users:

• Super Stream: during the disconnection, it is possible to understand the disconnection cause and reconnect the stream like:

var consumer = await system.CreateSuperStreamConsumer(configuration);
        var completed = new TaskCompletionSource<bool>();
        configuration.ConnectionClosedHandler = async (reason, stream) =>
        {
            if (reason == ConnectionClosedReason.Unexpected)
            {
                await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false)
                );
                completed.SetResult(true);
            }
        };

The same is true for the standard consumer.

• Metadata update

 MetadataHandler = async update =>
 {
    await consumer.ReconnectPartition(
                    await system.StreamInfo(stream).ConfigureAwait(false));
                        
 }   

v.1.8.0-beta.1

Enhancements

• Multiple Producers and Consumers per connection by @Gsantomaggio in #328
• New event to handle Metadata update by @Gsantomaggio in #332

Bug Fixes

• Fix connections to a server on different locales by @Noonlord in #329

To Read

The RabbitMQ stream protocol supports multi-producers and multi-consumers per TCP Connection.
This version introduces the connection pool for Consumers and Producers.

There is a new ConnectionPoolConfig setting:

       new StreamSystemConfig
        {
            ConnectionPoolConfig = new ConnectionPoolConfig()
            {
                ConsumersPerConnection = 10, 
                ProducersPerConnection = 10, 
            }
        };

ConsumersPerConnection == The number of consumers per connection min 1 max 255 default is 1
ProducersPerConnection == The number of producers per connection min 1 max 255 default is 1

Each connection can handle different streams; see the image:

Performances

Sharing the same connection for multiple streams reduces the number of connections, but it could impact the performances:

• Consumer side. If one consumer is slow, it can also affect the other consumers
• Producer side: If all the producers are at full-rate, it can reduce the performances

The proper parameter depends on your environment.

Tip

You can use different StreamSystemConfig like:

configToReduceTheConnections = new StreamSystemConfig
        {
 ConnectionPoolConfig = new ConnectionPoolConfig()
            {
                ConsumersPerConnection = 50, // high value 
                ProducersPerConnection = 50,  // high value
            }
}

configToIncreaseThePerformances = new StreamSystemConfig
        {
 ConnectionPoolConfig = new ConnectionPoolConfig()
            {
                ConsumersPerConnection = 1, // low value 
                ProducersPerConnection = 1,  // low value
            }
}

There are many combinations from 1 to 255.

New Contributors

• @Noonlord made their first contribution in #329

Full Changelog: v1.7.4...v1.8.0-beta.1

v1.7.4

Enhancements

• Increase the timeout for publish confirmation from 3s to 10s by @Gsantomaggio in #325. Note: it is always possible to configure the timeout on the config:

new ProducerConfig(system, stream)
{
   TimeoutMessageAfter = TimeSpan.FromSeconds(2), // here

• Bump versions by @lukebakken in #324

Full Changelog: v1.7.3...v1.7.4

v1.7.3

Enhancements

• Add Info class to the Producer/Consumer classes by @Gsantomaggio in #322 and #323 It is possible to get the stream and the reference

Full Changelog: v1.7.2...v1.7.3

v1.7.2

Enhancements

• Add DateTimeOffset test by @Gsantomaggio in #307
• Force localhost connections when the client connects to localhost by @Zerpet in #305
• Removed unused class MyMethodAttribute from Producer.cs by @TroelsL in #312
• Improve test speed by @Gsantomaggio in #308
• Add docs to timestamp offset; add additional constructors by @ricsiLT in #303

Bug Fixes

• Fix the Unsubscribe timeout problem by @Gsantomaggio in #313
• Solve the problem with memory leak. Added closing connection by @MikhailTushev in #306

New Contributors

• @MikhailTushev made their first contribution in #306
• @Zerpet made their first contribution in #305
• @TroelsL made their first contribution in #312

Full Changelog: v1.7.1...v1.7.2

v1.7.1

Enhancements

• Add more info during the startup and add a more detailed message in case the filter is not supported by @Gsantomaggio in #301
• Add Completion on _waitForConfirmationActionBlock by @Gsantomaggio in #298 it waits until the _waitForConfirmationActionBlock.SendAsync finishes.
• Update rabbitmq to 3.13.0-beta.6 version for ci by @Gsantomaggio in #292

Full Changelog: v1.7.0...v1.7.1

v1.7.0

Enhancements

• Add CRC32 checkSum control in #285
  See the documentation
• Add the stream name in case of an error during the parse in #284.