DEV Community: Thomas Eyde

Memory stream is not expandable

Thomas Eyde — Sun, 06 Oct 2024 14:29:19 +0000

Every time I have encountered this exception, I have spent too much time figuring out how to solve it.

My usual use case is to simulate an Azure Storage container, where I need to open a stream for reading, writing or appending.

Read and write is simple:

class BlobContainerStub
{
    readonly Dictionary<string, MemoryStream> streams = [];

    public async Task<Stream> OpenRead(string name)
    {
        await Task.CompletedTask;
        var stream = streams.GetValueOrDefault(name);
        if (stream == null) throw new InvalidOperationException();
        return new MemoryStream(stream.ToArray());
    }

    public async Task<Stream> OpenWrite(string name)
    {
        await Task.CompletedTask;
        var stream = new MemoryStream();
        streams[name] = stream;
        return stream;
    }
}

Append is where it becomes difficult. My first, naive approach:

class BlobContainerStub
{
    public async Task<Stream> OpenAppend(string name)
    {
        await Task.CompletedTask;
        var stream = streams.GetValueOrDefault(name);
        if (stream == null)
        {
            stream = new MemoryStream();
            streams[name] = stream;
            return stream;
        }
        else
        {
            // ObjectDisposedException: 
            // Cannot access a closed Stream.
            stream.Seek(0, SeekOrigin.End);
            return stream;
        }
    }
}

Of course the stream is closed, the previous operation closed it. It is not possible to reopen it, so a new one is needed:

    public async Task<Stream> OpenAppend(string name)
    {
        await Task.CompletedTask;
        var stream = streams.GetValueOrDefault(name);
        if (stream == null)
        {
            stream = new MemoryStream();
            streams[name] = stream;
            return stream;
        }
        else
        {
            // ArgumentException:
            // Stream was not writable.
            streams[name] = new MemoryStream(stream.ToArray());
            return stream;
        }
    }

If you create a MemoryStream this way, it is not writable. I keep forgetting this, because I cannot understand why it is that way.

Next attempt is to copy data from old to new stream:

    public async Task<Stream> OpenAppend(string name)
    {
        var stream = streams.GetValueOrDefault(name);
        if (stream == null)
        {
            stream = new MemoryStream();
            streams[name] = stream;
            return stream;
        }
        else
        {
            // ObjectDisposedException:
            // Cannot access a closed Stream.
            var appendable = new MemoryStream();
            await stream.CopyToAsync(appendable);
            return appendable;
        }
    }

But now I am back to the stream being closed. How about writing the content to the new stream?

class BlobContainerStub
{
    public async Task<Stream> OpenAppend(string name)
    {
        await Task.CompletedTask;
        var stream = streams.GetValueOrDefault(name);
        if (stream == null)
        {
            stream = new MemoryStream();
            streams[name] = stream;
            return stream;
        }
        else
        {
            var appendable = new MemoryStream();
            appendable.Write(stream.ToArray());
            streams[name] = appendable;
            return appendable;
        }
    }
}

And there it is. In order to create a writable MemoryStream with content, you cannot do it in the most obvious way. You have to first create a new, empty MemoryStream, then write the existing content to it.

Final code after refactoring:

class BlobContainerStub
{
    readonly Dictionary<string, MemoryStream> streams = [];

    public async Task<Stream> OpenRead(string name)
    {
        await Task.CompletedTask;
        var stream = streams.GetValueOrDefault(name);
        if (stream == null) throw new InvalidOperationException();
        return new MemoryStream(stream.ToArray());
    }

    public async Task<Stream> OpenWrite(string name)
    {
        await Task.CompletedTask;
        var stream = new MemoryStream();
        streams[name] = stream;
        return stream;
    }

    public async Task<Stream> OpenAppend(string name)
    {
        await Task.CompletedTask;
        var stream = streams.GetValueOrDefault(name);
        var appendable = new MemoryStream();

        if (stream != null)
        {
            appendable.Write(stream.ToArray());
        }

        streams[name] = appendable;
        return appendable;
    }
}

TableClient PropertyValueTooLarge exception message may be incorrect

Thomas Eyde — Tue, 01 Oct 2024 08:17:50 +0000

I observed the following exception in the logs a few days ago:

---> Azure.RequestFailedException: The property value exceeds the maximum allowed size (64KB). If the property value is a string, it is UTF-16 encoded and the maximum number of characters should be 32K or less.
RequestId:fb842d88-5002-002e-363f-1342d7000000
Time:2024-09-30T13:50:16.5210829Z
Status: 400 (Bad Request)
ErrorCode: PropertyValueTooLarge

This exception has a few issues:

It does not tell which property which is too long.
The message is wrong if the property is PartitionKey or RowKey.

Worse, the documentation is also incorrect:

RowKey Property
(...)
The row key is a string value that may be up to 1024 characters in size.

https://learn.microsoft.com/en-us/rest/api/storageservices/understanding-the-table-service-data-model#rowkey-property

There is a difference between characters and bytes. If the text is UTF-16, the limit is 512 characters.

It took me long enough to narrow down the issue, which was RowKey being too long.

My solution:

Generate the candidate key, may be too long with invalid characters
Create a Crc32 hash and prepend to the candidate
Truncate this to max 512 characters

The hash will ensure a unique RowKey in case two truncated candidates should be the same.

Hvordan designe korrekt kode i C# - Del 1

Thomas Eyde — Tue, 28 Apr 2020 07:43:36 +0000

Det virker som en uungåelig skjebne for mange prosjekter at de ender opp like, med forsinkelser, uløste feil og en komplett uforståelig kodebase. Det til tross for at vi alle er kompetente og bringer med oss masse erfaring.

Jeg tror den grunnleggende årsaken til det er at vi mangler en generell teori for det vi driver med. Uten en slik teori er det vanskelig å argumentere for hva som er korrekt og vi faller gjerne tilbake på personlige preferanser og erfaring.

Men om vi analyserer preferansene våre, kan vi klare å finne noen egenskaper som korrekt kode må inneha, og noen enkle prinsipper til å veilede oss?

Denne artikkelserien er mitt forsøk på det. Jeg definerer min versjon av korrekt kode, etablerer noen prinsipper, og demonstrerer en designprosess som jeg synes fungerer bra.

Definisjon

Korrekt kode har disse egenskapene:

Eliminerer feil
Ekskluderer ugyldige tilstander
Er lett å resonnere over
Promoterer korrekt bruk

Prinsipper

Vi ønsker korrekt kode fordi det gir oss noen garantier som gjør det lettere å skrive feilfri kode. Garantiene vi vil ha er:

Et objekt er alltid korrekt
Et objekt kan ikke brukes feil

Dette utleder noen prinsipper:

Objekter instansieres med en factory.
Et instansiert objekt er immutable.
Vår minste byggestein er et value object.
Vi tillater ikke bruk av null.

Factory

Factory er verktøyet vårt for å konstruere korrekte objekter. En factory returnerer en korrekt instans eller feiler i forsøket:

var divisor = NonZeroNumber.Of(10);

class NonZeroNumber
{
    static NonZeroNumber Of(decimal value)
    {
        if (value == 0) throw new InvalidArgumentException("Cannot be 0");
        return new NonZeroNumber {Value = value};
    }
}

Immutable

Når vi først har et garantert korrekt objekt, så risikerer vi ikke å ødelegge den garantien ved å tillate endringer. Objektene våre er immutable:

var divisor = NonZeroNumber.Of(10);
divisor.Value = 0; // compile error

class NonZeroNumber
{
    public decimal Value { get; private set; }
}

Value objects

Vi bruker ikke primitive typer direkte, fordi det verken kan garantere korrekt verdi eller bruk. Primitiver kan beskrive en mengde, men ikke av hva. Derfor vil den minste byggesteinen vår være et value object:

var dividend = Number.Of(10);
var divisor = NonZeroNumber.Of(5);
var quotiend = Divide(dividend, divisor);

Number Divide (Number dividend, NonZeroNumber divisor)
{
    return Number.Of(dividend.Value / divisor.Value);
}

Ingen bruk av null

Om vi skal garantere korrekte objekter som ikke kunne brukes feil, kan vi ikke tillate bruk av null. Når ekskluderer bruk null blir vi tvunget til å revurdere hvordan vi modellerer fraværet av verdi.

Vi kan velge å uttrykke det eksplisitt:

var user = User.None;

Eller å uttrykke det med flere tilstander:

var newCar = RegisteredCar.Of(registrationNumber, owner);
var usedCar = newCar.ReregisterOn(newOwner);

abstract class Car
{
    RegistrationNumber Number { get; private set; }
    Owner Owner { get; private set; }
}

class RegisteredCar : Car
{
    static RegisteredCar Of(RegistrationNumber number, Owner owner)
    {
        return new RegisteredCar
        {
            RegistrationNumber = number,
            Owner = owner
        }
    }

    ReregisteredCar ReregisterOn(Owner newOwner)
    {
        return ReregisteredCar.Of(this, newOwner);
    }
}

class ReregisteredCar : Car
{
    static ReregisteredCar Of(RegisteredCar car, Owner owner)
    {
        return new ReregisteredCar
        {
            RegistrationNumber = car.RegistrationNumber,
            Owner = owner,
            PreviousOwners = new []{ car.Owner }
        }
    }

    Owner[] PreviousOwners { get; private set; }
}

Veien videre

Hittil har jeg definert noen egenskaper jeg mener korrekt kode må ha, argumentert for at det finnes prinsipper vi må følge, og antydet at det finnes en enkel designprosess.

I neste artikkel vil jeg bruke en typisk chat som problemstilling, der jeg starter med en typisk og naiv modell. Jeg kommer til å vise hvordan denne modellen kan forbedres ved å følge prosessen og anvende prinsippene jeg har presentert her.

Relevante lenker

Towards general theories of software engineering
Making Defects Impossible
Entities and Value Objects in C# for DDD