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

Reply via email to