@ianbattersby In essence this is @JontyMC's direction of travel with his reference data work. If you use EventStore as a message store, you can expose a stream that we directly consume instead of going via RabbitMQ
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
PS I want to move the DB connections in the Tasks example to a SQLCE store for messaging, but I'll get to that as soon as I can
IAmAMessageConsumerFactory has a Create method that takes in a routing key parameter. Shouldn't we be creating a consumer per queue, not per routing key?
We have a situation in people where we've configured mulitple routing keys for the same queue
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
just opened #104 which has a tiny fix for the Requeue method
IAmAChannelFactory uses routingKey in both its methods too. Looking at where routingKey is used, apart from logging it's only used to bind the queue to that routing key.
OK, so I think we can support multiple routing keys for one queue as RabbitMQ lets you bind to multiple topics. So the simple fix would be to allow that.
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
OK raised 105, and 106
iancooper/Paramore#105 and iancooper/Paramore#106
Morning, I'm just looking at ways to gracefully abort pipeline processing (e.g. if a pre-condition check fails) and was wondering: what happens if base.handle() is not called?
If you don't call base.handle you won't call a subsequent step, but will return to the calling step. You need to throw an exception
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
also iancooper/Paramore#108 (would be good to get that in asap)
once the ci build is done obv
We should probably internalize newtonsoft.. sigh
@holytshirt :+1: thank you
Hi guys, is there a way to have Brighter only log at a WARN level?
I need DEBUG logs from my app but Brighter is quite verbose
@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 :-)
We are using log4net, and I just needed to know if brighter had its own logger name (a-la NHibernate)
I'll have a look at the plumbing code (didn't write it myself)
I'll be plugging away at the Monitoring and Management stuff today. Possibly with a side journey into the CommandSource stuff to document and provide an example.
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