It sounds like it must be unique then. I would propose the following: 1. If user defines the instanceName, then we assign it to the node. 2. If user does not define the instance name, then we have to give it some unique value, like node ID or PID.
Will this change be backward compatible, or should we leave it as null if user does not define it? D. On Fri, Dec 30, 2016 at 4:19 PM, Denis Magda <[email protected]> wrote: > Sounds reasonable. Agree that 'instanceName' suits better considering your > explanation. > > -- > Denis > > On Friday, December 30, 2016, Valentin Kulichenko < > [email protected]> wrote: > > This name identifies instance of Ignite, in case there are more than one > > within an application. Here are our API methods around this: > > > > // We provide a name and get newly started *Ignite* instance. > > Ignite ignite = Ignition.start(new > IgniteConfiguration().setGridName(name)); > > > > // We provide a name and get existing *Ignite* instance. > > Ignite ignite = Ignition.ignite(name); > > > > This has nothing to do with nodes. For node representation we have > > ClusterNode API, which already has nodeId() method for identification. > > > > In other words, if we choose nodeName, we will have both nodeName and > > nodeId in the product, but with absolutely different meaning and used in > > different parts of API. How user is going to understand the difference > > between them? In my view, this is even more confusing than current > gridName. > > > > -Val > > > > On Fri, Dec 30, 2016 at 2:42 PM, Denis Magda <[email protected]> > wrote: > > > >> Alexander, frankly speaking I'm still for your original proposal - > >> nodeName. The uniqueness specificities can be set in the doc. > >> > >> -- > >> Denis > >> > >> On Friday, December 30, 2016, Alexander Fedotov < > >> [email protected]> wrote: > >> > Well, then may be we should go with one of the below names: > >> > > >> > processNodeName > >> > jvmNodeName > >> > runtimeNodeName > >> > processScopedNodeName > >> > jvmScopedNodeName > >> > runtimeScopedNodeName > >> > processWideNodeName > >> > jvmWideNodeName > >> > runtimeWideNodeName > >> > > >> > Regards, > >> > Alexander > >> > > >> > 31 дек. 2016 г. 12:37 AM пользователь "Denis Magda" < > [email protected]> > >> > написал: > >> > > >> > The parameter specifies a node name which has to be unique per JVM > >> process > >> > (if you start multiple nodes in a single process). In my understanding > it > >> > was mainly introduced to handle these multiple-nodes-per-JVM > scenarios. > >> > > >> > However, several nodes can have the same name cluster wide. > >> > > >> > — > >> > Denis > >> > > >> > > >> >> On Dec 30, 2016, at 1:30 PM, Dmitriy Setrakyan < > [email protected]> > >> > wrote: > >> >> > >> >> Now I am confused. What is the purpose of this configuration > parameter? > >> >> > >> >> On Fri, Dec 30, 2016 at 1:15 PM, Denis Magda <[email protected]> > wrote: > >> >> > >> >>> See Val’s concern in the discussion. I’m absolutely fine with > >> ‘nodeName’. > >> >>> > >> >>> — > >> >>> Denis > >> >>> > >> >>>> On Dec 30, 2016, at 1:13 PM, Dmitriy Setrakyan < > [email protected] > >> > > >> >>> wrote: > >> >>>> > >> >>>> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda <[email protected]> > >> wrote: > >> >>>> > >> >>>>> What’s about ‘localNodeName’? > >> >>>>> > >> >>>> > >> >>>> Why is it better than "nodeName"? Isn't it obvious that the name is > >> for > >> >>> the > >> >>>> local node? > >> >>> > >> >>> > >> > > >> > > >
