I have followed rest API(linked below) tutorial to get all the device registrations of push notifications in MFP. But I am getting maximum size of 5000 records, but I need all the device registrations. Kindly help me.
restapi_push_device_registrations_get
There is no way to get all the device registration records in a single REST call as 5000 is the maximum limit.
However you can achieve this using offset and size parameter of Mobilefirst Push Device Registrations (GET) Endpoint.
Pass size as 5000 and offset as 0 returns first 5000 device registration records
Pass size as 5000 and offset as 5000 returns next 5000 device registration
records.
Related
I have an Openstack Aodh alarm and it will start the action when the memory usage is greater than 85% for one minute. Now I would like to trigger the action immediately, manually, which means force the alarm action start even though the condition doesn't reach the limits, but how?
According to the docs, I've tried to set the state of Aodh alarm to alarm, but it didn't work, it evaluated the memory usage and do nothing(cause its less than 85%), then set the state back to ok again.
Are there any ways to force trigger Aodh alarm action? I would appreciate any help.
Here are the parts of my Aodh alarm:
aggregation_method: mean
alarm_actions: [u'trust+http://192.168.0.100:8004/v1/284e047522bd4adfa3aa5109f1c7513b/stacks/corey_test/d9915fd3-5086-4d38-971b-2694c41e8099/resources/rdgw_scaleup_policy/signal']
alarm_id: e6402673-9a8e-4745-a8df-699edd6ab57a
comparison_operator: gt
enabled: True
evaluation_periods: 1
granularity: 60
metric: memory_util
ok_actions: []
repeat_actions: True
resource_type: instance
severity: low
state: ok
state_reason: Transition to ok due to 1 samples inside threshold, most recent: 11.0
threshold: 85.0
type: gnocchi_aggregation_by_resources_threshold
Update 2020/11/04
The only thing that comes into my mind is to reduce the threshold and evalution_periods temporarily (ex: threshold:1, periods:1), that will force the alarm start scaling, after the new instance is created, recover the threshold and evalution_periods values back. It works but I don't think that is the best method.
The alarm actions are AFAIU just HTTP POSTs to the URLs listed in 'alarm_actions', so you can do it yourself (provided you have access to that URL).
In your particular case it is clearly a Heat stack scaling action. You should be able to make a HTTP POST to appropriately similar URL - replace trust+https://<host>:<port> part with public Heat endpoint (openstack catalog show orchestration) and add a valid Keystone token to the request header.
Alternatively, for Heat stack scaling you can use use the openstack stack resource signal command (that does effectively the same REST call, just helps you with auth and endpoint discovery) - the stack ID and the resource name are visible in the URL, so in your case it will be openstack stack resource signal d9915fd3-5086-4d38-971b-2694c41e8099 rdgw_scaleup_policy
I have a service bus trigger in an Azure function app which reads the messages ( which are in Json format) coming from the subscription. I would like to know if there is a way to limit the number of request processed by Service bus. So for example if my service bus get triggered and it has 20 messages to be processed, I would like only the first 10 to be processed and then next 10. How can I achieve that?
I am asking this because I am doing some manipulation with the received messages, first i creating a list of the information and running some sql query over it in C# and would prefer my code to NOT handle all the messages at once.
you can configure this in the host.json. Here's the documentation:
learn.microsoft.com
Just add this "maxConcurrentCalls": 10 to the messageHandlerOptions, then it will just process 10 messages simultaneously.
I am working on a flutter app that fetches 341 documents from the firestore, after 2 days of analysis I found out that my read requests are increasing too much. So I made a chart on the stackdriver metrics explorer from which I get to know that my app is just reading 341 docs a single time, it's the firebase console which is increasing my reads.
Now, comes to what are the questions that are bothering me,
1)How reads are considered when we see data on the console and how can I reduce my read requests? Basically there are 341 docs but it is showing more than 600 reads whenever I refresh my console.
2)As you can see in the picture there are two types of document reads 'LOOKUP' and 'QUERY', what's the exact difference between them?
3)I am getting data from the firestore with a single instance and when I open my app the chart shows 1 active client which is cool but in the next 5 minutes, the number of active clients starts to increase.
Can anybody please explain to me why this is happening?
For the last question, I tried to disable all the service accounts and then again opened my app but got the same thing again.
Firestore.instance.collection("Lectures").snapshots(includeMetadataChanges: true).listen((d){
print(d.metadata.isFromCache);//prints false everytime
print(d.documents.length);// 341
print(d.documentChanges.length);//341
});
This is the snippet I am using. When the app starts it runs only once.
I will try to answer your questions:
How reads are considered when we see data on the console and how can I
reduce my read requests? Basically there are 341 docs but it is
showing more than 600 reads whenever I refresh my console.
Reads are considered depending on your how you query your Firestore database in addition to your access to this database from the console so using of the Firebase console will incur reads and even if you leave the console open to do other stuff, when new changes to database occured these changes will incur reads also, automatically.and any document read from the server is going to be billed. It doesn't matter where the read came from. The console should be included in that.
Check this official documentation under the "Manage data" title you can see there is a note : "Note: Read, write, and delete operations performed in the console count towards your Cloud Firestore usage."
Saying that if you think there is an issue with this, you can contact Firebase support directly to have more detailed answers.
However, If you check the free plan of Firebase you can see that you have 50K free reads per day.
A workaround that I found for this (thanks to Dependar Sethi)
Bookmarking the Usage tab of the Firestore page. (So you basically
'Skip' the Data Tab)
Adding a dummy collection in a certain way that ensures it is the
first collection(alphabetically) which gets loaded by default on
the Firestore page.
you can find his full solution here.
Also, you can optimise your queries however you want to retreive only the data that you want using where() method and pagination with Firebase
As you can see in the picture there are two types of document reads
'LOOKUP' and 'QUERY', what's the exact difference between them?
I guess there are no important difference between them but "QUERY" is getting the actual data(when you call data() method) while "LOOKUP" is getting a reference of these data(without calling data() method).
I am getting data from the firestore with a single instance and when I
open my app the chart shows 1 active client which is cool but in the
next 5 minutes, the number of active clients starts to increase.
For this question, considering the metrics that you are choosing in Stackdriver I can see 3 connected clients. and as per the decription of "connected client" metric:
The number of active connections. Each mobile client will have one connection. Each listener in admin SDK will be one connection. Sampled every 60 seconds. After sampling, data is not visible for up to 240 seconds.
So please check: how many mobiles are connected to this instance and how many listeners do you have in your app. The sum of all of them is the actual number of connected clients that you are seeing in Stackdriver.
I am using realm.js 2.3.3 with node.js app for storing latest state of iot devices.
At present I have 3 schemas (10 columns each - all numbers and booleans ) each with 1 row / device. We have around 1600 devices live and they send data every second. At max 200 devices are online at any given time.
I always keep realm in write mode by calling beginTransaction at start of the app and then every second I call commitTransaction to flush the latest state to disk followed by beginTransaction. This also ensures that realm is always in write mode. I never call compact as it freezes the entire app for some time.
In all there are close to 5000 rows which should be around 1MB of data (verified by calling compact). But the realm file has grown to 290 MB in 2 days.
How can I keep the file size realistic?
I want to programatically send SMS / text messages from my Meteor app; many people recommend twilio for this, and there are several Meteor Twilio packages (findable via atmosphere and/or googling/binging). I don't know if one of these packages is decidedly better than the other, but for now, at least, I'm using the abhiaayer:meteor-twilio package.
My concern is that, when you create a Twilio account, they assign you a "from" phone number (you can't, apparently, just use your own). Maybe I'm misunderstanding how this works, but before I go too far down this path, I want to know if the sender of the SMS -- IOW the user of my app -- will be able to use their phone number as the "from"/sender phone number.
After all, the whole point of my app is to allow the user to send out multiple identical texts (such as "where are you?" or "are you okay?") to friends/family, and then get a response back from them (to his phone, not to a Twilio-supplied number).
If it's possible to use Twilio with your own phone number as the "from"/sending number, has anyone got suggestions on Meteor package preferences (abhiaayer, andreioprisan, DispatchMe) and how that can be accomplished from Meteor?
I imagine the basic code would be pretty much the same, regardless of package used; e.g., here's an example from the andreioprisan package
twilio = Twilio(ACCOUNT_SID, AUTH_TOKEN);
twilio.sendSms({
to:'+16515556677', // Any number Twilio can deliver to
from: '+14506667788', // A number you bought from Twilio and can use for outbound communication
body: 'word to your mother.' // body of the SMS message
}, function(err, responseData) { //this function is executed when a response is received from Twilio
if (!err) { // "err" is an error received during the request, if any
// "responseData" is a JavaScript object containing data received from Twilio.
// A sample response from sending an SMS message is here (click "JSON" to see how the data appears in JavaScript):
// http://www.twilio.com/docs/api/rest/sending-sms#example-1
console.log(responseData.from); // outputs "+14506667788"
console.log(responseData.body); // outputs "word to your mother."
}
});
I did create a Twilio account, and have the "from" number (not my actual cell phone number) they assigned my account, and the SID, but I don't kow what the AUTH_TOKEN should be.
If what I intend is not possible from Twilio, what I may do is just write the app so that all the selected "to" numbers can be copied to the clipboard, so that the user can paste them into his SMS screen's "recipients" textbox; but I was hoping to afford the user the luxury of simply tapping a button.
I don't think you can do this (send from the user's own cell number using Twilio). If your app is an actual mobile app as opposed to a web app you can use the Android or iOS APIs for sending SMS from the user's phone. I'm not sure of the details of this and certainly with iOS it looks like you can't do so fully automatically for obvious reasons (you could just spam all the user's contacts for instance, and this would incur a monetary cost to the user).
There's a Cordova plugin here which can do what you want: https://github.com/cordova-sms/cordova-sms-plugin (I haven't used it so can't vouch for it but it seems to be actively maintained).
If it is a web app, your suggesting of copying the numbers to clipboard is by far the most straightforward solution and I would recommend that in the first instance. For completeness I've included some details and considerations below of how you can do 2-way communication with Twilio (or alternatives such as Nexmo) in a couple of ways, in case someone finds it helpful. It's not exactly trivial though. 1-way communication is a lot easier!
Send via API
From your app the user types a message and selects who to send it to. You app then connects to your server which uses the Twilio API to send N messages to the N recipients. These messages will appear to come from the Twilio-provided number.
Send via SMS
The user manually sends an SMS to your Twilio number and then you receive a webhook to your server from Twilio with the message details. You have to do the processing to work out who to forward the message to and then use the Twilio API to do so. Again the recipients will see a message from the Twilio-provided number.
Replies
When a recipient replies to the message, Twilio sends you a webhook with the details and you can determine who sent the original message and forward the reply back to the original sender.
Number Pooling
One of the obvious flaws here is that if multiple users send a message to the same person then there's no way of telling which message they are replying to. There's no message IDs passed with SMS so you have to use multiple sending numbers (one per unique sender to a particular recipient). The amount of numbers required is basically the most number of different senders one user would have to reply to (this is not generally possible to work out beforehand, so you would have to call the API to provision a new number on the fly).
To give a more concrete example say you have 2 users (S1 & S2) and 3 recipients (R1, R2 & R3). You have 1 Twilio-provided number (N1).
S1 sends a message to R1 via your app, you use N1 to send the message via the Twilio API. R1 receives the message from N1. If they reply, you receive a message to N1 from R1 so you know you need to forward it to S1.
S1 sends a message to R2 via your app, R2 has not yet received any messages so you can reuse N1 to send the message. R2 replies to N1 and again you can forward it to S1. If this is delivered in-app, no further problems, if the reply is forwarded via SMS then we'd need to provision a new number (N2) to enable S1 to reply to R2's reply.
S2 sends a message to R3 via your app, as before you can reuse N1 and still route the reply correctly.
Now if S2 sends a message to R1, we realise that R1 has already received messages from S1 using number N1. In this case we can't use N1 because we cannot identify who the reply was intended for. If we haven't already, we need to provision a new number (N2) and now we can send the message so R1. When R1 replies to N2 we know the reply needs to be forwarded to S2.
The more users sending to one recipient, the bigger (and more expensive) your number pool gets. It's probably worth implementing some kind of timeout (say 72 hours) in which the recipient can reply. So in this case if the timeout had expired after S1 sent the message to R1 via N1, we could reuse N1 for the communication between S2 and R1. Obviously this isn't entirely foolproof but it could reduce costs.
Identity
The other issue with sending from a pooled number. I send a message to Dan via an app, and he receives that message from a random number:
Hi Dan, how are you?
How does Dan know who sent the message? You'd have to add some identifier to every message (or at least the first in each conversation thread).