I have a use case where the update of an AWS GreenGrass v2 component can not be done unless the device is in a certain state.
This state is external to the GreenGrass runtime, but is obviously accessible.
My question is:
How can fetching a job, to be executed on a device, be delayed? or;
How can a job be fetched when a certain condition is satisfied?
We have a fleet of devices that will be in various states.
I'm looking at this as well. I don't have a specific answer yet, but I think the intention is that you configure your deployment to notify the application before running the deployment on each thing. The application then listens for the notifications and responds back whether to defer the deployment or proceed. https://docs.aws.amazon.com/greengrass/v2/developerguide/ipc-component-lifecycle.html#ipc-operation-subscribetocomponentupdates
Related
We are following the theory that as users we must issue a command to the Context Broker to change the state of a device: Image 1
In our case, this command already works if we do it from the IoT Agent, but however, if we execute it from the Context Broker through a PATCH, it does not reach the IoT Agent.
Do you know why this could be happening?
Our Context Broker request is the following: Image 2
And finally, the request we make from the IoT Agent, which is the one that works, is this: Image 3
Another doubt that arises is, if the IoT Agent updates all the information in the Context Broker, why not execute the request from there instead of from the Contex Broker?
Your request to Context Broker seems to be ok. Sometimes, the lack of ?type in the request causes problems (see for instance this post) but it doesn't seem to be your case.
I'd suggest to check registrations at Orion. Registration is the mechanism in which the request forwarding from Orion to IOTAgent is based (more info in Orion documentation. IOTAgent should create and manage them, but something could be failing. You can get existing registrations in Orion with the GET /v2/registrations operation.
With regards:
Another doubt that arises is, if the IoT Agent updates all the information in the Context Broker, why not execute the request from there instead of from the Contex Broker?
The FIWARE data management model is context-centric. Thus, the Context Broker is the central piece of the architecture, to intermediate between context producer and context consumer. Commands are a kind of "context production", so it makes sense that Context Broker deals with commands. Note that the client issuing the command maybe doesn't even are able to access to the IOTAgent directly (they use to be "close" to the physical devices they manage and not typically open to direct client requests).
I have a few question about the remote deployment of functions as shown the diagram:
If have remote statefun functions (multiple instance with the Undertow as shown in the examples fronted by api gateway):
Do we need to configure the api gateway to send calls with same url to the same backend hosting the function or does the frame work take care of it ?
From my understanding each function is keeping local state. If one instance is relocated, or we scale the functions, how does the local state get redistributed ?
If there is any documentation, on this, please let me know.
Thanks.
The functions are stateless. All of the state they need in order to respond to an invocation is included in the message, and the response will include any updates to the state that are needed. Because they are stateless there's no need to worry about sessions or instance affinity or rescaling for remote functions.
The developers have given talks that get into some of these details. I'll suggest a talk by Tzu-Li (Gordon) Tai, Stateful Functions: Polyglot Event-Driven Functions for Stateful Distributed Applications.
I'm trying to figure out how to create an offline / online approch to use within a huge application.
Right now, each part of the application has its own model and datalayer, who directly read / write data from / to SQL. My boss is asking me to create a kind of buffer that, in case of connectivity failure, might be used to store data until the connection to SQL return active.
What I'm trying to create is something like this: move all datalayers into a servicestack service. Each "GET" method should query the database and store the result into a cache to be reused once the connection to SQL is not available. Each "POST" and "PUT" method must execute their actions or store the request into a cache if the connection fail. this cache must be cleared once the connection to SQL is restored.
How can I achieve this? Mine is a WPF application running on Windows 10.
Best regards
Enrico
Maintaining caches on the server is not going to help create an offline Application given the client wouldn't have access to the server in order to retrieve those caches. What you'd need instead is to maintain state on the client so in the event that network access is lost the client is loading from its own local caches.
Architecturally this is easiest achieved with a Web App using a Single Page App framework like Vue (+ Vuex) or React (+ Redux or MobX). The ServiceStack TechStacks and Gistlyn Apps are good (well documented) examples of this where they store client state in a Vuex store (for TechStacks created in Vue) or Redux Store (for Gistlyn created in React), or the Old TechStacks (created with AngularJS).
For good examples of this checkout Gistlyn's snapshots feature where the entire client state can be restored from a single serialized JSON object or approach used the Real Time Network Traveler example where an initial client state and delta's can be serialized across the network to enable real-time remote control of multiple connected clients.
They weren't developed with offline in mind, but their architecture naturally leads to being offline capable, courtesy of each page being first loaded from its local store then it fires off a Request to update its local cache which thanks to the reactivity of JS SPA fx's, the page is automatically updated with the latest version of the server.
Messaging APIs
HTTP has synchronous tight coupling which isn't ideal for offline communication, what you want instead is to design your write APIs so they're One Way/Asynchronous so you can implement a message queue on the client which queues up Request DTOs and sends them reliably to the server by resending them (using an exponential backoff) until the succeed without error. Then for cases where the client needs to be notified that their request has been processed they can either be done via Server Events or via the client long-polling the server checking to see if their request has been processed.
Couple of questions:
I have list of components on the client app which has some near real time info e.g. status, which I want to display.
I have server app, which can pull the status info from a third party REST endpoint.
My question is, should I cycle through all the components in the client app and request the server app for the status?
Or should I have a server worker thread, which pulls the status info and publishes on the websocket, which the client can then update the state of the component.
Or is there background thread which I can run on the client app, which will update the status and the state. How will this conflict with the dispatch/queuing of events from user interactions.
I think I might be asking some of the architectural questions and the answers might be "it depends" ambiguous, but anyone who has done this before and any guidance is appreciated.
Thanks, Rajesh
It depends :) But it's safe to go with server-side approach since with client-side you would have to deal with CORS and cross-domain ajax calls in general. Most of the 3rd party API do not allow to make arbitrary AJAX calls from other domains. Those that do allow that usually have API quota which is again easier to manage since you can keep your keys secret on the server and throttle and cache requests.
Server side approach requires more effort though. So it's a prototype and 3rd party API allows cross-domain requests – go for it, it's easier, for production app, consider doing this on the server.
For client-side approach if 3rd party API doesn't offer subscriptions, yes you would have to poll, but you don't have to cycle through components. You can abstract this polling in one, root component and then just pass props down.
You are right, the answer is "it depends".
Basically, you have two options:
Poll the server for the current status.
I believe you do not have to cycle through all the components and query their status. You could just have an API that provides the server the timestamp when you last queried the status, and the server will respond with just the information that has changed since the last query.
This is simple and will work fine if the updates are not huge, and you can afford to be a little late.
You could have a dedicated websocket connection with the server
In this case, the server will push any new updates to your front-end whenever any new update is available. This is a little cumbersome to implement, but is the right approach if the updates are near real-time.
To answer your question about having a background-thread on the front-end: no, you cannot have background-threads on the front-end. Javascript doesn't work that way. What you do have are callbacks. Whenever the server pushes you any new information, a callback, that you define, will be called and you can do whatever UI changes you need from here.
My question is, should I cycle through all the components in the client app and request the server app for the status?
No, this sounds very inefficient to me.
However, if you decide to poll from the client, it should be done only from a single component that is parent to all children that need the information. The parent then passes its state to the children and they update on each poll.
Or should I have a server worker thread, which pulls the status info and publishes on the websocket, which the client can then update the state of the component.
Absolutely. Let this socket be in your top-level application component which holds the real-time info in its state and passes down to its children. Whenever information gets published to the socket, update the top-level application state with the new real-time info and all children will rerender displaying the most current information.
I want to send a particular HTTP request (or otherwise communicate a message) to every (dynamic/autoscaled) instance which is currently running for a particular App Engine application.
My goal is to trigger each instance to discard some locally cached data (because I have just modified the underlying data and want them to reload it).
One possible solution is to store a value in Memcache, and have instances check this each time they handle a request to see if they should flush their cache. But this adds latency to every request.
Another possible solution would be to somehow stop all running instances. No fixed overhead, but some impact while instances are restarted.
An even less desirable solution would be to redeploy the application code in order to cause all instances to be stopped. This now adds additional delay on my end as a deployment takes some time.
You could use the management API to list instances for a given version, but I'd suggest that you'd probably want to use something like the PubSub API to create a subscription on each of your App Engine instances. Since each instance has its own subscription, any messages sent to the monitored queue will be received by all instances.
You can create the subscription at startup (the /_ah/start endpoint may be useful), and then delete it at shutdown (using the /_ah/stop endpoint).