Correct and this is a pure practical issue. I can even imagine scenario
where you have a cluster and for compliance reasons visor is running in a
demilitarized zone.
And all I'm saying is that the visor CACHE command or any for that matter
should not hang waiting to connect to specific clients.
It should maybe timeout indicate so and get the info it has at least. Or
maybe just give us the server nodes/info if available.
That's where I would like your opinion on it.
On Tue, 18 Jun 2019 at 22:51, Denis Magda <dma...@gridgain.com> wrote:
> 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
>
>
