RubyKaigi is happening at Sendai, Japan from 31st May to
2nd June. It is perhaps the only conference where one can find almost all
the core Ruby team members in attendance.
This is Prathamesh.
I bring you live details about what is happening
at the Kaigi over the next two days.
If you are at the conference please come and say “Hi” to me.
Faster Apps, No Memory Thrash: Get Your Memory Config Right by Noah Gibbs
Noah
gave an awesome talk on techniques to manage
the memory used by Ruby applications.
One of the main point while dealing with GC is to
make it run less, which means don’t create too many objects.
He also mentioned that
if application permits then
destructive operations such as gsub! or concat
should be used
since they save CPU cycles and memory.
Ruby allows setting up environment variables for managing the heap memory
but it is really hard to choose values for these environment variables blindly.
Noah has built a tool which uses GC.stat results from applications
to estimate the values of the memory related environment variables. Check out the
EnvMem gem.
In the end, he discussed some advanced debugging methods like checking
fragmentation percentage. The formula is prepared by Nate Berkopec.
We can also use GC::Profiler to profile the code in real time to see how GC is behaving.
Benchmark used for this talk can be found here.
Slides for this talk can be found here.
Guild prototype
Next I attended talk by
Koichi Sasada
on
Guild prototype. He discussed the proposed design spec for Guild with a demo
of Fibbonacci number program with 40 core CPU and 40 guilds.
One of the
interesting observations is that
performance drops as number of guilds increases because
of the global locking.
He discussed the concept of sharable and non-sharable objects. Sharable objects can be shared
across multiple Guilds whereas non-sharable objects can only be used one Guild. This also means,
you can’t make thread unsafe program with Guilds “by design”.
He discussed about the challanges
in specifying the sharable objects for Guilds.
Overall, there is stil a lot of work left to be done for Guilds to become a part of Ruby. It includes
defining protocols for sharable and non-sharable objects, making sure GC runs properly in case of Guilds,
synchronization between different Guilds.
Soutaro from SideCI gave a talk on
Steep, a gradual type checker for Ruby.
In the past, Matz has said that he doesn’t like type definitions to be
present in the Ruby code. Steep requires type definitions to be present
in separate files with extension .rbi. The Ruby source code needs little
amount of annotations.
Steep also has a scaffold generator to generate the basic type definitions
for existing code.
As of now, Steep runs slower than Sorbet which was discussed yesterday by Stripe team.
Soutaro also discssued issues in type definitions due to meta programming in libraries such as Active Record.
That looks like a challange for Steep as of now.
Web console
After the tea break, I attended talk by Genadi on how web console works.
He discussed the implementation of web-console in detail with references to
Ruby internals related to bindings. He compared the web-console interface
with IRB and pry and explained the difference. As of now, web console has to
monkey patch some of the Rails internals. Genadi has added support for
registering interceptors which
will prevent this monkey patching in Rails 6. He is also mentoring a Google summer of
code student to work on Actionable errors project where the user can take actions like running pending
migrations via the webpage itself when the error is shown.
Ruby committers v/s the World
RubyKaigi offers this unique event where all the Ruby committers come on stage and
face the questions from the audience. This year the format was slightly different
and it was run in the style of the Ruby core developer meeting. The agenda was
predecided with some questions from the people and some tickets to discuss.
The session started with discussion of features coming up in Ruby 2.6.
After that, the questions and the tickets in the agenda were discussed. It was good
to see how the Ruby team takes decisions about features and suggestions.
RubyKaigi is happening at Sendai, Japan from 31st May to
2nd June. It is perhaps the only conference where one can find almost all
the core Ruby team members in attendance.
This is Prathamesh.
I bring you live details about what is happening
at the Kaigi over the next three days.
If you are at the conference please come and say “Hi” to me.
Matz’s keynote
RubyKaigi started with Matz’s keynote. He used lot of proverbs applying
them to the Ruby language and software development.
He talked about one of the hardest problems in programming - naming with an example of
yield_self.
Matz added alias then to the yield_self method yesterday. He also discussed about googlability of the names.
Ironically, Ruby was named in 1993 which was before Google had started.
Matz also touched upon
JIT option being introduced in Ruby 2.6
and guild as the ways the language continues to improve in
performance and concurrency.
There is a talk on Guild by Koichi Sasada on second day of RubyKaigi which
will have further details about it.
Matz ended the keynote talking about the need of maintaining backward compatibility
and not running into the situation like Ruby 1.9 or Python 3 where the compatibility was not
maintained. He also stressed upon the community aspect of the Ruby language and its importance
in the success of Ruby.
ETL processing in Ruby using Kiba
Thibaut Barrère
gave a talk on
Kiba - a data processing ETL framework for Ruby.
He discussed about
the design decisions that went into the version 1 and how it evolved to version 2 which was recently released.
Kiba provides programmatic API which can be used in the background jobs instead of shelling out. It also
has support for multistep batch processing.
Thibaut also explained how it can be used for data migration,
reusing the components and big rewrites. He observed that the performance has been gradually increasing with each Ruby release over the years.
Next I attended talk from
Anton Davydov
on architecture patterns in Hanami apps.
He discussed about the problems typical Rails applications face
and
how abstractions can address those issues.
He explained how Hanami tries to achieve business logic isolation, avoid global state, sequential logic and test coverage.
Functional callable objects, containers, dry-containers, dry-inject and event sourcing are some of the abstractions that can be used in Hanami apps that help in
achieving this.
Lightning talks
The last session of the day was lightning talks.
The talk on
Rib(wordplay on IRB) was an interesting one. Rib is yet another interactive Ruby shell but lightweight compared to IRB and pry. It has some nice features like auto indent, multiline history, filtering of callers. It can also beep when the console starts, so you know it is time to get back to work.
I liked another talk where
Watson
had worked on improving the performance of JSON gem.
He achieved this by using CRuby API whereever applicable and avoiding heavy calls like rbfuncall.
Check these two
pullrequests for benchmark and more discussions.
Apart from these talks,
there were lot of other talks as well which I could not attend.
Stripe team
is building a
type checker for Ruby
which looks very interesting and is is extremely fast.
Bozhidar Batsov
gave a talk on Rubocop project and
how it has evolved over the years.
There was also a talk on Karafka - event driven architecture in Ruby.
This talk was a good precursor to the Hanami talk where event driven architecture was mentioned again.
Other talks from day one
ranged from memory management, playing with Ruby synatx, code highlighter, deep learning, C extensions to Rubygems.
That’s all for the day one. Looking forward to the day two already!
Rails 5.0 had introduced
redirect_back method
to perform redirection to
path present in HTTP_REFERER.
If there is no HTTP_REFERER present,
then site is redirected to fallback_location.
Now consider the following scenario.
In one of the searches on google.com,
we see a link to bigbinary.com.
On clicking the link,
we are navigated to bigbinary.com.
When somebody gets redirected to bigbinary.com from google.com,
the HTTP REFERER is set to google.com
If bigbinary.com uses redirect_back in its code
then the user will get redirected to google.com
which might be undesired behavior for some applications.
To avoid such cases,
Rails 5.2 has added a flag
allow_other_host
to not allow redirecting to a different host other than the current site.
By default, allow_other_host option is set to true.
So if you do not want users to go back to google.com then
you need to explicitly set allow_other_host: false.
> request.host
#=> "http://www.bigbinary.com"
> request.headers["Referer"]
#=> "http://www.google.com"
# This will redirect back to google.com
redirect_back(fallback_path: "/")
# This will not redirect back to google.com
redirect_back(fallback_path: "/", allow_other_host: false)
There are various ways to generate JSON in Rails.
There is
to_json
method built in Rails.
We can also use
jbuilder gem
or
active model serializer gem
which can help us achieve the same.
As the number of records in the database grow,
Rails can take a very long time to generate a response.
The bottleneck can generally be traced back to JSON generation.
Recently,
in one of our applications,
we faced this issue where a
page was taking too long to load.
The load time was critical for us
as this was the most visited page on the site.
The page was loading a race,
its racers and their lap details.
The page was loading fine for short races,
with 10-15 racers and each racer having 30-50 laps.
But for endurance races,
with around 50-80 racers and each racer having around 700-800 laps,
we were hitting the bottleneck with load times.
After benchmarking, JSON generation at the backend was found to be the culprit.
PostgreSQL 9.2 and above have built in support for generating JSON
using functions row_to_json and array_to_json.
Let’s look into both of them in detail.
row_to_json
row_to_json returns each of the rows as JSON object.
We could use a subquery to only fetch the attributes/columns which we require.
select row_to_json(lap)
from (
select id, number, position, time, flag_type from laps
) lap;
{"id":1,"number":1,"position":4,"time":"628.744","flag_type":"Green"}
{"id":2,"number":2,"position":4,"time":"614.424","flag_type":"Green"}
.
.
.
array_to_json
To understand array_to_json function,
we must first look into array_agg.
array_agg is an aggregate function.
Aggregate functions compute a single result
from a set of input values.
sum, min, max are some other examples
of aggregate functions.
array_agg concatenates all the input values
into a PostgreSQL array.
select array_agg(lap)
from (
select id, number, position, time, flag_type from laps
) lap;
{"(1,1,4,\"628.744\",\"Green\")","(2,2,4,\"614.424\",\"Green\")", ... }
To convert this PostgreSQL array into JSON,
we can use the array_to_json function.
select array_to_json(array_agg(lap))
from (
select id, number, position, time, flag_type from laps
) lap;
[{"id":1,
"number":1,
"position":4,
"time":"628.744",
"flag_type":"Green"},
...]
A more complex example
We can use the above two functions
together to generate custom JSON response.
select row_to_json(u)
from (
select first_name, last_name,
(
select array_to_json(array_agg(b))
from (
select number, position, time, flag_type
from laps
inner join racer_laps
on laps.id = racer_laps.lap_id
where racer_laps.racer_id = racers.id
) b
) as laps
from racers
where first_name = 'Jack'
) u;
{
"first_name": "Jack",
"last_name": "Altenwerth",
"laps": [
{
"number": 1,
"position": 4,
"time": "628.744",
"flag_type": "Green"
},
{
"number": 2,
"position": 4,
"time": "614.424",
"flag_type": "Green"
},
...
]
}
Using the functions in Rails
We can use the above mentioned functions in Rails as shown here.
query = <<~EOQ
select row_to_json(u)
from (
select first_name, last_name,
(
select array_to_json(array_agg(b))
from (
select number, position, time, flag_type
from laps
inner join racer_laps
on laps.id = racer_laps.lap_id
where racer_laps.racer_id = racers.id
) b
) as laps
from racers
where first_name = 'Jack'
) u;
EOQ
generated_json = ActiveRecord::Base.connection.execute(query).values;
puts generated_json
{
"first_name": "Jack",
"last_name": "Altenwerth",
"laps": [
{
"number": 1,
"position": 4,
"time": "628.744",
"flag_type": "Green"
},
{
"number": 2,
"position": 4,
"time": "614.424",
"flag_type": "Green"
},
...
]
}
Although the code to generate the JSON
using the above way is more verbose
and less readable
compared to other ways to generate JSON in Rails,
it is more performant.
Observations
On the racer’s page,
generating the JSON using the PostgreSQL functions,
gave us the following improvements.
For short races (10-15 racers and each racer having 30-50 laps),
the average API response time decreased from 40ms to 15ms.
For endurance races (50-80 racers and each racer having around 700-800 laps),
the average API response time decreased from 1200ms to 20ms.
Conclusion
Use Rails way of generating JSON as long as you can.
If performance starts to be an issue then
don’t be afraid of using the features made available
by the database. In this case we would be trading
performance for complexity in code. However sometimes
this trade is worth it.
We wanted to have a tool that is easy to use and that will help
us capture what response we are getting from the API in a format
that is easy to share in github issue, in slack or in an email.
As a consulting company we work with various teams
around the world and during development phase either API is unstable
or they do not do what they should be doing.
We originally built this tool using React.
Elm compiler is quite strict and forced us to take into consideration
all possibilities. This lead us to notice a few bugs which were still
present in React code.
In this way Elm compiler helped us produce “correct” software
by eliminating some of the bugs that we would have found later.
JSON encoding/decoding is a hard problem in Elm in general.
In most of the cases we know the shape of the API response
we are going to get.
In the case of
APISnapshot
we do not know the shape of the JSON response we will get.
Because of that it took us a bit longer to build the application.
However, this forced us to really dig deep into JSON encoding/decoding
issue in Elm and we learned a lot.
We would like to thank all the contributors
to the project. Special shout out goes to
Jasim for the discussion
and
the initial work
on parsing the JSON file.
We like the combination of Elm and Ruby on Rails so much so that
we are building AceHelp using the same technologies.
AceHelp is open source
from day one.
In Ruby 2.4 when we pass a block to a method, which further passes to another
method, Ruby creates a new Proc object by the given block before passing this proc to the
another method.
This creates unnecessary objects even when the block parameter is not accessed.
It also creates a chain of Proc objects when the block parameter is passed
through various methods.
Proc creation is one a heavyweight operation because
we need to store all local variables (represented by Env objects in MRI internal) in the heap.
Ruby 2.5 introduced a lazy proc allocation.
Ruby 2.5 will not create a Proc object
when passing a block to another method.
Insead, it will pass the block information.
If the block is accessed somewhere else, then it creates a Proc object by the given block.
This results in lesser memory allocation and faster execution.
Prior to Rails 5.2, MySQL and PostgreSQL adapters had
select_value, select_values & select_rowsselect_{value,values,rows}
methods.
They improve the performance
by not instantiating
ActiveRecord::Result.
However these methods broke query caching of
ActiveRecord::FinderMethods#exists? method.
Let’s check the issue.
Recently, we faced a DDoS attack in one of the clients’ projects. There were many requests from different IPs to root and login paths, and we were running thrice the usual number of servers to keep the system alive.
We are using Cloudflare’s HTTP proxy and it was doing a great job preventing malicious requests, but we wanted to check if we can avoid the loading/captcha pages which Cloudflare uses to filter requests. We came to a conclusion that we would be able to mitigate the ongoing attack if we could throttle requests by IP.
Cloudflare has an inbuilt Rate Limiting feature to throttle requests, but it would be a little expensive in our case since Cloudflare charges by the number of good requests and it was a high traffic website. On further analysis, we found that throttling at application level would be enough in that situation and the gem
Rack::Attack
helped us with that.
Rack::Attack is a Rack middleware from Kickstarter. It can be configured to throttle requests based on IP or any other parameter.
To use Rack::Attack, include the gem in Gemfile.
gem"rack-attack"
After bundle install, configure the middleware in config/application.rb:
config.middleware.useRack::Attack
Now we can create the initializer config/initializers/rack_attack.rb to configure Rack::Attack.
By default, Rack::Attack uses Rails.cache to store requests information.
In our case, we wanted a separate cache for Rack::Attack and it was configured as follows.
If the web server is behind a proxy like Cloudflare, we have to configure a method to fetch the correct remote_ip address. Otherwise, it would block based on proxy’s IP address and would result in blocking a lot of legit requests.
classRack::AttackclassRequest<::Rack::Requestdefremote_ip# Cloudflare stores remote IP in CF_CONNECTING_IP header@remote_ip||=(env['HTTP_CF_CONNECTING_IP']||env['action_dispatch.remote_ip']||ip).to_sendendend
Requests can be throttled based on IP address or any other parameter.
In the following example, we are setting a limit of 40rpm/IP for “/” path.
The downside of this configuration is that after the 1 minute period, the attacker can launch another 40 requests/IP simultaneously and it would exert pressure on the servers. This can be solved using exponential backoff.
classRack::Attack# Exponential backoff for all requests to "/" path## Allows 240 requests/IP in ~8 minutes# 480 requests/IP in ~1 hour# 960 requests/IP in ~8 hours (~2,880 requests/day)(3..5).eachdo|level|throttle("req/ip/#{level}",:limit=>(30*(2**level)),:period=>(0.9*(8**level)).to_i.seconds)do|req|req.remote_ipifreq.path=="/"endendend
If we want to turn off throttling for some IPs (Eg.: Health check services), then those IPs can be safelisted.
classRack::AttackclassRequest<::Rack::Requestdefallowed_ip?allowed_ips=["127.0.0.1","::1"]allowed_ips.include?(remote_ip)endendsafelist('allow from localhost')do|req|req.allowed_ip?endend
We can log blocked requests separately and this is helpful for analyzing the attack.
Sidekiq
is a background job processing library for Ruby.
Sidekiq offers three versions: OSS, Pro and Enterprise.
OSS is free and open source and has basic features.
Pro and Enterprise versions are closed source and paid,
thus comes with more advanced features.
To compare the list of features offered by each of these versions,
please visit Sidekiq website.
Sidekiq Pro 3.4.0
introducedsuper_fetch strategy
to reliably fetch jobs from the queue in Redis.
In this post, we will discuss the benefits of using super_fetch strategy.
Problem
Open source version of Sidekiq comes with basic_fetch strategy.
Let’s see an example to understand how it works.
Let’s add Sidekiq to our Gemfile and run bundle install to install it.
gem'sidekiq'
Add following Sidekiq worker in app/workers/sleep_worker.rb.
As we can see, the job with ID 5d8bf898c36a60a1096cf4d3
was picked up by Sidekiq
and it started processing the job.
If we check the Sidekiq queue size in the Rails console, it will be zero now.
>>Sidekiq::Queue.new.size=>0
Let’s shutdown the Sidekiq process gracefully
while Sidekiq is still in the middle of processing our scheduled job.
Press either Ctrl-C or run kill -SIGINT <PID> command.
As we can see, Sidekiq pushed back the unfinished job back to Redis queue
when Sidekiq received a SIGINT signal.
Let’s verify it.
>>Sidekiq::Queue.new.size=>1
Before we move on, let’s learn some basics about signals such as SIGINT.
A crash course on POSIX signals
SIGINT is an interrupt signal.
It is an alternative to hitting
Ctrl-C from the keyboard.
When a process is running in foreground,
we can hit Ctrl-C to signal the process to shut down.
When the process is running in background,
we can use kill command to send a SIGINT signal to the process’ PID.
A process can optionally catch this signal and shutdown itself gracefully.
If the process does not respect this signal and ignores it,
then nothing really happens and the process keeps running.
Both INT and SIGINT are identical signals.
Another useful signal is SIGTERM.
It is called a termination signal.
A process can either catch it
and perform necessary cleanup or just ignore it.
Similar to a SIGINT signal,
if a process ignores this signal, then the process keeps running.
Note that, if no signal is supplied to the kill command,
SIGTERM is used by default.
Both TERM and SIGTERM are identical signals.
SIGTSTP or TSTP is called terminal stop signal.
It is an alternative to hitting Ctrl-Z on the keyboard.
This signal causes a process to suspend further execution.
SIGKILL is known as kill signal.
This signal is intended to kill the process immediately and forcefully.
A process cannot catch this signal,
therefore the process cannot perform cleanup or graceful shutdown.
This signal is used
when a process does not respect and respond
to both SIGINT and SIGTERM signals.
KILL, SIGKILL and 9 are identical signals.
There are a lot of other signals besides these,
but they are not relevant for this post.
Please check them out here.
A Sidekiq process pays respect
to all of these signals and behaves as we expect.
When Sidekiq receives a TERM or SIGTERM signal,
Sidekiq terminates itself gracefully.
Back to our example
Coming back to our example from above,
we had sent a SIGINT signal to the Sidekiq process.
$kill-SIGINT40510
On receiving this SIGINT signal,
Sidekiq process having PID 40510 terminated quiet workers,
paused the queue and waited for a while
to let busy workers finish their jobs.
Since our busy SleepWorker did not finish quickly,
Sidekiq terminated that busy worker
and pushed it back to the queue in Redis.
After that, Sidekiq gracefully terminated itself with an exit code 0.
Note that, the default timeout is 8 seconds
until which Sidekiq can wait to let the busy workers finish
otherwise it pushes the unfinished jobs back to the queue in Redis.
This timeout can be changed with -t option
given at the startup of Sidekiq process.
Sidekiq recommends
to send a TSTP and a TERM together
to ensure that the Sidekiq process shuts down safely and gracefully.
On receiving a TSTP signal,
Sidekiq stops pulling new work
and
finishes the work which is in-progress.
The idea is to first send a TSTP signal,
wait as much as possible (by default for 8 seconds as discussed above)
to ensure that busy workers finish their jobs
and then send a TERM signal
to shutdown the process.
Sidekiq pushes back the unprocessed job in Redis when terminated gracefully.
It means that Sidekiq pulls the unfinished job and starts processing again when
we restart the Sidekiq process.
We can see that Sidekiq pulled the previously terminated job
with ID 5d8bf898c36a60a1096cf4d3 and processed that job again.
So far so good.
This behavior is implemented using
basic_fetch
strategy which is present in the open sourced version of Sidekiq.
Sidekiq uses BRPOP Redis command
to fetch a scheduled job from the queue.
When a job is fetched,
that job gets removed from the queue and
that job no longer exists in Redis.
If this fetched job is processed, then all is good.
Also, if the Sidekiq process is terminated gracefully on
receiving either a SIGINT or a SIGTERM signal,
Sidekiq will push back the unfinished jobs back to the queue in Redis.
But what if the Sidekiq process crashes in the middle
while processing that fetched job?
A process is considered as crashed
if the process does not shutdown gracefully.
As we discussed before,
when we send a SIGKILL signal to a process,
the process cannot receive or catch this signal.
Because the process cannot shutdown gracefully and nicely,
it gets crashed.
When a Sidekiq process is crashed,
the fetched jobs by that Sidekiq process
which are not yet finished get lost
forever.
Therefore,
the job having name argument as B or ID as 37a5ab4139796c4b9dc1ea6d
is completely lost.
There is no way to get that job back.
Losing job like this may not be a problem for some applications
but for some critical applications this could be a huge issue.
We faced a similar problem like this.
One of our clients’ application is deployed on a Kubernetes cluster.
Our Sidekiq process runs in a Docker container
in the Kubernetes
pods
which we call background pods.
Here’s our stripped down version of
Kubernetes deployment
manifest which creates a Kubernetes deployment resource.
Our Sidekiq process runs in the pods spawned by that deployment resource.
When we apply an updated version of this manifest
,for say, changing the Docker image, the running pods are terminated
and new pods are created.
Before terminating the only container in the pod,
Kubernetes executes sidekiqctl stop $pid 60 command
which we have defined using the
preStop
event handler.
Note that, Kubernetes already sends SIGTERM signal
to the container being terminated inside the pod
before invoking the preStop event handler.
The default termination grace period is 30 seconds and it is configurable.
If the container doesn’t terminate within the termination grace period,
a SIGKILL signal will be sent to forcefully terminate the container.
The sidekiqctl stop $pid 60 command executed in the preStop handler does
three things.
Sends a SIGTERM signal to the Sidekiq process running in the container.
Waits for 60 seconds.
Sends a SIGKILL signal to kill the Sidekiq process forcefully
if the process has not terminated gracefully yet.
This worked for us when the count of busy jobs was relatively small.
When the number of processing jobs is higher,
Sidekiq does not get enough time
to quiet the busy workers
and fails to push some of them back on the Redis queue.
We found that some of the jobs were getting lost
when our background pod restarted.
We had to restart our background pod for
reasons such as
updating the Kubernetes deployment manifest,
pod being automatically evicted by Kubernetes
due to host node encountering OOM (out of memory) issue, etc.
We tried increasing both
terminationGracePeriodSeconds in the deployment manifest
as well as the sidekiqctl stop command’s timeout.
Despite that,
we still kept facing the same issue
of losing jobs whenever pod restarts.
We even tried sending TSTP and then TERM after a timeout
relatively longer than 60 seconds.
But the pod was getting harshly terminated
without gracefully terminating Sidekiq process running inside it.
Therefore we kept losing the busy jobs
which were running during the pod termination.
Sidekiq Pro’s super_fetch
We were looking for a way to stop losing our Sidekiq jobs
or a way to recover them reliably when our background Kubernetes pod restarts.
We realized that the commercial version of Sidekiq,
Sidekiq Pro offers an additional fetch strategy,
super_fetch,
which seemed more efficient and reliable
compared to basic_fetch strategy.
Let’s see what difference super_fetch strategy
makes over basic_fetch.
We will need to use sidekiq-pro gem which needs to be purchased.
Since Sidekiq Pro gem is close sourced, we cannot fetch it
from the default public gem registry,
https://rubygems.org.
Instead, we will have to fetch it from a private gem registry
which we get after purchasing it.
We add following code to our Gemfile and run bundle install.
See that line where it says SuperFetch: recovered 1 jobs.
Although the job wasn’t pushed back to the queue in Redis,
Sidekiq somehow recovered our lost job having ID f002a41393f9a79a4366d2b5
and reprocessed that job again!
Interested to learn about how Sidekiq did that? Keep on reading.
Note that, since Sidekiq Pro is a close sourced and commercial software,
we cannot explain super_fetch’s exact implementation details.
As we discussed in-depth before,
Sidekiq’s basic_fetch strategy uses BRPOP Redis command
to fetch a job from the queue in Redis.
It works great to some extent,
but it is prone to losing job
if Sidekiq crashes or does not shutdown gracefully.
On the other hand, Sidekiq Pro offers super_fetch strategy which uses
RPOPLPUSH Redis command to fetch a job.
RPOPLPUSH Redis command provides
a unique approach towards implementing a reliable queue.
RPOPLPUSH command accepts two lists
namely a source list and a destination list.
This command atomically
returns and removes the last element from the source list,
and pushes that element as the first element in the destination list.
Atomically means that both pop and push operations
are performed as a single operation at the same time;
i.e. both should succeed, otherwise both are treated as failed.
super_fetch registers a private queue in Redis
for each Sidekiq process on start-up.
super_fetch atomically fetches a scheduled job
from the public queue in Redis
and pushes that job into the private queue (or working queue)
using RPOPLPUSH Redis command.
Once the job is finished processing,
Sidekiq removes that job from the private queue.
During a graceful shutdown,
Sidekiq moves back the unfinished jobs
from the private queue to the public queue.
If shutdown of Sidekiq process is not graceful,
the unfinished jobs of that Sidekiq process
remain there in the private queue which are called as orphaned jobs.
On restarting or starting another Sidekiq process,
super_fetch looks for such orphaned jobs in the private queues.
If Sidekiq finds orphaned jobs, Sidekiq re-enqueue them and processes again.
It may happen that
we have multiple Sidekiq processes running at the same time.
If a process dies among them, its unfinished jobs become orphans.
This Sidekiq wiki
describes in detail the criteria which super_fetch relies upon
for identifying which jobs are orphaned and which jobs are not orphaned.
If we don’t restart or start another process,
super_fetch may take 5 minutes or 3 hours to recover such orphaned jobs.
The recommended approach is to restart or start another Sidekiq process
to signal super_fetch to look for orphans.
Interestingly, in the older versions of Sidekiq Pro,
super_fetch performed checks for orphaned jobs and queues
every 24 hours
at the Sidekiq process startup.
Due to this, when the Sidekiq process crashes,
the orphaned jobs of that process remain unpicked for up to 24 hours
until the next restart.
This orphan delay check window
had been later lowered to 1 hour in Sidekiq Pro 3.4.1.
Another fun thing to know is that,
there existed two fetch strategies namely
reliable_fetch
and timed_fetch
in the older versions of Sidekiq Pro.
Apparently, reliable_fetchdid not work with Docker
and timed_fetch had asymptotic computational complexity O(log N),
comparatively
less efficient
than super_fetch,
which has asymptotic computational complexity O(1).
Both of these strategies had been deprecated
in Sidekiq Pro 3.4.0 in favor of super_fetch.
Later, both of these strategies had been
removed
in Sidekiq Pro 4.0
and are not documented anywhere.
Final result
We have enabled super_fetch in our application and
it seemed to be working without any major issues so far.
Our Kubernetes background pods does not seem to
be loosing any jobs when these pods are restarted.
Update : Mike Pheram, author of Sidekiq, posted following
comment.
Faktory provides all of the beanstalkd functionality, including the same reliability, with a nicer Web UI. It’s free and OSS.
https://github.com/contribsys/faktory http://contribsys.com/faktory/
For Ruby developers,
it’s common to switch between
multiple Ruby versions for multiple projects
as per the needs of the project.
Sometimes, the process of
going back and forth with multiple Ruby versions
could be frustrating for the developer.
To avoid this we add
.ruby-version files
to our projects so that
version manager tools
such as rvm, rbenv etc.
can easily determine which Ruby version
should be used for that particular project.
One other case that Rails developers
have to take care of is ensuring that
the Ruby version used to run Rails
by the deployment tools
is the one that is desired.
In order to ensure that we
add ruby version to Gemfile.
This will help bundler install dependencies
scoped to the specified Ruby version.
Good News! Rails 5.2 makes our work easy.
In Rails 5.2,
changes have been made
to introduce .ruby-version file
and also add the Ruby version to Gemfile
by default after creating an app.
In our new project,
we should be able to see
.ruby-version in its root directory
and it will contain value 2.5.
Also, we should see following line
in the Gemfile.
In today’s era of containerization,
no matter what container we are using
we need an image to run the container.
Docker images are stored on container registries
like Docker hub(cloud),
Google Container Registry(GCR), AWS ECR, quay.io etc.
We can also self-host docker registry on any docker platform.
In this blog post, we will see
how to deploy docker registry
on kubernetes using storage driver S3.
As per docker registry documentation,
We can simply start the registry using docker image registry.
Basic parameters when deploying production registry are:
Authentication
SSL
Storage
We will use htpasswd authentication for this post though registry image
supports silly and token based authentication as well.
Docker registry requires applications to use SSL certificate and key in the registry.
We will use kubernetes service, which terminates SSL on ELB level using annotations.
For registry storage, we can use filesystem, s3, azure, swift etc. For the complete list of options please visit docker site site.
We need to store the docker images pushed to the registry.
We will use S3 to store these docker images.
Steps for deploying registry on kubernetes.
Get the ARN of the SSL certificate to be used for SSL.
If you don’t have SSL on AWS IAM, upload it using the following command.
$aws iam upload-server-certificate --server-certificate-name registry --certificate-body file://registry.crt --private-key file://key.pem
Get the arn for the certificate using the command.
$aws iam get-server-certificate --server-certificate-name registry | grep Arn
Create S3 bucket which will be used to store docker images using s3cmd or aws s3.
$s3cmd mb s3://myregistry
Bucket 's3://myregistry/' created
Create a separate namespace, configmap, deployment and service
for registry using following templates.
kubectl apply -f registry-namespace.yml registry-configmap.yml registry-deployment.yaml registry-namespace.yml
namespace "registry" created
configmap "auth" created
deployment "registry" created
service "registry" created
Now that we have created registry, we should map DNS to web service ELB endpoint.
We can get the webservice ELB endpoint using the following command.
$kubectl-n registry get svc registry -o wide
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
registry 100.71.250.56 abcghccf8540698e8bff782799ca8h04-1234567890.us-east-2.elb.amazonaws.com 443:30494/TCP 1h app=registry
We will point DNS to this ELB endpoint with domain registry.myapp.com
Once we have registry running, now it’s time to push the image to a registry.
First, pull the image or build the image locally to push.
We write scripts to automate setup and deployment of Rails applications.
In those scripts, in many places, we need to run system commands like
bundle install, rake db:create, rake db:migrate and many more.
Let’s suppose we need to run migrations using
rake db:migrate in a Rails project setup script.
We can use the Kernel#system method.
irb>system('rake db:migrate')
Ruby 2.5.0
Executing system returns true or false.
Another feature of system is that it eats up the exceptions.
Let’s suppose our migrations can run successfully. In this case the system command
for running migrations will return true.
irb>system('rake db:migrate')=>true
Let’s suppose we have a migration that is trying to add a column to a table which
does not exist. In this case, the system command for running migrations will return
false.
As we can see, even when there is a failure in executing system commands, the return
value is false. Ruby does not raise an exception in those cases.
However, we can use raise explicitly to raise an exception and halt the setup
script execution.
irb>system('rake db:migrate')||raise('Failed to run migrations')==20180311211836AddFirstNameToAdmins:migrating=============================--add_column(:admins,:first_name,:string)rakeaborted!StandardError:Anerrorhasoccurred,thisandalllatermigrationscanceled:
PG::UndefinedTable:ERROR:relation"admins"doesnotexist:ALTERTABLE"admins"ADD"first_name"charactervarying...Tasks:TOP=>db:migrate(Seefulltracebyrunningtaskwith--trace)Traceback(mostrecentcalllast):2:from/Users/amit/.rvm/rubies/ruby-2.5.0/bin/irb:11:in`<main>'
1: from (irb):4
RuntimeError (Failed to run migrations)
Ruby 2.6.0-preview1
Ruby 2.6 make our lives easier by providing an option exception: true so that
we do not need to use raise explicitly to halt script execution.
irb>system('rake db:migrate',exception: true)==20180311211836AddFirstNameToAdmins:migrating=============================--add_column(:admins,:first_name,:string)rakeaborted!StandardError:Anerrorhasoccurred,thisandalllatermigrationscanceled:
PG::UndefinedTable:ERROR:relation"admins"doesnotexist:ALTERTABLE"admins"ADD"first_name"charactervarying...Tasks:TOP=>db:migrate(Seefulltracebyrunningtaskwith--trace)Traceback(mostrecentcalllast):3:from/Users/amit/.rvm/rubies/ruby-2.6.0-preview1/bin/irb:11:in`<main>'
2: from (irb):2
1: from (irb):2:in `system'RuntimeError(Commandfailedwithexit1:rake)
Ruby 2.6 works the same way as previous Ruby versions when used
without the exception option or used with exception set as false.
system is not the only way to execute scripts like these.
We wrote a blog
6 years ago which discusses the differences between running commands using
backtick, exec, sh, popen3, popen2e and Process.spawn.
The Chinese version of this blog is available
here.
Let’s see what happens when an exception is raised inside a thread.
division_thread=Thread.newdoputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"endsleep1puts"In the main thread"
Note that
the last two lines from the block were not printed.
Also notice that after failing in the thread the program
continued to run in main thread. That’s why we got the
message “In the main thread”.
This is because the default behavior of Ruby is to
silently ignore exceptions in threads and then to
continue to execute in the main thread.
Enabling abort_on_exception to stop on failure
If we want an exception in a thread to stop further processing
both in the thread and in the main thread then we can enable
Thread[.#]abort_on_exception on that thread to achieve that.
Notice that in the below code we are using
Thread.current.
division_thread=Thread.newdoThread.current.abort_on_exception=trueputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"endsleep1puts"In the main thread"
$RBENV_VERSION=2.4.0rubythread_example_2.rbCalculating4/0indivision_threadthread_example_2.rb:5:in`/': divided by 0 (ZeroDivisionError)
from thread_example_2.rb:5:in `blockin<main>'
As we can see once an exception was encountered in the thread
then processing stopped on both in the thread and in the main thread.
Note that
Thread.current.abort_on_exception = true
activates this behavior
only for
the current thread.
If we want this behavior globally for all the
threads then we need to use
Thread.abort_on_exception = true.
Running program with debug flag to stop on failure
Let’s run the original code with
--debug option.
$RBENV_VERSION=2.4.0ruby--debugthread_example_1.rbthread_example_1.rb:1:warning: assignedbutunusedvariable-division_threadCalculating4/0indivision_threadException`ZeroDivisionError' at thread_example_1.rb:3 - divided by 0
Exception `ZeroDivisionError' at thread_example_1.rb:7 - divided by 0
thread_example_1.rb:3:in `/':dividedby0(ZeroDivisionError)fromthread_example_1.rb:3:in`block in <main>'
In this case the exception is printed in detail and
the code in main thread was not executed.
Usually when we execute a program with --debug option
then the behavior of the program does not change.
We expect the program to print more stuff but we do not
expect behavior to change. However in this case the --debug
option changes the behavior of the program.
Running program with join on thread to stop on failure
If a thread raises an exception
and abort_on_exception and $DEBUG flags are not set
then
that exception will be processed
at the time of joining of the thread.
division_thread=Thread.newdoputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"enddivision_thread.joinputs"In the main thread"
$RBENV_VERSION=2.4.0rubythread_example_3.rbCalculating4/0indivision_threadthread_example_3.rb:3:in`/': divided by 0 (ZeroDivisionError)
from thread_example_3.rb:3:in `blockin<main>'
Both Thread#join and Thread#value
will stop processing in the thread and in the main thread
once an exception is encountered.
Introduction of report_on_exception in Ruby 2.4
Almost 6 years ago,
Charles Nutter (headius)
had proposed that the exceptions raised in threads
should be automatically logged and reported, by default.
To make his point,
he explained issues similar to what we discussed above
about the Ruby’s behavior
of silently ignoring exceptions in threads.
Here
is the relevant discussion on his proposal.
Following are some of the notable points discussed.
Enabling Thread[.#]abort_on_exception, by default,
is not always a good idea.
There should be a flag which, if enabled,
would print the thread-killing
exception info.
In many cases, people spawn one-off threads which are not
hard-referenced using Thread#join or Thread#value.
Such threads gets garbage collected.
Should it report the thread-killing exception
at the time of garbage collection if such a flag is enabled?
Should it warn using
Warning#warn
or redirect to STDERR device while reporting?
Charles Nutter suggested that
a configurable global flag Thread.report_on_exception
and instance-level flag Thread#report_on_exception
should be implemented having its default value as true.
When set to true,
it should report print exception
information.
Matz and other core members approved that
Thread[.#]report_on_exception can be implemented
having its default value set to false.
Charles Nutter, Benoit Daloze and other people demanded that
it should be true by default so that programmers
can be aware of the silently disappearing threads
because of exceptions.
Shyouhei Urabe advised that
due to some technical challenges,
the default value should be set to false
so as this feature could land in Ruby.
Once this feature is in then the default value can be changed in a later release.
Nobuyoshi Nakada (nobu)
pushed an
implementation
for Thread[.#]report_on_exception
with a default value set to false.
It was released in Ruby 2.4.0.
Let’s try enabling report_on_exception globally
using Thread.report_on_exception.
Thread.report_on_exception=truedivision_thread=Thread.newdoputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"endaddition_thread=Thread.newdoputs"Calculating nil+4 in addition_thread"puts"Result is: #{nil+4}"puts"Exiting from addition_thread"endsleep1puts"In the main thread"
$RBENV_VERSION=2.4.0rubythread_example_4.rbCalculating4/0indivision_thread#<Thread:0x007fb10f018200@thread_example_4.rb:3 run> terminated with exception:thread_example_4.rb:5:in`/': divided by 0 (ZeroDivisionError)
from thread_example_4.rb:5:in `blockin<main>'
Calculating nil+4 in addition_thread
#<Thread:0x007fb10f01aca8@thread_example_4.rb:9 run> terminated with exception:
thread_example_4.rb:11:in `block in <main>':undefinedmethod`+' for nil:NilClass (NoMethodError)
In the main thread
It now reports the exceptions in all threads.
It prints that the Thread:0x007fb10f018200
was terminated with exception: divided by 0 (ZeroDivisionError).
Similarly, another thread Thread:0x007fb10f01aca8
was terminated with exception: undefined method '+' for nil:NilClass (NoMethodError).
Instead of enabling it globally for all threads,
we can enable it for a particular thread
using instance-level Thread#report_on_exception.
division_thread=Thread.newdoputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"endaddition_thread=Thread.newdoThread.current.report_on_exception=trueputs"Calculating nil+4 in addition_thread"puts"Result is: #{nil+4}"puts"Exiting from addition_thread"endsleep1puts"In the main thread"
In the above case
we have enabled report_on_exception flag just for addition_thread.
Let’s execute it.
$RBENV_VERSION=2.4.0rubythread_example_5.rbCalculating4/0indivision_threadCalculatingnil+4inaddition_thread#<Thread:0x007f8e6b007f70@thread_example_5.rb:7 run> terminated with exception:thread_example_5.rb:11:in`block in <main>': undefined method `+'fornil:NilClass(NoMethodError)Inthemainthread
Notice how it didn’t report the exception
which killed thread division_thread.
As expected, it reported the exception
that killed thread addition_thread.
With the above changes
ruby
reports the exception as soon as it encounters.
However if these threads are
joined then they will still raise exception.
division_thread=Thread.newdoThread.current.report_on_exception=trueputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"endbegindivision_thread.joinrescue=>exceptionputs"Explicitly caught - #{exception.class}: #{exception.message}"endputs"In the main thread"
$RBENV_VERSION=2.4.0rubythread_example_6.rbCalculating4/0indivision_thread#<Thread:0x007f969d00d828@thread_example_6.rb:1 run> terminated with exception:thread_example_6.rb:5:in`/': divided by 0 (ZeroDivisionError)
from thread_example_6.rb:5:in `blockin<main>'Explicitlycaught-ZeroDivisionError:dividedby0Inthemainthread
See how we were still be able
to handle the exception raised
in division_thread above after joining it
despite it reported it before
due to Thread#report_on_exception flag.
report_on_exception defaults to true in Ruby 2.5
Benoit Daloze (eregon)
strongly advocated that
both the Thread.report_on_exception and Thread#report_on_exception
should have default value as true.
Here
is the relevant feature request.
After approval from Matz,
Benoit Daloze pushed the
implementation
by fixing the failing tests and
silencing the unnecessary verbose warnings.
It was released as part of Ruby 2.5.
Now in ruby 2.5
we can simply write like this.
division_thread=Thread.newdoputs"Calculating 4/0 in division_thread"puts"Result is: #{4/0}"puts"Exiting from division_thread"endaddition_thread=Thread.newdoputs"Calculating nil+4 in addition_thread"puts"Result is: #{nil+4}"puts"Exiting from addition_thread"endsleep1puts"In the main thread"
Let’s execute it with Ruby 2.5.
$RBENV_VERSION=2.5.0rubythread_example_7.rbCalculating4/0indivision_thread#<Thread:0x00007f827689a238@thread_example_7.rb:1 run> terminated with exception (report_on_exception is true):Traceback(mostrecentcalllast):1:fromthread_example_7.rb:3:in`block in <main>'
thread_example_7.rb:3:in `/': divided by 0 (ZeroDivisionError)
Calculating nil+4 in addition_thread
#<Thread:0x00007f8276899b58@thread_example_7.rb:7 run> terminated with exception (report_on_exception is true):
Traceback (most recent call last):
thread_example_7.rb:9:in `block in <main>':undefinedmethod`+' for nil:NilClass (NoMethodError)
In the main thread
We can disable the thread exception reporting
globally using Thread.report_on_exception = false
or for a
particular thread using Thread.current.report_on_exception = false.
Future Possibilities
In addition to this feature,
Charles Nutter also
suggested
that it will be good if there exists
a callback handler
which can accept
a block to be executed when a thread
dies due to an exception.
The callback handler can be at global level
or it can be for a specific thread.
Thread.on_exceptiondo# some stuffend
In the absence of such handler libraries need to resort to custom
code to handle exceptions. Here is how
Sidekiq handles exceptions raised in threads.
Important thing to note is that report_on_exception does not change behavior of the code.
It does more reporting when a thread dies and when it comes to thread dies more reporting
is a good thing.
Let’s look at the output.
Each value in the array [1, nil, 1, 0, nil, 1, nil]
denotes the count of line executions by the interpreter
for each line in score.rb file.
This array is also called the “line coverage”
of score.rb file.
A nil value in line coverage array means
coverage is disabled for that particular line number
or it is not a relevant line.
Lines like else, end and blank lines
have line coverage disabled.
Here’s how we can read above line coverage result.
Line number 1 (i.e. 0th index in the above result array) was executed once.
Coverage was disabled for line number 2 (i.e. index 1) as it is blank.
Line number 3 (i.e. index 2) was executed once.
Line number 4 did not execute.
Coverage was disabled for line number 5 as it contains only else clause.
Line number 6 was executed once.
Coverage was disabled for line number 7 as it contains just end keyword.
After Ruby 2.5
There was a pull request opened in 2014
to add method coverage and decision coverage metrics in Ruby.
It was rejected
by Yusuke Endoh
as he saw some issues with it
and mentioned that he was also working on a similar implementation.
Please note that column numbers start from 0
and
line numbers start from 1.
Let’s try to read above printed branch coverage result.
[:if, 0, 3, 0, 7, 3] reads that
if statement
starts at line 3 & column 0
and
ends at line 7 & column 3.
[:then, 1, 4, 2, 4, 15] reads that
then clause
starts at line 4 & column 2
and
ends at line 4 & column 15.
Similarly,
[:else, 2, 6, 2, 6, 15] reads that
else clause
starts at line 6 & column 2
and
ends at line 6 & column 15.
Most importantly
as per the branch coverage format,
we can see that
the branch from if to then was never executed
since COUNTER is 0.
The another branch from if to else was executed once
since COUNTER is 1.
Method Coverage
Measuring method coverage helps us
identify which methods were invoked and which were not.
We have a file grade_calculator.rb.
students_scores={"Sam"=>[53,91,72],"Anna"=>[91,97,95],"Bob"=>[33,69,63]}defaverage(scores)scores.reduce(&:+)/scores.sizeenddefgrade(average_score)caseaverage_scorewhen90.0..100.0then:Awhen80.0..90.0then:Bwhen70.0..80.0then:Cwhen60.0..70.0then:Delse:Fendenddefgreetputs"Congratulations!"enddefwarnputs"Try hard next time!"endstudents_scores.eachdo|student_name,scores|achieved_grade=grade(average(scores))puts"#{student_name}, you've got '#{achieved_grade}' grade."ifachieved_grade==:Agreetelsifachieved_grade==:Fwarnendputsend
To measure method coverage of above file,
let’s create grade_calculator_coverage.rb
by enabling methods option
on Converage#start method.
Therefore,
[Object, :grade, 9, 0, 17, 3] => 3
reads that the Object#grade method
which starts from line 9 & column 0
to
line 17 & column 3
was invoked 3 times.
What’s the use of these different types of coverages anyway?
Well, one use case is to integrate this
in a test suite and to determine which
lines, branches and methods are executed and which ones are not executed
by the test.
Further,
we can sum up these
and evaluate total coverage of
a test suite.
Author of this feature, Yusuke Endoh (mame)
has released coverage-helpers gem
which allows further advanced manipulation and processing of
coverage results obtained using Coverage#result.
In one of our projects, we implemented GPG decryption.
What is GPG ?
GPG is a complete and free implementation of the OpenPGP standard
as defined by
RFC4880 (also known as PGP).
We used
GPGME
gem for this purpose.
It provides three levels of API.
In our case, we used
Crypto
which has the high level convenience methods to encrypt, decrypt, sign and verify signatures.
We needed to import private key for decrypting a file
that was encrypted using paired public key.
First let’s import the required private key.
Here, pinentry_mode option allows password input without pop up.
We did not use latest version of GPG
since it does not support pinentry_mode option.
Instead, We used 2.1.20 version
which has support for this option.
Here
is the build instruction for that.
If you are learning functional programming
then
you can’t go far
without running into
“identity function”.
An identity function is a very basic function that
takes one argument
returns the argument
f(x)=x;
This seems like the most useless function in the world.
We never needed any function like this while building any application.
Then what’s the big deal about this identity function.
In this blog we will see
how this identity concept is used in the
real world.
For the implementation
we will be using Ramda.js.
We previously
wrote about
how
we, at BigBinary,
write JavaScript code
using Ramda.js.
Again please note that in the following code R stands for Ramda and not
for programming language R.
Before Ruby 2.5,
if we want to log a caught exception,
we would need to format it ourselves.
classAverageServiceattr_reader:numbers,:coerced_numbersdefinitialize(numbers)@numbers=numbers@coerced_numbers=coerce_numbersenddefaveragesum/countendprivatedefcoerce_numbersnumbers.mapdo|number|beginFloat(number)rescueException=>exceptionputs"#{exception.message} (#{exception.class})\n\t#{exception.backtrace.join("\n\t")}"puts"Coercing '#{number}' as 0.0\n\n"0.0endendenddefsumcoerced_numbers.map(&:to_f).sumenddefcountcoerced_numbers.size.to_fendendaverage=AverageService.new(ARGV).averageputs"Average is: #{average}"
$RBENV_VERSION=2.4.0rubyaverage_service.rb54f71s0invalidvalueforFloat():"4f"(ArgumentError)average_service.rb:18:in`Float'
average_service.rb:18:in `blockincoerce_numbers'
average_service.rb:16:in `map'average_service.rb:16:in`coerce_numbers'
average_service.rb:6:in `initialize'
average_service.rb:37:in `new'average_service.rb:37:in`<main>'
Coercing '4f' as 0.0
invalid value for Float(): "1s0" (ArgumentError)
average_service.rb:18:in `Float'
average_service.rb:18:in `block in coerce_numbers'average_service.rb:16:in`map'
average_service.rb:16:in `coerce_numbers'
average_service.rb:6:in `initialize'average_service.rb:37:in`new'
average_service.rb:37:in `<main>'
Coercing '1s0'as0.0Averageof[5.0,0.0,7.0,0.0]is: 3.0
It was proposed
that there should be a simple method
to print the caught exception
using the same format
that ruby uses while printing
an uncaught exception.
Some of the proposed method names were
display, formatted, to_formatted_s,
long_message, and full_message.
Matz approved
the Exception#full_message method name.
In Ruby 2.5, we can re-write above example
as follows.
classAverageServiceattr_reader:numbers,:coerced_numbersdefinitialize(numbers)@numbers=numbers@coerced_numbers=coerce_numbersenddefaveragesum/countendprivatedefcoerce_numbersnumbers.mapdo|number|beginFloat(number)rescueException=>exceptionputsexception.full_messageputs"Coercing '#{number}' as 0.0\n\n"0.0endendenddefsumcoerced_numbers.map(&:to_f).sumenddefcountcoerced_numbers.size.to_fendendaverage=AverageService.new(ARGV).averageputs"Average is: #{average}"
$RBENV_VERSION=2.5.0rubyaverage_service.rb54f71s0Traceback(mostrecentcalllast):6:fromaverage_service.rb:37:in`<main>'
5: from average_service.rb:37:in `new'
4: from average_service.rb:6:in `initialize'3:fromaverage_service.rb:16:in`coerce_numbers'
2: from average_service.rb:16:in `map'
1: from average_service.rb:18:in `block in coerce_numbers'average_service.rb:18:in`Float': invalid value for Float(): "4f" (ArgumentError)
Coercing '4f' as 0.0
Traceback (most recent call last):
6: from average_service.rb:37:in `<main>'
5: from average_service.rb:37:in `new'4:fromaverage_service.rb:6:in`initialize'
3: from average_service.rb:16:in `coerce_numbers'
2: from average_service.rb:16:in `map'1:fromaverage_service.rb:18:in`block in coerce_numbers'
average_service.rb:18:in `Float': invalid value for Float(): "1s0" (ArgumentError)
Coercing '1s0'as0.0Averageof[5.0,0.0,7.0,0.0]is: 3.0
Note that,
Ruby 2.5 prints exception backtrace
in reverse order
if STDERR is unchanged and is a TTY
as discussed
in our previous blog post.
Stack trace or backtrace
is a sequential representation
of the stack of method calls
in a program which gets printed
when an exception is raised.
It is often used
to find out the exact location
in a program
from where the exception was raised.
Before Ruby 2.5
Before Ruby 2.5,
the printed backtrace contained
the exception class and the error message
at the top.
Next line contained where in the program
the exception was raised.
Next we got more lines
which contained cascaded method calls.
$RBENV_VERSION=2.4.0rubydivision_service.rb50division_service.rb:9:in`/': divided by 0 (ZeroDivisionError)
from division_service.rb:9:in `divide'
from division_service.rb:13:in `<main>'
In the printed backtrace above,
the first line shows the location,
error message and the exception class name;
whereas the subsequent lines shows
the caller method names and their locations.
Each line in the backtrace above
is often considered as a stack frame
placed on the call stack.
Most of the times,
a backtrace has so many lines that
it makes it very difficult
to fit the whole backtrace in the visible viewport
of the terminal.
Since the backtrace is printed in top to bottom order
the meaningful information
like error message,
exception class
and the exact location where the exception was raised
is displayed at top of the backtrace.
It means developers
often need to scroll to the top
in the terminal window
to find out what went wrong.
After Ruby 2.5
Over 4 years ago an
issue
was created to make printing of backtrace
in reverse order configurable.
After much discussion
Nobuyoshi Nakada
made the commit to
print backtrace and error message
in reverse order
only when the error output device (STDERR)
is a TTY (i.e. a terminal).
Message will not be printed in reverse order
if the original STDERR
is attached to something like a File object.
This feature makes
the debugging convenient
when the backtrace size is a quite big
and cannot fit in the terminal window.
We can easily see the error message
without scrolling up now.
Note that,
the Exception#backtrace attribute
still holds an array of stack frames
like before
in the top to bottom order.
So if we rescue the caught exception
and print the backtrace manually
Also,
note that if we assign
STDERR with a File object,
thus making it a non-TTY
puts"STDERR is a TTY? [before]: #{$stderr.tty?}"$stderr=File.new("stderr.log","w")$stderr.sync=trueputs"STDERR is a TTY? [after]: #{$stderr.tty?}"classDivisionServiceattr_reader:a,:bdefinitialize(a,b)@a,@b=a.to_i,b.to_ienddefdivideputsa/bendendDivisionService.new(ARGV[0],ARGV[1]).divide
we can get the old behavior
but the backtrace would be written
to the specified file
and not to STDERR.
$RBENV_VERSION=2.5.0rubydivision_service.rb50STDERRisaTTY?[before]:trueSTDERRisaTTY?[after]:false$catstderr.logdivision_service.rb:14:in`/': divided by 0 (ZeroDivisionError)
from division_service.rb:14:in `divide'
from division_service.rb:18:in `<main>'$
