Open adityar7 opened 10 years ago
Wouldn't it be simpler to have a thread call report(…)
instead? For example in saleor
project I am planning to introduce a thread pool to do just that.
Well, I don't know if it'll be simpler since everyone who uses the app will end up having to write the same code, since this really needs to be non-blocking for almost every use case. So it may as well be pushed down to the app.
It could be made optional via a parameter. I didn't add that yet to get your comments on the approach in case you'd want to merge something like this.
In either case it would be much simpler to introduce thread pooling at the report(…)
level (as opposed to creating a new thread for each call). For example by introducing a thread pool object that exposes a .report(…)
method with an identical signature.
I am not against merging that to the library itself, I'd just prefer to keep the extra complexity out of the existing reporting mechanism.
Sure, a thread pool will be better indeed. I'll try to update my patch some time soon.
Blocking the server code is unrealistic in most cases. The network request should be done asynchronously.
Would you consider merging something like the following commit that uses a separate thread?
https://github.com/adityar7/google-measurement-protocol/commit/770d199884a2ceff576d61f365ea809215bb5fa1