I have the following message transport scenarios
Client -> Calls SignalR -> Calls NServiceBus -> Process Message internally -> Calls NServiceBus Gateway service with Result -> Calls SignalR Hub -> Updates the client with result.
In choosing whether to use SignalR vs. long polling, I need to know if SignalR is scaleable. So in doing my homework I came across SignalR on Azure Service Bus. The setup is done on the Global.asax application start.
Ultimately I need to be able to do this, from inside an NServiceBus handler:
var context = GlobalHost.ConnectionManager.GetHubContext<MyHub>();
context.Clients.Group(group).addMessage(message);
The question is if context will be jacked up, because I'm (potentially) calling it from another machine than the one the client was connected to?
Also what is the sharding schema that the SignalR implementation uses to seed the topics? I know I can configure it to use N-number of topics, but how is it actually determining which message goes to which topics and if it's relevant from an external caller PoV.
You should be able to use GlobalHost.ConnectionManager.GetHubContext in any application where you have registered ServiceBusMessageBus as your IMessageBus via SignalR's GlobalHost.DepenencyResolver. This is done for you if you call GlobalHost.DepenencyResolver.UseServiceBus(...) in the application.
If you do this, a message will be published to Azure Service Bus for each call to addMessage or any other hub method on the IHubContext returned from GetHubContext. If there are subscribed clients connected to other nodes in the web farm, the other nodes will pick up the message from Service Bus and relay it to the subscribed clients.
Which topic a message goes to should not be relevant from the PoV of an external caller. You can use multiple topics to improve throughput, but for most use cases one should be sufficient.
If you choose to use more than one topic, you can think about the topic a message goes to as being essentially random. The only thing that is guaranteed is that messages from the same sender will go to the same topic. This allows SignalR to keep messages from the same sender in order.
Caveat emptor: SignalR has not yet had an official release supporting scale out. The 1.1 version will be the first release to support scale out officially.
Related
We want to use Google pub/sub to consume messages. In rabbitMQ, whenever a message published, we were getting it and processing it. Our process operation takes 3-4 hours and because of that our consumers are windows services.
We dont want to use pub/sub pull because we dont want to poll. But Pub/sub push publishing to a web endpoint. Because of our long running process, we cannot use web app or web api. Is there any chance to consume pub/sub messages like in rabbitmq without requesting always and consuming when there is a message only.
Thanks
The Google Pub Sub technology does not requires that one continually explicitly poll the PubSub environment. If one is using the client libraries one can configure a callback function within the client application that is invoked when a new message is published to the topic against which the subscription has been taken.
I am trying to achieve a pub/sub with azure service bus.
I started with this tutorial and it worked so far:
https://azure.microsoft.com/en-gb/documentation/articles/service-bus-dotnet-how-to-use-topics-subscriptions/
But in my dedicated case i am not exactly sure how i should do it exactly:
I have a web api running on azure web app that is scaled to three instances.
I have a console application client that triggers some messages to a dedicated topic.
What i want to achieve is, that all three instances of the web api get the messages delivered that is send to the message bus.
So it is a fire forget action:
Client sends message to topic
Every subscriber that is CURRENTLY subscribing to this topic should get the message
I am not interested in older messages that were sent when the subscriber was inactive/offline. I am just syncing an in memory cache over these instances so it is really a short living info when i need to know which keys i have to invalidate. but it is important that every subscriber gets the information to avoid stale data.
I am not exactly sure if i have to create a subscription dynamically in the startup code of the web api so that every instance has its own subscription or if i can subscribe all web app instances to the same subscription?
I would like not to dynamically create subscriptions since i don't know when to remove them again (e.g. scaled down to 2 instances instead of three).
but i was unable to find any documentation how to do this and if it is okey that multiple clients subscribe to the same subscription or if i need to create a subscription per client.
I am not exactly sure if i have to create a subscription dynamically in the startup code of the web api so that every instance has its own subscription or if i can subscribe all web app instances to the same subscription?
Service Bus subscribers adopt the Competing Consumer pattern by default. You must create a unique subscription for each Web API instance in order each instance to receive a copy of the message. It will be easiest to do this when the Web API instance starts up.
I would like not to dynamically create subscriptions since i don't know when to remove them again (e.g. scaled down to 2 instances instead of three).
You can configure the subscription to be auto-deleted after being idle for some period of time. "Idle" in this case would mean that the Web API instance has spun down and is no longer attempting to receive messages on the subscription. When creating the subscription set the AutoDeleteOnIdle time span for a brief duration, currently a minimum of 5 minutes. Now you can create a new subscription when the Web API instance starts and know that it will be automatically deleted soon after the Web API instance stops.
I am not interested in older messages that were sent when the subscriber was inactive/offline.
When creating the topic, set the DefaultMessageTimeToLive for a brief duration e.g. 5 seconds. This will ensure that new subscribers don't see old messages.
I am new to NServiceBus and am trying to do something that seems harder than it should be...so I am starting to wander if I am missing something about the nsb bigger picture.
Here is the scenario:
Expose WCF endpoint to client from which they request a long-running operation.
I'd like to map the inbound request to a NServiceBus Message.
Publish the message to the bus for processing.
Send a reply to the client acking that their request has been received and we will begin processing it.
Bus works the message through a handler.
When the work has been completed, call the client back on their "callback" endpoint (wcf) to give them the result of the long-running request that they made.
I welcome corrective criticisms, examples or links that may be of use. Thank you in advance!
There is potential for you to do this via the NSB pipeline. You can configure handlers to execute in the order you specify. In your case this would be book-ended with the notifications. Depending on the use case it may be better to forward the notifications to another endpoint that handles just those types of communications. What you need to consider are the failure scenarios. If the handler fails and the message gets retried, what will happen?
This is all predicated on the idea that you do not need to maintain state. If you do, then you will want to look into using a Saga. This will keep state around per long running transaction and give you some more features you may require, such as timeouts.
A long running process can be either synchronous or asynchronous. It can't be both.
You can use NServiceBus for asynchronous processing of the long running task and generating of your progress information. Adam mentions the sagas. You can use a saga to keep track of progress. It will also help you with dividing you process into more granular tasks and give things like automatic retries that deal with transient failures for free.
However, you will have to use another mechanism to send the progress information back to the user. Periodic polling, long polling, hidden iframe, websockets, whatever - have a look at ideas exposed by SignalR. There's a nice video here that talks about sending notifications to browsers.
According to the NServiceBus website, you can expose your NSB endpoint as a WCF service:
Interoperability
You can expose your NServiceBus endpoints as WCF services with as
little as one line of code and the standard WCF configuration. All you
need to do is write an empty class that inherits from
NServiceBus.WcfService specifying the types of the request and the
response and NServiceBus does the rest as follows:
public class MyService : NServiceBus.WcfService<MyCommand, MyErrorCodes> { }
I have done some work integrating legacy MSMQ clients with NServiceBus - it works but you have to make sure the message is constructed correctly.
Messages sent to an NServiceBus endpoint must be enclosed in a <Messages/> envelope and must have a namespace. For example:
<Messages xmlns="http://tempuri.net/MyNservicebusMessage">
<MyNservicebusMessage body/> ...etc
</Messages>
Also, if you want to use NServiceBus auditing you have to ensure the MSMQ "Response Queue" message header has a value, although I don't think the value matters.
I have searched a lot, but still I had few doubts about MSMQ implementation of WCF service.
Hence I have put this quetion.
I want to implement single publisher and multiple subscribers asynchronous message system.
I have decided to use WCF service as the publisher.
I have multiple instances of the window service on different machines as the multiple subscribers.
Q. I want to know that, how this model can be implemented as the old MSMQ approach?
The object of following type would be used in the message
[Serializable]
public class Message
{
public string Signal{get;set;}
public Guid Identifier{get;set;}
}
In the above class, Identifier would be used by the windows service to decide whether the message was published for that service or not.
Q. How the different window services will read the same queue?
Q. Where the queue should be hosted?
Q. Is it possible to send the acknowledgement from Window service(subscriber) to WCF service(publisher)?
Any help would be appreciated.
In answer to your questions:
I want to know that, how this model can be implemented as the old
MSMQ approach?
First off, MSMQ does not support publish subscribe out of the box.
How the different window services will read the same queue?
So in publish subscribe, there in no ONE queue. Instead there are multiple queues, in fact one per participant in the pub sub scenario. So each publisher has a queue and each subscriber has a queue.
This configuration enables subscribers to send subscribe/unsubscribe messages to the publisher, and allows the publisher to send messages to the subscribers as necessary after evaluating the subscriptions.
Where the queue should be hosted?
These queues can be hosted locally to each participant, or can be hosted together in some clustered location.
Is it possible to send the acknowledgement from Window
service(subscriber) to WCF service(publisher)?
MSMQ does provide basic support for request/response messaging via response-queue and correlation-id message header fields, though this is not truly out of the box (as you are required to consume and program against these values)
If you are not required to use WCF there is a fairly mature platform called nservicebus which sits on top of MSMQ and does provide support for all the messaging patterns you need.
I'm trying to create a feedback system which all messages get posted to then published back to the correct subsystem. We are using queues quiet heavily and i want to make the subscriber code as clean as possible. I want to switch based off the message id i get into the feedback system and publish to its specific subscriber. i don't want to make a service for each subscriber to listen for messages.. i was thinking i could set up a queue for each subscriber and trigger to invoke a com+ component.. but i'm looking for a more modern way..
I was looking into NServiceBus but it seems i'd need to make a service/executable/webservice for each listening system ( its a little less work to make a C# dll and invoke a method) and i'm not sure if NServiceBus can handle dynamic endpoints based off a preloaded config ( loaded from a db ). WCF is also a choice.. it can handle dynamic endpoints for sure..
what do you think is the best solution for the lease amount of code/ scalable for new systems to subscribe?
Thanks
In case you are ok with online solutions you could take a look at the latest .NET Services SDK for Windows Azure which has queue service bus http://www.microsoft.com/azure/netservices.mspx It relies on WCF messages and supports routing etc. Some blog posts about this here http://vasters.com/clemensv/default.aspx
Another framework you could try is MassTransit http://code.google.com/p/masstransit/
It seems you're looking for a service host, rather than a message broker. If so, Microsoft's recommended way is to host your WCF services in IIS. They can still use MSMQ as transport, but the services themselves will be managed by IIS. IIS has evolved significantly since its early days as HTTP server, now it's closer to an application server, with its choice of transports (TCP, MSMQ, HTTP), pooling, activation, lifetime policies etc.
Although I find WCF+MSMQ+IIS somewhat overcomplicated this is the price you pay to play on the Microsoft field.
For nice and simple message broker, you can use Active MQ instead of MSMQ, it will give you message brokering as well as pub/sub. It's quite easy to work with in .NET, check this link out: http://activemq.apache.org/nms/