Hallon and Passenger

[Bodo Tasche]

I just tried to create a little Webserver for a few calls to libspotify. On my local machine using WEBrick it works perfectly. But it fails to run on a passenger. The login! Method of the Session Object never returns and locks the instance.

Currently I am suspecting the forking method of passenger. 

Has anybody here already got Hallon running inside of a passenger instance?

Thanks,

Bodo

[Kim Burgestrand]

Hi!

It might very well be the forking, but it could also be that your sessions share cache directory, something that

somebody else had an issue with fairly recently.

GitHub issue explaining the cache directory: https://github.com/Burgestrand/Hallon/issues/137

Try changing cache directory between instances and see if that’ll stop libspotify from locking itself down.

— Kim

--
You received this message because you are subscribed to the Hallon ruby gem mailing list.

- To view this group online, visit https://groups.google.com/d/forum/ruby-hallon
- To post to this group, send email to ruby-...@googlegroups.com
- To unsubscribe from this group, send email to ruby-hallon...@googlegroups.com
 
 

[Bodo Tasche]

I was that one :) . That made it work on Webrick, but it fails to work with passenger.

[Kim Burgestrand]

On Tuesday, 11 December 2012 at 08:01, Bodo Tasche via Hallon wrote:

I was that one :) . That made it work on Webrick, but it fails to work with passenger.

Had my guesses ;).

In that case it’s most likely passenger forking after you’ve initialized the session. You must

initialize the session *after* passenger has forked your application, so you have one session

per fork, instead of sharing it. It’s the same thing you need to do to network connections for

things such as redis and activerecord.

With that said, I’m not sure it will even work if you do create the session after the fork, but in

theory I think it should. libspotify is a strange beast.

— Kim

[Bodo Tasche]

The problem: I don't know when exactly Passenger does the fork. I already tried to start the session in the controller code for the view, but even that fails. I am now using a second instance I communicate with that is not run by passenger.

Has nobody here tried to run this stuff within a Passenger instance and got it working?

[Aurélien Malisart]

Hi,

I think I have the same fork issue with Resque.  If I run the job through the console with its 'perform' method, it works well.  If the job is enqueued, when the Resque worker process executes it, it runs forever.

Resque has an 'after_fork' callback hook, I tried to make the connection there but it does not work either.

Any idea or parades ?

Aurels

[Aurélien Malisart]

Here is the code :

Resque.after_fork do |job|

  unless Hallon::Session.instance?

    session = Hallon::Session.initialize(HALLON_KEY, {

      :load_playlists    => true,

      :settings_location => "#{Rails.root}/tmp/hallon/#{UUIDTools::UUID.random_create.to_s}",

      :cache_location    => "#{Rails.root}/tmp/hallon/#{UUIDTools::UUID.random_create.to_s}"

    })

    session.login!(HALLON_LOGIN, HALLON_PASSWORD)

  end

end

[Kim Burgestrand]

I know people have used Hallon with Resque successfully. Initially they had issues with it locking up,

but the issue was resolved after creating the session *inside* the perform method.

Keep in mind that if you run Hallon in multiple processes (i.e. multiple forks) at the same time, you should

take great care to make sure that the `cache_directory` is not the same directory in every process, or it

will make libspotify lock up either way.

Another suggestion is to use Sidekiq instead.

Keep in mind that using libspotify concurrently in any way can be a bit tricky. libspotify is not thread-safe;

however, Hallon should be.

— Kim 

[Aurélien Malisart]

Sorry I haven't seen the reply !

We tried to create the session inside the perform method but it was hanging too. We only have one worker for that queue.

We managed to do what we want with a cron job instead but it's a kind of quick solution !

[Aurélien Malisart]

Hey,

I confirm that it works great with Sidekiq which does use threads instead of forked sub-processes. I'm lucky that it can work alongside Resque ;-)

[Kim Burgestrand]

Glad to see it works for you. :)

Resque.after_fork do |job|

  unless Hallon::Session.instance?

Hallon::Session.instance? should never return true in this case. If it does, it means you already

have a session somehow, which you shouldn’t. There should only be one session per fork.

That said, I haven’t tried libspotify and forking myself, I just know that others have.

— Kim

On Friday, 18 January 2013 at 14:32, Aurélien Malisart via Hallon wrote:

Hey,

I confirm that it works great with Sidekiq which does use threads instead of forked sub-processes. I'm lucky that it can work alongside Resque ;-)

--

[Aurélien Malisart]

On Friday, 18 January 2013 23:22:27 UTC+1, Kim Burgestrand wrote:

Glad to see it works for you. :)

;-)

 

Resque.after_fork do |job|

  unless Hallon::Session.instance?

Hallon::Session.instance? should never return true in this case. If it does, it means you already

have a session somehow, which you shouldn’t. There should only be one session per fork.

Yes it's totally useless here, it was a cut and paste from another location.