0

We are developing an app with a chat feature. We have an ejabberd (15.02) configured to use mod_offline_post to use the offline message hook and forward all messages for offline clients to an url of our own which then forwards to the GCM.

However as we are developing an app, we also need XEP-198 (stream management) enabled to handle connection loss. This is working fine in itself. Streams are created and resumed, messages are acknowledged.

The problem is, that the jabber is waiting for a stream to resume and is not forwarding any offline messages to the offline message hook and thus to our mod and post url. It is storing them in its offline storage of course and they get delivered when the recipient resumes its stream.

Is there any way to configure the jabber to call the offline message hook while ejabberd_c2s:fsm_next_state:2517 Waiting for resumption of stream for... ?

PS: We use smack on the client side to provide stream management

Flow
  • 23,572
  • 15
  • 99
  • 156
Pete
  • 10,720
  • 25
  • 94
  • 139
  • Assuming that your client tries to keep an XMPP over TCP connection established to your server, then why do you even use GCM and not just wait until the client has re-established the connection? – Flow Mar 02 '15 at 11:49
  • Because if the app is closed completely we still want the client user to know that he has an incoming message. Clicking the GCM notification will open the app, the connection is re-established and the message is delivered. – Pete Mar 03 '15 at 06:35
  • You could use a sticky background service which would run even if no activity of your app is in foreground. – Flow Mar 03 '15 at 07:02

1 Answers1

1

In my understanding the behaviour of ejabberd is correct from the XMPP specification point of view. It is doing the right thing and should not in that case forward message to the offline store, because you are not offline technically.

It is just not the right place to place your push processing.

Mickaël Rémond
  • 9,035
  • 1
  • 24
  • 44
  • Thanks for the answer. That's what I figured out as well. Turns out, it is already working as intended. The Jabber closes the stream after an idle time of 5 minutes and then forwards all offline messages to our push URL. If the client reconnects before that time, he just gets all messages directly from the jabber offline storage. So I've just been too impatient. – Pete Mar 03 '15 at 14:05