I am working on one Asp.Net application and need to send mails periodically based on some event. First I thought of creating a thread in global.asax and start thread in application_start. But that becomes a bit of problem when application pool crashes or something. So I implemented a windows service and started thread in that and log any errors in windows event log. This works fine. But I need to know whether I am implementing it correctly or is there a better way of doing it?
I think you are moving (or moved already) to the right direction.
We have similar architectures as well, in some cases we used MSMQ to queue outgoing notifications from the ASP.NET application then the Windows Service, usually called Messaging Manager, can grab asynchronously the incoming messages and send the emails or alerts out.
this proves to be effective and robust, if anything crashes after the message has been queued, nothing will be lost because the windows service will always process the messages in the queue, so you can have ASP.NET recycling or the machine with the windows service being rebooted, nothing is lost ever. And in fact in normal production mode, messages are sent out instantly, the decoupling or loose of sync is mostly hidden when everything is working smooth and servers are not overloaded or suffering anything.
In a later project we are now implementing something similar using TIBCO technologies, EMS for the queues and Business Works for queue subscribers.
Using a Windows Service for this kind of tasks is the preferred way instead of doing it in the ASP.NET application. You may also take a look at Quartz.NET which could simply your code for scheduling the task execution and dealing with threads. But if you don't want to write Windows Services probably the simplest would be to have a console application that will do the job of sending emails and then simply use the Windows Task Scheduler to run it at regular intervals.
Another option is a message-based approach. You could have a Windows Service/Console Application reading messages of a message queue (like msmq) and send email when a message is recieved. You can then have your ASP.NET application publish messages to this queue.
Minibuss is a lightweight client for msmq which is very easy to work with. Another options is NServiceBus.
Related
I want to deploy an Windows services in parallel for redundancy and load balancing purposes.
How can i be sure that when the client sends a request to both of these services, that only 1 of them process the actual call?
Example:
When the client or other services sends a message to start a manufacturing process, both of these services will recieve that request. I want to make sure that only one of those services processes this request, so that manufacturing process do not get started twice!
Do they need to able to talk to themself?
Is there a possibility to sync those services?
Which is the most elegant/robust way of handling this problem?
Look into using a mutex to allow both services to only pick up a message once.
Mutex Description C#
Although, you'll need to make sure this can work in the way you want. this can help schedule between application processes and boundaries, but if this is deploy to two different machines, or Cloud services, the Mutex isn't going to work.
for that you'll need to figure out another of communicating across the applications, usually using a database or a MSMQ to create a message queue that you can pop messages off as you need them from each service.
The safest way, and also the best practice, for your example, would be to retrieve (not to peek) messages from a queue leveraging MSMQ. This gives you a clear explanation of the use case: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/msmq/ms706253(v=vs.85)
~Pino
I'm doing a simple Messaging system for a Windows Mobile in C#. The application consists in sending and receiving simple text messages using a Web service communication. The messages queue should be persistent, avoiding data lost if the connection with the web service fail or the application crash.
I know about MSMQ, RabbitMQ, DotNetMQ, but they should be installed in the device and this are really simple devices, I don't want to install any other tool in each of the mobiles just for this simple task.
I already implemented the function to write an XML serialized queue with the messages into a file and I read and write all the time from this file.
I'd appreciate any better idea to solve this problem.
Thanks
MSMQ does not need to be installed is supported natively on Windows Mobile 6.5 devices. BTW: there are still many vendors in industrial area providing WM65 based devices, so this is not yet outdated.
The Windows Mobile (CE) based MSMQ is persistent and simple to use. It is normally used for interprocess-communication on the device or for client server communication (which requires MSMQ installed on the 'server').
So, the main thread creates a MSMQ, one thread in your process fills the MSMQ and another can 'peek' and, after successful transmission, 'dequeue' messages from the same MSMQ. See here for a simple example.
I don't really know what's available for Windows Mobile but you can try using basic queue (normal or concurrent, depends on your app) accompanied by two files. Write everything that is enqueued to one "Enqueue log" file and write everything that is dequeued to another "Dequeue log" file.
This two files can always give you enough information to restore your queue, and you don't need to fully rewrite/fully serialize your queue. It needs to be implemented by hand though.
About dequeue:
for example, lets say I have a queue with 3 messages: "one", "two", "three". Now I want to send the next (also the first) message "one". I append the line "one - starting removal from queue" to my "dequeue log", then I dequeue "one" from my queue object and send it where I want it to be sent to. When it is sent, I append " - finished removal from queue" to my "dequeue log". Now I have a line "one - starting removal from queue - finished removal from queue" in my log file.
It doesn't matter when do I crash, I'll always will be able to restore the state of queue object (at least for now I fail to see any logic mistakes in this process). So imho it's not tricky but still... some code should be coded. And it would be a few pages of code.
Sure, there is a better idea is to use SQLite.
I hope this will help you.
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.
So basically I am thinking about attempting load testing on my asp.net application using various features all at once. There is a lot of dependencies and ajax requests being performed in this application so it seems like a simple replay of captured http requests will not suffice and due to other features like picking out random operations, performing then verifying results across several machines, simple load testing software will not suffice.
Also there is no budget to this project for spending, so commercial implementations can not be used. I'm debating on trying to use MSMQ (never used before) to handle communication between clients, but if that is really complicated to set up then I would either use a database table as a queue or a simple TCP server with each test machine as its clients.
Features I want are: immediate failure (one client crashes, then all clients should stop), each test run should start with a brand new scenario with no prior messages, and ability to publish a start and stop event. Also it would be nice if I don't have to worry about state management (leaning towards TCP server for this over database) or concurrency.
It doesn't sound like MSMQ is what you need. It is a message-passing asynchronous communication method, akin to email. You can send a message to another queue that no one is even listening to (i.e. the application isn't running). It seems to me you want a more "online" communication model.
How about creating agents (client applications that sit on many machines and create the load) that expose a WCF service where a controller program can connect to all of them and instruct the agents what to do? It can be a duplex contract, so that the agents can send the controller a notifications. When one of them send a error notification, the controller can instruct all the other agents to shut down. Also I'd go for a Net.TCP binding rather than HTTP binding.
Some time ago i Wrote a service with a timer that make an action every n minutes. All was right. But now, I want to write a service that waits for a signal, message or something from a gui application for doing his job.
I want me process to sleep pacefull (not in a infinite loop sniffing something) until my winforms application tell him "Hey, do things and give me a ring when the work is done"
could someone give me staring point?
Thanks.
You can use Windows Communication Foundation to allow your client to communicate with your service, send it requests, and register to receive progress events from existing running jobs.
You need to use interprocess communication (IPC). For C#, this usually means either .NET remoting -- on older versions of .NET -- or Windows Communication Foundation (WCF) -- on newer versions of .NET.
Essentially, the client application connects to an interface implemented by the service, and can then call methods on it, as if it was in the same process.
If this is too complicated, you could use a named event object, which the service waits on, and the client sets.
Starting point:
Self-hosting WCF service
Any of the IPC mechanisms qualify to get this done. If your needs a simple, just message passing, consider either a named pipe (NamedPipeServerStream) or a socket. If they are elaborate, consider Remoting over an IPC channel or WCF.
Personally, I like named pipes for this. Just make sure the pipe name is prefixed by "Global\" so it is visible from the interactive desktop session. Encrypt the messages if security is a concern. Spin up a background thread in your service that makes a blocking call on the pipe stream to implement the message handling.
If the windows service is on the same machine, you could stop and start the service? or call a webservice that stops/starts a service on a another machine?
If you did have a service that polls (or "sniffs") for something to do , this could be a very small and basic call to a database to check for something that will trigger the actual work?