justmara

we've done something like this too, but have gone a bit further :) but our code is valid only for SimpleTrigger, because we don't make use of any others thou...

to _dynamically_ read one must support IOptionsMonitor, because IOptionsSnapshot is read once on class activation via DI, while Monitor can be dynamically changed in the same class instance.

Getting same error on version 3.7.0 I set up two consumers on same queue for different types, but with same topic: ``` public class SimplifiedNaming : Conventions { public SimplifiedNaming()...

@zidad with HandlerCollectionPerQueueFactory it crushes on registration phase with error ``There is already a handler for message type 'Msg`1'``. As it if tries to register both handlers (for message and...

So why is this closed? Is it obsolete (like if this functionality were already included in Quartz but not mentioned here) or simply `wont do`?

hmm, will check that failing tests tomorrow

Something weird happens with AppVeyor build: ``` OrleansGenerateCode: "dotnet" "C:\projects\orleans-streams-rabbitmqstreamprovider\packages\microsoft.orleans.codegenerator.msbuild\3.0.0-rc1\build\..\tasks\netcoreapp3.0\Orleans.CodeGenerator.MSBuild.dll" SourceToSource "C:\projects\orleans-streams-rabbitmqstreamprovider\Orleans.Streams.RabbitMqStreamProvider.Tests\obj\Release\netcoreapp2.1\RabbitMqStreamTests.orleans.g.args.txt" ``` It is compiled under `netcoreapp2.1`, but Orleans.Codegenerator.MSBuild tries to use `netcoreapp3.0` task for some reason o_O

No luck? Maybe I can help somehow? The most confusing part is that it builds and passes tests locally :) So I cant guess whats wrong with AppVeyor.

@zitmen can you point me what issues are you talking about so I could try checking myself? I've ran these tests locally for many times without issues. And regarding _3.0...

Why did you make your own IQueueAdapterCache? Orlean's default SimpleQueueAdapterCache is not enough for your needs? Or does it act somehow different? I've replaced your cache with Orlean's built-in in...