Develop Reference

Realm PermissionManager.getPermissions() error after connection reset

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).

Stream resumption in ejabberd is not working

First Case:
I am using PSI client in Ubuntu 16.04 LTS and my ejabberd version is 16.03.
I am facing message lost issues hence i have gone through this link for stream management : http://xmpp.org/extensions/xep-0198.html
When i send following request
<enable xmlns='urn:xmpp:sm:3' resume='true'/>
Server response is ok for me, i.e
<enabled xmlns="urn:xmpp:sm:3" id="g2gCbQAAAANELTVoA2IAAAW+YgAMmKxiAAnx/A==" max="300" resume="true"/>
After some chatting with other user, when i send following Stream resumption request :
<resume xmlns='urn:xmpp:sm:3'
h='0'
previd='g2gCbQAAAANELTVoA2IAAAW+YgAMmKxiAAnx/A=='/>
I got the following error:
<failed xmlns="urn:xmpp:sm:3"><unexpected-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas"/></failed>
I have tried all the ways like disconnect the network, kill application and offline the user. But stream resumption is not working.
I am not getting the problem, Please help me.
Second Case:
When i use following configuration in ejabberd.yml:
listen:
port: 5222
module: ejabberd_c2s
resend_on_timeout: if_offline
stream_management: true
And start chatting after enables stream management. Then for the case of network disconnect and application kill, My all messages are storing in the offline queue (if i am not able to reconnect within 300 sec). In this process no one message is lost.
But my problem is this process is work only for mobile (ejabberd_c2s module). Web or Bosh is not supporting the stream management (ejabberd_http module). How can i use stream management for Bosh or web?

xmpp with openfire client connection lost suddently with smack 4.1

I am working with the XMPPTCPConnection to connect with my openfire server, Connected successfully and sent/receive data packets successfully. Connection remains stable but suddenly drops with an exception and I am getting no clue about this exception.
My server disconnect idle user time is 60 sec. And I have implemented all ping manager, and re-connection code. So its reconnecting but not getting why it get disconnected with exception or how to resolve this exception.
E/MainService: Connection to XMPP server was lost.org.jivesoftware.smack.SmackException: Parser got END_DOCUMENT event. This could happen e.g. if the server closed the connection without sending a closing stream element
07-28 10:21:22.003 12719-16068/com.thatsit.android D/SMACK:
XMPPConnection closed due to an exception (0)
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: org.jivesoftware.smack.SmackException: Parser got END_DOCUMENT event. This could happen e.g. if the server closed the connection without sending a closing stream element
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPConnection.java:1170)
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPConnection.java:952)
07-28 10:21:22.003 12719-16068/com.thatsit.android W/System.err: at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnection.java:967)
07-28 10:21:22.013 12719-16068/com.thatsit.android W/System.err: at java.lang.Thread.run(Thread.java:818)
Any help will be highly appreciate.

there is no need to disconnect ideal users.
If you again disconnect then make a service that is working in background and check the xmpp connection every 10 seconds.If connected then there is no need to connect but if disconnect then connect it to server again. I have handled this from my app.
I have also open source code on github.If you want then you can refer from there.
This is not updated code with 4.1 but i have already made changes but need to upload. Today evening i'll upload updated code.
Thanks, Hope this will help to solve your problem.

Actually there are two issues related to yours: one is in Openfire 4.x.x and one is in the Smack 4.0.7 library.
There is a bug (OF-1308) in Openfire 4.x.x and above that when the server disconnects a client, it doesn't send the end-tag of stream to the client as an intentional disconnection. It just closes the socket and causes PacketReader getting END_DOC event.
In Smack, the PacketReader handles IOException (unexpected loss of network connectivity), end-tag of stream (an intentional disconnection), or END_DOC (unexpected disconnection from server like server crashed.) Getting IOException will trigger Reconnection Manager if it is enabled. Getting an end-tag of stream will trigger normal connection close event. However, Smack treats the END_DOC as getting end-tag of stream. In my opinion, Smack should treat END_DOC as IOException since the end-tag of stream has not been received.
There is another twist. If you have compression enabled, PacketReader gets IOException if the server simply closes the socket. If compression is disabled, PacketReader gets END_DOC if the server simply closes the socket.
In your case, when there is an idle timeout enabled, the client should not trigger ReconnectionManager. Otherwise, it defeats the purpose of idle timeout. I am testing my fix, so I haven't reported the Smack bug to the Ignite Community yet.

SMTPTransport sendMessage stuck on connection loss

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...

Socket close timing

I have what appears to be a timing problem between a client (Galaxy Nexus) and a custom server since upgrading from Ice Cream Sandwich to Jelly Bean. Here is the general flow:
Client opens socket, issues HTTP get to server
Server accepts, starts new thread, responds with HTTP header and 200 OK.
Server writes (binary) file to socket.
Client reads data from socket and saves to a file.
After server thread writes all data, it closes the socket, and terminates
This has worked well over the past several months prior to the Jelly Bean update. Since the update the binary transfer succeeds about 70% of the time. The remaining 30% fails
when 'serverSocket.getInputStream().read' returns a -1 indicating the end of stream has been reached. No data has been read, no error exceptions raised, nothing in logcat.
The possibility of a timing problem arises when I change the server behavior in step #5. The thread was closing the socket after the write with the observed problems. If I remove the socket close, terminate the thread after the write, and let the OS eventually close the socket then it seems to work all the time.
I used tcpdump and WireShark to look at the packets in both the successful and failed cases. In the failed case a socket is closed in a few milli-seconds while in the successful case the socket is closed is a quarter or more of a second. The net of this is that any delay we cause in the socket closing improves our chances for success.
If anyone has any suggestions with what we may be doing to cause this problem or suggestions on how to narrow down the problem please feel free to respond. I can add code samples if required.

It looks like that when the server ask for the connection close, the socket is immediatly closed. Maybe the default ocket linger's time has changed between version ???
Try setting the socket linger's time using:
socket.setSoLinger(boolean on, int timeout);
to have the server waiting some time before close channel if some data still waiting to be sent.
If this doesn't solve, you can change your flow above to:
...
4.Client reads data from socket and saves to a file.
5.Client send confirmation to server.
6.Server close connection.
--EDITED--
A gracefull way to achive the above without additional TCP data packets traveling for the closing confirmation is:
when server finish writing to the socket calls:
socket.shutdownOutput();
when client socket.read() returns -1, client calls:
socket.close();
This ensures that client is informed that all data has been sent, and sender will wait for the socket closure protocol to complete.