masstransit/greenpipes

An asynchronous pipe implementation for the Task Parallel Library

Green Pipes

GreenPipes is a middleware library for the Task Parallel Library.

GreenPipes is a library built from the message pipeline of MassTransit. In fact, MassTransit is using GreenPipes, instead of the internal pipeline (it was entirely harvested to GreenPipes for that very purpose). In addition, since the pipeline is now standalone, it can be used with other libraries such as Automatonymous to get a cohesive understanding of the data flow through the pipeline.

greenpipes's Issues

TypeCache: StackOverflowException if class has property of same type as class itself

Hey,
attempt to initialize proxy object of the class, that has a property of same type as class itself causes a StackOverflowException to be thrown.
For example initialization of proxy class for ExceptionInfo interface (from MassTransit) throws:

var exception = TypeCache<ExceptionInfo>.InitializeFromObject(new {});

Conveying state object in context

Similar to the CancellationToken, I often need to pass around an object-typed state so that I can satisfy any of the TAP, EAP, APM programming models that clients might desire.

Right now, I'm deriving from PipeContext and adding a state property because "object" is too indiscriminate for the type-keyed Payload functionality in PipeContext/BasePipeContext.

Have you considered a name-keyed Payload functionality? I haven't looked deeply enough to work out what else Payload is being used for, so that might not be practical.

Wrong version on greenpipes.dll

Inside the nuget package for version 1.0.10, the version for greenpipes.dll is 1.1.0.83
The file and product version are both listed like this.

Shouldn't it be 1.0.10?

DynamicFilter Race Condition

Yeah, you don't use ??= in a highly threaded system. Live and learn.

GreenPipes NuGet Package incorrectly specifies patch-level

The specification of a patch level for .NET Framework 4.5 (ie. 4.5**.2**) makes it impossible for us to target a most-common major.minor in our own solutions because GreenPipes "requires" .NET 4.5.2 ... (ie. where we target .NET 4.5 in our packaging, we only assign patch-level to EXE projects, since this is what ultimately determines which CLR patch-level is loaded at runtime, not the patch level specified in any nuspec.)

To clarify:

When you Target and/or Package for .NET Framework 4.5 we can target all patch levels and still use your nuget package, such as .NET 4.5, 4.5.1, 4.5.2, 4.6, 4.7, etc.

When you Target and/or Package for .NET Framwork 4.5.2 (note the patch-level specification) we can only include your package when we also target .NET 4.5.2 or later in our nuspec. Thus, the current version constraint precludes our creating a package which targets the broader .NET Framework 4.5 version.) This has the adverse effect of preventing us from using a platform target of .NET 4.5 in our shared library builds which reference these packages.

Again, we assign/assert/require a Framework patch-level by virtue of the Framework Target of our EXE projects. Class-libraries and their nuspecs necessarily always target the broader Framework Targets (ie. no patch-level.

Can you please make it a matter of practice to target the lowest-supported major+minor (and avoid the specification of a Framework patch-level unless it is absolutely necessary to address a bug)?

We do not have a workaround for this, this framework patch-level constraint breaks our builds and we're unable to leverage the latest MassTransit packages without also taking on this dependency.

Thanks for any assist.. let me know if I can clarify further.

Rebuild GreenCache may cause deadlock?

This was observed, not sure how if at all to reproduce since the node tracker should only contain resolved nodes. And I thought this was only called during Clear, so need to confirm.

Abstract or Virtual properties cause ArgumentExceptions

The following (new) test case fails.

[TestFixture]
public class AbstractProperty_Specs
{
    [Test]
    public void Should_cache_properties_nicely()
    {
        var cache = new ReadWritePropertyCache<AbstractProperty>(true);

        var instance = new AbstractProperty();

        const string expectedValue = "Chris";
        cache["Name"].Set(instance, expectedValue);

        Assert.AreEqual(expectedValue, instance.Name);
    }

    class AbstractProperty : AbstractClass
    {
        public override string Name { get; set; }
    }

    abstract class AbstractClass
    {
        public abstract string Name { get; set; }
    }
}

When creating the cache there seems to be no deduplication of the property names?

static IDictionary<string, ReadWriteProperty<T>> CreatePropertyCache(bool includeNonPublic)
{
    return new Dictionary<string, ReadWriteProperty<T>>(typeof(T).GetAllProperties()
        .Where(x => x.CanRead && (includeNonPublic || x.CanWrite))
        .Where(x => x.SetMethod != null)
        .Select(x => new ReadWriteProperty<T>(x))
        .ToDictionary(x => x.Property.Name));
}

Race conditions: eviction of used send endpoint from GreenCache leads to errors

I'd love to come with code but it is a bit hard since it is about race conditions.

Here's what is happening in our Production:

• We use MassTransit with RabbitMQ transport;
• We override SendEndpointCacheDefaults.MaxAge to be 30 minutes, which is significantly shorter that the default (24 hours). There are reasons for that as we have on-demand service process which is going down when inactive, and we want to dispose inactive channels sooner rather than later.
• Internally, MT is using GreenPipes.GreenCache to cache send endpoints. The above cache as per my understanding of the code has the eviction policy based solely on time, and the time of the bucket is immutable and is only assigned when the bucket is created.

This leads once in a while to the following unpleasant scenario:

• The send endpoint is in use
• The same endpoint is evicted from cache and being disposed in another thread
• This ends up with a variety of exceptions, for example: System.Threading.Tasks.TaskCanceledException A task was canceled ... at MassTransit.RabbitMqTransport.Pipeline.ConfigureTopologyFilter1.d__6.MoveNext()`

When I think of the best resolution to that, in my opinion the timestamp of the GreenCache's bucket should be updated when the bucket is used, i.e. switch from "created" to "last used" time. This would prevent the used objects from being evicted.