Google recently introduced the parameter priority in their documentation of GCM. The documentation reads:
Sets the priority of the message. Use values between 0 - 10, where the higher value represents higher priority.
But what does this priority actually mean? What do the different values, 0 - 10, indicate?
After a bit of time I found the answer: priority is an argument used in notifications for iOS (like the newly added content_available parameter).
The documentation for priority is well hidden, but can be find in The Binary Interface and Notification Format, in the table of "items and their identifiers":
The notification’s priority. Provide one of the following values:
10 The push message is sent immediately.
The remote notification must trigger an alert, sound, or badge on the device. It is an error to use this priority for a push that contains only the content-available key.
5 The push message is sent at a time that conserves power on the device receiving it.
Related
Looking to understand whether there is a a bulletproof event from the namagedObject side of c8y where we know the device has just connected.
I have a microservice that listens for events in real time and I want to trigger a process once we know a device has connected to send its payload.
We have used:
"c8y_Connection": {"status":"CONNECTED"}
We have had the microservice log to Slack all events from managedObjects where we saw for three days the "status":"CONNECTED" value in the payload of our demo devices at reporting times.
But after three days, we see no more this "CONNECTED" state (all payloads showing "DISCONNECTED").
What I am trying to achieve from the inventoryObject event is to understand when a device had connected and sent payload to know when data had arrived. I then go get the data and process it externally. This is post registration and as part of the daily data send cycle for my type of device.
What would be the best way to understand when a device has sent payload in a microservice? I want to notify an external application with either “data is arriving for id 35213” or even better, “data has arrived for device 35213, and here’s the $payload”.
Just as a general information ahead:
The c8y_Connection fragment showing connected shows an active MQTT connection or an active long polling connection and it is only evaluated once every minute.
So if the client is just sending data and immediately disconnecting afterwards this might not picked up.
If you want to see the device having send something to Cumulocity maybe the c8y_Availability fragment is a better as it holds the timestamp when the device last send something.
{ "lastMessage": "2022-10-11T14:49:50.201+09:00", "status": "UNAVAILABLE"}
Also here the evaluation (or better the update to database) only happens every minute.
Both c8y_Availability and c8y_Connection however are only generated if the availability monitoring has been activated for the device (by defining a required interval for the device).
So if you have activated the availability monitoring and you see a "lastMessage" you can reliably say that the device has already send something to Cumulocity.
I play with nsqd a little bit and met the prob mentioned in the title. But when I send message via single nsqd, there is no such prob. Does this mean message should always be sent via same nsqd?
Here is my project. https://github.com/hoozecn/nsqd-cluster
It's resolved by set a higher MaxInFlight value.
ref: https://github.com/nsqio/nsq/issues/1213
I'm sending messages over GCM with TTL=15 - and they arrive just fine. Despite that fact, the developer console (where GCM messages can be tracked) show status=expired.
According to Google's docs, expired means:
Reached their time-to-live (TTL) and expired.
Am I doing something wrong? Perhaps I'm not acking the message on my Android app?
As Reference;
time_to_live: This parameter specifies how long (in seconds) the message should be
kept in GCM storage if the device is offline. The maximum time to live
supported is 4 weeks, and the default value is 4 weeks. For more
information, see Setting the lifespan of a message.
So 15 seconds are too short to track you may want to increase this value.
I want to use RabbitMQ to broadcast the state of an object continuously to any consumers which maybe listening. I want to set it up so when a consumer subscribes it will pick up the last available state...
Is this possible?
Use a custom last value cache exchange:
e.g.
https://github.com/squaremo/rabbitmq-lvc-plugin
Last value caching exchange:
This is a pretty simple implementation of a last value cache using RabbitMQ's pluggable exchange types feature.
The last value cache is intended to solve problems like the following: say I am using messaging to send notifications of some changing values to clients; now, when a new client connects, it won't know the value until it changes.
The last value exchange acts like a direct exchange (binding keys are compared for equality with routing keys); but, it also keeps track of the last value that was published with each routing key, and when a queue is bound, it automatically enqueues the last value for the binding key.
It is possible with the Recent History Custom Exchange. It says that it will put the last 20 messages in the queue, so if it configurable you may be able to change that to the last 1 message and you are done.
If that doesn't work, ie the number is fixed at 20, then you may have to process the first 19 messages off the queue and take the status from the 20th. This is a bit of an annoying work around but as you know the parameter is always 20 this should be fine.
Finally if this doesn't suit you perhaps you will set you consumer to wait until the first status is receive, presuming that the status is broadcast reasonably frequently. Once the first status is received then start the rest of the application. I am assuming here that you need the status before doing something else.
hi
I cannot see any explanation of the implementation of the collapse_key.
I think i understand what it does but not how it do it!
Android Cloud to Device Messaging Framework
I have a C2DM framework set up and sending 4 types of messages to many phones.
String messages very basic looks kind of like this:
type:name:uuid
type:name:uuid:number
type:uuid:id
If the phone is off many of this can get piled up waiting for phone on-line.
as far as i can tell my system works but what will the collapse_key do for me here?
addEncodedParameter(sb, "collapse_key", "no_ide_what_to_put_here");
You mentioned retrying the same message 3 times and using the same key value. It doesn't really have to be the same message. If you've got a message that indicates the current price of a stock, for instance, and you really only care about the latest price, then you could send different messages with the same key. When the device comes back online, it only gets the latest price quote message.
This may have been what you were saying already, but wanted to make it clear it's not only for "retrying sending same message".
I found this text: “collapse key” used for overriding old messages with the same key on the Google C2DM servers" I think if im retrying sending same message 3 times I must use same key value right. Google cloud server will send the latest msg with the same key value
...but be aware of the following (from http://code.google.com/intl/sv-SE/android/c2dm/):
"Note that since there is no guarantee of the order in which messages get sent, the "last" message may not actually be the last message sent by the application server."
But maybe this is not an issue if you don't generate a lot of messages.