- Show the various communication types and terminology.
- Use Resque to deliver welcome emails ansynchronously
Asynchronous messaging will send a message and return immediately.
A message can be a call to a method or function. Calling a method is actually sending a message to a object.
Smalltalk and many OO purist use the sending a message language instead of calling a method.
A good example of an asynchronous message is sending a letter though the US Mail or through "the post".
We will not get an immediate reply or response to our letter. It takes some time to get delivered. And we may, or may not get a reply.
The channel that we sending the message through is the US Postal Service. The message container is the envelope and message content is the text in the letter.
If no reply is expected it would be a fire and forget type of message. Thinking that most junk mail sent is a fire and forget type of message.
If we have a reply to our letter then the recipient used the return address as a callback. The message container, envelope, has a return address that can be used as a callback.
If the letter is sent to more than one recipient it would be multicast. For example a bulk advertisement would be multicast to many potential customers and the message would mostly be a fire and forget message.
If the sender was frozen in suspended animation after sending the letter then they would be in blocking mode. Imagine one deposits their letter in a mailbox and is frozen until the mailman delivers a reply.
Of course, we can go on with our lives while we wait for a response to a letter. So we operate in non-blocking mode. Doing something after depositing the letter.
If we continually check our mailbox for a reply to our letter we are polling the mailbox.
If we're really obsessed we could be stopped from doing anything until we receive a reply. Continually polling our mailbox and doing nothing else, a kind of blocking, until we get a response. A desperate state it is.
-
Asynchronous messaging Send a message and return immediately.
-
Blocking mode - Waiting for a reply to a message or operation until a reply is received.
-
Non-blocking mode - Send a message and return immediately to the entity that sent the message. No waiting for a reply to a message.
-
Fire and Forget - Send a message that you don't expect a reply to.
-
Multicast - Send a message to more than one receiver.
-
Point to Point - Send a message to a specific receiver.
-
Callback - The operation to perform by the reciever after processing an incomijng message. Many times it will be an operation involving the sender of the message. Perhaps telling the sender of the status of the operation requested in the sent message.
-
Channel - A container of messages. Typically this would be a queue that each message would be sent to. But, there are many types of Channels.
- Priority Queue - Each message has a priority that it will processed according to.
- Topic Hierarchy - A tree where each node is a topic and a subscriber can register to recieve all messages for a topic and the sub-topics of a topic node.
- Persistent Queue - Persist the contents until in case the queue crashes and needs to restart in a known state.
- Telegraph - Non-blocking , point to point messaging.
Telegram is sent from one office to another. - Email - Non-blocking. Can be point to point or multi-cast. Sending to one receipient is point to point. Sending to a mailing list or CC'ng many would be multicast.
- Ajax HTTP Requests - Non-blocking, point to point. Typically requires a callback.
- DOM Event Handling - DOM Events are put into a web browser's queue and pulled out and processed after the Javascript call stack is empty. These are non-blocking messages/events that are processed by a callback.
This should be more familiar to us as we have been mostly using this throughout this course.
Synchronous messaging will send a message and wait for a reply.
- Tawking to another person. A conversation.
Unless your exceedingly pedantic an insist that each party in the conversation take turns talking. - A phone call.
- Skype.
- Invoking a function or method. Passing a message to an object.
- Calling a function that will read data from a file.
Reading data from a file will block the main execution thread of a program while it:
- Spins up the Disk Drive.
- Does a transalation from virtual memory to physical memory.
- Cause a page fault.
- Look for the drive track and sector that the contents of the file resides in.
- Read the contents from the disk.
- Return the data read.
- Making a HTTP Request to remote API. We will block until the API returns a response. Typically, we will have a timeout, 30 seconds maybe, that we wait for a reply.
- Uploading a file.
For example, if one has to upload a large video file it can block the process that should be serving HTTP Requests. Maybe, the video needs to converted to another format? This can be a very long running process that will block the requestor for a long time.
We are going to move the task of sending an email through Rails from being a synchronous task to a asynchronous task.
Resque implements a Publisher Subcriber design pattern. Resque uses Redis to define queues, or channels, that we publish messages into. http://www.eaipatterns.com/toc.html Excellent resource for messaging pattern: Enterprise Integration Patterns
Rails will publish a message that will represent some operation, send email in this case, into a queue.
These send email messages will be pulled out of the queue and processed by worker processes that subscribe to the queue that Rails is publishing into.
We are going to start off with the completed rails action mailer lesson. From Rails EMail Demo github repo. This is from the 'done' branch.
This will replace a synchronous call to send an email with a asynchronous call_. Resque.enqueue will push a messages into a Resque, backed by Redis, queue.
The controller is acting as a publisher.
def create
...
# UserMailer.signup_confirmation(@user).deliver
Resque.enqueue(MailWorker, @user.id)
...
end
This will create a Plain Old Ruby Object (PORO) that will be a Resque Worker.
A Worker subscribes to a queue pulling messages off that queue and processing them. In this case we will be pulling messages that direct the Workers to mail signup confirmations.
We MUST set a queue that the messages will be published into and subscribers/workers will pull off of.
The worker/s are subscribers.
class MailWorker
@queue = :mailer_queue
def self.perform(user_id)
@user = User.find(user_id)
# Send sign up email
UserMailer.signup_confirmation(@user).deliver
end
end
This will start Redis locally on port 6379.
brew install redis
redis-server /usr/local/etc/redis.conf
Add this to the Gemfile and bundle
gem "resque", "~> 2.0.0.pre.1", github: "resque/resque"
This will make the Rails environment, (models, ...), available within Resque classes. Typically Resque workers.
require "resque/tasks"
# Make Rails models, etc., available to Resque workers.
task "resque:setup" => :environment
defaults: &defaults
host: localhost
port: 6379
development:
<<: *defaults
staging:
<<: *defaults
production:
<<: *defaults
Dir[File.join(Rails.root, 'app', 'workers', '*.rb')].each { |file|
require file }
config = YAML::load(File.open("#{Rails.root}/config/redis.yml"))[Rails.env]
puts "Redis config is #{config}"
Resque.redis = Redis.new(:host => config['host'], :port => config['port'])
We don't have any yet, but it doesn't blow up :-)
rake resque:work QUEUE='*'
Start rails and go to the localhost:3000. Enter in a name and email.
A welcome email for the new users should show up in the mailcatcher web interface
Implement the above using alternate background processing libraries such as, Delayed Job and Sidekiq. See Railscasts for these libraries and Comparing Background Libraries
If you're feeling like a challenge send emails asynchronously with ZeroMQ.
OR if sending email doesn't work with ZeroMQ try executing a long running task with ZeroMQ. For example a large-ish fibonacci calculation as shown in this article.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent