Re: How to do address resolution?

[Denis Magda]

Thanks, John. That connectivity improvement fixes situations when a server
needs to open a connection to a client but fails. The client will be
opening the connection instead after getting a special message via the
discovery networking layer. It won’t improve the communication between
Visor and clients.

We’ll document the address resolver in the future. Thanks for pointers.

Denis

On Wednesday, July 1, 2020, John Smith  wrote:

> Sorry, mixed the thread, it the one that asks if server nodes connect back
> to thick clients and it was you who mentioned the new feature...
>
> On Wed., Jul. 1, 2020, 4:03 p.m. John Smith, 
> wrote:
>
>> If you look for the "what does all partition owners have left mean?"
>> thread.
>>
>> There is mention to improve the protocol so that other nodes don't need
>> to connect to clients running inside containers... It links to another
>> thread indicating that there may be a PR to add a flag of some sort to mark
>> the client as "virtualized" or something like that...
>>
>> As for the docs... There's only this https://ignite.
>> apache.org/releases/latest/javadoc/org/apache/ignite/configuration/
>> BasicAddressResolver.html
>>
>> And nothing is mentioned elsewhere in the official docs.
>>
>> On Wed., Jul. 1, 2020, 2:22 p.m. Denis Magda,  wrote:
>>
>>> But you guys also mentioned in my other thread that you are working on a
 feature that doesn't require connecting to the client when it's running
 inside a container.
>>>
>>>
>>> What is the tread you're referring to? Visor always will be connecting
>>> to the clients regardless of your deployment configuration.
>>>
>>>  Anyways thanks for creating an issue and as well just wondering if any
 docs should be updated for containers because I found the
 BasicAddresResolver java doc by chance.
>>>
>>>
>>> You're always welcome. Could you point out the documentation you used to
>>> configure the AdressResolver? Agree, we need to document or blog about best
>>> practices.
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jul 1, 2020 at 10:49 AM John Smith 
>>> wrote:
>>>
 Hi, yes I figured that visor is just another thick client.

 By using address resolver on my thick client applications inside
 container everything works fine and visor also connects properly (no need
 to add all client configs everywhere).

 As stated it just adds tiny delay when visor needs to connect to the
 other clients. And of course the "issue" when it fully blocks because it
 can't reach the client even though it knows the client is there.

 I dunno if I'm the only one who is using mixed environment. But you
 guys also mentioned in my other thread that you are working on a feature
 that doesn't require connecting to the client when it's running inside a
 container.

 Anyways thanks for creating an issue and as well just wondering if any
 docs should be updated for containers because I found the
 BasicAddresResolver java doc by chance.

 On Wed., Jul. 1, 2020, 12:51 p.m. Denis Magda, 
 wrote:

> Hi John,
>
> As Stephen mentioned, Visor connects to the cluster in a way similar
> to server nodes and thick clients. It's connected as a daemon node that is
> filtered out from metrics and other public APIs. That's why you don't see
> Visor being reported in the cluster topology metrics along with servers or
> thick clients: https://ignite.apache.org/releases/latest/
> javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#
> setDaemon-boolean-
>
> As a daemon node, Visor uses the same networking protocols to join the
> cluster and communicate with other cluster members:
>
>- Discovery SPI - As any server node or a thick client, Visor will
>join the cluster by connecting to one of the server nodes. It will use 
> an
>IP Finder that you set in your IgniteConfiguration file. Once Visor 
> joins
>the cluster, it will collect information about the cluster topology and
>display these basic metrics to you in a terminal window. Visor receives
>this information about the cluster topology through the server node 
> used to
>join the cluster. The same server node will update Visor on any 
> topology
>changes.
>- Communication SPI - Whenever Visor needs to get metrics from a
>specific server or thick client, it will open a direct TCP/IP 
> connection
>with the server/client. In your case, it failed to reach out to some
>clients and hung. The hanging is not the right way of handling this 
> type of
>issues and I've opened a ticket to address this:
>https://issues.apache.org/jira/browse/IGNITE-13201
>
>
> Considering this implementation specificities, I can recommend you do
> one of the following:
>
>- List all 

Re: How to do address resolution?

[John Smith]

Sorry, mixed the thread, it the one that asks if server nodes connect back
to thick clients and it was you who mentioned the new feature...

On Wed., Jul. 1, 2020, 4:03 p.m. John Smith,  wrote:

> If you look for the "what does all partition owners have left mean?"
> thread.
>
> There is mention to improve the protocol so that other nodes don't need to
> connect to clients running inside containers... It links to another thread
> indicating that there may be a PR to add a flag of some sort to mark the
> client as "virtualized" or something like that...
>
> As for the docs... There's only this
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/BasicAddressResolver.html
>
> And nothing is mentioned elsewhere in the official docs.
>
> On Wed., Jul. 1, 2020, 2:22 p.m. Denis Magda,  wrote:
>
>> But you guys also mentioned in my other thread that you are working on a
>>> feature that doesn't require connecting to the client when it's running
>>> inside a container.
>>
>>
>> What is the tread you're referring to? Visor always will be connecting to
>> the clients regardless of your deployment configuration.
>>
>>  Anyways thanks for creating an issue and as well just wondering if any
>>> docs should be updated for containers because I found the
>>> BasicAddresResolver java doc by chance.
>>
>>
>> You're always welcome. Could you point out the documentation you used to
>> configure the AdressResolver? Agree, we need to document or blog about best
>> practices.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jul 1, 2020 at 10:49 AM John Smith 
>> wrote:
>>
>>> Hi, yes I figured that visor is just another thick client.
>>>
>>> By using address resolver on my thick client applications inside
>>> container everything works fine and visor also connects properly (no need
>>> to add all client configs everywhere).
>>>
>>> As stated it just adds tiny delay when visor needs to connect to the
>>> other clients. And of course the "issue" when it fully blocks because it
>>> can't reach the client even though it knows the client is there.
>>>
>>> I dunno if I'm the only one who is using mixed environment. But you guys
>>> also mentioned in my other thread that you are working on a feature that
>>> doesn't require connecting to the client when it's running inside a
>>> container.
>>>
>>> Anyways thanks for creating an issue and as well just wondering if any
>>> docs should be updated for containers because I found the
>>> BasicAddresResolver java doc by chance.
>>>
>>> On Wed., Jul. 1, 2020, 12:51 p.m. Denis Magda, 
>>> wrote:
>>>
 Hi John,

 As Stephen mentioned, Visor connects to the cluster in a way similar to
 server nodes and thick clients. It's connected as a daemon node that is
 filtered out from metrics and other public APIs. That's why you don't see
 Visor being reported in the cluster topology metrics along with servers or
 thick clients:
 https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setDaemon-boolean-

 As a daemon node, Visor uses the same networking protocols to join the
 cluster and communicate with other cluster members:

- Discovery SPI - As any server node or a thick client, Visor will
join the cluster by connecting to one of the server nodes. It will use 
 an
IP Finder that you set in your IgniteConfiguration file. Once Visor 
 joins
the cluster, it will collect information about the cluster topology and
display these basic metrics to you in a terminal window. Visor receives
this information about the cluster topology through the server node 
 used to
join the cluster. The same server node will update Visor on any topology
changes.
- Communication SPI - Whenever Visor needs to get metrics from a
specific server or thick client, it will open a direct TCP/IP connection
with the server/client. In your case, it failed to reach out to some
clients and hung. The hanging is not the right way of handling this 
 type of
issues and I've opened a ticket to address this:
https://issues.apache.org/jira/browse/IGNITE-13201

 Considering this implementation specificities, I can recommend you do
 one of the following:

- List all the thick clients in the AddressResolver configuration.
This is required. Hope my explanation above makes things clear for you.
- Or, run Visor from inside the private network. You would need to
ssh to one of your machines. With this, you don't need to deal with
AddressResolvers.
- Or, use contemporary tools for Ignite cluster monitoring. Ignite
supports JMX and OpenCensus protocols that allow you to consume metrics
from tools like Zabbix or Prometheus. You deploy a tool inside of your
private network so that it can collect metrics from the cluster and 
 

Re: How to do address resolution?

[John Smith]

If you look for the "what does all partition owners have left mean?" thread.

There is mention to improve the protocol so that other nodes don't need to
connect to clients running inside containers... It links to another thread
indicating that there may be a PR to add a flag of some sort to mark the
client as "virtualized" or something like that...

As for the docs... There's only this
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/BasicAddressResolver.html

And nothing is mentioned elsewhere in the official docs.

On Wed., Jul. 1, 2020, 2:22 p.m. Denis Magda,  wrote:

> But you guys also mentioned in my other thread that you are working on a
>> feature that doesn't require connecting to the client when it's running
>> inside a container.
>
>
> What is the tread you're referring to? Visor always will be connecting to
> the clients regardless of your deployment configuration.
>
>  Anyways thanks for creating an issue and as well just wondering if any
>> docs should be updated for containers because I found the
>> BasicAddresResolver java doc by chance.
>
>
> You're always welcome. Could you point out the documentation you used to
> configure the AdressResolver? Agree, we need to document or blog about best
> practices.
>
> -
> Denis
>
>
> On Wed, Jul 1, 2020 at 10:49 AM John Smith  wrote:
>
>> Hi, yes I figured that visor is just another thick client.
>>
>> By using address resolver on my thick client applications inside
>> container everything works fine and visor also connects properly (no need
>> to add all client configs everywhere).
>>
>> As stated it just adds tiny delay when visor needs to connect to the
>> other clients. And of course the "issue" when it fully blocks because it
>> can't reach the client even though it knows the client is there.
>>
>> I dunno if I'm the only one who is using mixed environment. But you guys
>> also mentioned in my other thread that you are working on a feature that
>> doesn't require connecting to the client when it's running inside a
>> container.
>>
>> Anyways thanks for creating an issue and as well just wondering if any
>> docs should be updated for containers because I found the
>> BasicAddresResolver java doc by chance.
>>
>> On Wed., Jul. 1, 2020, 12:51 p.m. Denis Magda,  wrote:
>>
>>> Hi John,
>>>
>>> As Stephen mentioned, Visor connects to the cluster in a way similar to
>>> server nodes and thick clients. It's connected as a daemon node that is
>>> filtered out from metrics and other public APIs. That's why you don't see
>>> Visor being reported in the cluster topology metrics along with servers or
>>> thick clients:
>>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setDaemon-boolean-
>>>
>>> As a daemon node, Visor uses the same networking protocols to join the
>>> cluster and communicate with other cluster members:
>>>
>>>- Discovery SPI - As any server node or a thick client, Visor will
>>>join the cluster by connecting to one of the server nodes. It will use an
>>>IP Finder that you set in your IgniteConfiguration file. Once Visor joins
>>>the cluster, it will collect information about the cluster topology and
>>>display these basic metrics to you in a terminal window. Visor receives
>>>this information about the cluster topology through the server node used 
>>> to
>>>join the cluster. The same server node will update Visor on any topology
>>>changes.
>>>- Communication SPI - Whenever Visor needs to get metrics from a
>>>specific server or thick client, it will open a direct TCP/IP connection
>>>with the server/client. In your case, it failed to reach out to some
>>>clients and hung. The hanging is not the right way of handling this type 
>>> of
>>>issues and I've opened a ticket to address this:
>>>https://issues.apache.org/jira/browse/IGNITE-13201
>>>
>>> Considering this implementation specificities, I can recommend you do
>>> one of the following:
>>>
>>>- List all the thick clients in the AddressResolver configuration.
>>>This is required. Hope my explanation above makes things clear for you.
>>>- Or, run Visor from inside the private network. You would need to
>>>ssh to one of your machines. With this, you don't need to deal with
>>>AddressResolvers.
>>>- Or, use contemporary tools for Ignite cluster monitoring. Ignite
>>>supports JMX and OpenCensus protocols that allow you to consume metrics
>>>from tools like Zabbix or Prometheus. You deploy a tool inside of your
>>>private network so that it can collect metrics from the cluster and open 
>>> a
>>>single port number for those who will observe the metrics via a tool's 
>>> user
>>>interface. If you need both monitoring and *management* capabilities, 
>>> then
>>>have a look at GridGain Control Center.
>>>
>>> -
>>> Denis
>>>
>>>
>>> On Wed, Jul 1, 2020 at 8:39 AM John Smith 
>>> wrote:
>>>
 S

Re: How to do address resolution?

[Denis Magda]

>
> But you guys also mentioned in my other thread that you are working on a
> feature that doesn't require connecting to the client when it's running
> inside a container.


What is the tread you're referring to? Visor always will be connecting to
the clients regardless of your deployment configuration.

 Anyways thanks for creating an issue and as well just wondering if any
> docs should be updated for containers because I found the
> BasicAddresResolver java doc by chance.


You're always welcome. Could you point out the documentation you used to
configure the AdressResolver? Agree, we need to document or blog about best
practices.

-
Denis


On Wed, Jul 1, 2020 at 10:49 AM John Smith  wrote:

> Hi, yes I figured that visor is just another thick client.
>
> By using address resolver on my thick client applications inside container
> everything works fine and visor also connects properly (no need to add all
> client configs everywhere).
>
> As stated it just adds tiny delay when visor needs to connect to the other
> clients. And of course the "issue" when it fully blocks because it can't
> reach the client even though it knows the client is there.
>
> I dunno if I'm the only one who is using mixed environment. But you guys
> also mentioned in my other thread that you are working on a feature that
> doesn't require connecting to the client when it's running inside a
> container.
>
> Anyways thanks for creating an issue and as well just wondering if any
> docs should be updated for containers because I found the
> BasicAddresResolver java doc by chance.
>
> On Wed., Jul. 1, 2020, 12:51 p.m. Denis Magda,  wrote:
>
>> Hi John,
>>
>> As Stephen mentioned, Visor connects to the cluster in a way similar to
>> server nodes and thick clients. It's connected as a daemon node that is
>> filtered out from metrics and other public APIs. That's why you don't see
>> Visor being reported in the cluster topology metrics along with servers or
>> thick clients:
>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setDaemon-boolean-
>>
>> As a daemon node, Visor uses the same networking protocols to join the
>> cluster and communicate with other cluster members:
>>
>>- Discovery SPI - As any server node or a thick client, Visor will
>>join the cluster by connecting to one of the server nodes. It will use an
>>IP Finder that you set in your IgniteConfiguration file. Once Visor joins
>>the cluster, it will collect information about the cluster topology and
>>display these basic metrics to you in a terminal window. Visor receives
>>this information about the cluster topology through the server node used 
>> to
>>join the cluster. The same server node will update Visor on any topology
>>changes.
>>- Communication SPI - Whenever Visor needs to get metrics from a
>>specific server or thick client, it will open a direct TCP/IP connection
>>with the server/client. In your case, it failed to reach out to some
>>clients and hung. The hanging is not the right way of handling this type 
>> of
>>issues and I've opened a ticket to address this:
>>https://issues.apache.org/jira/browse/IGNITE-13201
>>
>> Considering this implementation specificities, I can recommend you do one
>> of the following:
>>
>>- List all the thick clients in the AddressResolver configuration.
>>This is required. Hope my explanation above makes things clear for you.
>>- Or, run Visor from inside the private network. You would need to
>>ssh to one of your machines. With this, you don't need to deal with
>>AddressResolvers.
>>- Or, use contemporary tools for Ignite cluster monitoring. Ignite
>>supports JMX and OpenCensus protocols that allow you to consume metrics
>>from tools like Zabbix or Prometheus. You deploy a tool inside of your
>>private network so that it can collect metrics from the cluster and open a
>>single port number for those who will observe the metrics via a tool's 
>> user
>>interface. If you need both monitoring and *management* capabilities, then
>>have a look at GridGain Control Center.
>>
>> -
>> Denis
>>
>>
>> On Wed, Jul 1, 2020 at 8:39 AM John Smith  wrote:
>>
>>> So this is what I gathered from this experience.
>>>
>>> When running commands on Visor's console, Visor will attempt to connect
>>> to the thick client.
>>>
>>> For example if you type the "node" command and attempt to get detailed
>>> statistics for a specific thick client, Visor will pause on the data region
>>> stats until it can connect.
>>>
>>> Furthermore if you have multiple thick clients and Visor has not
>>> connected to some of them yet and you call a more global command like
>>> "cache", this command will also pause until a connection has been made to
>>> all thick clients.
>>>
>>> 1- Whether this is good behaviour or not is up for debate. Especially
>>> the part when a thick client is listed in the topology/nod

Re: How to do address resolution?

[John Smith]

Hi, yes I figured that visor is just another thick client.

By using address resolver on my thick client applications inside container
everything works fine and visor also connects properly (no need to add all
client configs everywhere).

As stated it just adds tiny delay when visor needs to connect to the other
clients. And of course the "issue" when it fully blocks because it can't
reach the client even though it knows the client is there.

I dunno if I'm the only one who is using mixed environment. But you guys
also mentioned in my other thread that you are working on a feature that
doesn't require connecting to the client when it's running inside a
container.

Anyways thanks for creating an issue and as well just wondering if any docs
should be updated for containers because I found the BasicAddresResolver
java doc by chance.

On Wed., Jul. 1, 2020, 12:51 p.m. Denis Magda,  wrote:

> Hi John,
>
> As Stephen mentioned, Visor connects to the cluster in a way similar to
> server nodes and thick clients. It's connected as a daemon node that is
> filtered out from metrics and other public APIs. That's why you don't see
> Visor being reported in the cluster topology metrics along with servers or
> thick clients:
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setDaemon-boolean-
>
> As a daemon node, Visor uses the same networking protocols to join the
> cluster and communicate with other cluster members:
>
>- Discovery SPI - As any server node or a thick client, Visor will
>join the cluster by connecting to one of the server nodes. It will use an
>IP Finder that you set in your IgniteConfiguration file. Once Visor joins
>the cluster, it will collect information about the cluster topology and
>display these basic metrics to you in a terminal window. Visor receives
>this information about the cluster topology through the server node used to
>join the cluster. The same server node will update Visor on any topology
>changes.
>- Communication SPI - Whenever Visor needs to get metrics from a
>specific server or thick client, it will open a direct TCP/IP connection
>with the server/client. In your case, it failed to reach out to some
>clients and hung. The hanging is not the right way of handling this type of
>issues and I've opened a ticket to address this:
>https://issues.apache.org/jira/browse/IGNITE-13201
>
> Considering this implementation specificities, I can recommend you do one
> of the following:
>
>- List all the thick clients in the AddressResolver configuration.
>This is required. Hope my explanation above makes things clear for you.
>- Or, run Visor from inside the private network. You would need to ssh
>to one of your machines. With this, you don't need to deal with
>AddressResolvers.
>- Or, use contemporary tools for Ignite cluster monitoring. Ignite
>supports JMX and OpenCensus protocols that allow you to consume metrics
>from tools like Zabbix or Prometheus. You deploy a tool inside of your
>private network so that it can collect metrics from the cluster and open a
>single port number for those who will observe the metrics via a tool's user
>interface. If you need both monitoring and *management* capabilities, then
>have a look at GridGain Control Center.
>
> -
> Denis
>
>
> On Wed, Jul 1, 2020 at 8:39 AM John Smith  wrote:
>
>> So this is what I gathered from this experience.
>>
>> When running commands on Visor's console, Visor will attempt to connect
>> to the thick client.
>>
>> For example if you type the "node" command and attempt to get detailed
>> statistics for a specific thick client, Visor will pause on the data region
>> stats until it can connect.
>>
>> Furthermore if you have multiple thick clients and Visor has not
>> connected to some of them yet and you call a more global command like
>> "cache", this command will also pause until a connection has been made to
>> all thick clients.
>>
>> 1- Whether this is good behaviour or not is up for debate. Especially the
>> part when a thick client is listed in the topology/nodes but cannot be
>> reached and visor hangs indefinitely.
>> 2- Not sure if this behaviour in any way affects the server node if they
>> ever attempt to open a connection to a thick client and the protocol
>> somehow freezes just like #1 above.
>>
>> On Tue, 30 Jun 2020 at 09:54, John Smith  wrote:
>>
>>> Ok so. Is this expected behaviour? From user perspective this seems like
>>> a bug.
>>>
>>> Visor is supposed to be used as a way to monitor...
>>>
>>> So if as a user we enter a command and it just freezes indefinently it
>>> just seems unfriendly.
>>>
>>> In another thread the the team mentioned that they are working on
>>> something that does not require the protocol to communicate back to a thick
>>> client. So wondering if this is in a way related as well...
>>>
>>> On Tue., Jun. 30, 2020, 6:58 a.m. Il

Re: Setting Cache Size using Max Records

[Denis Magda]

1. There is no any public API for that but you can follow a workaround
suggested here
.
If you have a POJO class of your domain object, then create an instance,
convert it to BinaryObjectImpl and get the array size (as suggested on
StackOverflow).

2. No, you have to set the size in advance. However, the combination of
initial and max size might do the trick for you. Use the initial size for
after you calculate the value for an expected number of records the cache
has to store while the max size can give you an extra space to deal with
the calculation/estimations errors.

-
Denis


On Tue, Jun 30, 2020 at 9:08 PM Victor  wrote:

> Yes, user upfront defines a config and the idea indeed is to convert the
> number of records to total bytes.
>
> Followup around this. Given i want to calculate the exact row entry size
> upfront, even before the data is added. Couple of queries,
>
> 1. Is there a way(api) just based on the Cache (table), be able to inspect
> the capacity a row can hold based on the column datatypes?
> 2. Can the Dataregion be set post the cache is created?
>
> Thanks,
> Victor
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: ScanQuery Transform: fail to deserialze! ignite 2.8.0, java 11

[Denis Magda]

Hi Rafael,

Lamdas and anonymous classes capture and serialize their Inner/OuterClass
with all the fields, and classes of the fields of those fields, etc. In
your case, ScanQueryClass was captured during the lamda serialization and
that class was not found during deserialization on the other side:

Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to
read field [name=capturingClass]
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:192)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:874)
... 20 more
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
ScanQueryTest
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:724)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:721)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1638)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1575)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1552)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readClass(BinaryReaderExImpl.java:383)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:907)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:703)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:188)
... 21 more
*Caused by: java.lang.ClassNotFoundException: ScanQueryTest*
at
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:398)
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8828)
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerContextImpl.java:374)
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:715)
... 29 more

My advice is to avoid using lambdas and anonymous classes due to this
specificity. Instead, you can create "private static classes" and Ignite
will be serializing an instance of that class only:

private static class MyFilter implements IgniteClosure {

}

Lamdas are nice for demos and simple code samples where Inner/OuterClasses
are simple Java classes. While in real production environments, things can
get messy.

-
Denis


On Wed, Jul 1, 2020 at 9:36 AM Rafael Troilo 
wrote:

> Hey Guys,
>
> I have a strange problem with the Transform part of a ScanQuery that I get
> a deserialize object exception for the SerializedLambda.
> > javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=java.lang.invoke.SerializedLambda]
>
> Strange is that it works very well in other cases like:
>
> try (Ignite ignite = Ignition.start("ignite.xml")) {
>   IgniteCache cache =
> ignite.createCache("ScanTransformTest");
>   cache.put(1, "Hello");
>
>   // 1  Just a broadcast with a IgniteClosure works!
>   compute.broadcast((a) -> 123L, "Hello").forEach(System.out::println);
>
>   // 2 Running the ScanQuery on the remote server. Works too!
>   compute.broadcast(() -> {
> try(QueryCursor cursor = cache.query(new
> ScanQuery<>().setLocal(true), (a) -> 234L)){
>   for( Long row : cursor) {
> return row;
>   }
> }
> return 0;
>   }).forEach(System.out::println);
>
>
>   // 3 But running it from the client side it fails!
>   try(QueryCursor cursor = cache.query(new ScanQuery<>(), (a) ->
> 345L)){
> for( Long row : cursor) {
>   System.out.println(row);
>   break;
> }
>   }
>
> }
>
> Also changing the Lambda to a actually class implementing IgniteClosure
> results in the same problem.
>
> Any idea what I'm doing wrong?
>
> We are running ignite ver. 2.8.0#20200226-sha1:341b01df
> With java openjdk 11.0.7 2020-04-14
>
> Thank you!
>
> Best,
> Rafael
>
>
> Error Log:
> Exception in thread "main" javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Failed to deserialize object
> [typeName=java.lang.invoke.SerializedLambda]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1317)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:173)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDis

Re: How to do address resolution?

[Denis Magda]

Hi John,

As Stephen mentioned, Visor connects to the cluster in a way similar to
server nodes and thick clients. It's connected as a daemon node that is
filtered out from metrics and other public APIs. That's why you don't see
Visor being reported in the cluster topology metrics along with servers or
thick clients:
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#setDaemon-boolean-

As a daemon node, Visor uses the same networking protocols to join the
cluster and communicate with other cluster members:

   - Discovery SPI - As any server node or a thick client, Visor will join
   the cluster by connecting to one of the server nodes. It will use an IP
   Finder that you set in your IgniteConfiguration file. Once Visor joins the
   cluster, it will collect information about the cluster topology and display
   these basic metrics to you in a terminal window. Visor receives this
   information about the cluster topology through the server node used to join
   the cluster. The same server node will update Visor on any topology changes.
   - Communication SPI - Whenever Visor needs to get metrics from a
   specific server or thick client, it will open a direct TCP/IP connection
   with the server/client. In your case, it failed to reach out to some
   clients and hung. The hanging is not the right way of handling this type of
   issues and I've opened a ticket to address this:
   https://issues.apache.org/jira/browse/IGNITE-13201

Considering this implementation specificities, I can recommend you do one
of the following:

   - List all the thick clients in the AddressResolver configuration. This
   is required. Hope my explanation above makes things clear for you.
   - Or, run Visor from inside the private network. You would need to ssh
   to one of your machines. With this, you don't need to deal with
   AddressResolvers.
   - Or, use contemporary tools for Ignite cluster monitoring. Ignite
   supports JMX and OpenCensus protocols that allow you to consume metrics
   from tools like Zabbix or Prometheus. You deploy a tool inside of your
   private network so that it can collect metrics from the cluster and open a
   single port number for those who will observe the metrics via a tool's user
   interface. If you need both monitoring and *management* capabilities, then
   have a look at GridGain Control Center.

-
Denis


On Wed, Jul 1, 2020 at 8:39 AM John Smith  wrote:

> So this is what I gathered from this experience.
>
> When running commands on Visor's console, Visor will attempt to connect to
> the thick client.
>
> For example if you type the "node" command and attempt to get detailed
> statistics for a specific thick client, Visor will pause on the data region
> stats until it can connect.
>
> Furthermore if you have multiple thick clients and Visor has not
> connected to some of them yet and you call a more global command like
> "cache", this command will also pause until a connection has been made to
> all thick clients.
>
> 1- Whether this is good behaviour or not is up for debate. Especially the
> part when a thick client is listed in the topology/nodes but cannot be
> reached and visor hangs indefinitely.
> 2- Not sure if this behaviour in any way affects the server node if they
> ever attempt to open a connection to a thick client and the protocol
> somehow freezes just like #1 above.
>
> On Tue, 30 Jun 2020 at 09:54, John Smith  wrote:
>
>> Ok so. Is this expected behaviour? From user perspective this seems like
>> a bug.
>>
>> Visor is supposed to be used as a way to monitor...
>>
>> So if as a user we enter a command and it just freezes indefinently it
>> just seems unfriendly.
>>
>> In another thread the the team mentioned that they are working on
>> something that does not require the protocol to communicate back to a thick
>> client. So wondering if this is in a way related as well...
>>
>> On Tue., Jun. 30, 2020, 6:58 a.m. Ilya Kasnacheev, <
>> ilya.kasnach...@gmail.com> wrote:
>>
>>> Hello!
>>>
>>> I can see the following in the thread dump:
>>> "main" #1 prio=5 os_prio=0 tid=0x7f02c400d800 nid=0x1e43 runnable
>>> [0x7f02cad1e000]
>>>java.lang.Thread.State: RUNNABLE
>>> at sun.nio.ch.Net.poll(Native Method)
>>> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:951)
>>> - locked <0xec066048> (a java.lang.Object)
>>> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:121)
>>> - locked <0xec066038> (a java.lang.Object)
>>> at
>>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3299)
>>> at
>>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
>>> at
>>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
>>> at
>>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2713)
>>> at
>>> org.a

ScanQuery Transform: fail to deserialze! ignite 2.8.0, java 11

[Rafael Troilo]

Hey Guys,

I have a strange problem with the Transform part of a ScanQuery that I get a 
deserialize object exception for the SerializedLambda.
> javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
> Failed to deserialize object [typeName=java.lang.invoke.SerializedLambda]

Strange is that it works very well in other cases like: 

try (Ignite ignite = Ignition.start("ignite.xml")) {
  IgniteCache cache = ignite.createCache("ScanTransformTest");
  cache.put(1, "Hello");

  // 1  Just a broadcast with a IgniteClosure works!
  compute.broadcast((a) -> 123L, "Hello").forEach(System.out::println);
   
  // 2 Running the ScanQuery on the remote server. Works too!
  compute.broadcast(() -> {
try(QueryCursor cursor = cache.query(new 
ScanQuery<>().setLocal(true), (a) -> 234L)){  
  for( Long row : cursor) {
return row;
  }
}
return 0;
  }).forEach(System.out::println);


  // 3 But running it from the client side it fails!
  try(QueryCursor cursor = cache.query(new ScanQuery<>(), (a) -> 345L)){  
for( Long row : cursor) {
  System.out.println(row);
  break;
}
  }

}

Also changing the Lambda to a actually class implementing IgniteClosure results 
in the same problem.

Any idea what I'm doing wrong?

We are running ignite ver. 2.8.0#20200226-sha1:341b01df 
With java openjdk 11.0.7 2020-04-14

Thank you!

Best,
Rafael


Error Log:
Exception in thread "main" javax.cache.CacheException: class 
org.apache.ignite.IgniteCheckedException: Failed to deserialize object 
[typeName=java.lang.invoke.SerializedLambda]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1317)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryFutureAdapter.next(GridCacheQueryFutureAdapter.java:173)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$5.onHasNext(GridCacheDistributedQueryManager.java:645)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.AutoClosableCursorIterator.hasNext(AutoClosableCursorIterator.java:49)
at ScanQueryTest.main(ScanQueryTest.java:49)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to 
deserialize object [typeName=java.lang.invoke.SerializedLambda]
at 
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10310)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryRequest.finishUnmarshal(GridCacheQueryRequest.java:389)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1625)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:586)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1843)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1468)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$5200(GridIoManager.java:229)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1365)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: class org.apache.ignite.binary.BinaryObjectException: Failed to 
deserialize object [typeName=java.lang.invoke.SerializedLambda]
at 
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:913)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1764)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:307)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:101)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:81)
at 
org.apa

Re: How to do address resolution?

[Stephen Darlington]

It’s not that Visor connects to a thick client, it’s that it is a thick client. 
There are some weird implementation details — like it’s written in Scala and 
using “daemon mode” — but it becomes part of the cluster, so the same “rules” 
apply as any other thick client. Connections to other nodes are “on demand” so 
the pause it likely to be it trying to open a communicationSPI connection to 
one of the other nodes.

I agree that this is not necessarily intuitive for an administrative tool, but 
it’s what we have until all the functionality can be provided by a thin client 
or using the REST API.

> On 1 Jul 2020, at 16:38, John Smith  wrote:
> 
> So this is what I gathered from this experience.
> 
> When running commands on Visor's console, Visor will attempt to connect to 
> the thick client.
> 
> For example if you type the "node" command and attempt to get detailed 
> statistics for a specific thick client, Visor will pause on the data region 
> stats until it can connect.
> 
> Furthermore if you have multiple thick clients and Visor has not connected to 
> some of them yet and you call a more global command like "cache", this 
> command will also pause until a connection has been made to all thick clients.
> 
> 1- Whether this is good behaviour or not is up for debate. Especially the 
> part when a thick client is listed in the topology/nodes but cannot be 
> reached and visor hangs indefinitely.
> 2- Not sure if this behaviour in any way affects the server node if they ever 
> attempt to open a connection to a thick client and the protocol somehow 
> freezes just like #1 above.
> 
> On Tue, 30 Jun 2020 at 09:54, John Smith  > wrote:
> Ok so. Is this expected behaviour? From user perspective this seems like a 
> bug.
> 
> Visor is supposed to be used as a way to monitor...
> 
> So if as a user we enter a command and it just freezes indefinently it just 
> seems unfriendly.
> 
> In another thread the the team mentioned that they are working on something 
> that does not require the protocol to communicate back to a thick client. So 
> wondering if this is in a way related as well...
> 
> On Tue., Jun. 30, 2020, 6:58 a.m. Ilya Kasnacheev,  > wrote:
> Hello!
> 
> I can see the following in the thread dump:
> "main" #1 prio=5 os_prio=0 tid=0x7f02c400d800 nid=0x1e43 runnable 
> [0x7f02cad1e000]
>java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.Net.poll(Native Method)
> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:951)
> - locked <0xec066048> (a java.lang.Object)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:121)
> - locked <0xec066038> (a java.lang.Object)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3299)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2713)
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2672)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1656)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1731)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1436)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
> at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
> at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:392)
> at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:528)
> at 
> org.apache.ignite.internal.IgniteComputeImpl.execute(IgniteComputeImpl.java:498)
> at org.apache.ignite.visor.visor$.execute(visor.scala:1800)
> 
> It seems that Visor is trying to connect to client node via Communication, 
> and it fails because the network connection is filtered out.
> 
> Regards,
> -- 
> Ilya Kasnacheev
> 
> 
> пн, 29 июн. 2020 г. в 23:47, John Smith  >:
> Ok.
> 
> I am able to reproduce the "issue" unless we have a misunderstanding and we 
> are talking about the same thing...
> 
> My thick client runs inside a container in a closed network NOT bridged and 
> NOT host. I added a flag to my application that allows it to add the address 
> resolver to the config.
> 
> 1- If I disable address resolution and I connect with visor to th

Re: How to do address resolution?

[John Smith]

So this is what I gathered from this experience.

When running commands on Visor's console, Visor will attempt to connect to
the thick client.

For example if you type the "node" command and attempt to get detailed
statistics for a specific thick client, Visor will pause on the data region
stats until it can connect.

Furthermore if you have multiple thick clients and Visor has not
connected to some of them yet and you call a more global command like
"cache", this command will also pause until a connection has been made to
all thick clients.

1- Whether this is good behaviour or not is up for debate. Especially the
part when a thick client is listed in the topology/nodes but cannot be
reached and visor hangs indefinitely.
2- Not sure if this behaviour in any way affects the server node if they
ever attempt to open a connection to a thick client and the protocol
somehow freezes just like #1 above.

On Tue, 30 Jun 2020 at 09:54, John Smith  wrote:

> Ok so. Is this expected behaviour? From user perspective this seems like a
> bug.
>
> Visor is supposed to be used as a way to monitor...
>
> So if as a user we enter a command and it just freezes indefinently it
> just seems unfriendly.
>
> In another thread the the team mentioned that they are working on
> something that does not require the protocol to communicate back to a thick
> client. So wondering if this is in a way related as well...
>
> On Tue., Jun. 30, 2020, 6:58 a.m. Ilya Kasnacheev, <
> ilya.kasnach...@gmail.com> wrote:
>
>> Hello!
>>
>> I can see the following in the thread dump:
>> "main" #1 prio=5 os_prio=0 tid=0x7f02c400d800 nid=0x1e43 runnable
>> [0x7f02cad1e000]
>>java.lang.Thread.State: RUNNABLE
>> at sun.nio.ch.Net.poll(Native Method)
>> at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:951)
>> - locked <0xec066048> (a java.lang.Object)
>> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:121)
>> - locked <0xec066038> (a java.lang.Object)
>> at
>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:3299)
>> at
>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createNioClient(TcpCommunicationSpi.java:2987)
>> at
>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2870)
>> at
>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2713)
>> at
>> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2672)
>> at
>> org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1656)
>> at
>> org.apache.ignite.internal.managers.communication.GridIoManager.sendToGridTopic(GridIoManager.java:1731)
>> at
>> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1436)
>> at
>> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:666)
>> at
>> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:538)
>> at
>> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
>> at
>> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:764)
>> at
>> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:392)
>> at
>> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:528)
>> at
>> org.apache.ignite.internal.IgniteComputeImpl.execute(IgniteComputeImpl.java:498)
>> at org.apache.ignite.visor.visor$.execute(visor.scala:1800)
>>
>> It seems that Visor is trying to connect to client node via
>> Communication, and it fails because the network connection is filtered out.
>>
>> Regards,
>> --
>> Ilya Kasnacheev
>>
>>
>> пн, 29 июн. 2020 г. в 23:47, John Smith :
>>
>>> Ok.
>>>
>>> I am able to reproduce the "issue" unless we have a misunderstanding and
>>> we are talking about the same thing...
>>>
>>> My thick client runs inside a container in a closed network NOT bridged
>>> and NOT host. I added a flag to my application that allows it to add the
>>> address resolver to the config.
>>>
>>> 1- If I disable address resolution and I connect with visor to the
>>> cluster and try to print detailed statistics for that particular client,
>>> visor freezes indefinitely at the Data Region Snapshot.
>>> Control C doesn't kill the visor either. It just stuck. This also
>>> happens when running the cache command. Just freezes indefinitely.
>>>
>>> I attached the jstack output to the email but it is also here:
>>> https://www.dropbox.com/s/wujcee1gd87gk6o/jstack.out?dl=0
>>>
>>> 2- If I enable address resolution for the thick client then all the
>>> commands work ok. I also see an "Accepted incoming communication
>>> connection" log in the client.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, 29 Jun 2020 at 15:30, Ilya Kasnacheev 
>>> wrote:
>>>
 Hello!

 The easiest way 

Re: Blocked system-critical thread has been detected - After upgrade to 2.8.1

[akorensh]

Manu,
  Can you set up the lightest load/simplest topology possible, send the
Ignite logs from 
  all nodes(server and clients), including the GC logs, and we will take a
look.
 
https://apacheignite.readme.io/docs/jvm-and-system-tuning#detailed-garbage-collection-stats
Thanks, Alex



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: CusterGroup topology unexpectedly empty

[akurbanov]

Using ignite reference is completely fine.

What is the exact exception being thrown in this case? I would expect to see
this if the node is out of topology, what does the logs tell? Do other nodes
see this one in the topology?

Please check if there are NODE_FAILED events for the node on other topology
members, where the exception is observed.

Best regards,
Anton



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Ignite node log file setup

[kay]

Hello, I'm waiting for reply :)

How can I set system property to use in ignite config file??
I set and got a error so , attacted log file before..

Thank you so much



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

CusterGroup topology unexpectedly empty

[Raymond Wilson]

I've been researching a problem where we see a ClusterGroup topology
becoming unexpectedly empty. I have not found anything that is similar to
my case outlined below:

We have some code using the C# client on Ignite 2.8.0 like this:

var _group = _ignite?.GetCluster()?.ForAttribute(_roleAttribute, "True");

There are nodes in the grid (deployed on AWS EKS) that have a local
attribute with the  _roleAttribute name set to the value "True", yet this
command sometimes decides that there are no matching nodes. Once it does
so, it does not seem to change requiring a restart of the grid.

In this instance, the _ignite reference may be a long lived reference to
the object returned by Ignition.GetIgnite("GridName") and cached for future
reference. Is this a safe practice, or can the underlying Ingite object
change leaving a long lived Ignite reference containing stale state
information about the grid?

Thanks,
Raymond.
.

-- 

Raymond Wilson
Solution Architect, Civil Construction Software Systems (CCSS)
11 Birmingham Drive | Christchurch, New Zealand
+64-21-2013317 Mobile
raymond_wil...@trimble.com

Re: Blocked system-critical thread has been detected - After upgrade to 2.8.1

[Manu]

Hi Alex, thanks so much.

We are reduced topology to picture below (1 server node and 3 clients).

- 1 Ignite server node: IMDB with persistence enabled
- 3 Ignite client nodes: for SQL query, messaging (topic, queue) and
countdown latches.

All pluggable elements (TOPIC listener and QUEUE listener) are online.

This topology works perfectly with 2.7.6. But with 2.8.1 not... 

Also we are detected that failure (blocked thread) occurs when pluggable
modules are online (green lines and blocks) and we make only 1 request (not
by heavy load).

 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/