Make Intercom thread safe#103
Make Intercom thread safe#103tscolari wants to merge 1 commit intointercom:masterfrom tscolari:master
Conversation
Removed the instance variables on modules, that would be shared between different threads, by the `Thread.current` hash.
|
👍 |
|
Alternatively you could pass the |
|
A lot of other API libraries seem to be completely moving away from a global configuration as it's not threadsafe: http://www.rubydoc.info/gems/twitter This would be the best option moving forward. |
|
Agreed; we're looking at making Intercom-Ruby multi-app (and threadsafe) in the near future. |
|
@josler any progress here? I just set up intercom and I'm seeing an average response time of ~187ms for the event API, so I'd like to run the create inside a thread. I'm not changing anything about the Intercom configuration at runtime, so maybe it's safe as is? |
|
No news to share about this currently. For your use case it should be fine if you're not switching credentials between threads. |
|
#159 - this is a WIP beta of v3 of this client, which does not have global credentials |
|
This is implemented now! 🎉 |
5 participants
Removed the instance variables on modules, that would be shared between different threads, by the
Thread.currenthash.Currently on driftrock.com our use case requires us to switch intercom credentials on each request, this changes will make it possible for apps using thread servers (e.g. puma) to safely switch their intercom credentials.
A best approach in my opinion would instead of a module,
Intercombe a proper class and get instantiated (it's already a module with state anyway), but that would be a breaking change.