I am asking this for local cluster.
Here is the code for getting the address and the name of the worker:
def f():
worker = get_worker().name
return worker
client.run(f)
Output:
{'tcp://127.0.0.1:58709': 0,
'tcp://127.0.0.1:58710': 2,
'tcp://127.0.0.1:58711': 1}
It is in the dictionary. The key is the address and the value is the name of the worker. is there any way to assign the worker's name while creating the client? or any way around.
just changing the dictionary value doesn't change the original of the worker.
My motivation behind this:
*My goal is to create a worker and assign the preprocessing task to that. After the create two models let's say logistic reg and random forest classifier.
and Now I want to scale up the worker using the scale method. and assign the model training for two models on two new workers.
But the thing is how will I identify which worker is the new worker? Because the worker name is like worker_0, worker_1, worker_2. Is the new worker which is created either worker_0 or worker_1? How do identify the new worker name?
I do believe that new worker names are in an incremental fashion.
But I need proof to validate my reason. That's why I thought It better to change the name. So that I can keep track of the worker more easily.*
Reference for the original question: How to get the worker name in dask cluster?
I'm afraid the current implementation of LocalCluster does not allow you to set the name via the constructor. You could propose a change to the codebase via a PR.
It raises the question, what do you wish to achieve with the names? You already have both a unique sequence number (the current .name) and unique UUID-based ID for every worker, as well as the workers' unique TCP addresses.
Finally - and this is untested - you could plausibly use client.run together with get_worker() to set the .name attribute dynamically at runtime, should you wish. The following would set the name attribute for the specific worker (as a TCP address) given in the workers= list.
def set_name(name):
get_worker().name = name
client.run(set_name, "name1", workers=[..])
-EDIT-
After providing motivation, I believe this question is not actually asking what you want - maybe make a new a new question. Perhaps clinet.who_has is what you want, but your workflow isn't clear to me.
Related
I have a simple BPMN flow where on instantiation a human task gets created. I need the ability to cancel / delete the human task whilst the process instance is active and the workflow moves to the next logical step. See attached proccess
I am considering using an interrupting boundary event with a dynamic message name so that I am sure of only cancelling the specific task. I am trying to have a general pattern for cancelling only the specific task (identified by the task ID, for example). Hence, I would like use the ID of the task in the message name of boundary event. Is that possible?
Otherwise, what would be the best approach for achieving the desired outcome of being able to cancel / delete a specific task?
I have also looked at this post but it doesnt address the specific query I have around dynamic naming
Have you tried to use "Process Instance Modification"? ->
https://docs.camunda.org/manual/latest/user-guide/process-engine/process-instance-modification/
IMHO you could cancel the specific task by ID and instantiate a new one after the transaction point of the User Task. When instantiating, you can pass to the new process the variables needed from the old process
You don't need to make the message name unique. Instead include a correlation criteria when you send the message, so the process engine can identify a unique receiver. The correlation criteria could be
the unique business key of the process instance
a unique (combination of) process data / correlation keys
the process instance id
https://docs.camunda.org/manual/latest/reference/rest/message/post-message/
In "RegisterCreatureEvent( entry, event, function )", it defines entry as "The ID of one or more Creatures". How do I go about specifying multiple creatures?
Edit: It was pointed out to me that creatures is plural because there can be more than one copy of a creature spawned in the world. You cannot specify multiple entries in RegisterCreatureEvent.
The library implements the id only as a number, so you cannot provide multiple ids in a table.
https://github.com/ElunaLuaEngine/Eluna/blob/8f5c4699b2531c408b615f55270541a7267c742b/GlobalMethods.h
You should try to use Creature familiy ids here.
http://elunaluaengine.github.io/Creature/GetCreatureFamily.html
CREATURE_FAMILY_VOIDWALKER can perhaps be used to register events for all voidwalkers.
But that's just a guess from reading the docs and some sourcode. I have no way to test this.
In my application there are already many nodes with different labels. We are passing property value at the time of creation. I wanted to have 2 properties for all the nodes by default (like creationDate and createdBy). Is there any possibility from configuration side that we can pass these property by default to all the nodes at the time of creation.
If by configuration, you only mean neo4j.conf, then no. You need some code to actually compute the value of the properties anyway: how do you represent the date, how do you determine who created the node?
To do that, you could deploy an extension in Neo4j to intercept the creation of nodes through transaction events by implementing a TransactionEventHandler: you'll get the TransactionData which directly exposes the nodes that were created, on which you can then set the audit properties you want.
The handler is registered through GraphDatabaseService, which can be obtained at startup by implementing PluginLifecycle and exposing the implementation via the Service Locator mechanism (put the class name in META-INF/services/org.neo4j.server.plugins.PluginLifecycle).
https://facebook.github.io/relay/graphql/objectidentification.htm is very clear around what Node is and how it behaves, but it doesn't specify which objects must implement it, or what the consequences are if your object doesn't implement it. Is there a set of features that don't work? Are such objects completely ignored? Not all objects in the existing spec (e.g. pageInfo) implement it, so it's clearly not universally required, but pageInfo is somewhat of a special case.
Another way of thinking about the Node interface is that objects that implement it are refetchable. Refetchability effectively means that an object has an ID that I can use to identify the object and retrieve it; by convention, these IDs will usually be opaque, but will contain type information and an identifier within that type (eg. a Base-64 encoding of a string like "Account:1234").
Relay will leverage refetchability in two ways:
Under a process known as "diffing", if you already have some data for an object identified by ID QWNjb3VudDoxMjM0 (say, the name and address fields), and you then navigate to a view where we show some additional fields (location, createdAt) then Relay can make a minimal query that "refetches" the node but only requests the missing fields.
Relatedly, Relay will diff connections and will make use of the Node interface to fill in missing data on those (example: through some combination of navigation you might have full information for some items in a view, but need to fill in location for some items within the range, or you might modify an item in a connection via a mutation). So, in basic pagination, Relay will often end up making a first + after query to extend a connection, but if you inspect its network traffic in a real app you will also see that it makes node queries for items within connections.
So yes, you're right that pageInfo doesn't implement Node, and it wouldn't really make sense for it to do so.
I ran into a problem which required me to have access to a bunch of variables which need to be changed every so often, so I made a Misc model and there is only ever one instance of it. This was my solution for having editable global variables.
It holds all types of stuff that didn't seem like they deserve their own models. Is this acceptable or does this violate some Rails-buliding principle I'm not aware of? It works, but I have doubts.
Is there a better alternative to this strategy (think fetching/editing (as an example) Misc.first.todays_specials).
If this is passable, then is there a way to prevent a creation of more than one item of a model in the database? The problem with the above approach as you can see is that if there are all of a sudden TWO entries for Misc, things will get wonky as it requests the .first under the assumption that there's ever only going to be one.
You can create a table for Settings storing key-value configs. It will be scalable and not depend on predefined keys. Also you won't have a table with one row this way.
If you need lots of read/writes you might also want to cache rails SQL Caching
you could use a singleton pattern.
a singleton class is a class that can only have one instance.
so you could do something like this:
initializers/config.rb
require 'singleton'
class MyConfig
include Singleton
attr_accessor :config1
def initialize
self.config1 = ["hello", "world"]
end
end
and use it in this way:
MyConfig.instance.config1
You can also consider global variables. Global variables are those which start with the $ sign, and are accessible in the whola application by all instances of your ws.
Using a singleton to hold global state is a very bad idea, especially in a web-server:
If you are using a multi-threaded environment - you will run into thread-safety issues.
More relevantly - if you run multi-process, or multi-server (as you would have to, if your web application ever succeeds...) - the state will be inconsistent, as changes in one process/machine will not be propagated to the other processes/machines.
A restart of your application will destroy the state of the application, since it is held only in memory.
You could use an SQL solution, as suggested by #Tala, but if you want something more light-weight and 'freestyle', you might want to look at some key-value stores like memcached or redis, where you could save your state in a central location, and fetch it when needed.