One day Threads are crashing

[numeroteca]

I am not able to isolate the problem, but all the one day threads by the user Hinterlaces http://pageonex.com/threads/by/Hinterlaces are broken. Returns Internal Server Error in the browser. The logs doesn't provide extra information.

I tried to reproduce it in this thread http://www.pageonex.com/numeroteca/test-repeated/ and it also fails. (5 venezuelan newspapers, 1 day, 4 topics). You can edit it here http://www.pageonex.com/threads/test-repeated/edit

[numeroteca]

I saw this in the logs, might be related to #177

Started GET "/Hinterlaces/portadas-06-08/" for 66.249.75.92 at 2013-08-09 17:48:44 +0000
Processing by CodingController#display as */*
  Parameters: {"username"=>"Hinterlaces", "thread_name"=>"portadas-06-08"}
  Rendered coding/display.html.erb within layouts/application (76.8ms)
Completed 500 Internal Server Error in 102ms

ActionView::Template::Error (undefined method `[]' for nil:NilClass):
    108: <div class="row">
    109:    <div class="span2">
    110:        <ul class='thread-coposite-labels'>
    111:            <% @img_map_info['row_info'].each do |media_id,info| %>
    112:                <li style="height:<%=info['height']%>px"><%=info['name']%></li>
    113:            <% end %>
    114:        </ul>
  app/views/coding/display.html.erb:111:in `_app_views_coding_display_html_erb___2087096186610103946_27359220'

[rahulbot]

Short Story:

One-day threads have REALLY big composite images, because each front page is the full width! This is blowing out our memory while we try to generate them. I fixed this by setting a max size for each column of the composite image. I set that to half the full image width, so it won't mess up the bar chart alignment.

Full Story:

I could not reproduce this on my local machine. I looked on the production server and it looks like the composite image generation might have died in the middle. I say this because the app/assets/images/threads/2/161/970/ directory is missing the image_map.json, results.jpg, and results.zip files.

So then I went in to the rails console (rails console production) and deleted the composite image dir:

Threadx.find_by_thread_name('test-repeated').remove_composite_images

Then I tailed the log (tail -f log/production.log)while I hit the display page, which triggered a regeneration of the composite images. This generated an apache-level server error. Maybe memory? So I added in some logging during generation of the composite images (8691dc6c6cf317e16711a73c4f4cf202512e56c1) and tried again... it dies while creating overlays for the topics.

So I tried changing the thread to be two days - that died while combining them into composites. I tried three days - that worked fine! I changed it back to one day, and it died while creating overlays for topics again. I'm guessing this is about the size of the composite image - with only one day maybe the images are too big. Maybe we need a maximum image width while creating composites? I did this (bd73c8ccb84c0db9cd045de80b36ccaeaa0d36a6) and it worked!

[numeroteca]

That seems like a good fix. Apart from the memory size, one day threads were a problem in terms of visualization, too long scroll down.