HTTPService is busy #748
Comments
|
Post a more complete set of logs. You’ve posted only a few seconds of cherry picked logs. |
|
Is this enough? 07-01 09:23:16.852 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:23.645 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:23.658 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 102.82985, apparent speed: 14.689979 07-01 09:23:23.811 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:23.827 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:30.639 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:30.651 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 105.71879, apparent speed: 15.102684 07-01 09:23:38.647 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:38.659 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 111.31876, apparent speed: 13.914845 07-01 09:23:45.647 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:45.663 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 109.004654, apparent speed: 15.572093 07-01 09:23:54.197 DEBUG [TSLocationManager onLocationResult] 07-01 09:23:54.210 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 113.123314, apparent speed: 16.160473 07-01 09:24:02.651 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:02.662 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 103.01662, apparent speed: 11.446291 07-01 09:24:02.844 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:02.855 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:13.640 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:13.655 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 76.985245, apparent speed: 7.6985245 07-01 09:24:13.844 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:13.854 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:19.644 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:19.659 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 60.890244, apparent speed: 12.178049 07-01 09:24:19.822 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:19.834 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:27.644 DEBUG [TSLocationManager onLocationResult] 07-01 09:24:27.657 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 76.06713, apparent speed: 9.508391 07-01 09:25:33.637 INFO [BackgroundGeolocation$j run] 07-01 09:26:09.634 DEBUG [b a] 07-01 09:26:17.891 INFO [BackgroundGeolocation$j run] 07-01 09:26:44.498 DEBUG [b a] 07-01 09:26:44.668 INFO [BackgroundGeolocation$j run] 07-01 09:33:31.600 DEBUG [TSLocationManager onLocationResult] 07-01 09:33:31.607 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 79.624756, apparent speed: 0.19612008 07-01 09:33:47.713 DEBUG [TSLocationManager onLocationResult] 07-01 09:33:47.727 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 82.68316, apparent speed: 5.1676974 07-01 09:34:47.922 DEBUG [b a] 07-01 09:34:51.068 DEBUG [b a] 07-01 09:44:56.727 DEBUG [TrackingService a] 07-01 09:44:56.747 DEBUG [TSLocationManager onLocationResult] 07-01 09:44:56.759 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 37.408615, apparent speed: 0.06183242 07-01 09:44:56.957 DEBUG [TSLocationManager onLocationResult] 07-01 09:44:56.974 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:00.433 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:00.462 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 25.30101, apparent speed: 8.43367 07-01 09:45:05.914 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:05.932 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 56.312702, apparent speed: 11.262541 07-01 09:45:08.445 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:08.456 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 31.11081, apparent speed: 15.555405 07-01 09:45:16.061 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:16.073 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 40.5026, apparent speed: 5.786086 07-01 09:45:20.650 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:20.670 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 25.50815, apparent speed: 6.3770375 07-01 09:45:59.142 DEBUG [TSLocationManager onLocationResult] 07-01 09:45:59.158 DEBUG [TSLocationManager locationIsInvalid] Distance from last location: 28.538124, apparent speed: 0.75100327 |
|
See attached file for 19,060 lines of logs. Min log level = trace. |
|
Show me more context of your code. I want to see under what conditions you're executing this: const gpsPositionsToSyncCount = await BackgroundGeolocation.getCount();
if (gpsPositionsToSyncCount > 0 && store.getState().device.deviceInfo.isConnected) {
try {
await log(`realmUtility.forceSync() - Attempting to sync ${gpsPositionsToSyncCount} positions`, logLevel.info);
await BackgroundGeolocation.sync();
}
catch(e) {
log(`realmUtility.forceSync() - An error occurred while syncing GPS points ${e}`, logLevel.error);
}
} |
|
So i've removed this block to see if manual syncing was causing blocking issues. This hasn't seemed to have helped and we still have positions stuck. Can you confirm 'HttpService is busy' has nothing to do with our server and an HTTP request is never made? What options do we have here? Should we set autoSync to false and handle HTTP requests ourselves via headless tasks and foreground listeners? Are there any drawbacks from doing this? |
|
@christocracy Tomorrow I'll be collecting some logs and preparing a set of code to post here. |
|
And my context of reproduction is when my users disable and re-enable their 3g connections. |
|
It’s not unusual to see this message. The plugin performs http requests synchronously, selecting records from its database 1-by-1 until the database is empty. If the http-service is already operating, you’ll see “Http service is busy”. If the server isn’t responding, it’s going to timeout after 60s and set a flag isBusy = false. |
|
Ok, so then my case may be different and I'm not going in the right direction.
The requests I'm making within my code are using the Also I'm using 2 other libs that may implicate on the Http service being stuck: sentry and amplitude Would you think this is another issue that is not related with the |
|
The plugin’s iOS http service is written in pure Obj-c, it isn’t affect by other plugins. Your server isn’t answering the bell. Response: 0, timeout |
|
I'm not shipping to iOS, I build only for android 6+ |
|
My mistake. Let me change channel :) The plugin’s Android http service is written in pure Java, it isn’t affect by other plugins. Your server isn’t answering the bell (or outbound http request isn’t possible) Response: 0, timeout |
|
I would try observing the unfiltered |
|
Sure I'll be collecting logs and analysing this tomorrow, I'll also try to isolate the issue even more by disabling some dependencies. |
|
Why not try reproducing in the sample app? It’s linked in the README. Clone and build it to your device. |
|
Good advice, I'll try that for sure |
|
Hey guys, since this lib and react-native use okhttp I believe this might be the issue square/okhttp#3278 which leads to square/okhttp#3378 OBS: it only happens with emulators |
|
Thanks @heltonandreazza. That sure sounds like what @wesleycoder is talking about. |
|
@heltonandreazza keep in mind, the plugin defaults to |
|
@heltonandreazza, @wesleycoder I built the SampleApp successfully with 📂
|
|
Careful with that, react-native android supports down to minSdkVersion 16 as does this plugin: https://github.com/transistorsoft/react-native-background-geolocation/blob/master/android/build.gradle#L22 But if you move higher than the 3.12.x support branch of OkHttp you must move your minSdkVersion to 21: https://cashapp.github.io/2019-02-05/okhttp-3-13-requires-android-5 Appears to be about 10% (and falling of course) of marketshare on Android at this point |
|
@christocracy thanks for the reply, |
|
@heltonandreazza I can make a test-build for you configured like so, if you wish: new OkHttpClient.Builder()
.protocols(Arrays.asList(Protocol.HTTP_1_1))
.build();I'll publish it to a branch for you to try. |
|
@heltonandreazza Here you go: branch okhttp-Protocol.HTTP_1_1 |
|
@christocracy I think the link is private, I'm receiving 404 |
|
Right, I thought you were a customer. I published it the private repo. Pushed to this public repo: |
|
Yep, as I expected it didn't work. I'll be watching okhttp's devs feedback thanks !! |
|
here is a sample with the issue just in case someone needs to do some testes https://github.com/heltonandreazza/geolocation-sample |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. You may also mark this issue as a "discussion" and I will leave this open. |
|
Closing this issue after a prolonged period of inactivity. Fell free to reopen this issue, if this still affecting you. |
|
Hi, I am fencing the same issue of HttpService is busy. |
That’s not an issue that needs solving. That’s a normal and expected thing to see. |
|
Ohk, But you can tell me why this is coming in log, even server and services working fine and how can i fix this |
As I said above: "that’s not an issue that needs solving. That’s a normal and expected thing to see". The plugin's HTTP service uploads records synchronously. The message simply means the HTTP service is already in the process of uploading and doesn't need to be interrupted. There is nothing unusual about that message the needs to be "fixed". You are mistaken in thinking it's abnormal -- it's NOT abnormal and does not need "fixing". |
Environment
react-native -v): 0.59.4Expected Behavior
GPS points should be synced with our configured URL.
Actual Behavior
We should not be seeing 'HTTPService is busy' message. Currently, device gets into a state where device essentially becomes blocked and points no longer get synced and remain in device's local database.
Steps to Reproduce
Intermittent. Some devices are tracked without any issues while others get stuck in this state.
Context
We currently have an app for truck drivers. Our app has been designed to work offline. We use Realm to store data offline and on every major action (e.g. viewing trips or stops) we ensure that offline data and source of truth (server database) are in sync. One of the methods that conditionally gets called on every major action is BackgroundGeolocation.sync();
I understand that we don't technically need to call BackgroundGeolocation.sync() manually because the library takes care of this automatically. However, we have a diagnostics screen which shows how many GPS points are stored in local db (awaiting sync) and there is a button to manually attempt to sync positions. This requirement came from management.
Note... We also listening on connection changes via the NetInfo library. When connectivity is detected, this is another place we attempt to manually call BackgroundGeolocation.sync()
Debug logs
Logs
The text was updated successfully, but these errors were encountered: