Smack: StanzaListener.processPacket() are not called on GCM incoming message

Smack Smack Dev
1

Hello.

I’m programming GCM(Google Cloud Messaging) backend server with Smack 4.1.3.

Problem is when my backend receives first GCM incoming message, processPacket() doesn’t called for that message.

But when second message arrives, processPacket() called for FIRST message.

Then third message comes, processPacket() doesn’t called.

And on fourth message, processPacket() called for THIRD message.

My console debug log prints like this.

07:27:51 User logged (0): MY_SENDER_ID@gcm.googleapis.com:5235/Smack6DCD9C77

07:27:51 XMPPConnection authenticated (0)

// First GCM incoming message.

07:27:56 RECV (0): <message to="MY_SENDER_ID@gcm.googleapis.com" from="devices@gcm.googleapis.com" … “message_id”:“15” …

// processPacket doesn’t called

// Second GCM message comes.

07:27:58 RECV (0): <message to="MY_SENDER_ID@gcm.googleapis.com" from="devices@gcm.googleapis.com" … “message_id”:“16” …

// Then processPacket() for FIRST message called immediately. processPacket() just prints received XML message.

Received:<message to="MY_SENDER_ID@gcm.googleapis.com" from="devices@gcm.googleapis.com" … “message_id”:“15” …

// Third GCM message.

07:28:04 RECV (0): <message to="MY_SENDER_ID@gcm.googleapis.com" from="devices@gcm.googleapis.com" … “message_id”:“17” …

// processPacket doesn’t called

// Fourth GCM message.

07:28:05 RECV (0): <message to="MY_SENDER_ID@gcm.googleapis.com" from="devices@gcm.googleapis.com" … “message_id”:“18” …

// processPacket() for THIRD message called.

Received:<message to="MY_SENDER_ID@gcm.googleapis.com" from="devices@gcm.googleapis.com" … “message_id”:“17” …

…

I googled about this and found same question about this on stackoverflow.

The link is this.

http://stackoverflow.com/questions/31583930/not-able-receiving-all-messages-from -google-cloud-messaging-with-ccs

My code is nearly identical to above link’s code.

Is it bug or am I missing something?

Thank you for your help.

2

Could you attach a debugger an see why the listener is not invoked for the second and fourth stanza, and only for the first/third after the second/fourth arrived?

3

Hello.

I attached debugger and found some info.

When first message arrives, then call chain goes down like this.

AbstractXMPPConnection.parseAndProcessStanza() called.

->

PacketParserUtils.parseStanza(parser)

->

PacketParserUtils.parseMessage()

->

PacketParserUtils.parseExtensionElement()

->

ParserUtils.forwardToEndTagOfDepth()

->

MXParser.more()

->

org.jivesoftware.smack.util.ObservableReader

line #40 public int read(char[] cbuf, int off, int len) throws IOException { // len: 6565 off: 1627 cbuf: char[8192]@5721

line #41: int count = wrappedReader.read(cbuf, off, len); // len: 6565 count: 387

line #42: if (count > 0) {

line #43: String str = new String(cbuf, off, count); // off: 1627 count: 387 cbuf: char[8192]@5721

I omitted some method in call chain… But important thing is when FIRST message comes, it eventually comes down to line #41.

When I did ‘Step Into’ at line #41. My debugging session ends. I don’t know whether IntelliJ IDEA can’t go into JAVA core library or maybe I’m doing something wrong… anyway, It stops there.

And then, when I send SECOND message from android terminal to GCM, my debugger point starts at line #42 immediately.

It’s strange… and I don’t have no idea. But it really is. and from there execution continues.

line #43, count: 387 is exactly incoming message’s length.

incoming message looks like this

{“data”:{“hello”:“world”},“time_to_live”:30,“from”:" c7Nz3yaqhLk:APA91bHmKjY9vNPgeCScrOnxjt_GHcX1uZBVbZ9aFQdH-_1IzO5Dl_NYuRIuJXYkTOq1 FNJv-Ri8GmaLXvIL7ZCAWjulEWPinRWRd3vwG7RtW0sdV4sXZ54",“message_id”:“7”,“category” :“com.mycompany”}

I replaced some word for personal info, but above message’s length is exactly 387.

JDK version is 8.

I changed version to 7 and same thing happens.

Do you have any idea?

Thank you for your concern.

4

[SMACK-695] JSON and GCM parser does an erroneous extra next() - Jive Software Open Source

5

Thanks for debugging. I’ve uploaded a new snapshot of 4.1.4 which includes Remove erroneous next() from AbstractJsonExtensionProvider · Flowdalic/Smack@b1e4884 · GitHub . Could you try 4.1.4-SNAPSHOT and report back if it solves the issue?

6

Tested with smack-core-4.1.4-20150824.091133-4.jar & smack-experimental-4.1.4-20150824.091155-4.jar files.

And then the problem is fixed.

Thank you very much for quick fix.

Your help is much appreciated.

7

You are welcome. There is a tipjar at igniterealtime/Smack · GitHub