wenxi-zeng
commented
1 year ago hi @Recio, you can do either way since the new library supports both. from your description, looks like multiple analytics could exist at the same time if go with the scoped way. be mindful of the performance hit in this case, since multiple queues/listeners are singleton, keeping multiple analytics instances inside of them is equivalent to having multiple analytics singleton. looks like using a singleton approach would yield better performance (assuming I understand your scenario correctly).
the event methods (track/identify/group/etc) are designed in a fire and forget way and we have an internal thread manager that catches all the exceptions, so that exceptions in the SDK won't crash the caller service/app. you can handle the exception by providing an exception handler to configuration, see example here.
Hey,
We're currently migrating from an old implementation and would love some guidelines on how to properly manage the lifecycle of the Analytics client.
It's going to be mainly used to consume messages from a queue and push them to segment. The queue will have multiple listeners based on message type and those would be singletons as they are long running processes that are bound to the same queue with a filter.
Should we use a factory for the Analytics client to assure a "scoped" behaviour or can we use a singleton approach for the a shared client used by all the queues?
Side question, are there any exceptions that can be thrown by the Analytics client on the Track method?
Thank you so much!