rtomayko / rack-cache

Real HTTP Caching for Ruby Web Apps

Home Page:http://rtomayko.github.io/rack-cache/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Threads and Disk Storage

chengguangnan opened this issue · comments

I was using the disk storage and it took me a long time to realize that the current thread id was attached by rack-cache as part of the filename?

I'm using 16 unicorn workers, It's not really acting as a cache.

Also note that everytime I restart unicorn all the 16 thread ids got changed.

Interesting. I haven't dug in to verify but I could see the thread id being used while the file is being written before its moved into place but using it as part of the final filename definitely feels way wrong. I'll try to take a peek.

Hmm, after looking at the diff in #106, the thread id shouldn't be being used in the final filename, only during writing, which is correct. The file is written to a per-thread temporary file and then moved into the final location atomically:

https://github.com/basex/rack-cache/blob/patch-1/lib/rack/cache/entitystore.rb#L123-L135

Here's where the final body filename is generated (SHA1 of the body content):

https://github.com/basex/rack-cache/blob/patch-1/lib/rack/cache/entitystore.rb#L10-L23

commented

I noticed that rack-cache is now recommended by rails 4 in it's environment config file. It's time to release a new gem which contains this fix. Otherwise, the wide audience of rails may experience the same issue and it would take them a long time to figure it out.

See my previous comment. The thread id is used only when writing the temporary file. If you're seeing misses across workers then something else is wrong.

commented

Sorry I missed the comments. You are right.