Hangs when deployed to Heroku running Puma

[Bajinai]

Using the app with Puma locally works perfectly, but hosting it on Heroku (with Puma as well) makes the code hang, whenever FillablePDF.new is called. Have you experienced the hanging with Puma as well?

[vkononov]

The hanging problem is something I've been investigating for a long time, but so far I have not had any success fixing it. I've never tried deploying an app with this gem to Heroku, but I have one running on CentOS 7 using Nginx with a reverse proxy to Puma, and it doesn't have any problems. I actually wanted to try Heroku hosting before, but couldn't figure out how to tell Heroku to use both Ruby and Java. Can you tell me how you did so I could investigate?

[Bajinai]

We are running our Ruby app on Heroku, and have then added the https://github.com/heroku/heroku-buildpack-jvm-common buildpack which installs JDK, hope that helps your investigation!

[yv3s]

Hi, for information I'm also using Puma on Heroku and it works perfectly so far, I don't know if you fixed it but no problem here. Thanks for this amazing gem

Best

[vkononov]

Thanks, @yv3s. Glad it's working. I haven't had time do proper testing on this issue yet. Hopefully, the problem was with Heroku itself or an older version of Puma. @Bajinai, is it working for you too?

[vkononov]

Closing this issue, as it has not received any activity for almost a year.

[leomayleomay]

hi @vkononov, thanks for coming up with a gem to make filling up PDF easier. However, I could confirm this is still an issue for Ruby 2.6.3, Rails 6.0.2.1, I am using Unicorn as app server, and it hangs in rails console once I tried to load PDF with FillablePDF.new 'a.pdf'

[leomayleomay]

however, it works perfectly under bare irb instead of rails console

[dkleiman]

Hi @vkononov, I'm having the same issue with Ruby 2.5.3. and Rails 5.2.4 where FillablePDF.new hangs in rails console but works fine with irb. I've done a bit of investigation and it looks like this is the line that's hanging: https://github.com/vkononov/fillable-pdf/blob/master/lib/fillable-pdf.rb#L25

Hope this helps! Thanks for your work on this.

[MatUrbanski]

however, it works perfectly under bare irb instead of rails console

I have the same problem. Did you find a solution for that?

[jaehocho]

I also have the same issue. Is there a fix or a work around?

[vkononov]

@leomayleomay @MatUrbanski Could you let me know if you're still having the issue with the 0.9.0 version of the gem? Thanks!

[MatUrbanski]

@vkononov I'm still having the same issue. In the IRB everything is working fine, but when I try to use it in rails console then it freezes:

[MatUrbanski]

@vkononov It seems that I found what is causing an issue. From my Gemfile I removed spring gem:

  gem 'spring'
  gem 'spring-watcher-listen', '~> 2.0.0'

and now gem is working fine in rails console:

[vkononov]

Thanks, @MatUrbanski. I'll update the README with your findings.

[jaehocho]

Has anyone found a solution for this?

I had this issue on my local environment (MacOS) and was able to fix it by upgrading itext version.

However, now I am having the same issue on Heroku deploy. in FillablePDF initializer, it hangs. I was able to put logging to find out that it hangs PDF_WRITER.new method.

Interestingly, it works fine on Rails console on heroku. I saw @MatUrbanski fixed by removing spring gem, but I don't have that. Perhaps it's a conflict with another gem? Really strange.

def initialize(file_path)
  raise IOError, "File at `#{file_path}' is not found" unless File.exist?(file_path)
  @file_path = file_path
  begin
    @byte_stream = BYTE_STREAM.new
    @pdf_reader = PDF_READER.new @file_path

    # the code hangs here ################################
    @pdf_writer = PDF_WRITER.new @byte_stream

    @pdf_doc = PDF_DOCUMENT.new @pdf_reader, @pdf_writer
    @pdf_form = PDF_ACRO_FORM.getAcroForm(@pdf_doc, true)
    @form_fields = @pdf_form.getFormFields
  rescue StandardError => e
    raise "#{e.message} (input file may be corrupt, incompatible, or may not have any forms)"
  end
end

[jaehocho]

I use Passenger on Heroku deploy. I found that passenger uses 'smart' thread spawning by default. I switched to 'direct' method and the problem went away. Smart spawning copies a thread to create a new one.

Passengers document indicates that it can create file descriptor sharing which can cause issues. I am guessing the shared file descriptors for the jar file somehow creates a deadlock.

https://www.phusionpassenger.com/library/indepth/ruby/spawn_methods/#unintentional-file-descriptor-sharing

Updated my Profile from:

web: bundle exec passenger start -p $PORT --max-pool-size 6

To:

web: bundle exec passenger start -p $PORT --max-pool-size 6 --spawn-method direct

[simonfranzen]

I am not sure why this is closed, because the error still exist with puma on heroku. Would it be helpful to get someone from puma gem into this thread? @jaehocho seem to have it fixed by a config for passenger. Maybe there is something similar for puma?

[DanAndreasson]

Also having issues. Heroku and puma. It also hangs locally with spring. Using 0.9.2. Any ideas?

[vkononov]

@DanAndreasson Please check out the README.md for the latest list of known issues (I don't think spring is an issue any more) and for how to deploy on Heroku. Also, you could not have been using version 0.9.2 on August 18, because it did not come out until November 30. Please actually try version 0.9.2.

@simonfranzen Is it the latest version that keeps hanging? Version 0.9.2?