Timeout on results_native.rb:139 when run through Puma server

[slash4]

Hi ! Downgrade to Rails 4 went good, and I could implement couchbase-orm on my existing cassandra objects with ease. This is awesome !

In development environment (Thin) everything works. But in staging/prod we use Puma, and every call to Couchbase times out on line 139 of results_native. I guess this has to do with async management, but I don't see any config in the source. Any thoughts ?

When everything will be allright, I'll be happy to make a pull request with small improvements I made (Rails4 compat, and compound-keys in views).

Thanks a lot !

[slash4]

Breaking news, under Thin, it does not work either, but it's another error : Can't yield from root fiber with stacktrace :

/usr/local/bundle/bundler/gems/libcouchbase-42d248ea3a39/lib/libcouchbase/results_fiber.rb:264:in yield' /usr/local/bundle/bundler/gems/libcouchbase-42d248ea3a39/lib/libcouchbase/results_fiber.rb:264:in resume'
/usr/local/bundle/bundler/gems/libcouchbase-42d248ea3a39/lib/libcouchbase/results_fiber.rb:140:in `take'

🤔

When played from a non-web environment (Rspec or rails c for example) every thing goes right because it seems calls are done synchronously. Am I missing something ?

@stakach I read on another thread that you were using couchbase-orm in production environment, which webserver are you using for that ?

[stakach]

Awesome, thanks for letting me know - I'll take a look today

[stakach]

We have it running on Puma and a web server of my own concoction called spider-gazelle.
Spider uses results_fiber like thin.

Are you certain that the production server can communicate with the database?

[stakach]

Puma executes requests in the same way that rspec or rails c does.

In all environments requests technically execute in async however on platforms that don't play well with async we use mutex's and condition variables to signal when results are available. So progress is blocked by the mutex.
On Thin Fibers are used to pause execution and resume it when the result is available.

My best guess on the issues you are experiencing are either an older broken version of the library is in use or some ports not open between the server and all database nodes

[slash4]

Hi, thanks for you answers, after a lot of debug, I decided to build a simple rails app from scratch, and implement a simple couchbase-orm model in it. And.... it works ! So I guess this is a compatibility issue with another gem in my existing app. Time to figure out which one now :)

[stakach]

Are you certain you are running the latest libcouchbase?
i.e. there isn't an older version in the lock file?

Also when you tested your production environment in Thin were you using rack-fiber_pool? As that probably caused the root fiber error if you were not using it

[stakach]

Also I haven't tested Puma in clustered mode.
There might be an issue with forking the process? Might be worth looking into

[slash4]

Clustered mode seems to be OK as my new project has the exact same configuration file than the first project.

If your talking about the libcouchbase gem, yes, I use the lastest one. If you mean the underlying lib, I use libcouchbase from apt repo. Do you think it is outdated ? Here is my install command line apt-get --assume-yes install libcouchbase-dev libcouchbase2-bin build-essential cmake. Don't really know what version is given.

Youre right, I didn't use rack-fiber-pool. I'll try, it may solve the issue at least for Thin.

[stakach]

The libcouchbase gem is actually bundled with the libcouchbase library - compiles when you install. So no need to install apt-get versions of libcouchbase

[slash4]

Really ?? Oh nice to know. I'll try without the apt.

[slash4]

OK !! It works. Believe it or not, it was a Rails.application.eager_load! hidden in a initializer that was causing the problem. My understanding of it, is that loading occurs before couchbase-orm can effectively connect to the server. After that, it is stuck in the middle of the road and cannot reconnect properly.

2 days to figure out. Damn. Thanks for your precious help. Reaaally appreciated.

[slash4]

Hey @stakach it's me again. Funny enough, in staging and production environment, eager_loading is recommended and configured by default in rails config files. Which makes the bug appear again :( How did you get it working ? Did you bypassed eager_loading ?

[slash4]

For your information, one can workaround this issue by moving CouchbaseOrm classes into their own folder at the root of the rails app, and then integrate this path to autoload_paths :
config.autoload_paths << "#{config.root}/couchbase_models"

This exclude the models from eager_loading, but keep them available at runtime. So far so good :)