I know I can call up the scheduled message in c#/code and delete a scheduled message like this
Scheduled messages can be removed by calling CancelScheduledMessageAsync(sequenceNumber)
But I can't seem to figure out how to do it with Service Bus Explorer or in the Azure dashboard. Is it possible with either?
It's possible to delete specific messages using QueueExplorer (I'm the author). It is a commercial tool, but if it's a one-of thing you can use free trial.
https://www.cogin.com/mq/
Btw. we are a bit lucky with scheduled messages, since Azure Service Bus API has that CancelScheduledMessageAsync function. It's more problematic for regular messages. All we can do, whether from some script or from QueueExplorer, is to start receiving all messages before the one we want deleted, and then "abandon" receive for all of those in front. It's not only slow, but increments their Delivery count and they could end up in dead letter queue. It would be great if Azure Service Bus would have "delete message" functionality in API.
Both Azure dashboard and Service Bus Explorer do not support this option.
For Service Bus Explorer you can raise a feature request here.
Related
We have created Azure service bus queue and have a azure function - servicebus queue trigger subscribed to it. We now want this queue to convert to Topic as we will need multiple subscription to it. is there a way that we can convert queue to Topic without deleting queue and re creating this as a Topic. I understand that Azure function code which is in c# needs to be changed so it points to service bus topic.
Thanks,
Punit Singhi
Use the ForwardTo feature for forwarding a message to the topic entity.
I have a website which runs SingalR to inform the front end of certain back end events so it can update. The back end comprises the website back end as well as other services running as console apps, Azure workers, etc. which may or may not be on the same machine as the website runs.
I need some way to grab those back end events and send them down to the clients over SignalR. I would immediately use a service bus, but I'm concerned about managing the subscriptions in the website. I'm interested in eventually using SignalR scale out (with service bus as the backplane), but it seems I won't be able to publish to the backplane topics as the names of the topics is an internal implementation detail.
Question is then: Should I use a service bus subscription in the website and how should I manage the subscription (to ensure that it conforms to the ASP.Net lifecycle), or should I try to use the service bus backplane and how do I publish to it?
I need to create a windows service that processes a job queue.
A trigger will fill up the queue, and the windows service will process that queue.
I know how to create a windows service (using a timer), but I'm not sure about how tell the trigger (CLR project) to fill the queue, and how to process it.
I'm new in C#, so any example, ideas, guidances are wellcome
Thank you
Sounds like you need a MQ (message queueing) system. Try looking into this (RabbitMQ) as a starting point, then update your question with specifics if need be.
http://www.rabbitmq.com/tutorials/tutorial-one-dotnet.html
Here is Microsoft's implementation of it (MSMQ):
http://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx
Thank you Bill Sambrone.
I found SQL Server Service Broker (http://technet.microsoft.com/en-us/library/ms345108%28v=sql.90%29.aspx)
It is a service that uses queues to send messages that are guaranteed to arrive to destiny, it can send messages between databases, remote databases, and also to external apps. I'm sending the messages to my c# external app. And the best is that it comes bundled inside SQL server.
I am working to port an application which was designed to work in a non-Azure environment. One of the elements of the architecture is a singleton which does not scale, and which I'm hoping to replace w/ multiple worker processes serving the resource that the singleton currently provides.
I have the necessary changes in place to replace the singleton, and am at the point of constructing the communications framework to provide interconnection from the UI servers to the resource workers and I'm wondering if I should just use a TCP binding on a WCF service or whether using the Azure Service Bus would make more sense. The TCP/WCF is easy, but doesn't solve the complete problem: how do I ensure that only one worker processes a UI request?
From reading the available documentation, it sounds like the service bus will solve this, but I've yet to see a concrete example of implementation. I'm hoping someone here can assist and/or point me in the right direction.
Seems that Azure Service Bus queues are the right solution for you.
Azure Service Bus can be used in 3 different ways:
Queues
Topics
Relays
From windows azure site:
Service Bus queues provide one-way asynchronous queuing. A sender sends a message to a Service Bus queue, and a receiver picks up that message at some later time. A queue can have just a single receiver
You can find more info at:
http://www.windowsazure.com/en-us/develop/net/fundamentals/hybrid-solutions/
Adding to Davide's answer.
Another alternative would be to use Windows Azure Queues. They are designed to facilitate asynchronous communication between web and worker roles. From your web role you push messages into a queue which is polled by your worker roles.
Your worker role can "Get" one or more messages from a queue and work on those messages. When you get a message from a queue, you can instruct the queue service to make those messages invisible to other callers for a certain amount of time (known as message visibility timeout). That would ensure that only worker role instance get to work on a message.
Once the worker role has completed the work, it can simply delete the message. If there's an error in processing the message, the message automatically reappears in the queue once the visibility timeout period has expired. You may find this link helpful: http://www.windowsazure.com/en-us/develop/net/how-to-guides/queue-service/.
Azure queues are not designed for inter process communication, but inter-application communication. The message delivery latency is substantial, and delivery timing cannot be guaranteed. Websockets or NetTcpBinding is more suitable for applications that talk to eachother in realtime. Although must admit, you get some free stuff with queuez, especially the locking mechanisms. Just my 2 cents
I'm designing a service for sending out emails for our eCommerce site (order confirmations, alerts etc...)
The plan is to have a "SendEmail" method, that generates a chunk of XML representing the email to be sent, and sticks it on an Amazon SQS queue.
My web app(s) and other applications will use this to "send" emails.
I then require a way of checking the queue, and physically sending out the email messages.
(I know how I'm going to be dispatching emails)
I'm curious as to what the best way to "poll" the queue would be?
Should I create a windows service, and use something like Quartz.net to schedule it to check the queue every x number of minutes for example?
Is there a better way of doing this?
Sounds more like Amazon SNS is your huckleberry. (not really sure what that means, but I saw it in a movie once).
SQS is more of a "hopefully someone comes looking for this message at some point before it expires!" where SNS seems more like a "I need to make sure this gets to whoever needs it right away!"
It even includes email as a pre-built transport. (not even sure if that's the right word)
Amazon SNS provides a simple web services interface that can be used to create topics you want to notify applications (or people) about, subscribe clients to these topics, publish messages, and have these messages delivered over clients’ protocol of choice (i.e. HTTP, email, etc.). Amazon SNS delivers notifications to clients using a “push” mechanism that eliminates the need to periodically check or “poll” for new information and updates.
To be sure, they have the same freemium model as the rest of the services with limitations on email:
You can get started with Amazon SNS for free. Each month, Amazon SNS customers pay no charges for the first 100,000 Amazon SNS Requests, no charges for the first 100,000 Notifications over HTTP and no charges for the first 1,000 Notifications over Email.
If I were you, and if I REALLY wanted to make SQS work for this scenario, I would create a windows service that retrieves any messages from the queue every 10 minutes and then dispatches them.
If I could potentially use a different service, I would seriously consider using something like Postmark (Which I just found out about today thanks to a comment on Jeff Atwood’s blog post). You would just submit your email message info to their api, and they would do the rest. They even have a api for checking for bounced emails. I have never used this service, but I think it sounds great and would seriously consider using it in the future.
Looks like SES is what you need. http://aws.amazon.com/ses/ It is very inexpensive too compared to other similar services or building other systems.
You can use the AWS Beanstalk service to consume the tasks in the Queue.
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features-managing-env-tiers.html
Windows service is the best way, but you must not take it. To run background job in ASP.NET environment there is HostingEnvironment.QueueBackgroundWorkItem. A good starting point to implement continues polling (via long polling) is sqs-consumer.