Skip to main content

Pulsar DotPulsar

Added

  • A number of resilience, correctness, and performance improvements
  • The optional listener name can be set via the PulsarClientBuilder
  • Experimental: Added an extension method for IConsumer that will 'Process' and auto-acknowledge messages while creating an Activity (useful for doing tracing)
  • Schema support for the following types
    • Boolean
    • Bytes (using byte[] and ReadOnlySequence\<byte>)
    • String (UTF-8, UTF-16, and US-ASCII)
    • INT8, INT16, INT32, and INT64
    • Float and Double
    • Time (using TimeSpan)
    • Timestamp and Date (using DateTime)

Changed

  • Breaking: Building a producer will now create an IProducer\<T>\ The non-generic IProducer interface is still there, but messages can only be sent (ISend) with IProducer\<T>
  • Breaking: Building a reader or consumer will now create an IConsumer\<T> or IReader\<T>\ The non-generic IReader and IConsumer are still there, but messages can only be consumed/read (IReceive) with IConsumer\<T> and IReader\<T>
  • Breaking: Receiving a message with now return an IMessage\<T> instead of the Message class (which is now internal)\ The non-generic IMessage can be used if 'Value()' (decoding the 'Data' bytes) is not used (when just handling raw messages)
  • Breaking: The message builder is now generic
  • Setting an Action and Func StateChangedHandler on the ConsumerBuilder, ReaderBuilder, and ProducerBuilder are now extension methods
  • Setting an Action and Func ExceptionHandler on the PulsarClientBuilder are now extension methods

Fixed

  • When the broker sends a CommandClose[Producer/Consumer] all in-flight (and following) requests to the broker are ignored.\ Even though we reconnect the consumer, reader, or producer the tasks for the in-flight requests will hang as long as the connection is kept alive by other producers/consumers/readers.\ This situation is now handled and the requests will be sent again on the new connection.
Was this helpful?