-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multi-process access in Heroku environment causes PubNub initialization to occasionally fail #21
Comments
Thanks for notice @rafalyesware, i'm checking it and i will apply fix asap. |
Thanks @blazeroot. FWIW, all the Ruby UUID gems seem to have some failing or another... I don't know if you really need a UUID or just a large unique value, but if you can do without a proper UUID the Mongo ObjectID seems like a great choice (c.f. http://docs.mongodb.org/manual/reference/object-id/) for multi-host / multi-process environments. |
@blazeroot FWIW, we don't need EXACTLY per the UUID-spec, just a UUID-like pattern that has an equivalent duplicates collision domain within its own alogrithm, and UUID's. |
Fixed and tested. @rafalyesware please use master branch of pubnub and let me know if that helps. |
You guys are all right! 👍 Will try to pull this in to our code ASAP, thanks! |
@blazeroot Pulled the latest gem off master and it is working as promised. Thanks for the quick turnaround! |
@rafalyesware No problem! I'm happy to hear that! |
As noted in assaf/uuid#28 and assaf/uuid#6, the UUID gem has multi-process access issues in certain environments (in our case, running push workers in Heroku via Resque or Resque-Pools).
About 2,000 times during a 24-hour period, we see the following crash of the push worker:
It would be great if the PubNub gem didn't depend on an inheretly-multi-process-unsafe gem for UUID by default (uuidtools seems like a nice alternative, SecureRandom.uuid is a possibility as well).
The text was updated successfully, but these errors were encountered: