Support Pavel’s point of view. Also Alexander please make sure that your changes are merged into ignite-2.0 branch rather than to the master. I think this functionality has to be available in 2.0 first. Finally, please update 2.0 Migration Guide once you’ve finished with this task: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide <https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.0+Migration+Guide>
— Denis > On Jan 10, 2017, at 1:58 AM, Pavel Tupitsyn <ptupit...@apache.org> wrote: > > I think we should fix log output as well and replace all "grid" occurences > with "instance". > > On Tue, Jan 10, 2017 at 12:55 PM, Alexander Fedotov < > alexander.fedot...@gmail.com> wrote: > >> Hi, >> >> I think we should leave null as a default value for unnamed Ignite >> instances. At least that change should be considered out of the current >> scope. >> >> What about naming, I'm also renaming log occurrences of "grid" and "grid >> name" where it stands reasonable. >> Are there places in the logging logic where we should prefer name "grid" or >> "grid name" instead of "Ignite instance name" or "Ignite instance name" can >> be used without any semantic impact? >> >> On Sat, Dec 31, 2016 at 11:23 AM, Alexander Fedotov < >> alexander.fedot...@gmail.com> wrote: >> >>> Okay. From the all said above I suppose "instanceName" should work for >>> IgniteConfiguration and "igniteInstanceName" in all other places. >>> >>> Regards, >>> Alexander >>> >>> 31 дек. 2016 г. 3:43 AM пользователь "Dmitriy Setrakyan" < >>> dsetrak...@apache.org> написал: >>> >>> 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 <dma...@gridgain.com> >> wrote: >>> >>>> Sounds reasonable. Agree that 'instanceName' suits better considering >>> your >>>> explanation. >>>> >>>> -- >>>> Denis >>>> >>>> On Friday, December 30, 2016, Valentin Kulichenko < >>>> valentin.kuliche...@gmail.com> 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 <dma...@gridgain.com> >>>> 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 < >>>>>> alexander.fedot...@gmail.com> 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" < >>>> dma...@apache.org> >>>>>>> написал: >>>>>>> >>>>>>> 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 < >>>> dsetrak...@apache.org> >>>>>>> wrote: >>>>>>>> >>>>>>>> Now I am confused. What is the purpose of this configuration >>>> parameter? >>>>>>>> >>>>>>>> On Fri, Dec 30, 2016 at 1:15 PM, Denis Magda <dma...@apache.org> >>>> 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 < >>>> dsetrak...@apache.org >>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> On Fri, Dec 30, 2016 at 1:12 PM, Denis Magda < >> dma...@apache.org> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> What’s about ‘localNodeName’? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Why is it better than "nodeName"? Isn't it obvious that the >> name >>> is >>>>>> for >>>>>>>>> the >>>>>>>>>> local node? >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> >> >> -- >> Kind regards, >> Alexander. >>
