John, Sure, you’re right that Visor is the tool for management and monitoring. Not sure that Ilya’s statement makes a practical sense.
Looping in our Visor experts. Alexey, Yury, could you please check out the issue? Denis On Tuesday, June 18, 2019, John Smith <java.dev....@gmail.com> wrote: > Ok but visor is used to get info on cache etc... So it just hangs on > client's it cannot reach. Maybe it should have a timeout if it can't reach > the specific node? Or does it have one but it's super high? > Or if it knows it's a client node then to handle it differently? > > > On Tue, 18 Jun 2019 at 10:57, Ilya Kasnacheev <ilya.kasnach...@gmail.com> > wrote: > >> Hello! >> >> Visor is not the tool to debug cluster. control.sh probably is. >> >> Visor is a node in topology (a daemon node, but still) and as such it >> follows the same limitations as any other node. >> >> Regards, >> -- >> Ilya Kasnacheev >> >> >> пт, 14 июн. 2019 г. в 22:41, John Smith <java.dev....@gmail.com>: >> >>> Hi, It's 100% that. >>> >>> I'm just stating that my applications run inside a container network and >>> the Ignite is installed on it's own VMS. The networks see each other and >>> this works. Also Visor can connect. No problems. >>> It's only when for example we have a dev machine connect from WIFI and >>> while a full mesh cluster is created VISOR cannot reach that node. >>> Or what if a badly configured client connects and causes this issue. >>> >>> All I'm saying if Ignite Visor is THE TOOL to debug and check cluster >>> state etc... It's a bit odd that it hangs for ever if it cannot reach a >>> specific client. I think that Visor/the protocol should know that it's a >>> CLIENT ONLY and not try to get stats from it. What do you think? >>> >>> >>> >>> On Thu, 13 Jun 2019 at 09:52, Ilya Kasnacheev <ilya.kasnach...@gmail.com> >>> wrote: >>> >>>> Hello! >>>> >>>> Please enable verbose logging and share logs from both visor, client >>>> and server nodes, so that we could check that. >>>> >>>> There should be messages related to connection attempts. >>>> >>>> Regards, >>>> -- >>>> Ilya Kasnacheev >>>> >>>> >>>> чт, 13 июн. 2019 г. в 00:06, John Smith <java.dev....@gmail.com>: >>>> >>>>> The clients are in the same low latency network, but they are running >>>>> inside container network. While ignite is running on it's own cluster. So >>>>> from that stand point they all see each other... >>>>> >>>>> On Wed, 12 Jun 2019 at 17:04, John Smith <java.dev....@gmail.com> >>>>> wrote: >>>>> >>>>>> Ok thanks >>>>>> >>>>>> On Mon, 10 Jun 2019 at 04:48, Ilya Kasnacheev < >>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> As a rule, a faulty thick client can destabilize a cluster. Ignite's >>>>>>> architecture assumes that all clients are collocated, i.e. that the >>>>>>> network >>>>>>> between any two nodes (including clients) is reliable, fast and >>>>>>> low-latency. >>>>>>> >>>>>>> It is not recommended to connect thick clients from different >>>>>>> networks. Use thin clients where possible. >>>>>>> >>>>>>> You can file a ticket against Apache Ignite JIRA regarding visor >>>>>>> behavior if you like. >>>>>>> >>>>>>> Regards, >>>>>>> -- >>>>>>> Ilya Kasnacheev >>>>>>> >>>>>>> >>>>>>> пт, 7 июн. 2019 г. в 23:15, John Smith <java.dev....@gmail.com>: >>>>>>> >>>>>>>> Correct. Should it not at least timeout and at least show what it >>>>>>>> has available? Basically we have a central cluster and various clients >>>>>>>> connect to it from different networks. As an example: Docker >>>>>>>> containers. >>>>>>>> >>>>>>>> We make sure that the clients are client nodes only and we avoid >>>>>>>> creating any caches on clients. >>>>>>>> >>>>>>>> On Fri, 7 Jun 2019 at 10:19, Ilya Kasnacheev < >>>>>>>> ilya.kasnach...@gmail.com> wrote: >>>>>>>> >>>>>>>>> Hello! >>>>>>>>> >>>>>>>>> I think that Visor will talk to all nodes when trying to run >>>>>>>>> caches command, and if it can't reach client nodes the operation will >>>>>>>>> never >>>>>>>>> finish. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> -- >>>>>>>>> Ilya Kasnacheev >>>>>>>>> >>>>>>>>> >>>>>>>>> ср, 5 июн. 2019 г. в 22:34, John Smith <java.dev....@gmail.com>: >>>>>>>>> >>>>>>>>>> Hi, any thoughts on this? >>>>>>>>>> >>>>>>>>>> On Fri, 31 May 2019 at 10:21, John Smith <java.dev....@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I think it should at least time out and show stats of the nodes >>>>>>>>>>> it could reach? I don't see why it's dependant on client nodes. >>>>>>>>>>> >>>>>>>>>>> On Thu, 30 May 2019 at 11:58, John Smith <java.dev....@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Sorry pressed enter to quickly.... >>>>>>>>>>>> >>>>>>>>>>>> So basically I'm 100% sure if visor cache command cannot reach >>>>>>>>>>>> the client node then it just stays there not doing anything. >>>>>>>>>>>> >>>>>>>>>>>> On Thu, 30 May 2019 at 11:57, John Smith < >>>>>>>>>>>> java.dev....@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, running 2.7.0 >>>>>>>>>>>>> >>>>>>>>>>>>> - I have a 4 node cluster and it seems to be running ok. >>>>>>>>>>>>> - I have clients connecting and doing what they need to do. >>>>>>>>>>>>> - The clients are set as client = true. >>>>>>>>>>>>> - The clients are also connecting from various parts of the >>>>>>>>>>>>> network. >>>>>>>>>>>>> >>>>>>>>>>>>> The problem with ignite visor cache command is if visor cannot >>>>>>>>>>>>> reach a specific client node it just seems to hang indefinitely. >>>>>>>>>>>>> >>>>>>>>>>>>> Choose node number ('c' to cancel) [0]: c >>>>>>>>>>>>> visor> cache >>>>>>>>>>>>> >>>>>>>>>>>>> It just stays like that no errors printed nothing... >>>>>>>>>>>>> >>>>>>>>>>>> -- -- Denis Magda