Develop Reference

Failed to publish the request over MQTT - Flutter - Parse Server

I have a sample app that uses Parse Server. I've been testing my app on both emulator and physical devices and I noticed that the response time is much slower on the physical device.
This one is from the emulator.
and this is one is from the physical device:
I've been scratching my head regarding this one. I've also posted it on the parse community platform and followed the advice there to manually monitor the server for every change I've made until I reach my prior server configuration. I overhauled the server from scratch. Do some load testing -> Deployed the server on a replica set -> load testing. Now, I'm in the process of doing some basic queries. I used ADB logcat to see what's happening on both device and saw these errors on the physical device and not on the emulator:
E[N rtchannel]_rt_mqtt_publish_callback(356)=>Failed to publish the request over MQTT. token:be925eea-407c-417d-96c9-3af5a7e83e48, category:mcd-sync-data-task-category, requestId:54138, error:Error Domain=mqtt Code=3008
E[S sync]_createResponseError(166)=>Network Response be925eea-407c-417d-96c9-3af5a7e83e48 contains sync error Error Domain=mqtt Code=3008 - Underlying error (null): Error Domain=mqtt Code=3008
This one also shows before pulling the payload.
W[S sync-state-machine]MCDSyncStateMachineScheduleDelayedRetry(173)=>skipping the new retry with longer delay
W[S sync]_scheduleNextCursorRetry(326)=>skipping delayed retry due to state machine state decision
The number of times these errors pop up is related to the number of queries executed. I did not put any configurations on the server which use MQTT. Any help is much appreciated.

Android MQTT , Client presence How to know setWill is working?

I am using below code to connect to MQTT server
MqttConnectOptions options = new MqttConnectOptions();
options.setCleanSession(true);
options.setKeepAliveInterval(Constants.CLOUD_KEEP_CONN_ALIVE);
byte[] payload = String.valueOf(0).getBytes((Charset.defaultCharset());
options.setWill("willTopic", payload, 0, true);
mAndroidAsyncClient.connect(options, this);
Once connected I get a callback . Now my question is how to debug in server , that setWill is working using mosquitto_sub .
I am using setWill to know client presence.
To confirm setWil is working I wanted to debug from server by subscribing to willtopic and get logs .
I tried connecting and disconnecting many times but there is message sent over will topic.
Command I used on server is
mosquitto_sub -t appTopic --will-topic willTopic
It will be helpful if anyone share the command or way to debug Mqtt setWill.
I tried referring to How to Find Connected MQTT Client Details . But it did not workout for me.

The only real way to test that the LWT (Last Will & Testement) message gets sent is to make the broker send it.
To do this you will have to cause a none clean shutdown of the client, given this is on android the easiest way would be to run the app in the emulator, let it connect then kill the emulator (You have to do this because last time I tried to get the emulator to disable all network activity I discovered it just sent the Network Down broadcasts but left the network up). Once the keep alive period expires and the broker notices the client has gone it should publish the LWT message and you should be able to see this with mosquitto_sub.
There may be ways to query the broker for a given LWT message but this would be totally dependant on the broker you are using. I'm not aware of any brokers that make this easy, but there may be something under the '$SYS/#' topic tree on brokers that support that interface.
EDIT:
Also when using mosquitto_sub you should just be using the -t not --will-topic. --will-topic is the topic that mosquitto_sub would publish it's own LWT on if it was disconnected. You can have as many -t options as you need, and -v will print the topic name before the message body so you can tell them apart
mosquitto_sub -v -t appTopic -t willTopic

Google cloud messaging GCM through proxy

I am having trouble sending a message to a device through the company proxy.
I have done the GCM tutorial on the google site and have successfully registered a device on the google servers with the android emulator,
and also on the server at my end.
For this I had to go through the company proxy, setting it in the access point of the emulator.
Now the problem I have is sending a message from my server to the device through the same proxy.
I am using the servlet code from the demo which uses the
com.google.android.gcm.server.Sender
helper class to send the message.
I am running the servlets on tomcat 7.
I have tried setting the proxy up in the catalina.properties file like so.
http.proxyHost=proxy.company.com
http.proxyPort=8080
And I have tried setting properties inside the servlet itself like below.
System.setProperty("http.proxyHost", "proxy.company.com");
System.setProperty("http.proxyPort", "8080");
But still I get the timeout.
I know its the company proxy because I got the messaging working at home where I have no proxy.
I have seen a proxy object created in the java code and then a connection created with it, but I dont think that is usable here since I am using Sender helper class to send the message.
This is the line that fails in a timeout.
Result result = sender.send(message, registrationId, 5);
Any help would be appreciated.
Regards
Bill

Alright, I finally have it working. In my comment I mentioned that I had succeeded in sending out the message, but the emulator was not recieving it. I had forgotten to follow my own earlier advice and run the emulator from the command line with the proxy parameters set like so:
emulator.exe -avd avd22google -http-proxy proxy.company.com:8080 -debug-proxy
So to summarise, my initial problem was that I had registered the emulator on the with GCM and with my local server, but the when I clicked send message I was getting a timeout.
I initially thought it was the firewall so I did some research and set up the proxy in tomcats catalina.properties file.
This made no difference.
I used the "Charles" web proxy debugger software to see where the message was attempting to be sent to and it came up with https://android.googleapis.com:443
So I initially I added the following to my catalina.properties file:
https.proxyHost=proxy.company.com
https.proxyPort=443
It still did not work. A colleague of mine told me that our company proxy handles all types of requests through port 8080, so I changed the the poort line to:
https.proxyPort=8080
This allowed the message to be sent out.
But then the message was not getting through to the emulator and I was receiving the following error in LogCat.
[GTalkConnection.12] doConnect: caught XMPPError connecting to mtalk.google.com:5228.: -- caused by: java.net.SocketException: The operation timed out
Then I remembered that you need to start the emulator with the command line to get it to use the proxy. Once I did this a flood of messages appeared on my emulator!
So I finally have it working end to end. It's taken me about a week to get GCM fully working within my company firewall, so hopefully this post can help some other poor sod doing this in the future.
cheers
Bill

Android sipdemo timeout when making calls

Having a problem with the android sipdemo timing out when making calls. The native sip client on the phone has no issues calling, works perfect. Its When i initiate the call within the sipdemo i get a timeout in the logcat. timeout is set to standard of 30 seconds.. a local asterisk box is what its connecting to. Registers fine.

I'm having the same problem.
I traced packages in wireshark and here's what I found:
I register to SIP server in SipDemo
I register to SIP server on Desktop (using Ekiga)
I place a call in SipDemo to Ekiga.
INVITE message gets sent to Ekiga
Trying is sent from Ekiga to the server
Ringing is sent from Ekiga to SipDemo
I answer the call on Ekiga client
OK (with session description) is sent from Ekiga to SipDemo. This happens 11 times before Ekiga just gives up
BYE is sent from Ekiga client to SipDemo
Please note that OK is being sent 11 times before Ekiga just gives up and ends the call. This is why the call lasts just 30 seconds.
If you take a look at the RFC here:
http://www.ietf.org/rfc/rfc3261.txt section 13.3.1.4
you can see that the reason Ekiga is giving up on SipDemo client is because it never gets ACK back from SipDemo.
I believe this is android bug, but I can't imagine they could have missed something this basic in their SIP implementation.
In the next few days, I'll try to dig up some answers in android source code...
I'll try see what happens when establishing calls between 2 SipDemo applications. If it works, that means android just ignores ACK all together.
EDIT:
I just tried a call between 2 SipDemo clients. It sends OK 5 times and gives up on the OK, but does not end the call. Interesting behavior :)
EDIT2:
I dug up androids SIP implementation, and I found that ACK should get sent... Even logcat logs this, but I still see nothing in Wireshark. I thought maybe it gets blocked or something, so I ran Shark (like Wireshark for android) on the device, pulled the dump to my laptop, opened it up in Wireshark, and I don't see ACK anywhere. I even looked trough all packets... No filters, just in case I might be filtering it out. Anyways... Here's what I found in android code:
http://hi-android.info/src/com/android/server/sip/SipSessionGroup.java.html
class: SipSessionImpl
method: private boolean outgoingCall(EventObject evt)
in case Response.OK:
you can see this call:
mSipHelper.sendInviteAck(event, mDialog);
In SipHelper, method sendInviteAck, you can see:
if (DEBUG) Log.d(TAG, "send ACK: " + ack);
dialog.sendAck(ack);
Dialog is nist javax.sip, so I don't think there's a need to go further...
I see this message "send ACK" in my logcat when running the application
EDIT3:
I noticed that this issue occurs only with some SIP servers. I now tried opensips, and it works fine. I guess the problem I was having had to do with the server responding to androids keep-alive OPTIONS messages with 404 Not Found. Then, android tried to not use the server as soon as possible. Because of that, as soon as android got the address of its peer client, it tried to send a direct message, and failed

Hard to tell just like that. Try capturing the packages with wireshark, filter for the SIP protocol and have a look at what is sent over the network. Also try it with the native client and compare it to the sipdemo.
Another starting point is the log of your asterisk instance (systemlog)
If you can't figure it out yourself, post the results here.

Lost messages with aSmack

i'm using aSmack in my Android app to receive messages from my Desktop-Jabber-client. This works fine and even if my android phone is offline (after the connection was closed properly) it will receive the offline messages after the next login.
But when i enter the airplane-mode on the phone or shutdown the phone so that the connection is abruptly closed (without calling disconnect() on the Connection-object) the phone stays "online" in the contact-list of my Desktop-Jabber-client for a while and i can send messages to it. However these messages never arrive. Even though the phone logs in to the server again. These messages are lost.
Does anyone know how to fix this issue? Losing messages in a chat is not an option. :)
EDIT: Added Test-Code
BroadcastReceiver: http://pastebin.com/cFLzGXgy
Service: http://pastebin.com/wLpQCQfT
The first one is a BroadcastReceiver starting the service (second URL) each time the phone is connected to a network.
PS: This is only a test-code! You must change the server/username/password if you want to use/test it.

You can try to send delivered message from client b to client A when the message arrival. The problem is if the client A is offline (no connection break) the delivered confirm don't send until the user receives the message and the client B can't re-send the message.

you can try to send acknowledgement of receiving the message using Smackx Message Events
this will assure the message is delivered else you take corrective action.

this problem occurs when your connection broke.
You need "Stream Management" XEP-198 enabled connections to achieve this messages. refer to this blog : http://op-co.de/blog/posts/XEP-0198/ Basically it allows for stanza acknowledgement and stream resumption, which is exactly what you want to do in case.so you should wait till smack will 4.1 release.