I'm running a state file and an orchestrator inside a reactor, I'd like to know if it's possible to delay the orchestrator to make sure it runs after the first state file has finished?
change your reactor so it isn't calling both. instead have it call a different orchestration. that first calls the state then calls the fist orchestration that will use require on the first state.
as for the question, no reactor will just fire off everything all at once. it is best to do fine grain control over actions in an orchestration.
Related
I'm just getting started with Meteor and I have a REST API hooked up with publish / subscribe that can periodically update per client. How do I run this behavior once globally and only refresh as long as a client is connected?
My first use case is periodically refreshing content while clients are active. My second use case is having some kind of global lock to make sure a task is only happening once at a time. I'm trying to use Meteor to make a deployment UI and I only want 1 deployment to happen at once.
publish/subscribe will work automatically only when clients are connected. However, do not put any functionality that you want to control amount of execution times in publish or subscribe functions. They might run arbitrary amount of times.
If you want some command to be executed by any client use Meteor.methodss on server side, and call it explicitly with Meteor.call from client template event.
To make sure that only one deployment happens at any given time, simplest way would be to create another collection, called for example, CurrentDeployments.And any time deployment script function in Meteor.methods is executed, check with CurrentDeployments.findOne if there are ongoing deployment or not, and only call new one if none is running.
As a side bonus, subscribe to CurrentDeployments in client, to disable 'deploy' button in case one is already running.
New to firebase and trying to understand how things work. I have an android app and plan to use the offline support and I'm trying to figure out whether or not I need to use callbacks. When I make a call like:
productNode.child("price").setValue(product.price)
Does that call to setValue happen synchronously on the main thread and the sync to the cloud happens asynchronously? Or does both execute asynchronously on a background thread?
The Firebase client immediately updates its local copy of the data with the new value. As part of this it fires any local (value, child_*) events that are needed.
Sending of the data to the database happens on a separate thread. If you want to know when this has completed, you can register a CompletionListener.
If the server somehow cannot complete the write operation (typically because the write violates a security rule), the client will fire any additional events that are needed to get the app back into the correct state. So in the case of a value listener it will then fire a second value event with the previous value.
How does this.unblock work in Meteor?
The docs say:
Call inside a method invocation. Allow subsequent method from this client to begin running in a new fiber.
On the server, methods from a given client run one at a time. The N+1th invocation from a client won't start until the Nth invocation returns. However, you can change this by calling this.unblock. This will allow the N+1th invocation to start running in a new fiber.
How can new code start running in a new fiber if Node runs in a single thread? Does it only unblock when we get to an I/O request, but no unblock would happen if we were running a long computation?
Fibers are an abstraction layer on top of Node's Event Loop. They change how we write code to interact with the Event Loop, but they do not change how Node works. Meteor, among other things, is sort of an API to Fibers.
Each client request in Meteor creates a new fiber. Meteor methods called by the client, by default, will queue up behind each other. This is the default behavior likely because there is an assumption that you want Mongo up to date for all clients before continuing execution. However, if you do not need your clients to work with the latest up to date globals or data, you can use this.unblock() to put each of these client requests in Node's Event Loop without waiting for the previous to complete. However, we are still constrained to Node's Event Loop.
So this.unblock() works by allowing all client requests to that method enter the Event Loop (non IO blocking execution based on callbacks). However, as Node is still a single threaded application, CPU intensive operations will block the callbacks in the Event Loop. That is why Node is not a good choice for CPU intensive work, and that doesn't change with Meteor or Meteor's interaction with Fibers/the Event Loop.
A simple analogy: The Event Loop, or our single Node thread, is a highway. Each car on the highway is a complex event driven function that will eventually exit off the highway when its callbacks complete. Fibers allow us to more easily control who gets on the highway and when. Meteor methods allow a single car on the highway at a time by default, but when properly using this.unblock() you allow multiple cars on the highway. However, a CPU intensive operation on any fiber will cause a traffic jam. I/O and network will not.
Kind of an open question that I run into once in a while -- if you have an EJB stateful or stateless bean, or possibly a direct servlet process, that may with the wrong parameters start running long on a production system, how could you effectively add in a manual 'kill switch' for an administrator/person to specifically kill that thread/process?
You can't, or at least you shouldn't, interfere with application server threads directly. So a "kill switch" look definitively inappropriate to me in a Java EE environment.
I do however understand the problem you have, but would rather suggest to take an asynchronous approach where you split you job in smaller work unit.
I did that using EJB Timers and was happy with the result: An initial timer is created for the first work unit. When the app. server executes the timer, it then register as second one that correspond to the 2nd work unit, etc. Information can be passed form one work unit to the other because EJB Timers support the storage of custom information. Also, timer execution and registration is transactional, which is fine to work with database. You can even shutdown and restart the application sever with this approach. Before each work unit ran, we checked in database if the job had been canceled in the meantime.
I have an ASP.Net application that needs needs to have some work performed by another machine. To do this I am leaving a message on queue visible to both machines. When the work is done a message is left on second queue.
I need the ASP.Net application to check the second queue periodically to see if any of the tasks are complete.
Where is the best place to but such a loop? Global.asax?
I remember reading somewhere that you can get a function called after an interval. Would that be suitable?
To achieve periodical tasks on asp.net, I've found two acceptable approaches:
Spawn a thread during Application_Start at global.asax, in a while loop (1) Do the work (2) Sleep the thread for an interval.
Again in Application_Start, insert a dummy item into asp.net cache, expires in a certain interval and give that cache item a callback to be called when it's expired. In that callback, you can do the work and insert the cache item back the same way.
In both ways, you need to make sure that your thread keeps working even if there happens an error. You may place a restore code in SessionStart and BeginRequest to check your thread or cache item is there, and renew it if something has happened to it.
I assume that this is done on a regular basis, and that some other process puts the items on the queue?
If that is the case, you might put something in Global.asax that on application start creates a separate thread that simply monitors the queue, you could use a timer to have that thread sleep for X seconds, then check for results.