looks like heroku is using uppercase for the port system property, so please change the code here (https://gist.github.com/ajay-gov/408ab8fbc252419f8a481f2231ecf677#file-myserverloader-L110) to use "PORT" instead of "port"
it always autodetects the buildpack, and autogenerates a command, regardless if you soecify a procfil
it seems that you can override this by setting a config variable GRADLE_TASK. So can you try setting this in the config var to the following and give it a try:
heroku config:set GRADLE_TASK="run -Dport=$PORT"
We are basing this on what we read here: https://devcenter.heroku.com/articles/deploying-gradle-apps-on-heroku#the-procfile
heroku config:set GRADLE_TASK="run -Dport=$PORT"
We are basing this on what we read here: https://devcenter.heroku.com/articles/deploying-gradle-apps-on-heroku#the-procfile
@tlecouffe Hi Tyler, we're currently in the process of updating our Azure IoT offering in the Marketplace with a new example app and lots of documentation around it however we are still working through the azure approval process. That said, i would love you pass you over a link and hopefully get a bit of feedback from you on it. Can you pass along your email either here or emails us at developers@swim.ai and i will pass along the link to you? I think you will find the updates and new documentation to be much more helpful and i look forward to hearing what you think. As always, we are here to answer any questions you have.
Thanks! I'm at Tyler@inventedinteractive.com
@cvsekhar I'm not the best person to answer, so @scottswim @ajay-gov or anyone else please chime in. It's certainly possible to run only one Web Agent per Docker image (and it would work just fine). I'd only recommend that as an architecture decision if it was to keep uniform deployment across a larger application, or in other words, for the sake of simplicity. Otherwise that's probably a bit more infrastructure than is necessary.
@cvsekhar Here's an example greenhouse app that @scottswim built which uses Docker, which may be a helpful reference: https://github.com/swimos/greenhouse
@johnson_brad_twitter Yes its a purely architectural decision, when we introduce smartness into those agents like the traditional Agents as discussed in peter norvig book and we have so many agents acting on behalf of real things what is the thin line of deploying these apps is where I am getting lost.
@cvsekhar In general, having more web agents is the right pattern. Web agents guarantee single threaded access and having just one web agent means that all requests will go through that web agent which ends up as a bottle neck. On the contrary having multiple web agents means that different threads can process the requests to the different web agents in parallel which scales really well. Also having one or more web agents is a design decision which should be made independent of how you package the swim application (i.e. docker image or deb package etc.)
we can have these deployed as individual docker images for each thermostat or we can have them in one docker image representing all the thermostats. but when we introduce the smartness into these agents like depending on the values it receives and we need to take action based on some intelligent decision is where I am getting lost wether to represent each thermostat as a docker image or single a docker image handling all those thermostat represented by a webagent and driven by an id
you can use one docker image and set up multiple thermostat web agents and not incur the network cost. There is no extra work in writing code. Each Thermostat Web Agent will have a different id and will get instantiated dynamically as a message is sent to that URI (eg: /thermostat/1 or /thermostat/2)
Having one docker image with all the thermostat web agents also reduces the overhead of managing multiple images since you just have one
I was just wondering if the plane that the unit agents are on are subject to commands in
Commands that come from a command lane *
@Codeseys You can think of the plane as the container that holds Web Agents. You can send commands to a command lane in a Web Agent which gets routed through the plane. So a plane is analogous to a http server in that respect. In the REST world, you would make POST requests to a particular end-point which gets routed via the http server.
I have a parallel processing problem that I think might be ideal for Swim, but could use some pointers/advice. Each individual unit of work requires processing multiple (1-20) input packets that arrive over time, but are easily correlated by a unique Id. Processing consists of three distinct stages: A, B, and C – my thinking thus far would be that these would be three WebAgents. The “A” stage fills in “Lanes” as the complete set of input packets arrive. Sorry, but it gets more complex here. Stage “B” always occurs, but depending on the type of input data it may need to wait for all the input packets to Stage A to complete, or it can start processing right away. I think a Swim Plane allows for this, but confirmation would be appreciated. Finally, Stage “C” logically extends Stage “B” but only happens under certain data conditions. Thus, Stage “C” adds additional ‘lanes’ for certain types of data. Can this be accommodated? The final results need to be “egressed” to another system. I believe this is a decent fit for the Swim architecture; however my real questions concern scale: the process described is per installation. If this is installed in several hundred locations, then there will be WIDE variance in throughput/bandwidth required. Location 1, might require minimal usage/throughput as it is not heavily used. Location 2 may be just the opposite and require multiple instances of the various WebAgents to keep up with incoming processing. Are there descriptions/pointers/examples as to how Swim scales this way?
First off, yes this is a perfect situation to use Swim. For Stage A, i would create a webagent per unique ID. Stage B would be a single webagent which collects the incoming data to a lane and each time data arrives it would decide what to do based on the data it has as well as what arrived. That logic would happen on the the didSet or didUpdate, depending on what kind of lane you are using. From there, the lane in Stage B can populate Stage C and likeway Stage C would have logic in its didSet/didUpdate which decides what it need to do each time the lane gets data. The Swim Plane itself is mostly used to define the routing to all the various webagents which make up the application. We also use the swim plane to kick off any other tasks or processes which need to happen sich as importing CSV data or triggering a webagent to startup. I think our greenhouse demo may be a good example for you to start with as its a single app which is distrubuted across multiple devices and has lanes which talk to other lanes based on sensor data coming into the webagents. You can find the full source and documentation for that example here: https://github.com/swimos/greenhouse
Please feel free to reach out to us when/if you have questions or problems. We are happy to help out.
We also have lots of documentation on swim itself. That can be found at https://developer.swim.ai/, https://docs.swimos.org/java/latest/index.html, https://docs.swimos.org/js/latest/index.html and inside the tutorials on github at https://github.com/swimos
@blackduck-joe In general Swim scales better when the processing is distributed across multiple Web Agents. Web Agents are created for every unique URI i.e when you access /stageA/1, /stageA/2 etc. In your specific case, you will have a Swim Plane per device each of which is running the same application. Each installation can be configured with appropriate memory based on the load requirements.
For example: In Location1 which has minimal usage/throughput you can give the Application low memory (and create few Web agents). In Location 2 which has a high load, give the Application a lot of memory (and create a lot of Web Agents). You can alter the memory settings when you deploy the application. For instance:
For example: In Location1 which has minimal usage/throughput you can give the Application low memory (and create few Web agents). In Location 2 which has a high load, give the Application a lot of memory (and create a lot of Web Agents). You can alter the memory settings when you deploy the application. For instance:
java -Xmx 128M... for Location1 and java -Xmx 2G... for Location 2
@Codeseys Maybe you know this but I just want to make sure -The Web Agent class that you write is just a definition of the code associated with it. Web Agents are instantiated when you invoke the uri associated with it. So if you have a URI pattern
/myagent/:id for a type MyAgent, invoking /myagent/1 will create a new instance of the MyAgent type. So when you say "start on run", I am assuming that you want to start a particular instance of the web agent. You can do so by sending a command to that Web Agent. Here is an example: https://github.com/swimos/cookbook/blob/master/web_agents/src/main/java/swim/basic/BasicPlane.java#L38
So you could do this when you start the
Plane in the main method. Currently this is the only way to do it. In our next release you will be able to instantiate new Web Agents with know URIs by adding it in the recon file where you define the plane
Regarding your question about a stock simulator or a 3d open-world online game- these are really good use cases for swim. You just model web agents appropriately for these applications. For the stock simulator, each Stock could be a Web Agent and you could add lanes in Stock Web Agent to store bids from investors. Based on the bid received the stock price (which will be a lane) can fluctuate. Each investor could be a Web Agent as well where you can track their bids , order history and holdings.
thanks
ill look into it
newbie question about authentication with swim
i wish to use swim for financial app that have to scale up. I decided to start with authentication but i cannot figure out what cookbook or tutorial will help me to start with code. any help from SWIM team will be appreciated. A simple app with login password (maybe connected with Okta or so on) will be perfect for me
Hi @dsissoko, authenticating messages to and from a Swim server is nontrivial in its current form, involving code snippets that require more than an API-level understanding of Swim. While this has capabilities involving GoogleID and OpenID authenticators, we wish to simplify its usage so that it can be configured cleanly within server.recon itself. We'll add a tutorial on this once it is complete.
The high-level overview involves defining a swim.api.policy.PolicyDirective. The swim.api.auth.Authenticator interface serves as a convenient wrapper around this, and it has two implementers, swim.auth.GoogleIdAuthenticator and swim.auth.OpenIdAuthenticator. Instances of these can be injected into a Plane via swim.api.plane.PlaneContext.addAuthenticator().
That said, I recommend continuing building your app without the authentication piece, since adding it will be a simple addition to server.recon once the core is updated.