I am facing this issue and would like to know if someone facing it too and maybe have solution.
I also opened issue on Github but no answer so far
link to issue
After connection reset or dropped connection PermissionManager.getPermissions() return this error:
E/REALM_SYNC: Connection[4]: Reading failed: Connection reset by peer
E/REALM_JAVA: Error in __permission:
CONNECTION_RESET_BY_PEER(realm.basic_system:104): Connection reset by
peer E/REALM_SYNC: Connection1: Reading failed: Connection reset by
peer E/REALM_JAVA: Error in __wildcardpermissions:
CONNECTION_RESET_BY_PEER(realm.basic_system:104): Connection reset by
peer E/REALM_SYNC: Connection[2]: Reading failed: Connection reset by
peer
In other words, after connection reset (even manually disable and enable network) it is not possible to get user's permissions anymore.
This issue have big impact on the our app, since we need to show/hide UI components based on this permissions.
Also, does PermissionManager.getPermissions()not support offline mode?
Closing and re-opening the PermissionManager should fix the issue (at least it does for me).
Related
i discovered a really big problem (probably mine?) about the XMPP reconnection process in smack library v4.1.5 (Android) and openfire v4.0.1.
I activated the stream management on the client in this way:
XMPPTCPConnection.setUseStreamManagementDefault(true);
XMPPTCPConnection.setUseStreamManagementResumptionDefault(true);
and activated the automatic reconnection in this way:
ReconnectionManager.getInstanceFor(this.xmppConnection).enableAutomaticReconnection();
After the first successfull connection and login, when the internet connection goes down and the reconnection process starts I get the following error:
W/AbstractXMPPConnection: Connection closed with error
org.jivesoftware.smack.XMPPException$StreamErrorException: conflict You can read more about the meaning of this stream error at http://xmpp.org/rfcs/rfc6120.html#streams-error-conditions
<stream:error><conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1003)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:944)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:959)
The reconnection manager connects and authenticates very well but then I receive the previous error!
I tried to change the resource also but nothing, it doesn't work!
Someone could help me in understanding what is wrong?
When I make my request with only Volley everything goes well and my StringRequest goes to onResponse.
But when I switch to Volley + Okhttp combination, my request goes through, I receive the same response as before but then I get the following error message:
E/Volley﹕ [122319] BasicNetwork.performRequest: Unexpected response code 200 for <my request url>
java.io.IOException: closed
com.android.volley.NetworkError: java.io.IOException: closed
at com.android.volley.toolbox.BasicNetwork.performRequest(BasicNetwork.java:182)
at com.android.volley.NetworkDispatcher.run(NetworkDispatcher.java:114)
Caused by: java.io.IOException: closed
at okio.RealBufferedSource$1.read(RealBufferedSource.java:345)
at java.io.InputStream.read(InputStream.java:162)
at com.android.volley.toolbox.BasicNetwork.entityToBytes(BasicNetwork.java:254)
at com.android.volley.toolbox.BasicNetwork.performRequest(BasicNetwork.java:130)
at com.android.volley.NetworkDispatcher.run(NetworkDispatcher.java:114)
Im using this https://gist.github.com/bryanstern/4e8f1cb5a8e14c202750 for my OkHttpStack for Volley.
I haven't had too much time to investigate but I was running into the same issue when using the emulator connected through a proxy (Charles). For me the problem goes away when I test without a proxy or on device.
This exact same problem happened to me when using the start and stop methods of the RequestQueue. It was pointed out in many popular blogs that the RequestQueue should be stopped when user is flinging to ensure there's no jerking. However when you call stop, all RequestQueue's requests are stopped, even the ones which were already doing network call. The above exception happened when these requests are stopped preliminarily. Not calling the stop function solved the problem for me.
For those people using a Proxy (in my case Charles) besides configuring your proxy in Settings it is necessary to configure also your proxy in the Android Emulator.
So, here is my configuration in Settings Emulator
And this are the steps to configure the proxy using wifi in Android Emulator
Settings
Network & Internet
Wi-Fi
Android Wifi
Click on Setting icon
Click Edit icon
Configure your proxy
I have an application that is working on 2 out of 3 phones. On the third phone, Note 3, I am receiving the following error:
com.parse.ParseException: i/o failure: org.apache.http.conn.HttpHostConnectException: Connection to https://api.parse.com refused
All 3 phones are rooted and are connected to the same wifi network. I have also attempted to use a data connection.
Any help is appreciated.
OK I had the same problem for some time and guess what? Bjorn was right. I just reverted the Hosts file in adfree and problem solved
i am trying to develop a cordova(3.5.0) project in android platform and in that i have to check network connection availability before each API call. for that i am using 'navigator.connection.type',and some times it return 0. why this is happening? plz help me for solving this trouble
Without some more details I can only guess.. There are some conditions which may cause this.
navigator.connection.type = 0 -> connection type unknown.
So you may have a connection, you may not it simply hasn't been determined yet, or because of privileges the device isn't saying.
Are you calling this check too early? ie before deviceready
In our app we do not check the connection each time but we handle it this way:
by making the API request anyway, knowing that its possible to fail, we set a timeout and error handling. If it fails by error or timeout we check connection type and then ping the server with a simple "hello" "acknowledge" request. Its a super small request that we figure will work or if it timeouts again the connection must be so poor it might as well be disconnected.
This is because there are really two types of connection you need to check. Many miss this!
And also because its navigator totally lies some times... :/
Just because wifi is on and connected and navigator tells you this, it doesn't mean you will have a connection to the outside world. You need to check the network hardware (which is all navigator will tell you) but you must also check network connectivity, if this is something you are sensitive about.
i am using javamail's SMTPTransport.sendMessage method to send emails in my android app and everything works fine... but when i start sending a message and in the middle, i disable my wifi, it gets stuck. I have waited for more than 1hour now and it is still stuck; no exception is thrown... any idea how to handle this situation?
edit:
i have added a timeout
props.put("mail.smtp.connectiontimeout", "3000");
props.put("mail.smtp.timeout", "3000");
does not seem to work ... i have simulated a connection loss and it's already 5mins now and it is still in sending state and has not timed out
edit2:
timeout/error(not even sure if it is a timeout) occurred after 16mins
06-30 18:47:27.722: I/System.out(15906): javax.net.ssl.SSLException: Write error: ssl=0xdf8268: I/O error during system call, Invalid argument
edit 3:
it does not always throw an exception... i have simulated a connection loss and after 1hr, still no exception... it is in sending state..... and have not return yet :(
The current version of JavaMail only handles timeouts for reads, because that's all the JDK supports. For the next JavaMail release I've added support for write timeouts. You can experiment with it using the 1.5.1-SNAPSHOT release of JavaMail available in the maven.java.net repository. You'll need to set the "mail.smtp.writetimeout" property. Don't know if this will help you on Android since it's not really Java...