Quantcast
Channel: Ignite Realtime : Discussion List - All Communities
Viewing all articles
Browse latest Browse all 10742

Smack looses messages at connection shutdown/failure

$
0
0

Hi,

 

we are struggeling with several scenarios where smack (3.3.1) looses messages. Would be great if you could take a look at that.

 

Issue A)

XMPPConnection -> protected void shutdown(Presence unavailablePresence)


if (packetReader != null) {

                packetReader.shutdown();

}

 

Is called immediatly after the presence send. As a result are all messages on the wire between the server recognizing that (i.e. sending no more messages) and the listenerExecutor.shutdown() in PacketReader lost.

 

We think that this can be solved by moving the reader shutdown behind the Thread.sleep.

 

Issue B)

XMPPConnection -> protected void shutdown(Presence unavailablePresence)


The Thread.sleep is pretty short for our case (embedded ARM based hardware and a pretty bad mobile connection) and we are loosing messages here as we are not able to send all messages in the queue in that hard coded timeframe. Is it possible to make that one configurable at the connection API?

 

Even better would be switch to a timeout based approach where you send everything left in the queue until the timeout is reached. Well, I guess thats going to be a bigger task

 

 

Issue C)

PacketWriter -> private void writePackets(Thread thisThread) {

 

while (!done && (writerThread == thisThread)) {

                Packet packet = nextPacket();

                if (packet != null) {

                    writer.write(packet.toXML());

 

                    if (queue.isEmpty()) {

                        writer.flush();

                    }

                }

            }

 

The problem here is the exception handling and the underlying (nextPacket) "queue.poll". The (IO)exception handling does take care of the connection. However, the "packet" is lost in case of an IOException at writer.write. It would be great if you could peek at the quere bevore the socket write and than doing the real poll after the write.

 

We are aware that in case of a broken connection we will typically loose more messages to the socket itself than to smack, but at least one message loss at every socket failure can be avoided here

 

Thanks,

kai


Viewing all articles
Browse latest Browse all 10742

Trending Articles