Per XEP-0078: Non-SASL Authentication recommendation, when connection conflict occur is stated below:
"There is a resource conflict (i.e., there is already an active session with that resource identifier associated with the same username). The RECOMMENDED behavior is for the server to terminate the existing session and create the new one; however, the server MAY provide the opposite behavior if desired, leading to a conflict error for the newly requested login."
With ejabberd, the server will inform the client of the session conflict; but proceed to terminate and re-create a new session. However Smack 4.2.0 automatically closes the connection upon receiving this <stream:error/>-conflict. After this, the server and client connection state is no more in-sync. This has prevented the client attempt to re-login as the same <stream:error/> will again be issued by the server.
05-15 12:47:08.148 D/SMACK: RECV (0): <stream:error><conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/><text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>Replaced by new connection</text></stream:error>
05-15 12:47:08.273 W/αTalk:  org.jivesoftware.smack.AbstractXMPPConnection.callConnectionClosedOnErrorListen er() Connection XMPPTCPConnection[firstname.lastname@example.org/atalk] (0) 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'/><text xml:lang='en'>Replaced by new connection</text></stream:error>
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.parsePackets(XMPPTCPC onnection.java:1046)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader.access$300(XMPPTCPCon nection.java:980)
at org.jivesoftware.smack.tcp.XMPPTCPConnection$PacketReader$1.run(XMPPTCPConnecti on.java:996)
Sorry, it may be my mistake.My ejabberd server is setup to have only one instance login for each account. I have the same account setup on another machine which will automatically login on failure.
The test device was constantly being logout by the server, whenever the account on the other machine re-login the server on failure.
Will continue testing and monitoring; and feedback if otherwise.