I have a sample app that uses Parse Server. I've been testing my app on both emulator and physical devices and I noticed that the response time is much slower on the physical device.
This one is from the emulator.
and this is one is from the physical device:
I've been scratching my head regarding this one. I've also posted it on the parse community platform and followed the advice there to manually monitor the server for every change I've made until I reach my prior server configuration. I overhauled the server from scratch. Do some load testing -> Deployed the server on a replica set -> load testing. Now, I'm in the process of doing some basic queries. I used ADB logcat to see what's happening on both device and saw these errors on the physical device and not on the emulator:
E[N rtchannel]_rt_mqtt_publish_callback(356)=>Failed to publish the request over MQTT. token:be925eea-407c-417d-96c9-3af5a7e83e48, category:mcd-sync-data-task-category, requestId:54138, error:Error Domain=mqtt Code=3008
E[S sync]_createResponseError(166)=>Network Response be925eea-407c-417d-96c9-3af5a7e83e48 contains sync error Error Domain=mqtt Code=3008 - Underlying error (null): Error Domain=mqtt Code=3008
This one also shows before pulling the payload.
W[S sync-state-machine]MCDSyncStateMachineScheduleDelayedRetry(173)=>skipping the new retry with longer delay
W[S sync]_scheduleNextCursorRetry(326)=>skipping delayed retry due to state machine state decision
The number of times these errors pop up is related to the number of queries executed. I did not put any configurations on the server which use MQTT. Any help is much appreciated.
Related
I'm developing an adaptation for an android app, to communicate with a remote control, which has some pre defined commands.
I've followed this implementation to do the Bluetooth communication and it's working fine for sometime.
This app should communicate with the remote control every 5 minutes or less, and I've been using the app for almost 6 months now. The last week I've some command clashes problem and looking at the logs I couldn't identify why did that happened. The last time that this had happened the app was running for more than 24h, communicating with the remote control, without any communication issue.
Two of it's commands have some similar characters, the first one that have to be done, to establish the connection.
OK_CONN
And an sniffer command which keeps the pilot awake listening for some sensor data:
N
Looking at the logs I can see the answer for command N, after applying the command OK_CONN.
Is it possible for a Bluetooth command to lost part of it's data, during an established communication or am I doing something wrong when writing to a characteristic? Should I change the command names to avoid this kind of clash?
I'm using android 9, at a Sony XPeria XZ phone.
Edit to clarify #Emil comment
07:02:12.880 [BleThread] writing <OK+CONN> to characteristic
07:02:12.368 [Binder:19249_F] [onCharacteristicChanged():274]:
n command confirme
Looking at the logs I see that the last written command as an ok_conn but it has written only the N, this is been show as the last line, it has confirmed to receive the n command alone, instead of receiving the full data of ok_conn.
By name clashes I mean that maybe the last N of the ok_conn command is been accepted as the command.
I just realized what's going on, you can post that as an answer #Emil, my problem was at the logic that sends the first command, sometimes I send this command and the micro controller is not started yet, that's probably the reason of it getting only part of the command.
Not sure what you mean by name clashes, but Android will always write what you told it to write, without packet loss, as long as you follow the rules to never have more than one outstanding operation (always wait for callback before you send the next operation) and that your data must fit within the maximum length for the corresponding operation.
I am getting the error "It is impossible to create a new session because 'createSession' which takes HttpClient, InputStream and long was not found or it is not accessible"
also my Appium server gets killed autometically after this error in console.
Please help to resolve.
The error may occurs from various reason. You need to check your appium server log to know the exact cause. Beside that you can verify following.
Start your appium server in session-override option.
Make sure your appium server is running.
Make sure your are using correct url of appium server.
Confirm your device is properly connecting to the laptop. You can verify it by using adb devices command (for android). Make sure it is showing only one device.
Make sure your DesiredCapabilities are correct or all required desired capabilities are included.
Try re-starting the appium server.
I'm not yet entirely sure why but it seems that when I use the Firebase FCM services and have 2 or more emulators running on my Android Studio the Firebase FCM API behaviour goes nuts.
The Flow
A quick example is:
1 - I subscribe to a topic
FirebaseMessaging.getInstance().subscribeToTopic(topicName).addOnCompleteListener...
2 - Send messages (All good so far, I get all messages)
3 - Unsubscribe FirebaseMessaging.getInstance().unsubscribeFromTopic(topicName).addOnCompleteListener...
4 - Send messages (all good so far, I don't get messages anymore)
The problem:
When I repeat the same thing with two or more devices, it simply does not work, even though I get the response of the addOnCompleteListener method, let's say "unsubscribed", I still get messages.
Points to notice:
1 - Yes, I'm sure I unsubscribe only 1 device between the two, and the one I unsubscribe keeps getting messages (I can see in the log files).
2 - No, the problem does not happen when I use one emulator only
3 - I've already tried to use a real device via debug mode (connected via USB cable and I still have the same behaviour when running in parallel with another emulator)
4 - Yes, I'm sure I get the response from the FirebaseMessaging.getInstance().unsubscribeFromTopic(topicName) method before sending messages.
Specs:
Android Studio: 3.1.2
Firebase:
implementation 'com.google.firebase:firebase-core:16.0.4'
implementation 'com.google.firebase:firebase-messaging:17.3.3'
My assumption
There's something broken between the identification of more than one emulator when it's run in parallel, and therefore the Firebase topics API cannot distinguish accurately which is which.
Any thoughts?
Cheers in advance.
Since couple of weeks this exception appears sometimes on my App:
Non-fatal Exception: com.facebook.FacebookAuthorizationException: CONNECTION_FAILURE: TigonError(2): TigonLigerErrorDomain(2) AsyncSocketException: connect failed (immediately), type = Socket not open, errno = 101 (Network is unreachable)
at com.facebook.login.LoginManager.onActivityResult(LoginManager.java:218)
at com.facebook.login.LoginManager$1.onActivityResult(LoginManager.java:173)
at com.facebook.internal.CallbackManagerImpl.onActivityResult(CallbackManagerImpl.java:95)
at com.myapp.util.connect.FacebookConnect.onActivityResult(FacebookConnect.java:338)
Facebook SDK: 4.27.0
Android version's impacted: 4.4.2 and 7 (Crashlytics informations)
Have you got some ideas guys about this exception?
Thank you very much
UPDATE
I wrote a ticket on Facebook support, and after several messages, the last is:
Hi Anthony, thanks for the additional details. Looking at the data for your app,
there don't seem to be any failed API calls logged for your app. This indicates
that the login attempts failed before they reached our servers, and confirms
that this was indeed due to network errors.
I agree that it's not the ideal experience for users to have to retry their
login attempt, but in the case of network-related issues like this, this is the
best approach. I would recommend prompting the user to check their device
connectivity and initialize the login flow again.
From debugging this, it's unlikely that this is due to compatibility issues with
Retrofit, though I can't rule it out with certainty. It's more likely that the
affected users simply experienced a temporary drop in connectivity.
I'll mark this as closed since there doesn't seem to be a bug within the
Facebook SDK, but if you're able to get any information that would indicate
otherwise (for example, a way to consistently reproduce the error on a device
that has full internet connectivity), please let me know and I'll be glad to
help look into this again.
This exception means that user of your app is experiencing problems with his Internet connection. It is a problem that all the developers should care when making network calls, but it is especially important for mobile devices (the quality of mobile internet can be significantly low). Unfortunately netwok errors cannot be eliminated completely.
The common way of solving such a problem is making retries: either on the side of the app (retrying, showing user an error only after several network errors), either on the side of the user (suggesting user to try once more).
I am experiencing a bad behavior of Pubnub in the following scenario:
Pubnub SDK for Python as a subscriber
Python 3+Django on Ubuntu 14.04
Ubuntu machine hosted on Azure
Android Pubnub client as a publisher
It seems to be that, at a certain point, the Pubnub connection on the server side becomes stale, that is, any message sent from the client is not received by the subscriber.
I have noticed that there are some errors on the log related to pubnub connection:
WARNING 2015-09-30 17:21:24,778 connectionpool 26551 139638563919616 Retrying (Retry(total=0, connect=None, read=None, redirect=None)) after connection broken by 'ReadTimeoutError("HTTPConnectionPool(host='pubsub.pubnub.com', port=80): Read timed out. (read timeout=320)",)': /subscribe/.../.../0/...?uuid=...&auth=...&pnsdk=PubNub-Python/3.7.3
After about 5 minutes, the message is received and correctly processed.
I guess that the root of the problem lays in the way Azure manages long http connections, as:
The problem does not arise on my local machine, which has the very same OS version and the same stack
There is an obscure 'azure' parameter in the Python SDK. I tried to activate it without any noticeable difference
As a test I added two more subscribers on my pc and they both receive messages instaneously
Thanks.
It seems to be that the root cause is the fact that Azure cuts HTTP connections above 4 minutes (https://azure.microsoft.com/it-it/blog/new-configurable-idle-timeout-for-azure-load-balancer/).
On the other hand, though, Pubnub creates connections with 5 minutes timeout (320 seconds, see https://github.com/pubnub/python/blob/master/pubnub.py#L1881).
Unfortunately, the Pubnub 320 seconds timeout can not be changed, whereas the Azure timeout seems to be modifiable only via Powershell scripts (uncomfortable, especially if you do not have a Microsoft Window machine).
All in all, I changed the Pubnub source code with a 120 seconds timeout and now everything is going pretty well.
It would be advisable to:
Document that on Pubnub side
Modify Pubnub so that the 320 seconds timeout can be changed
Improve the Azure interface in order to change the timeout parameter without using Powershell
If there is anything that can be done from the PubNub SDK, look at this:
Azure flag on init
https://github.com/pubnub/python/blob/master/pubnub.py#L2112
https://github.com/pubnub/python/blob/master/pubnub.py#L2141-L2146
Linux platform
And this should be getting called if Azure is running on linux:
- https://github.com/pubnub/python/blob/master/pubnub.py#L69-L77
Let me know if that helps any.