Command Dispatcher, Processor, and Distributed Task Queue. https://www.nuget.org/profiles/BrighterCommand
Done. Yeah, using ES a immutable transaction layer is also an interesting concept I've thought.
FYI; Like this: https://github.com/SzymonPobiega/NServiceBus.EventStore
It turns out @JontyMC was not aware, but this exposing reference data as a stream is what Iain Robinson and Jim Webber covered in Rest In-Practice, though they wrote to an Atom Feed. I've just done a talk at Progressive.NET where I bastardized Mark Seeman's AtomStorage to do something very similiar (by badly abusing it) but its an interesting concept
I also know that Celery uses Redis to do this, and I believe that is quite common
Brighter creates a consumer per routing key, so we now have multiple consumers for the same queue racing each other
each is on a separate thread, correct? so this could create an undesirable situation for versioning and requeuing
it also uses the routingkey for the consumer and the configured exchange name when logging, so that can be wrong
rmq sends that information on the message, so it could be passed over
The alternative is to use wildcards on the topic
Understood on rmq for source of logs, we can look at that too
I'll raise the issues
iancooper/Paramore#105 and iancooper/Paramore#106
An exception is the preferred mechanism to exit a pipeline
@george-ayris Ask more though if that does not make sense
i have a couple more on my fork but want to discuss in person first because i have a feeling they will be more controversial
once the ci build is done obv
I need DEBUG logs from my app but Brighter is quite verbose
something like
<logger name="Brighter">
<level value="WARN" />
</logger>
@stefanoric Just to check I understand. You want to filter out the noise from our logger apart from WARN and above? If so, don't forget we use LibLog, so we are just using an abstraction over your underlying logger. So whatever works for your logger will work for us. You create an instance of a logger to pass into us (as part of the builder normally), so you should be able to identify the logger name, and do something specific with that logger that meets your reporting needs, depending on the underlying logger you use.
@stefanoric Or to put it another way. This should be for your app to control, if we got it right :-)
I'll have a look at the plumbing code (didn't write it myself)
It will be a line like: var logger = LogProvider.For<Program>();
@stefanoric You pass it in. Look for where you are using CommandProcessorBuilder. I expect you'll be able to track back from there to where you set up LibLog
I see we do something like
Bind<ILog>().ToConstant(LogProvider.For<MyService>());
(this is Ninject IoC plumbing)
and ILog is brighter's interface
What I get in the code is something like: