Is there any reason that Rebus cannot be used in a pub/sub protocol, subscribing to multiple endpoints publishing messages from a shared assembly?
When I try to configure a Rebus subscriber with this:
<rebus inputQueue="ocs.subscriber.input" errorQueue="ocs.subscriber.error" workers="1" maxRetries="5">
<endpoints>
<add messages="D3A.Messages" endpoint="ocs.publisher.input" />
<add messages="D3A.Messages" endpoint="ocs.publisher.input#osi2552" />
</endpoints>
</rebus>
An exception is thrown at
.Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
The exception thrown is this:
An unhandled exception of type 'Rebus.Configuration.ConfigurationException' occurred in Rebus.dll
Additional information:
An error occurred when trying to parse out the configuration of the RebusConfigurationSection:
System.Configuration.ConfigurationErrorsException: The entry 'D3A.Messages' has already been added. (C:\projects\OCS.Subscriber\bin\Release\OCS.Subscriber.vshost.exe.Config line 22)
at System.Configuration.BaseConfigurationRecord.EvaluateOne(String[] keys, SectionInput input, Boolean isTrusted, FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult)
at System.Configuration.BaseConfigurationRecord.Evaluate(FactoryRecord factoryRecord, SectionRecord sectionRecord, Object parentResult, Boolean getLkg, Boolean getRuntimeObject, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSectionRecursive(String configKey, Boolean getLkg, Boolean checkPermission, Boolean getRuntimeObject, Boolean requestIsHere, Object& result, Object& resultRuntimeObject)
at System.Configuration.BaseConfigurationRecord.GetSection(String configKey)
at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection(String sectionName)
at System.Configuration.ConfigurationManager.GetSection(String sectionName)
at Rebus.Configuration.RebusConfigurationSection.LookItUp()
at Rebus.Transports.Msmq.MsmqConfigurationExtension.UseMsmqAndGetInputQueueNameFromAppConfig(RebusTransportConfigurer configurer)
This seems a bit odd to me. It seems like a perfectly valid use case to have Rebus subscriber to multiple publishers - some sharing a common POCO assembly.
What is the reasoning behind this ... and (more importantly) is there a way to achieve this in Rebus?
And also: I was expecting Rebus to add this exception to the log (I use log4net) but it seems that exceptions thrown during configuration time of Rebus is not logged. This must be a mistake, right?
The reason why it doesn't readily work, is that it is assumed that each message type belongs to ("is owned by") one logical service only.
From the names of your publishers I assume that they're the same - i.e. that they're two instances of the same logical service, which means that you can easily achieve what you're after by letting them share their subscription storage - e.g. in a shared SQL Server.
When they share their subscription storage, it doesn't matter which one receives the subscription request, and therefore, you'd only need to map the message assembly to one of the instances.
PS: Good find with the logging thing - I've created an issue and it will be fixed soon ;)
PPS: Update about the logging thing - I remember now that Rebus intentionally does NOT log error during configuration - the reasoning is that logging is done only for exceptions that don't surface to the caller, because you'll be able to catch the other exceptions and do what you think should be done with them.
Related
I'm creating services in Scala just like in Java:
trait PersonService {
def getById(id: Long): Person
def getAll: Iterable[Person]
}
and also I have corresponding implementation of this service.
Actually this service interacts with DB layer and do some business logic. So this methods can throw exceptions.
So I have a question: Should I wrap return type of methods of service with Try?
I.e. should I use following declaration:
trait PersonService {
def getById(id: Long): Try[Person]
def getAll: Try[Iterable[Person]]
}
It depends on whether the error produced by the service is meaningful to the consumer. I.e. are they expected to know about the different DB failures and potentially retry? Or are you mapping the exceptions to a consumer meaningful instance? In both of those cases, I would use a Try[Person]
If all you end up is logging the error and you are just trying to avoid, I'd recommend logging in PersonService and returning an Option[Persons].
Alternatively, if you do want to communicate some information to distinguish failure from empty that does not rise to the level of exception, consider using an Either[FailureReason,Person]
You have 4 standard options:
Future: This might be the most idiomatic and flexible, allowing the consumer to more easily use the service asynchronously and to deal with errors (by matching with Failure).
Try: A Try signals to the consumer that operations may fail, and that they should be prepared to deal with its exceptions.
Either: You can use an Either similarly to a Try here, but with more customized error information (e.g. Either[ErrorType, ReturnType]).
Option: The simplest option here is Option, whereby you ignore the reason for the error and only return Some if the operation was successful.
Given a method in UserService: update, what's the best way to handle errors/exceptions here?
Option A:
def update(...): Try[User]
In this way, I need to define my custom exceptions and throw them in the function body when needed. Most of these exceptions are business errors (e.g. user_id cannot be changed, etc). The point here is no matter what exception(s) are thrown (business error, network exception, DB IO exception, etc), treat them the same way and just return a Failure(err) - let the upper layer handle them.
Option B:
def update(...): Either[Error, User]
This is the exception-free way. In the function body it catches all possible exceptions and turns them into Error, and for business errors just return Left[Error].
Using Try seems to be a more natural way to me as I want to handle errors. Either is a more generic thing - Either[Error, T] is just one special case and I think Try is invented for this special case. But I also read that we should avoid using exceptions for error handling...
So, which solution is better, and why?
There's no silver bullet.
As you noted already, Try is simply a more specialized version of Either, where the Left type is fixed to Throwable.
Try might be a good fit if you need to materialize exceptions thrown by external (perhaps java) libraries, as its constructor automatically catches them.
Another advantage of Try is that it has map and flatMap, so you can use it directly in for-comprehensions, whereas with Either you would have to explicitly project on the right case.
Anyway, there's plenty of alternative implementations with a "right-bias", and probably the scalaz \/ type is the most popular one.
That being said, I typically use \/ or the almost equivalent Validation (both from scalaz), as I like having the ability of returning errors that do not extend Throwable.
It also allows for more precise error types, which is a huge win.
I started to use Scalaz 7 Validation and/or disjunction to process a list of possibly failing operation and managing their result.
There is two well documented case for that kind of use cases:
1/ You want to check a list of conditions on something, and accumulate each error if any. Here, you always go the end of list, and in case of any error, you have failure as global result.
And that's an applicative functor at work.
2/ You want to execute several steps that may fail, and stop on the first one failing.
Here, we have a monad that goes nicely in Scala for-comprehension.
So, I have two other use cases that are among the same lines, but don't seems to feet well on any precedent case:
I want to process a list of step, possibly failing, and accumulate both error and success results (ex: it's a list of modification on files, errors may happen because that's the outer world, and success are patch that I want to keep for later).
The difference on the two use case is only if I want to stop early (on the first error) or go to the end of the list.
OK, so what is the correct thing for that ?
(writting the question leads me to think that it's just a simple foldLeft, does it ? I will let the question here to validate, and if anybody else wonder)
Take a look at Validation#append or its alias Validation#+|+. Given two validations, if both are success, it returns success of the values appended. If both are failures, it returns failure of the values appended. Otherwise, it returns the successful value. This requires an implicit Semigroup instance for the success type.
I'd do something like this:
scala> List(1.success[String], 2.success[String], "3".failure[Int], "4".failure[Int]).partition(_.isSuccess)
res2: (List[scalaz.Validation[java.lang.String,Int]], List[scalaz.Validation[java.lang.String,Int]]) = (List(Success(1), Success(2)),List(Failure(3), Failure(4)))
scala> val fun = (_:List[Validation[String, Int]]).reduceLeft(_ append _)
fun: List[scalaz.Validation[String,Int]] => scalaz.Validation[String,Int] = <function1>
scala> fun <-: res2 :-> fun
res3: (scalaz.Validation[String,Int], scalaz.Validation[String,Int]) = (Success(3),Failure(34))
UPD: With #129 and #130 merged, you can change fun to (_:List[Validation[String, Int]]).concatenate or (_:List[Validation[String, Int]]).suml
Or bimap like this:
scala> List(1.success[String], 2.success[String], "3".failure[Int], "4".failure[Int]).partition(_.isSuccess).bimap(_.suml, _.suml)
res6: (scalaz.Validation[java.lang.String,Int], scalaz.Validation[java.lang.String,Int]) = (Success(3),Failure(34))
What you need is approximately switching an Either[E, A] into a Writer[List[E], A]. The Writer monad logs the errors you encountered.
Sounds like you want a pair (SomveValue, List[T]) where T is your 'Failure' although I'd call it 'Warning' or 'Log' since you still get a result, so its not really a failure.
Don't know if Scalaz has anything fancy for this though.
It seems that invoking a PowerShell script block (by invoking the .Invoke() method) always produces a collection. Specifically, a collection of type
System.Collections.ObjectModel.Collection`1[[System.Management.Automation.PSObject, System.Management.Automation, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]
Even invoking an empty script block ({}.Invoke()) returns a collection. Invoking the same script block using the call operator (&) produces the normally expected return (either a scalar or [object[]]).
This turns out to be convenient if you need a collection instead of an array, but it seems kind of counterintuitive.
Does anyone know why it behaves this way?
I knew there are two different invocations, .Invoke() and .InvokeReturnAsIs() from reading the language spec. That's were I first noticed it.
I just don't understand the reasoning behind the naming convention and the way the mechanics of it appear to work. Looking at the documentation, what I would have thought would be the default invocation method is not what is used when the script block is invoked in PowerShell. It appears that .InvokeReturnAsIs() just returns a stream of objects, and then PowerShell wraps it into an object array if there's more than one object, as scalar if there's only one object, or creates a null object if there are none, as if there's an implicit pipeline there. Using .Invoke() returns a collection, always, and PowerShell leaves it as a collection.
Looks to be the difference between these two methods:
Invoke - Invokes the script block with the specified arguments,
returning the results as PSObject objects.
InvokeReturnAsIs - Runs the script block with the specified arguments.
This method returns the raw (unwrapped) result objects so that it can
be more efficient.
http://msdn.microsoft.com/en-us/library/system.management.automation.scriptblock_methods(v=vs.85).aspx
Invoke
$code = {"a"}
$code.Invoke().Gettype().FullName
Output:
System.Collections.ObjectModel.Collection`1[[System.Management.Automation.PSObject, System.Management.Automation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]
InvokeReturnAsIs
$code.InvokeReturnAsIs().GetType().FullName
Output:
System.String
My guess is that the team wanted to be consistent with the PowerShell.Invoke() API, which returns a Collection<PSObject>. This C# signature makes it easier for clients to consume 0, 1 or N returned values and not have to worry about checking for null and whether the returned object was wrapped or not.
From the .NET Design Guidelines:
DO NOT return null values from collection properties or from methods
returning collections. Return an empty collection or an empty array
instead.
You could say then why not just return object. Then I would have to against null or not and then I'd have to test to see if it implemented ICollection to determine if I had a scalar or collection. From a C# dev's point of view, this is a spew (pardon the rhyme). :-)
Because that is what it is designed to do, and there is an alternate!
Invoke - Invokes the script block with the specified arguments, returning the results as (collection of) PSObject objects.
InvokeReturnAsIs - Runs the script block with the specified arguments. This method returns the raw (unwrapped) result objects so that it can be more efficient.
Also, {}.invoke() returns null, so I don't know where you got the impressions that even that returns a collection.
http://msdn.microsoft.com/en-us/library/system.management.automation.scriptblock.invokereturnasis(v=vs.85).aspx
I have a Scala helper method that currently tries to fetch a URL and return an Option[String] with the HTML of that webpage.
If there are any exceptions (malformed url, read timeouts, etc...) or if there are any problems it returns a None. The question is, would it be better to just throw the exception so the calling code can log the exception or is it preferable to return the None in this case?
Creating exceptions is expensive because the stack trace has to be filled. Throwing and catching exceptions is also more expensive than a normal return. Considering that, you might ask yourself the following questions:
Do you want to force handling of an error by the caller? If so, don't throw an exception, as Scala has no checked-exception mechanism that forces the caller to catch them.
In case of an error, do you want to include details on why it failed? If not, you can just return Option[A], where A is your return type, and then you'd either have Some(validContent) or None, with no additional explanation. If yes, you can return something like Either[E, A] or a Scalaz Validation[E, A]. All of this options force the caller to somehow unwrap the result while being free to process the error E as he wants. Now what should E be?
Do you want to provide a stack trace in case of failure? If so, you could return Either[Exception, A] or Validation[Exception, A]. If you really go with the exception, you'll want to use Try[A], whose two possible cases are Failure(exc: Throwable) and Success(value: A). Note that you will of course incur the costs of creating the throwable. If not, you can maybe just return Either[String, A] (and be extra careful to remember whether Right means success or failure here — Left is usually used for errors, and Right for the “right” value — Validation is maybe clearer). If you want to optionally return a stack trace, you could use Lift's Box[A], which could be Full(validContents), Empty with no additional explanation (very similar to Option[A] up to here), or indicate a Failure which can store an error string and/or a throwable (and more).
Do you maybe want to provide multiple indications as to why it failed? Then return Either[Seq[String], A]. If you do this frequently, you may probably want to use Scalaz and a Validation[NonEmptyList[String], A] instead, which provides some other nice goodies. Look it up for more info about it or check out these usage examples.
I think that in this case, if is important to log the exceptions then by all means throw the exceptions (and possibly just return String instead of the option). Otherwise you might as well just return the None. One warning- there may be exceptions for other reasons that you don't foresee, in which case it may be dangerous to make a catch-all bit of code.
One thing that you could do is something like Lift's Box system. A Box is essentially an Option, but with a couple features added in: A Full is like a Some, an Empty is like a None, but Lift goes a step further and has a Failure, which is like an Empty but with a reason/message.
The general rule of thumb is "if you can handle the exception, handle it". So there's not enough context to guess. You can use the tryFetchUrl/fetchUrl pair of methods.