Memory leak in MapNodeResults

[18624049226]

start 2 node by ignite.sh

execute the following SQL:
create table dwd_t_order_loan_apply (
order_id varchar,
identity_no varchar,
loan_date varchar,
primary key (order_id,identity_no)
) WITH 
"template=partitioned,affinity_key=identity_no,CACHE_NAME=dwd_t_order_loan_apply";


create table dim_current_x_day (
id int,
biz_type int,
PRIMARY KEY (id)
) WITH "TEMPLATE=replicated,CACHE_NAME=dim_current_x_day";

INSERT INTO DWD_T_ORDER_LOAN_APPLY (ORDER_ID,IDENTITY_NO,LOAN_DATE) 
VALUES ('10081','510322199908266091','2023-11-09 15:05:04');


INSERT INTO DIM_CURRENT_X_DAY (ID,BIZ_TYPE) VALUES (1,1);
INSERT INTO DIM_CURRENT_X_DAY (ID,BIZ_TYPE) VALUES (3,1);
INSERT INTO DIM_CURRENT_X_DAY (ID,BIZ_TYPE) VALUES (7,1);
INSERT INTO DIM_CURRENT_X_DAY (ID,BIZ_TYPE) VALUES (15,1);
INSERT INTO DIM_CURRENT_X_DAY (ID,BIZ_TYPE) VALUES (30,1);

execute following query some times:

SELECT b.id,
max(last_trade) "last_trade"
from
(select max(loan_date) last_trade
from dwd_t_order_loan_apply where identity_no='510322199908266091'
) a JOIN dim_current_x_day b
GROUP BY b.id;

execute following command :
jmap -dump:format=b,file=/data/ignite.bin 

open ignite.bin by eclipse MAT:
At this point, you will see that there is data in the res instance 
object in MapNodeResults, which can lead to a serious memory leak issue, 
which is a serious vulnerability.
The normal SQL execution process involves releasing the resources held 
in the res instance object in MapNodeResults after a SQL query is executed.


issues.apache.org

[IGNITE-22437] Memory leak in MapNodeResults - ASF JIRA <#>

 https://issues.apache.org/jira/browse/IGNITE-22437 

Connecting cluster with Grid Gain Control Center

[BEELA GAYATRI via user]

TCS Confidential

Dear Team,

   Please suggest how to connect grid gain control center with the cluster  
that is  running our local server .We are using  Apache ignite 2.16.0. While 
generating token we are getting the below error from the control center. We 
have downloaded the agent


http://localhost:3000, cause="Connection refused: no further information"]
java.util.concurrent.ExecutionException: javax.websocket.DeploymentException: 
Connection failed.
at java.util.concurrent.FutureTask.report(FutureTask.java:122) 
~[?:?]
at java.util.concurrent.FutureTask.get(FutureTask.java:205) 
~[?:?]
at 
org.gridgain.control.springframework.util.concurrent.SettableListenableFuture.get(SettableListenableFuture.java:136)
 ~[control-center-agent-2.16.0.0.jar:?]
at 
org.gridgain.control.agent.transport.ws.WebSocketConnectionFactory.connect(WebSocketConnectionFactory.java:143)
 ~[control-center-agent-2.16.0.0.jar:?]
at 
org.gridgain.control.agent.transport.ws.WebSocketControlCenterClient$ControlCenterAgentConnectionWorker.connect(WebSocketControlCenterClient.java:385)
 ~[control-center-agent-2.16.0.0.jar:?]
at 
org.gridgain.control.agent.transport.ws.WebSocketControlCenterClient$ControlCenterAgentConnectionWorker.run(WebSocketControlCenterClient.java:343)
 [control-center-agent-2.16.0.0.jar:?]
Caused by: javax.websocket.DeploymentException: Connection failed.
at 
org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket._connect(GrizzlyClientSocket.java:413)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.access$000(GrizzlyClientSocket.java:81)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:212)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket$1.call(GrizzlyClientSocket.java:208)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.container.grizzly.client.GrizzlyClientSocket.connect(GrizzlyClientSocket.java:226)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.container.grizzly.client.GrizzlyClientContainer.openClientSocket(GrizzlyClientContainer.java:72)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.client.ClientManager$3$1.run(ClientManager.java:647) 
~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.client.ClientManager$3.run(ClientManager.java:696) 
~[tyrus-standalone-client-1.19.jar:?]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) 
~[?:?]
at 
org.glassfish.tyrus.client.ClientManager$SameThreadExecutorService.execute(ClientManager.java:849)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:118)
 ~[?:?]
at 
org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:493)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.tyrus.client.ClientManager.connectToServer(ClientManager.java:337)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.gridgain.control.springframework.web.socket.client.standard.StandardWebSocketClient.lambda$doHandshakeInternal$0(StandardWebSocketClient.java:151)
 ~[control-center-agent-2.16.0.0.jar:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) 
~[?:?]
at java.lang.Thread.run(Thread.java:834) ~[?:?]
Caused by: java.net.ConnectException: Connection refused: no further information
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) 
~[?:?]
at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:779) ~[?:?]
at 
org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler.onConnectedAsync(TCPNIOConnectorHandler.java:187)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.grizzly.nio.transport.TCPNIOConnectorHandler$1.connected(TCPNIOConnectorHandler.java:135)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.grizzly.nio.transport.TCPNIOConnection.onConnect(TCPNIOConnection.java:234)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:506)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:89)
 ~[tyrus-standalone-client-1.19.jar:?]
at 
org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:94)
 

Re: Ignite TryGet - cache data not found intermittently

[Charlin S]

Hi Pavel,
Thanking for your email.
> Perhaps something else is involved here, another thread or node changing
the value?
   I checked the application log and another thread did not do any other
operation for this particular data between this 45 seconds time gap.
   no chance for changing cache key value as this data is able to be read
after some time.
 I will keep you posted for small projects.

Thanks & Regards,
Charlin



On Thu, 6 Jun 2024 at 11:11, Pavel Tupitsyn  wrote:

> > Put and tryget are in two different methods called one after another
>
> That would be a very apparent bug in Ignite, and I don't see anything like
> that in JIRA or release notes.
> Perhaps something else is involved here, another thread or node changing
> the value?
>
> Please prepare a small project that we can run to reproduce the issue.
>
> On Wed, Jun 5, 2024 at 9:18 PM Charlin S  wrote:
>
>> Hi,
>> Put and tryget are in two different methods called one after another one
>> with some time gap based on work flow process
>>
>> We felt Ignite 2.10 okay for us.
>>
>> Thanks and Regards
>> Charlin
>>
>> On Wed, 5 Jun, 2024, 8:23 pm Pavel Tupitsyn, 
>> wrote:
>>
>>> - Do you run Put and TryGet on the same node?
>>> - Do you have a reproducer?
>>> - Ignite 2.10 was released 3 years ago, have you tried a newer version?
>>>
>>> On Wed, Jun 5, 2024 at 3:49 PM Charlin S  wrote:
>>>
 Hi All,
 I am unable to fetch data from cache by reading by
 key.intermittently (very rarely).

 Ignite version: 2.10
 Cache mode: Partition
 Client : C# with Ignite thick client

 Scenario:
 My C# application received a request for cache data insertion
 @ 09:09:35 and successfully insertion initiated at application side.
 Thereafter @ 09:10:21 C# application received a request to read cache
 data for the same key and Ignite TryGet could not fetch data.
 Note: We are able to get cache data by the same key after some time.

 Cache creation code
 var IgniteCache= IIgnite.GetCache("cacheModel")
 .WithExpiryPolicy(new ExpiryPolicy(
  TimeSpan.FromMinutes(60),
  TimeSpan.FromMinutes(60),
  TimeSpan.FromMinutes(60)
  ));

 Cache data insertion code
 IgniteCache.Put(cacheKey, (T)data);

 Cache data reading code
   IgniteCache.TryGet(Key, out var value);

 Thanks & Regards,
 Charlin

Re: Ignite TryGet - cache data not found intermittently

[Pavel Tupitsyn]

> Put and tryget are in two different methods called one after another

That would be a very apparent bug in Ignite, and I don't see anything like
that in JIRA or release notes.
Perhaps something else is involved here, another thread or node changing
the value?

Please prepare a small project that we can run to reproduce the issue.

On Wed, Jun 5, 2024 at 9:18 PM Charlin S  wrote:

> Hi,
> Put and tryget are in two different methods called one after another one
> with some time gap based on work flow process
>
> We felt Ignite 2.10 okay for us.
>
> Thanks and Regards
> Charlin
>
> On Wed, 5 Jun, 2024, 8:23 pm Pavel Tupitsyn,  wrote:
>
>> - Do you run Put and TryGet on the same node?
>> - Do you have a reproducer?
>> - Ignite 2.10 was released 3 years ago, have you tried a newer version?
>>
>> On Wed, Jun 5, 2024 at 3:49 PM Charlin S  wrote:
>>
>>> Hi All,
>>> I am unable to fetch data from cache by reading by
>>> key.intermittently (very rarely).
>>>
>>> Ignite version: 2.10
>>> Cache mode: Partition
>>> Client : C# with Ignite thick client
>>>
>>> Scenario:
>>> My C# application received a request for cache data insertion @ 09:09:35
>>> and successfully insertion initiated at application side.
>>> Thereafter @ 09:10:21 C# application received a request to read cache
>>> data for the same key and Ignite TryGet could not fetch data.
>>> Note: We are able to get cache data by the same key after some time.
>>>
>>> Cache creation code
>>> var IgniteCache= IIgnite.GetCache("cacheModel")
>>> .WithExpiryPolicy(new ExpiryPolicy(
>>>  TimeSpan.FromMinutes(60),
>>>  TimeSpan.FromMinutes(60),
>>>  TimeSpan.FromMinutes(60)
>>>  ));
>>>
>>> Cache data insertion code
>>> IgniteCache.Put(cacheKey, (T)data);
>>>
>>> Cache data reading code
>>>   IgniteCache.TryGet(Key, out var value);
>>>
>>> Thanks & Regards,
>>> Charlin
>>>
>>>
>>>
>>>

Re: Ignite TryGet - cache data not found intermittently

[Charlin S]

Hi,
Put and tryget are in two different methods called one after another one
with some time gap based on work flow process

We felt Ignite 2.10 okay for us.

Thanks and Regards
Charlin

On Wed, 5 Jun, 2024, 8:23 pm Pavel Tupitsyn,  wrote:

> - Do you run Put and TryGet on the same node?
> - Do you have a reproducer?
> - Ignite 2.10 was released 3 years ago, have you tried a newer version?
>
> On Wed, Jun 5, 2024 at 3:49 PM Charlin S  wrote:
>
>> Hi All,
>> I am unable to fetch data from cache by reading by
>> key.intermittently (very rarely).
>>
>> Ignite version: 2.10
>> Cache mode: Partition
>> Client : C# with Ignite thick client
>>
>> Scenario:
>> My C# application received a request for cache data insertion @ 09:09:35
>> and successfully insertion initiated at application side.
>> Thereafter @ 09:10:21 C# application received a request to read cache
>> data for the same key and Ignite TryGet could not fetch data.
>> Note: We are able to get cache data by the same key after some time.
>>
>> Cache creation code
>> var IgniteCache= IIgnite.GetCache("cacheModel")
>> .WithExpiryPolicy(new ExpiryPolicy(
>>  TimeSpan.FromMinutes(60),
>>  TimeSpan.FromMinutes(60),
>>  TimeSpan.FromMinutes(60)
>>  ));
>>
>> Cache data insertion code
>> IgniteCache.Put(cacheKey, (T)data);
>>
>> Cache data reading code
>>   IgniteCache.TryGet(Key, out var value);
>>
>> Thanks & Regards,
>> Charlin
>>
>>
>>
>>

Re: Ignite TryGet - cache data not found intermittently

[Pavel Tupitsyn]

- Do you run Put and TryGet on the same node?
- Do you have a reproducer?
- Ignite 2.10 was released 3 years ago, have you tried a newer version?

On Wed, Jun 5, 2024 at 3:49 PM Charlin S  wrote:

> Hi All,
> I am unable to fetch data from cache by reading by
> key.intermittently (very rarely).
>
> Ignite version: 2.10
> Cache mode: Partition
> Client : C# with Ignite thick client
>
> Scenario:
> My C# application received a request for cache data insertion @ 09:09:35
> and successfully insertion initiated at application side.
> Thereafter @ 09:10:21 C# application received a request to read cache data
> for the same key and Ignite TryGet could not fetch data.
> Note: We are able to get cache data by the same key after some time.
>
> Cache creation code
> var IgniteCache= IIgnite.GetCache("cacheModel")
> .WithExpiryPolicy(new ExpiryPolicy(
>  TimeSpan.FromMinutes(60),
>  TimeSpan.FromMinutes(60),
>  TimeSpan.FromMinutes(60)
>  ));
>
> Cache data insertion code
> IgniteCache.Put(cacheKey, (T)data);
>
> Cache data reading code
>   IgniteCache.TryGet(Key, out var value);
>
> Thanks & Regards,
> Charlin
>
>
>
>

Ignite TryGet - cache data not found intermittently

[Charlin S]

Hi All,
I am unable to fetch data from cache by reading by key.intermittently (very
rarely).

Ignite version: 2.10
Cache mode: Partition
Client : C# with Ignite thick client

Scenario:
My C# application received a request for cache data insertion @ 09:09:35
and successfully insertion initiated at application side.
Thereafter @ 09:10:21 C# application received a request to read cache data
for the same key and Ignite TryGet could not fetch data.
Note: We are able to get cache data by the same key after some time.

Cache creation code
var IgniteCache= IIgnite.GetCache("cacheModel")
.WithExpiryPolicy(new ExpiryPolicy(
 TimeSpan.FromMinutes(60),
 TimeSpan.FromMinutes(60),
 TimeSpan.FromMinutes(60)
 ));

Cache data insertion code
IgniteCache.Put(cacheKey, (T)data);

Cache data reading code
  IgniteCache.TryGet(Key, out var value);

Thanks & Regards,
Charlin

Enabling required jmx metrics with in specific registry group

[Murli Malik]

Hi All,

We are using default jmxexporter spi for monitering the cluster(2.16),
There are lot of metrics in the higher version, want to enable only
required metrics with in specific metric registry at cluster side. For
example, want to enable only StorageSize with in io.datastorage registry
group.

Got to know we can enable, can somebody help us with sample spring xml
configuration for the same.


And also, we have enable only jmxexporterspi but sys view having metrics
details, need to disable sys view metrics also. Any idea how to disable
system view?, below is our server-config file.



## Server config ##


http://www.springframework.org/schema/beans;
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
  xmlns:util="http://www.springframework.org/schema/util;
xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans.xsd
  http://www.springframework.org/schema/util
http://www.springframework.org/schema/util/spring-util.xsd;>
  
  

  
  












  

  


  

  






  













  

  


  


  

  

  

  

  

  


  

  

  

Re: Inquiry about Data Storage in ignite3: RockDB Usage and Data Preloading

[Pavel Tupitsyn]

Hello,

- Ignite 3 has native storage that does not rely on any third-party
implementations, similar to Ignite 2.
- RocksDB is a secondary, optional storage implementation.
- You don't need to preload data like in Ignite 2 (neither for native
storage nor for RocksDB)

On Tue, Jun 4, 2024 at 12:33 PM 常鑫  wrote:

> Hello，
> I am trying out ignite3 and have a few questions about RocksDB.
> My specific questions are as follows:
> 1. Is the usage of RocksDB in Ignite3 equivalent to using Ignite3's native
> storage, or are there any significant differences in terms of performance,
> maintenance, or functionality?
> 2. If I were to use RocksDB, would I need to preload data before it can be
> effectively utilized by Ignite3? (Like loadCache() in Ignite2)
> 3. Are there any specific use cases ?
> Your expertise in this area would be greatly appreciated.
> Thanks,
> Xin Chang
>
>

Inquiry about Data Storage in ignite3: RockDB Usage and Data Preloading

[常鑫]

Hello，
I am trying out ignite3 and have a few questions about RocksDB.
My specific questions are as follows:
1. Is the usage of RocksDB in Ignite3 equivalent to using Ignite3's native 
storage, or are there any significant differences in terms of performance, 
maintenance, or functionality?
2. If I were to use RocksDB, would I need to preload data before it can be 
effectively utilized by Ignite3? (Like loadCache() in Ignite2)
3. Are there any specific use cases ?
Your expertise in this area would be greatly appreciated.
Thanks,
Xin Chang

Re: Will Apache Ignite 3.0 be compliant with JSR107 sepc?

[Stephen Darlington]

The way that clients operate is quite different in AI3. You can't assume
the same thick/thin distinction.

There are two answers to your question:

1. Ignite 2 will continue to be available. Version 3 is a big update and
it's unlikely that everyone will move over on day 1. So if you like AI2,
it's safe to use it
2. Ignite 3 is currently in beta, so no one can give you definitive
answers. However, the goal is that AI3 will support the same (and more!)
workloads as 2, although the way you achieve the functionality may differ


On Mon, 3 Jun 2024 at 22:43, Amit Jolly  wrote:

> Hi Pavel,
>
> Thanks for the quick response.
>
> We are currently evaluating Apache Ignite for our project and are planning
> to use features like *CacheEntryProcessor*, *Thick clients with Near
> Cache *(Looks like 3.0 will only have thin clients and near cache is only
> supported in thick clients) and *Continues query cache*, while going
> through the code of 3.0, I could not find/validate whether these features
> will be supported in 3.0 or not.
>
> Is there any matrix which explains/shows feature to feature comparison
> between 2.X and 3.0?
>
> Thanks,
>
> Amit Jolly
>
> On Mon, Jun 3, 2024 at 1:41 AM Pavel Tupitsyn 
> wrote:
>
>> Amit, unfortunately, I don't have answers at the moment.
>>
>> I think a JSR107 wrapper can be developed on top of existing Ignite 3
>> APIs (Table + Compute), including CacheEntryProcessor support, but we don't
>> have specific plans for now.
>>
>> On Fri, May 31, 2024 at 4:34 PM Amit Jolly  wrote:
>>
>>> Hi Pavel,
>>>
>>> Thanks for the quick response.
>>>
>>> I had looked at the ignite-3 github repo and could not find any
>>> reference to JSR 107, hence asked this question.
>>>
>>> Since Ignite 2.X is fully JSR 107 compliant, now the question is if
>>> ignite-3 is going to be the successor of Ignite 2.X and is going to replace
>>> Ignite 2.X in future, will Ignite 3 be JSR 107 compliant as well? If yes,
>>> do we have timelines when ignite-3 will be JSR 107 compliant, If no, what
>>> will be the migration strategy for the current Ignite 2.X user using
>>> features listed in JSR 107.
>>>
>>> Thanks,
>>>
>>> Amit Jolly
>>>
>>>
>>>
>>>
>>>
>>> On Fri, May 31, 2024 at 12:08 AM Pavel Tupitsyn 
>>> wrote:
>>>
 For now it does not have any of that. KeyValueView [1] is a table
 access interface in Ignite 3 that is most similar to a "cache".


 https://github.com/apache/ignite-3/blob/main/modules/api/src/main/java/org/apache/ignite/table/KeyValueView.java

 On Thu, May 30, 2024 at 6:19 PM Amit Jolly 
 wrote:

> HI,
>
> Will Apache Ignite 3.0 be compliant with JSR107 sepc?
>
> In particular, I am looking at the feature CacheEntryProcessor support
> in Ignite 3.0
>
>
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-
>
>
> https://www.javadoc.io/doc/javax.cache/cache-api/latest/javax/cache/processor/EntryProcessor.html
>
> Thanks,
>
> Amit Jolly
>

Re: Will Apache Ignite 3.0 be compliant with JSR107 sepc?

[Amit Jolly]

Hi Pavel,

Thanks for the quick response.

We are currently evaluating Apache Ignite for our project and are planning
to use features like *CacheEntryProcessor*, *Thick clients with Near
Cache *(Looks
like 3.0 will only have thin clients and near cache is only supported in
thick clients) and *Continues query cache*, while going through the code of
3.0, I could not find/validate whether these features will be supported in
3.0 or not.

Is there any matrix which explains/shows feature to feature comparison
between 2.X and 3.0?

Thanks,

Amit Jolly

On Mon, Jun 3, 2024 at 1:41 AM Pavel Tupitsyn  wrote:

> Amit, unfortunately, I don't have answers at the moment.
>
> I think a JSR107 wrapper can be developed on top of existing Ignite 3 APIs
> (Table + Compute), including CacheEntryProcessor support, but we don't have
> specific plans for now.
>
> On Fri, May 31, 2024 at 4:34 PM Amit Jolly  wrote:
>
>> Hi Pavel,
>>
>> Thanks for the quick response.
>>
>> I had looked at the ignite-3 github repo and could not find any reference
>> to JSR 107, hence asked this question.
>>
>> Since Ignite 2.X is fully JSR 107 compliant, now the question is if
>> ignite-3 is going to be the successor of Ignite 2.X and is going to replace
>> Ignite 2.X in future, will Ignite 3 be JSR 107 compliant as well? If yes,
>> do we have timelines when ignite-3 will be JSR 107 compliant, If no, what
>> will be the migration strategy for the current Ignite 2.X user using
>> features listed in JSR 107.
>>
>> Thanks,
>>
>> Amit Jolly
>>
>>
>>
>>
>>
>> On Fri, May 31, 2024 at 12:08 AM Pavel Tupitsyn 
>> wrote:
>>
>>> For now it does not have any of that. KeyValueView [1] is a table access
>>> interface in Ignite 3 that is most similar to a "cache".
>>>
>>>
>>> https://github.com/apache/ignite-3/blob/main/modules/api/src/main/java/org/apache/ignite/table/KeyValueView.java
>>>
>>> On Thu, May 30, 2024 at 6:19 PM Amit Jolly  wrote:
>>>
 HI,

 Will Apache Ignite 3.0 be compliant with JSR107 sepc?

 In particular, I am looking at the feature CacheEntryProcessor support
 in Ignite 3.0


 https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-


 https://www.javadoc.io/doc/javax.cache/cache-api/latest/javax/cache/processor/EntryProcessor.html

 Thanks,

 Amit Jolly

>>>

Re: Will Apache Ignite 3.0 be compliant with JSR107 sepc?

[Pavel Tupitsyn]

Amit, unfortunately, I don't have answers at the moment.

I think a JSR107 wrapper can be developed on top of existing Ignite 3 APIs
(Table + Compute), including CacheEntryProcessor support, but we don't have
specific plans for now.

On Fri, May 31, 2024 at 4:34 PM Amit Jolly  wrote:

> Hi Pavel,
>
> Thanks for the quick response.
>
> I had looked at the ignite-3 github repo and could not find any reference
> to JSR 107, hence asked this question.
>
> Since Ignite 2.X is fully JSR 107 compliant, now the question is if
> ignite-3 is going to be the successor of Ignite 2.X and is going to replace
> Ignite 2.X in future, will Ignite 3 be JSR 107 compliant as well? If yes,
> do we have timelines when ignite-3 will be JSR 107 compliant, If no, what
> will be the migration strategy for the current Ignite 2.X user using
> features listed in JSR 107.
>
> Thanks,
>
> Amit Jolly
>
>
>
>
>
> On Fri, May 31, 2024 at 12:08 AM Pavel Tupitsyn 
> wrote:
>
>> For now it does not have any of that. KeyValueView [1] is a table access
>> interface in Ignite 3 that is most similar to a "cache".
>>
>>
>> https://github.com/apache/ignite-3/blob/main/modules/api/src/main/java/org/apache/ignite/table/KeyValueView.java
>>
>> On Thu, May 30, 2024 at 6:19 PM Amit Jolly  wrote:
>>
>>> HI,
>>>
>>> Will Apache Ignite 3.0 be compliant with JSR107 sepc?
>>>
>>> In particular, I am looking at the feature CacheEntryProcessor support
>>> in Ignite 3.0
>>>
>>>
>>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-
>>>
>>>
>>> https://www.javadoc.io/doc/javax.cache/cache-api/latest/javax/cache/processor/EntryProcessor.html
>>>
>>> Thanks,
>>>
>>> Amit Jolly
>>>
>>

Re: Will Apache Ignite 3.0 be compliant with JSR107 sepc?

[Amit Jolly]

Hi Pavel,

Thanks for the quick response.

I had looked at the ignite-3 github repo and could not find any reference
to JSR 107, hence asked this question.

Since Ignite 2.X is fully JSR 107 compliant, now the question is if
ignite-3 is going to be the successor of Ignite 2.X and is going to replace
Ignite 2.X in future, will Ignite 3 be JSR 107 compliant as well? If yes,
do we have timelines when ignite-3 will be JSR 107 compliant, If no, what
will be the migration strategy for the current Ignite 2.X user using
features listed in JSR 107.

Thanks,

Amit Jolly





On Fri, May 31, 2024 at 12:08 AM Pavel Tupitsyn 
wrote:

> For now it does not have any of that. KeyValueView [1] is a table access
> interface in Ignite 3 that is most similar to a "cache".
>
>
> https://github.com/apache/ignite-3/blob/main/modules/api/src/main/java/org/apache/ignite/table/KeyValueView.java
>
> On Thu, May 30, 2024 at 6:19 PM Amit Jolly  wrote:
>
>> HI,
>>
>> Will Apache Ignite 3.0 be compliant with JSR107 sepc?
>>
>> In particular, I am looking at the feature CacheEntryProcessor support in
>> Ignite 3.0
>>
>>
>> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-
>>
>>
>> https://www.javadoc.io/doc/javax.cache/cache-api/latest/javax/cache/processor/EntryProcessor.html
>>
>> Thanks,
>>
>> Amit Jolly
>>
>

RE: Best way to update and organize nodes

[Louis C]

Thanks for you answer, this is what I was looking for.
https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html

De : Jeremy McMillan 
Envoyé : jeudi 30 mai 2024 19:33
À : user@ignite.apache.org 
Objet : Re: Best way to update and organize nodes

This could work if you set up availability zones and use backup filters. Then 
you could perform maintenance one entire AZ at a time. When running during 
maintenance, your workload might exceed the capacity of the fraction of server 
nodes remaining up, so beware that.



On Thu, May 30, 2024, 11:30 Louis C mailto:l...@outlook.fr>> 
wrote:
Hello everyone,


I had a question that I could not really answer reading the documentation :
Let's say I have a cluster of 10 Ignite server nodes, with one cache with 
persistent data and 2 data backups.

I want to update the different nodes while maintaining the cluster activity 
(answering the clients requests). To do so I can stop gracefully one node, 
update it, and restart it, and then take care of the following nodes in the 
same fashion.
In my understanding, this should ensure that no data is lost and that the 
cluster is still active (is this really the case ?).
But this is quite long.

I wanted to know if it was possible to set the different partitions in such a 
way that we know that we can shutdown half (or 1/3) of the nodes in the same 
time, to speed up this process.
I guess it would be as if we have 5 primary nodes and 5 backups nodes, and that 
the 5 backup nodes take over when the 5 primary nodes shut down.


Is such a thing possible ?

Best regards,

Louis C.

Re: Will Apache Ignite 3.0 be compliant with JSR107 sepc?

[Pavel Tupitsyn]

For now it does not have any of that. KeyValueView [1] is a table access
interface in Ignite 3 that is most similar to a "cache".

https://github.com/apache/ignite-3/blob/main/modules/api/src/main/java/org/apache/ignite/table/KeyValueView.java

On Thu, May 30, 2024 at 6:19 PM Amit Jolly  wrote:

> HI,
>
> Will Apache Ignite 3.0 be compliant with JSR107 sepc?
>
> In particular, I am looking at the feature CacheEntryProcessor support in
> Ignite 3.0
>
>
> https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-
>
>
> https://www.javadoc.io/doc/javax.cache/cache-api/latest/javax/cache/processor/EntryProcessor.html
>
> Thanks,
>
> Amit Jolly
>

Re: Best way to update and organize nodes

[Jeremy McMillan]

This could work if you set up availability zones and use backup filters.
Then you could perform maintenance one entire AZ at a time. When running
during maintenance, your workload might exceed the capacity of the fraction
of server nodes remaining up, so beware that.



On Thu, May 30, 2024, 11:30 Louis C  wrote:

> Hello everyone,
>
>
> I had a question that I could not really answer reading the documentation :
> Let's say I have a cluster of 10 Ignite server nodes, with one cache with
> persistent data and 2 data backups.
>
> I want to update the different nodes while maintaining the cluster
> activity (answering the clients requests). To do so I can stop gracefully
> one node, update it, and restart it, and then take care of the following
> nodes in the same fashion.
> In my understanding, this should ensure that no data is lost and that the
> cluster is still active (is this really the case ?).
> But this is quite long.
>
> I wanted to know if it was possible to set the different partitions in
> such a way that we know that we can shutdown half (or 1/3) of the nodes in
> the same time, to speed up this process.
> I guess it would be as if we have 5 primary nodes and 5 backups nodes, and
> that the 5 backup nodes take over when the 5 primary nodes shut down.
>
>
> Is such a thing possible ?
>
> Best regards,
>
> Louis C.
>
>

Best way to update and organize nodes

[Louis C]

Hello everyone,


I had a question that I could not really answer reading the documentation :
Let's say I have a cluster of 10 Ignite server nodes, with one cache with 
persistent data and 2 data backups.

I want to update the different nodes while maintaining the cluster activity 
(answering the clients requests). To do so I can stop gracefully one node, 
update it, and restart it, and then take care of the following nodes in the 
same fashion.
In my understanding, this should ensure that no data is lost and that the 
cluster is still active (is this really the case ?).
But this is quite long.

I wanted to know if it was possible to set the different partitions in such a 
way that we know that we can shutdown half (or 1/3) of the nodes in the same 
time, to speed up this process.
I guess it would be as if we have 5 primary nodes and 5 backups nodes, and that 
the 5 backup nodes take over when the 5 primary nodes shut down.


Is such a thing possible ?

Best regards,

Louis C.

Will Apache Ignite 3.0 be compliant with JSR107 sepc?

[Amit Jolly]

HI,

Will Apache Ignite 3.0 be compliant with JSR107 sepc?

In particular, I am looking at the feature CacheEntryProcessor support in
Ignite 3.0

https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/IgniteCache.html#invoke-K-org.apache.ignite.cache.CacheEntryProcessor-java.lang.Object...-

https://www.javadoc.io/doc/javax.cache/cache-api/latest/javax/cache/processor/EntryProcessor.html

Thanks,

Amit Jolly

Re: 2.x timeline and migration to 3.x

[Raymond Liu]

Thank you so much, Pavel! That is all great to hear.

On Thu, May 30, 2024 at 9:13 AM Pavel Tupitsyn  wrote:

> > will 2.x continue to be developed for a year or two, will it be on
> critical patch support, or will it no longer be developed at all?
>
> 2.x and 3.x will co-exist in foreseeable future
>
> > will there be a typical upgrade path from 2.x to 3.x for existing
> clusters
>
> Yes
>
> > Is there a general target timeframe for Ignite 3.x to hit general
> availability
>
> 2024
>
> On Thu, May 30, 2024 at 2:56 PM Raymond Liu  wrote:
>
>> Hello,
>>
>> Does anyone know the plans for Ignite 2.x after 3.0 is released? e.g.
>> will 2.x continue to be developed for a year or two, will it be on critical
>> patch support, or will it no longer be developed at all?
>>
>> And, in the same vein, will there be a typical upgrade path from 2.x to
>> 3.x for existing clusters, or have the internals changed too much for that?
>>
>> Is there a general target timeframe for Ignite 3.x to hit general
>> availability? e.g. 2024-2025 vs. 2027-2029.
>>
>> I'm writing a proof of concept with Ignite 2.16 on a small team, and
>> answers to these questions will help us choose whether to use Ignite, which
>> features to rely on, and how soon we might plan for a migration after our
>> initial work.
>>
>> Thanks,
>> Raymond
>>
>

Re: 2.x timeline and migration to 3.x

[Pavel Tupitsyn]

> will 2.x continue to be developed for a year or two, will it be on
critical patch support, or will it no longer be developed at all?

2.x and 3.x will co-exist in foreseeable future

> will there be a typical upgrade path from 2.x to 3.x for existing clusters

Yes

> Is there a general target timeframe for Ignite 3.x to hit general
availability

2024

On Thu, May 30, 2024 at 2:56 PM Raymond Liu  wrote:

> Hello,
>
> Does anyone know the plans for Ignite 2.x after 3.0 is released? e.g. will
> 2.x continue to be developed for a year or two, will it be on critical
> patch support, or will it no longer be developed at all?
>
> And, in the same vein, will there be a typical upgrade path from 2.x to
> 3.x for existing clusters, or have the internals changed too much for that?
>
> Is there a general target timeframe for Ignite 3.x to hit general
> availability? e.g. 2024-2025 vs. 2027-2029.
>
> I'm writing a proof of concept with Ignite 2.16 on a small team, and
> answers to these questions will help us choose whether to use Ignite, which
> features to rely on, and how soon we might plan for a migration after our
> initial work.
>
> Thanks,
> Raymond
>

2.x timeline and migration to 3.x

[Raymond Liu]

Hello,

Does anyone know the plans for Ignite 2.x after 3.0 is released? e.g. will
2.x continue to be developed for a year or two, will it be on critical
patch support, or will it no longer be developed at all?

And, in the same vein, will there be a typical upgrade path from 2.x to 3.x
for existing clusters, or have the internals changed too much for that?

Is there a general target timeframe for Ignite 3.x to hit general
availability? e.g. 2024-2025 vs. 2027-2029.

I'm writing a proof of concept with Ignite 2.16 on a small team, and
answers to these questions will help us choose whether to use Ignite, which
features to rely on, and how soon we might plan for a migration after our
initial work.

Thanks,
Raymond

Re: Node requires maintenance, non-empty set of maintainance tasks is found - node is not coming up

[Jeremy McMillan]

If backup partitions are available when a node is lost, we should not
expect lost partitions.

There is a lot more to this story than this thread explains, so for the
community: please don't follow this procedure.

https://ignite.apache.org/docs/latest/configuring-caches/partition-loss-policy
"A partition is lost when both the primary copy and all backup copies of
the partition are not available to the cluster, i.e. when the primary and
backup nodes for the partition become unavailable."

If you attempt to access a cache and receive a lost partitions error, this
means there IS DATA LOSS. Partition loss means there are no primary or
backup copies of a particular cache partition available. Have multiple
server nodes experienced trouble? Can we be certain that the affected
caches were created with backups>=1?

If a node fails to start up, and complains about maintenance tasks, we
should be very suspicious this node's persistent data is corrupted. If the
cluster is activated with a missing node and caches have lost partitions,
then we know these caches have lost some data. If there are no lost
partitions, we can safely remove the corrupted node from the baseline and
bring up a fresh node, and add it to the baseline to replace it thus
restoring redundancy. If there are lost partitions and we need to reset
lost partitions to bring a cache back online, we should expect that cache
is missing some data and may need to be reloaded.

Cache configuration backups=2 is excessive except in edge cases. For
backups=n, the memory and persistence footprint cost is n+1 times the
nominal data footprint. This scales linear. The marginal utility we derive
from each additional backup copy is diminishing because for a probability
of any single node failure p or p/1, the likelihood of needing those extra
copies is p/(n+1) for n backup copies.

Think of backup partitions like multiple coats of paint. After the second
coat, nobody will be able to tell the difference if you applied a third or
fourth coat. It still takes the same effort and materials to apply each
coat of paint.

If you NEED fault tolerance, then it should be mandatory to conduct testing
to make sure the configuration you have chosen is working as expected. If
backups=1 isn't effective for single node failures, then backups=2 will
make no beneficial difference. With backups=1 we should expect a cache to
work without complaining about lost partitions when one server node is
offline.

On Wed, May 29, 2024 at 12:15 PM Naveen Kumar 
wrote:

> Thanks very much for your prompt response Gianluca
>
> just for the community, I could solve this by running the control.sh with
> reset lost partitions for individual cachereset_lost_partitions
> looks like it worked, those partition issue is resolved, I suppose there
> wouldnt be any data loss as we have set all our caches with 2 replicas
>
> coming to the node which was not getting added to the cluster earlier,
> removed from baseline --> cleared all persistence store --> brought up the
> node --> added the node to baseline, this also seems to have worked fine.
>
> Thanks
>
>
> On Wed, May 29, 2024 at 5:13 PM Gianluca Bonetti <
> gianluca.bone...@gmail.com> wrote:
>
>> Hello Naveen
>>
>> Apache Ignite 2.13 is more than 2 years old, 25 months old in actual fact.
>> Three bugfix releases had been rolled out over time up to 2.16 release.
>>
>> It seems you are restarting your cluster on a regular basis, so you'd
>> better upgrade to 2.16 as soon as possible.
>> Otherwise it will also be very difficult for people on a community based
>> mailing list, on volunteer time, to work out a solution with a 2 years old
>> version running.
>>
>> Besides that, you are not providing very much information about your
>> cluster setup.
>> How many nodes, what infrastructure, how many caches, overall data size.
>> One could only guess you have more than 1 node running, with at least 1
>> cache, and non-empty dataset. :)
>>
>> This document from GridGain may be helpful but I don't see the same for
>> Ignite, it may still be worth checking it out.
>>
>> https://www.gridgain.com/docs/latest/perf-troubleshooting-guide/maintenance-mode
>>
>> On the other hand you should also check your failing node.
>> If it is always the same node failing, then there should be some root
>> cause apart from Ignite.
>> Indeed if the nodes configuration is the same across all nodes, and just
>> this one fails, you should also consider some network issues (check
>> connectivity and network latency between nodes) and hardware related issues
>> (faulty disks, faulty memory)
>> In the end, one option might be to replace the faulty machine with a
>> brand new one.
>> In cloud environments this is actually quite cheap and easy to do.
>>
>> Cheers
>> Gianluca
>>
>> On Wed, 29 May 2024 at 08:43, Naveen Kumar 
>> wrote:
>>
>>> Hello All
>>>
>>> We are using Ignite 2.13.0
>>>
>>> After a cluster restart, one of the node is not coming up and in node
>>> logs are seeing this error - 

Re: Node requires maintenance, non-empty set of maintainance tasks is found - node is not coming up

[Naveen Kumar]

Thanks very much for your prompt response Gianluca

just for the community, I could solve this by running the control.sh with
reset lost partitions for individual cachereset_lost_partitions
looks like it worked, those partition issue is resolved, I suppose there
wouldnt be any data loss as we have set all our caches with 2 replicas

coming to the node which was not getting added to the cluster earlier,
removed from baseline --> cleared all persistence store --> brought up the
node --> added the node to baseline, this also seems to have worked fine.

Thanks


On Wed, May 29, 2024 at 5:13 PM Gianluca Bonetti 
wrote:

> Hello Naveen
>
> Apache Ignite 2.13 is more than 2 years old, 25 months old in actual fact.
> Three bugfix releases had been rolled out over time up to 2.16 release.
>
> It seems you are restarting your cluster on a regular basis, so you'd
> better upgrade to 2.16 as soon as possible.
> Otherwise it will also be very difficult for people on a community based
> mailing list, on volunteer time, to work out a solution with a 2 years old
> version running.
>
> Besides that, you are not providing very much information about your
> cluster setup.
> How many nodes, what infrastructure, how many caches, overall data size.
> One could only guess you have more than 1 node running, with at least 1
> cache, and non-empty dataset. :)
>
> This document from GridGain may be helpful but I don't see the same for
> Ignite, it may still be worth checking it out.
>
> https://www.gridgain.com/docs/latest/perf-troubleshooting-guide/maintenance-mode
>
> On the other hand you should also check your failing node.
> If it is always the same node failing, then there should be some root
> cause apart from Ignite.
> Indeed if the nodes configuration is the same across all nodes, and just
> this one fails, you should also consider some network issues (check
> connectivity and network latency between nodes) and hardware related issues
> (faulty disks, faulty memory)
> In the end, one option might be to replace the faulty machine with a brand
> new one.
> In cloud environments this is actually quite cheap and easy to do.
>
> Cheers
> Gianluca
>
> On Wed, 29 May 2024 at 08:43, Naveen Kumar 
> wrote:
>
>> Hello All
>>
>> We are using Ignite 2.13.0
>>
>> After a cluster restart, one of the node is not coming up and in node
>> logs are seeing this error - Node requires maintenance, non-empty set of
>> maintainance  tasks is found - node is not coming up
>>
>> we are getting errors like time out is reached before computation is
>> completed error in other nodes as well.
>>
>> I could see that, we have control.sh script to backup and clean up the
>> corrupted files, but when I run the command, it fails.
>>
>> I have removed the node from baseline and tried to run as well, still its
>> failing
>>
>> what could be the solution for this, cluster is functioning,
>> however there are requests failing
>>
>> Is there anyway we can start ignite node in  maintenance mode and try
>> running clean corrupted commands
>>
>> Thanks
>> Naveen
>>
>>
>>

-- 
Thanks & Regards,
Naveen Bandaru

Apache Ignite - Load balancer nodes standalone

[Eduardo Paludo via user]

I installed 4 apache ignite nodes on 4 virtual machines that are in a vmware 
cluster, one question I have is how do I connect to the cluster? Do I connect 
via the IP of any node? Or do I need to put nginx "in front" to do the load 
balancing? I didn't find anything about this in the official documentation.


Eduardo Henrique Paludo
Analista de Redes e Comunicação de Dados
(49) 3361-6661 - Ramal: 8074
Matriz Chapecó - SC
Visite nosso site: www.expressosaomiguel.com.br
[http://www.expressosaomiguel.com.br/logotipo_email/V3.png]
O conteúdo deste e-mail é confidencial e destinado exclusivamente ao 
destinatário especificado apenas na mensagem. É estritamente proibido 
compartilhar qualquer parte desta mensagem com terceiros, sem o consentimento 
por escrito do remetente. Se você recebeu esta mensagem por engano, responda a 
esta mensagem e siga com sua exclusão, para que possamos garantir que tal erro 
não ocorra no futuro.

Re: Node requires maintenance, non-empty set of maintainance tasks is found - node is not coming up

[Gianluca Bonetti]

Hello Naveen

Apache Ignite 2.13 is more than 2 years old, 25 months old in actual fact.
Three bugfix releases had been rolled out over time up to 2.16 release.

It seems you are restarting your cluster on a regular basis, so you'd
better upgrade to 2.16 as soon as possible.
Otherwise it will also be very difficult for people on a community based
mailing list, on volunteer time, to work out a solution with a 2 years old
version running.

Besides that, you are not providing very much information about your
cluster setup.
How many nodes, what infrastructure, how many caches, overall data size.
One could only guess you have more than 1 node running, with at least 1
cache, and non-empty dataset. :)

This document from GridGain may be helpful but I don't see the same for
Ignite, it may still be worth checking it out.
https://www.gridgain.com/docs/latest/perf-troubleshooting-guide/maintenance-mode

On the other hand you should also check your failing node.
If it is always the same node failing, then there should be some root cause
apart from Ignite.
Indeed if the nodes configuration is the same across all nodes, and just
this one fails, you should also consider some network issues (check
connectivity and network latency between nodes) and hardware related issues
(faulty disks, faulty memory)
In the end, one option might be to replace the faulty machine with a brand
new one.
In cloud environments this is actually quite cheap and easy to do.

Cheers
Gianluca

On Wed, 29 May 2024 at 08:43, Naveen Kumar  wrote:

> Hello All
>
> We are using Ignite 2.13.0
>
> After a cluster restart, one of the node is not coming up and in node logs
> are seeing this error - Node requires maintenance, non-empty set of
> maintainance  tasks is found - node is not coming up
>
> we are getting errors like time out is reached before computation is
> completed error in other nodes as well.
>
> I could see that, we have control.sh script to backup and clean up the
> corrupted files, but when I run the command, it fails.
>
> I have removed the node from baseline and tried to run as well, still its
> failing
>
> what could be the solution for this, cluster is functioning, however there
> are requests failing
>
> Is there anyway we can start ignite node in  maintenance mode and try
> running clean corrupted commands
>
> Thanks
> Naveen
>
>
>

Node requires maintenance, non-empty set of maintainance tasks is found - node is not coming up

[Naveen Kumar]

Hello All

We are using Ignite 2.13.0

After a cluster restart, one of the node is not coming up and in node logs
are seeing this error - Node requires maintenance, non-empty set of
maintainance  tasks is found - node is not coming up

we are getting errors like time out is reached before computation is
completed error in other nodes as well.

I could see that, we have control.sh script to backup and clean up the
corrupted files, but when I run the command, it fails.

I have removed the node from baseline and tried to run as well, still its
failing

what could be the solution for this, cluster is functioning, however there
are requests failing

Is there anyway we can start ignite node in  maintenance mode and try
running clean corrupted commands

Thanks
Naveen

Re: Realtime CDC demo

[Maksim Timonin]

Hi!

Apache Ignite now provides the `CdcManager` that captures changes in WAL
segments within the Ignite node. Actually, Ignite doesn't provide a
complete implementation of the CDC mode, but provides an opportunity to
implement it. Please check the docs in the `CdcManager` interface.

I suppose there are few possible implementations for the interface. Actual
implementation depends on the security requirements for the environment,
limiting the influence of the CDC on the operation of the node, etc. AFAIK,
currently there is no implementation to be open source.

Maksim

Realtime CDC demo

[38797715]

Hi team,

We have seen that Ignite's 2.16 version has released the feature of 
real-time CDC, but we have not seen the relevant documentation and demo 
code. Does the community have any relevant DEMO code to provide?

Re: Possible too long JVM pause - Ignite 2.10

[Stephen Darlington]

That's a great article, Ibrahim. Thanks for sharing!

On Thu, 9 May 2024 at 18:00, Ibrahim Altun 
wrote:

> Try this post
>
> https://medium.com/segmentify-tech/garbage-collection-g1gc-optimisation-on-apache-ignite-7217f2d9186e
>
>
> İbrahim Halil AltunExpert R Developer+90
> 536 3327510 • segmentify.com → UK • Germany
> • Turkey • Spain • Poland 
>
>
> On Thu, May 9, 2024 at 19:51 Jeremy McMillan  wrote:
>
>> Finding happiness is unfortunately never quite that simple.
>>
>>1. Understand why the garbage collector cannot function with shorter
>>pauses.
>>(may require GC logging configuration to provide key details)
>>2. Identify priorities.
>>(ie. absolute minimal GC pauses for best latency performance, or
>>maximum throughput, or minimal hardware footprint/cost...)
>>3. Choose a remediation solution based on stated priorities.
>>(ie. any combination of increase RAM, or possibly ironically CPU or
>>network capacity, decrease query workload, tune GC parameters, ...)
>>4. Implement the solution with appropriate changes to hardware, code,
>>configuration, and command line options, etc.
>>
>> Ignite tends to use Java heap mostly for handling query workload. The
>> slower these queries are, the greater number of them will be running
>> concurrently. Java heap needs to accommodate the sum of all running
>> queries' memory footprints, so the first remediation option on the list
>> should include making the slowest queries faster or less memory-hungry.
>> Alternatively, these queries could receive more server resources to spread
>> the load thinner, putatively by adding more nodes to the cluster. This will
>> divide the query load up, and also provide additional resources at the same
>> time. Node resource levels may also be upgraded to help the queries
>> complete faster if analysis reveals they are CPU bound or memory bound.
>> Only when we know the workload and resource level are properly matched
>> should we experiment with GC tuning options.
>>
>> On Thu, May 9, 2024 at 1:31 AM Charlin S  wrote:
>>
>>> Hi All,
>>>
>>> I am getting Possible too long JVM pause: 6403 milliseconds. JVM options
>>> used as below
>>> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms3g,-Xmx5g - client node 1
>>> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms1g,-Xmx4g  - client node 2
>>>
>>> Please suggest this.jvm option to avoid JVM pause issue.
>>>
>>> Thanks & Regards,
>>> Charlin
>>>
>>>
>>>
>>>
>>>
>>>
>>>

Re: Possible too long JVM pause - Ignite 2.10

[Ibrahim Altun]

Try this post
https://medium.com/segmentify-tech/garbage-collection-g1gc-optimisation-on-apache-ignite-7217f2d9186e


İbrahim Halil AltunExpert R Developer+90 536
3327510 • segmentify.com → UK • Germany •
Turkey • Spain • Poland 


On Thu, May 9, 2024 at 19:51 Jeremy McMillan  wrote:

> Finding happiness is unfortunately never quite that simple.
>
>1. Understand why the garbage collector cannot function with shorter
>pauses.
>(may require GC logging configuration to provide key details)
>2. Identify priorities.
>(ie. absolute minimal GC pauses for best latency performance, or
>maximum throughput, or minimal hardware footprint/cost...)
>3. Choose a remediation solution based on stated priorities.
>(ie. any combination of increase RAM, or possibly ironically CPU or
>network capacity, decrease query workload, tune GC parameters, ...)
>4. Implement the solution with appropriate changes to hardware, code,
>configuration, and command line options, etc.
>
> Ignite tends to use Java heap mostly for handling query workload. The
> slower these queries are, the greater number of them will be running
> concurrently. Java heap needs to accommodate the sum of all running
> queries' memory footprints, so the first remediation option on the list
> should include making the slowest queries faster or less memory-hungry.
> Alternatively, these queries could receive more server resources to spread
> the load thinner, putatively by adding more nodes to the cluster. This will
> divide the query load up, and also provide additional resources at the same
> time. Node resource levels may also be upgraded to help the queries
> complete faster if analysis reveals they are CPU bound or memory bound.
> Only when we know the workload and resource level are properly matched
> should we experiment with GC tuning options.
>
> On Thu, May 9, 2024 at 1:31 AM Charlin S  wrote:
>
>> Hi All,
>>
>> I am getting Possible too long JVM pause: 6403 milliseconds. JVM options
>> used as below
>> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms3g,-Xmx5g - client node 1
>> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms1g,-Xmx4g  - client node 2
>>
>> Please suggest this.jvm option to avoid JVM pause issue.
>>
>> Thanks & Regards,
>> Charlin
>>
>>
>>
>>
>>
>>
>>

Re: Possible too long JVM pause - Ignite 2.10

[Jeremy McMillan]

Finding happiness is unfortunately never quite that simple.

   1. Understand why the garbage collector cannot function with shorter
   pauses.
   (may require GC logging configuration to provide key details)
   2. Identify priorities.
   (ie. absolute minimal GC pauses for best latency performance, or maximum
   throughput, or minimal hardware footprint/cost...)
   3. Choose a remediation solution based on stated priorities.
   (ie. any combination of increase RAM, or possibly ironically CPU or
   network capacity, decrease query workload, tune GC parameters, ...)
   4. Implement the solution with appropriate changes to hardware, code,
   configuration, and command line options, etc.

Ignite tends to use Java heap mostly for handling query workload. The
slower these queries are, the greater number of them will be running
concurrently. Java heap needs to accommodate the sum of all running
queries' memory footprints, so the first remediation option on the list
should include making the slowest queries faster or less memory-hungry.
Alternatively, these queries could receive more server resources to spread
the load thinner, putatively by adding more nodes to the cluster. This will
divide the query load up, and also provide additional resources at the same
time. Node resource levels may also be upgraded to help the queries
complete faster if analysis reveals they are CPU bound or memory bound.
Only when we know the workload and resource level are properly matched
should we experiment with GC tuning options.

On Thu, May 9, 2024 at 1:31 AM Charlin S  wrote:

> Hi All,
>
> I am getting Possible too long JVM pause: 6403 milliseconds. JVM options
> used as below
> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms3g,-Xmx5g - client node 1
> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms1g,-Xmx4g  - client node 2
>
> Please suggest this.jvm option to avoid JVM pause issue.
>
> Thanks & Regards,
> Charlin
>
>
>
>
>
>
>

Re: Possible too long JVM pause - Ignite 2.10

[Stephen Darlington]

The documentation has some good suggestions:
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning#java-heap-and-gc-tuning

On Thu, 9 May 2024 at 07:31, Charlin S  wrote:

> Hi All,
>
> I am getting Possible too long JVM pause: 6403 milliseconds. JVM options
> used as below
> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms3g,-Xmx5g - client node 1
> -XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms1g,-Xmx4g  - client node 2
>
> Please suggest this.jvm option to avoid JVM pause issue.
>
> Thanks & Regards,
> Charlin
>
>
>
>
>
>
>

Possible too long JVM pause - Ignite 2.10

[Charlin S]

Hi All,

I am getting Possible too long JVM pause: 6403 milliseconds. JVM options
used as below
-XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms3g,-Xmx5g - client node 1
-XX:+DisableExplicitGC,-XX:+UseG1GC,-Xms1g,-Xmx4g  - client node 2

Please suggest this.jvm option to avoid JVM pause issue.

Thanks & Regards,
Charlin

Ignite Long JVM Pause Count

[satyajit.mandal.barclays.com via user]

Hi  Pavel,

We are observing  LongJVMPause count and  LongJVMPauseTotalDuration  higher  on 
 some  nodes  compared  to  other nodes  in the cluster. Are we missing  any  
settings or  this  is  expected  behaviour.


Thanks
Satyajit

Barclays Execution Services Limited registered in England. Registered No. 
1767980. Registered office: 1 Churchill Place, London, E14 5HP

Barclays Execution Services Limited provides support and administrative 
services across Barclays group. Barclays Execution Services Limited is an 
appointed representative of Barclays Bank UK plc, Barclays Bank plc and 
Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank 
plc are authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale 
Financial Services Limited is authorised and regulated by the Financial Conduct 
Authority.

This email and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this email in error, please 
notify the sender and immediately delete it and any attachments from your 
system. Do not copy, use, disclose or otherwise act on any part of this email 
or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any internet communications by 
any third party, or from the transmission of any viruses. Replies to this email 
may be monitored by the Barclays group for operational or business reasons.

Any opinion or other information in this email or its attachments that does not 
relate to the business of the Barclays group is personal to the sender and is 
not given or endorsed by the Barclays group.

Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays.

Ignite shutdown getting stuck indefinitely due to Binary Metadata Transport

[Atul Dhatrak]

Hi All ,



We have observed a peculiar case in which ignite shutdown gets stuck
indefinitely



We have deployed ignite 2  nodes in embedded mode.

   1. On Node1 , some cache operations are performed which triggers
   BinaryMetadata Transfer/sync up with other node
  1. This wait is indefinite and there is no timeout here
  2. As this is a cache put , one write lock also gets acquired.
   2. As node1 is waiting for response from node2 , Node1 gets segmented
   and loses connectivity with node2
  1. Due to this , Node1 never gets expected response from node2 and
  does not come out of the waiting
   3. On node segmentation , we are closing Ignite , but as some thread are
   still performing cache operation and are stuck at binary metadata transfer
   , Ignite is not able to close
  1. Ignite close is waiting for the write lock acquired in step 1 to
  get released ,which will not happen in this case.



Following is the thread dump



 java.lang.Thread.State: WAITING (parking)   -> <>

   at jdk.internal.misc.Unsafe.park(java.base@11.0.19/Native
 Method)

   at java.util.concurrent.locks.LockSupport.park(
java.base@11.0.19/LockSupport.java:323)

   at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:179)

   at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:142)

   at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport.putAndWaitPendingUpdate(BinaryMetadataTransport.java:281)

   at
org.apache.ignite.internal.processors.cache.binary.BinaryMetadataTransport.requestMetadataUpdate(BinaryMetadataTransport.java:221)

   at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:638)

   at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.addMeta(CacheObjectBinaryProcessorImpl.java:292)

   at
org.apache.ignite.internal.binary.BinaryContext.updateMetadata(BinaryContext.java:1337)

   at
org.apache.ignite.internal.binary.BinaryClassDescriptor.write(BinaryClassDescriptor.java:862)

   at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:232)

   at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:165)

   at
org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:152)

   at
org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:251)

   at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.marshalToBinary(CacheObjectBinaryProcessorImpl.java:583)

   at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toBinary(CacheObjectBinaryProcessorImpl.java:1492)

   at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.toCacheObject(CacheObjectBinaryProcessorImpl.java:1329)

   at
org.apache.ignite.internal.processors.cache.GridCacheContext.toCacheObject(GridCacheContext.java:1822)

   at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistWriteEntry(GridNearTxLocal.java:1546)

   at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.enlistWrite(GridNearTxLocal.java:1083)

   at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync0(GridNearTxLocal.java:635)

   at
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal.putAsync(GridNearTxLocal.java:484)

   at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$20.op(GridCacheAdapter.java:2511)

   at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$20.op(GridCacheAdapter.java:2509)

   at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4284)

   at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2509)

   at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2487)

   at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2466)

   at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1332)

   at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:867)



   java.lang.Thread.State: TIMED_WAITING (sleeping)  <>

   at java.lang.Thread.sleep(java.base@11.0.19/Native Method)

   at
org.apache.ignite.internal.util.IgniteUtils.sleep(IgniteUtils.java:8270)

 

Re: ignitevisorcmd tool - alternate option

[Николай Ижиков]

Hello.

You can configure sql view metric exporter to export all metrics in form of SQL 
view and query view via control.sh

https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics-system#sql-view


> 24 апр. 2024 г., в 09:43, Charlin S  написал(а):
> 
> Hi,
> Thank you all.
> metric works for me to find cache count. could you please let me know if any 
> option for getting all caches with count in single window or tabular format
> 
> Thanks & Regards,
> Charlin
> 
> 
> On Mon, 22 Apr 2024 at 14:59, Stephen Darlington  
> wrote:
> bin/control.sh --metric cache.SQL_PUBLIC_IGNITE
> 
> On Mon, 22 Apr 2024 at 10:06, Charlin S  wrote:
> Hi All,
> ./control.sh —system-view CACHES also not having cache records count.
> How to get cache count like visorcommand
> 
> Thanks & Regards,
> Charlin
> 
> 
> On Mon, 15 Apr 2024 at 22:21, Николай Ижиков  wrote:
> > Thanks for your email, able to get a list of caches like list . but the 
> > result format is not easy to understand. 
> System view command outputs table rows with the single line.
> You can adjust formatting with the following:
> 
> ./control.sh —system-view CACHES > output.txt
> 
> Then view output.txt with the any editor, disable wrap lines option.
> 
> 
> 
> > 15 апр. 2024 г., в 19:25, Stephen Darlington  
> > написал(а):
> > 
> > What tool are you using?
> > 
> > If you're using sqlline, you could do "!set output vertical" or only select 
> > the columns you're interested in.
> > 
> > On Mon, 15 Apr 2024 at 17:09, Charlin S  wrote:
> > Hello Nizhikov,
> > Thanks for your email, able to get a list of caches like list . but the 
> > result format is not easy to understand.
> > 
> > 
> > Thanks & Regards,
> > Charlin
> > 
> > 
> > On Mon, 15 Apr 2024 at 19:39, Николай Ижиков  wrote:
> > Hello, Charlin
> > 
> > Looks like system view CACHES can help you.
> > https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
> > 
> > 
> > > 15 апр. 2024 г., в 09:30, Charlin S  написал(а):
> > > 
> > > Hi All,
> > > Thank you for your email.
> > > Still I am missing cache -scan result details like below (in visorcmd). 
> > > 
> > >  Is it possible to get results using   --cache scan list .   ?
> > > 
> > > Thanks & Regards,
> > > Charlin
> > > 
> > > 
> > > 
> > > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков  wrote:
> > > Hello, Charlin
> > > 
> > > Please, take a look at system views:
> > > 
> > > NODES, BASELINE_NODES.
> > > 
> > > You can query them by control.sh - 
> > > 
> > > https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
> > > 
> > > control.sh --system-view nodes
> > > 
> > > 
> > > > 12 апр. 2024 г., в 15:38, Charlin S  написал(а):
> > > > 
> > > > Hi Pavel,
> > > > Thank you for your email. --baseline argument not showing client node 
> > > > list, actually 1 server and 1 client node should shown
> > > > 
> > > > 
> > > > 
> > > > Thanks & Regards,
> > > > Charlin
> > > > 
> > > > 
> > > > 
> > > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn  
> > > > wrote:
> > > > control.sh is the replacement:
> > > > https://ignite.apache.org/docs/latest/tools/control-script
> > > > 
> > > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah  
> > > > wrote:
> > > > Hi Charlin,
> > > > 
> > > > I am working as a Principal Architect at GridGain.
> > > > Let me know if you would like to have a call to discuss your project 
> > > > and needs, so I can figure out how to help you.
> > > > 
> > > > Regards,
> > > > Rajiv Shah
> > > > 
> > > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S  
> > > > wrote:
> > > > Hi All,
> > > > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 
> > > > and found that 
> > > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is 
> > > > the alternative way for checking grids statistics and cache details 
> > > > without ignitevisorcmd tool.
> > > > 
> > > > Thanks & Regards,
> > > > Charlin
> > > > 
> > > 
> > 
> 

Re: Ignite 2.16 - Multiple query fields are associated with the same alias

[Charlin S]

Hi,
Thank you for your email

Thanks and Regards
Charlin

On Wed, 24 Apr, 2024, 4:42 pm Pavel Tupitsyn,  wrote:

> Same thing. Fields get flattened for SQL, so you've got one column from
> Employee and another from EmpInfo causing a conflict.
>
> On Wed, Apr 24, 2024 at 2:06 PM Charlin S  wrote:
>
>> Hi,
>> Thank you for the email.
>> What about EmpInfo? Main class and child class having EmpName field
>> (error 1)
>>
>> Thanks and Regards,
>> Charlin
>>
>>
>> On Wed, 24 Apr, 2024, 4:25 pm Pavel Tupitsyn, 
>> wrote:
>>
>>> Employee class has two fields with the same name:
>>>
>>>   [QuerySqlField]
>>>   public string EMPCode { get; set; }
>>>
>>>   [QuerySqlField]
>>>   public string EmpCode { get; set; }
>>>
>>>
>>> Ignite 2.10 ignored this and used only one of those for SQL, which may
>>> lead to subtle bugs. So we added this validation.
>>>
>>> You'll have to rename one of the fields, or override SQL field name in
>>> the attribute:
>>> [QuerySqlField(Name = "EMPCode2")]
>>>
>>> On Wed, Apr 24, 2024 at 10:01 AM Charlin S 
>>> wrote:
>>>
 Hi All,
 I am upgrading Ignite from 2.10 to 2.16 and getting Multiple query
 fields are associated with the same alias error for *EMPCode* and *EmpName,
 *which is working with Ignite 2.10. unable to create Employee cache.

 Error 1:
 System.Exception: IgniteException for chache ::  Employee
  ---> Apache.Ignite.Core.Cache.CacheException: class
 org.apache.ignite.IgniteCheckedException: Multiple query fields are
 associated with the same alias [alias=EMPNAME]

 Error 2:
   System.Exception: IgniteException for chache ::  Employee
  ---> Apache.Ignite.Core.Cache.CacheException: class
 org.apache.ignite.IgniteCheckedException: Multiple query fields are
 associated with the same alias [alias=EMPCODE]

 Error 2 can be corrected by removing TmcCode property but why same
 error for EmpName?

 my class file
 Public class Employee: IBinarizable
 {
 [QuerySqlField]
 public string EMPCode { get; set; }
 [QuerySqlField]
 public string EmpCode { get; set; }
 [QuerySqlField]
 public string EmpName { get; set; }
 [QuerySqlField]
 public EmpInfo EmpInformation { get; set; }

 public void WriteBinary(IBinaryWriter writer)
 {
 if (writer != null)
 {
 writer.WriteString("empcode", EMPCode);
 writer.WriteString("empname",  EmpName );
 writer.WriteObject(" empInformation",  EmpInformation
 );
 }
 }
  public void ReadBinary(IBinaryReader reader)
 {
 if (reader != null)
 {
  EMPCode = reader.ReadString("empcode");
  EmpName = reader.ReadString("empname");
   EmpInformation = reader.ReadString("
 empInformation");
 }
  }
}

   public class EmpInfo : IBinarizable
   {
 [QuerySqlField]
 public string EmpName { get; set; }
 [QuerySqlField]
 public string EmpAddress{ get; set; }

public void WriteBinary(IBinaryWriter writer)
 {
 if (writer != null)
 {
 writer.WriteString(" empname  ",  EmpName   );
 writer.WriteString(" empaddress  ",   EmpAddress  );
 }
 }
  public void ReadBinary(IBinaryReader reader)
 {
 if (reader != null)
 {
   EmpName   = reader.ReadString(" empname  ");
   EmpAddress  = reader.ReadString(" empaddress  ");
 }
  }
   }

 Thanks & Regards,
 Charlin

Re: Ignite 2.16 - Multiple query fields are associated with the same alias

[Pavel Tupitsyn]

Same thing. Fields get flattened for SQL, so you've got one column from
Employee and another from EmpInfo causing a conflict.

On Wed, Apr 24, 2024 at 2:06 PM Charlin S  wrote:

> Hi,
> Thank you for the email.
> What about EmpInfo? Main class and child class having EmpName field (error
> 1)
>
> Thanks and Regards,
> Charlin
>
>
> On Wed, 24 Apr, 2024, 4:25 pm Pavel Tupitsyn, 
> wrote:
>
>> Employee class has two fields with the same name:
>>
>>   [QuerySqlField]
>>   public string EMPCode { get; set; }
>>
>>   [QuerySqlField]
>>   public string EmpCode { get; set; }
>>
>>
>> Ignite 2.10 ignored this and used only one of those for SQL, which may
>> lead to subtle bugs. So we added this validation.
>>
>> You'll have to rename one of the fields, or override SQL field name in
>> the attribute:
>> [QuerySqlField(Name = "EMPCode2")]
>>
>> On Wed, Apr 24, 2024 at 10:01 AM Charlin S 
>> wrote:
>>
>>> Hi All,
>>> I am upgrading Ignite from 2.10 to 2.16 and getting Multiple query
>>> fields are associated with the same alias error for *EMPCode* and *EmpName,
>>> *which is working with Ignite 2.10. unable to create Employee cache.
>>>
>>> Error 1:
>>> System.Exception: IgniteException for chache ::  Employee
>>>  ---> Apache.Ignite.Core.Cache.CacheException: class
>>> org.apache.ignite.IgniteCheckedException: Multiple query fields are
>>> associated with the same alias [alias=EMPNAME]
>>>
>>> Error 2:
>>>   System.Exception: IgniteException for chache ::  Employee
>>>  ---> Apache.Ignite.Core.Cache.CacheException: class
>>> org.apache.ignite.IgniteCheckedException: Multiple query fields are
>>> associated with the same alias [alias=EMPCODE]
>>>
>>> Error 2 can be corrected by removing TmcCode property but why same error
>>> for EmpName?
>>>
>>> my class file
>>> Public class Employee: IBinarizable
>>> {
>>> [QuerySqlField]
>>> public string EMPCode { get; set; }
>>> [QuerySqlField]
>>> public string EmpCode { get; set; }
>>> [QuerySqlField]
>>> public string EmpName { get; set; }
>>> [QuerySqlField]
>>> public EmpInfo EmpInformation { get; set; }
>>>
>>> public void WriteBinary(IBinaryWriter writer)
>>> {
>>> if (writer != null)
>>> {
>>> writer.WriteString("empcode", EMPCode);
>>> writer.WriteString("empname",  EmpName );
>>> writer.WriteObject(" empInformation",  EmpInformation
>>> );
>>> }
>>> }
>>>  public void ReadBinary(IBinaryReader reader)
>>> {
>>> if (reader != null)
>>> {
>>>  EMPCode = reader.ReadString("empcode");
>>>  EmpName = reader.ReadString("empname");
>>>   EmpInformation = reader.ReadString("
>>> empInformation");
>>> }
>>>  }
>>>}
>>>
>>>   public class EmpInfo : IBinarizable
>>>   {
>>> [QuerySqlField]
>>> public string EmpName { get; set; }
>>> [QuerySqlField]
>>> public string EmpAddress{ get; set; }
>>>
>>>public void WriteBinary(IBinaryWriter writer)
>>> {
>>> if (writer != null)
>>> {
>>> writer.WriteString(" empname  ",  EmpName   );
>>> writer.WriteString(" empaddress  ",   EmpAddress  );
>>> }
>>> }
>>>  public void ReadBinary(IBinaryReader reader)
>>> {
>>> if (reader != null)
>>> {
>>>   EmpName   = reader.ReadString(" empname  ");
>>>   EmpAddress  = reader.ReadString(" empaddress  ");
>>> }
>>>  }
>>>   }
>>>
>>> Thanks & Regards,
>>> Charlin
>>>
>>>
>>>

Re: Ignite 2.16 - Multiple query fields are associated with the same alias

[Charlin S]

Hi,
Thank you for the email.
What about EmpInfo? Main class and child class having EmpName field (error
1)

Thanks and Regards,
Charlin


On Wed, 24 Apr, 2024, 4:25 pm Pavel Tupitsyn,  wrote:

> Employee class has two fields with the same name:
>
>   [QuerySqlField]
>   public string EMPCode { get; set; }
>
>   [QuerySqlField]
>   public string EmpCode { get; set; }
>
>
> Ignite 2.10 ignored this and used only one of those for SQL, which may
> lead to subtle bugs. So we added this validation.
>
> You'll have to rename one of the fields, or override SQL field name in the
> attribute:
> [QuerySqlField(Name = "EMPCode2")]
>
> On Wed, Apr 24, 2024 at 10:01 AM Charlin S  wrote:
>
>> Hi All,
>> I am upgrading Ignite from 2.10 to 2.16 and getting Multiple query fields
>> are associated with the same alias error for *EMPCode* and *EmpName, *which
>> is working with Ignite 2.10. unable to create Employee cache.
>>
>> Error 1:
>> System.Exception: IgniteException for chache ::  Employee
>>  ---> Apache.Ignite.Core.Cache.CacheException: class
>> org.apache.ignite.IgniteCheckedException: Multiple query fields are
>> associated with the same alias [alias=EMPNAME]
>>
>> Error 2:
>>   System.Exception: IgniteException for chache ::  Employee
>>  ---> Apache.Ignite.Core.Cache.CacheException: class
>> org.apache.ignite.IgniteCheckedException: Multiple query fields are
>> associated with the same alias [alias=EMPCODE]
>>
>> Error 2 can be corrected by removing TmcCode property but why same error
>> for EmpName?
>>
>> my class file
>> Public class Employee: IBinarizable
>> {
>> [QuerySqlField]
>> public string EMPCode { get; set; }
>> [QuerySqlField]
>> public string EmpCode { get; set; }
>> [QuerySqlField]
>> public string EmpName { get; set; }
>> [QuerySqlField]
>> public EmpInfo EmpInformation { get; set; }
>>
>> public void WriteBinary(IBinaryWriter writer)
>> {
>> if (writer != null)
>> {
>> writer.WriteString("empcode", EMPCode);
>> writer.WriteString("empname",  EmpName );
>> writer.WriteObject(" empInformation",  EmpInformation   );
>> }
>> }
>>  public void ReadBinary(IBinaryReader reader)
>> {
>> if (reader != null)
>> {
>>  EMPCode = reader.ReadString("empcode");
>>  EmpName = reader.ReadString("empname");
>>   EmpInformation = reader.ReadString("
>> empInformation");
>> }
>>  }
>>}
>>
>>   public class EmpInfo : IBinarizable
>>   {
>> [QuerySqlField]
>> public string EmpName { get; set; }
>> [QuerySqlField]
>> public string EmpAddress{ get; set; }
>>
>>public void WriteBinary(IBinaryWriter writer)
>> {
>> if (writer != null)
>> {
>> writer.WriteString(" empname  ",  EmpName   );
>> writer.WriteString(" empaddress  ",   EmpAddress  );
>> }
>> }
>>  public void ReadBinary(IBinaryReader reader)
>> {
>> if (reader != null)
>> {
>>   EmpName   = reader.ReadString(" empname  ");
>>   EmpAddress  = reader.ReadString(" empaddress  ");
>> }
>>  }
>>   }
>>
>> Thanks & Regards,
>> Charlin
>>
>>
>>

Re: Ignite 2.16 - Multiple query fields are associated with the same alias

[Pavel Tupitsyn]

Employee class has two fields with the same name:

  [QuerySqlField]
  public string EMPCode { get; set; }

  [QuerySqlField]
  public string EmpCode { get; set; }


Ignite 2.10 ignored this and used only one of those for SQL, which may lead
to subtle bugs. So we added this validation.

You'll have to rename one of the fields, or override SQL field name in the
attribute:
[QuerySqlField(Name = "EMPCode2")]

On Wed, Apr 24, 2024 at 10:01 AM Charlin S  wrote:

> Hi All,
> I am upgrading Ignite from 2.10 to 2.16 and getting Multiple query fields
> are associated with the same alias error for *EMPCode* and *EmpName, *which
> is working with Ignite 2.10. unable to create Employee cache.
>
> Error 1:
> System.Exception: IgniteException for chache ::  Employee
>  ---> Apache.Ignite.Core.Cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Multiple query fields are
> associated with the same alias [alias=EMPNAME]
>
> Error 2:
>   System.Exception: IgniteException for chache ::  Employee
>  ---> Apache.Ignite.Core.Cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Multiple query fields are
> associated with the same alias [alias=EMPCODE]
>
> Error 2 can be corrected by removing TmcCode property but why same error
> for EmpName?
>
> my class file
> Public class Employee: IBinarizable
> {
> [QuerySqlField]
> public string EMPCode { get; set; }
> [QuerySqlField]
> public string EmpCode { get; set; }
> [QuerySqlField]
> public string EmpName { get; set; }
> [QuerySqlField]
> public EmpInfo EmpInformation { get; set; }
>
> public void WriteBinary(IBinaryWriter writer)
> {
> if (writer != null)
> {
> writer.WriteString("empcode", EMPCode);
> writer.WriteString("empname",  EmpName );
> writer.WriteObject(" empInformation",  EmpInformation   );
> }
> }
>  public void ReadBinary(IBinaryReader reader)
> {
> if (reader != null)
> {
>  EMPCode = reader.ReadString("empcode");
>  EmpName = reader.ReadString("empname");
>   EmpInformation = reader.ReadString("
> empInformation");
> }
>  }
>}
>
>   public class EmpInfo : IBinarizable
>   {
> [QuerySqlField]
> public string EmpName { get; set; }
> [QuerySqlField]
> public string EmpAddress{ get; set; }
>
>public void WriteBinary(IBinaryWriter writer)
> {
> if (writer != null)
> {
> writer.WriteString(" empname  ",  EmpName   );
> writer.WriteString(" empaddress  ",   EmpAddress  );
> }
> }
>  public void ReadBinary(IBinaryReader reader)
> {
> if (reader != null)
> {
>   EmpName   = reader.ReadString(" empname  ");
>   EmpAddress  = reader.ReadString(" empaddress  ");
> }
>  }
>   }
>
> Thanks & Regards,
> Charlin
>
>
>

Ignite 2.16 - Multiple query fields are associated with the same alias

[Charlin S]

Hi All,
I am upgrading Ignite from 2.10 to 2.16 and getting Multiple query fields
are associated with the same alias error for *EMPCode* and *EmpName, *which
is working with Ignite 2.10. unable to create Employee cache.

Error 1:
System.Exception: IgniteException for chache ::  Employee
 ---> Apache.Ignite.Core.Cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Multiple query fields are
associated with the same alias [alias=EMPNAME]

Error 2:
  System.Exception: IgniteException for chache ::  Employee
 ---> Apache.Ignite.Core.Cache.CacheException: class
org.apache.ignite.IgniteCheckedException: Multiple query fields are
associated with the same alias [alias=EMPCODE]

Error 2 can be corrected by removing TmcCode property but why same error
for EmpName?

my class file
Public class Employee: IBinarizable
{
[QuerySqlField]
public string EMPCode { get; set; }
[QuerySqlField]
public string EmpCode { get; set; }
[QuerySqlField]
public string EmpName { get; set; }
[QuerySqlField]
public EmpInfo EmpInformation { get; set; }

public void WriteBinary(IBinaryWriter writer)
{
if (writer != null)
{
writer.WriteString("empcode", EMPCode);
writer.WriteString("empname",  EmpName );
writer.WriteObject(" empInformation",  EmpInformation   );
}
}
 public void ReadBinary(IBinaryReader reader)
{
if (reader != null)
{
 EMPCode = reader.ReadString("empcode");
 EmpName = reader.ReadString("empname");
  EmpInformation = reader.ReadString(" empInformation");
}
 }
   }

  public class EmpInfo : IBinarizable
  {
[QuerySqlField]
public string EmpName { get; set; }
[QuerySqlField]
public string EmpAddress{ get; set; }

   public void WriteBinary(IBinaryWriter writer)
{
if (writer != null)
{
writer.WriteString(" empname  ",  EmpName   );
writer.WriteString(" empaddress  ",   EmpAddress  );
}
}
 public void ReadBinary(IBinaryReader reader)
{
if (reader != null)
{
  EmpName   = reader.ReadString(" empname  ");
  EmpAddress  = reader.ReadString(" empaddress  ");
}
 }
  }

Thanks & Regards,
Charlin

Re: ignitevisorcmd tool - alternate option

[Charlin S]

Hi,
Thank you all.
metric works for me to find cache count. could you please let me know if
any option for getting all caches with count in single window or
tabular format

Thanks & Regards,
Charlin


On Mon, 22 Apr 2024 at 14:59, Stephen Darlington 
wrote:

> bin/control.sh --metric cache.SQL_PUBLIC_IGNITE
>
> On Mon, 22 Apr 2024 at 10:06, Charlin S  wrote:
>
>> Hi All,
>> ./control.sh —system-view CACHES also not having cache records count.
>> How to get cache count like visorcommand
>>
>> Thanks & Regards,
>> Charlin
>>
>>
>> On Mon, 15 Apr 2024 at 22:21, Николай Ижиков  wrote:
>>
>>> > Thanks for your email, able to get a list of caches like list . but
>>> the result format is not easy to understand.>>
>>> System view command outputs table rows with the single line.
>>> You can adjust formatting with the following:
>>>
>>> ./control.sh —system-view CACHES > output.txt
>>>
>>> Then view output.txt with the any editor, disable wrap lines option.
>>>
>>>
>>>
>>> > 15 апр. 2024 г., в 19:25, Stephen Darlington 
>>> написал(а):
>>> >
>>> > What tool are you using?
>>> >
>>> > If you're using sqlline, you could do "!set output vertical" or only
>>> select the columns you're interested in.
>>> >
>>> > On Mon, 15 Apr 2024 at 17:09, Charlin S 
>>> wrote:
>>> > Hello Nizhikov,
>>> > Thanks for your email, able to get a list of caches like list . but
>>> the result format is not easy to understand.
>>> >
>>> >
>>> > Thanks & Regards,
>>> > Charlin
>>> >
>>> >
>>> > On Mon, 15 Apr 2024 at 19:39, Николай Ижиков 
>>> wrote:
>>> > Hello, Charlin
>>> >
>>> > Looks like system view CACHES can help you.
>>> >
>>> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
>>> >
>>> >
>>> > > 15 апр. 2024 г., в 09:30, Charlin S 
>>> написал(а):
>>> > >
>>> > > Hi All,
>>> > > Thank you for your email.
>>> > > Still I am missing cache -scan result details like below (in
>>> visorcmd).
>>> > > 
>>> > >  Is it possible to get results using   --cache scan list .   ?
>>> > >
>>> > > Thanks & Regards,
>>> > > Charlin
>>> > >
>>> > >
>>> > >
>>> > > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков 
>>> wrote:
>>> > > Hello, Charlin
>>> > >
>>> > > Please, take a look at system views:
>>> > >
>>> > > NODES, BASELINE_NODES.
>>> > >
>>> > > You can query them by control.sh -
>>> > >
>>> > >
>>> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
>>> > >
>>> > > control.sh --system-view nodes
>>> > >
>>> > >
>>> > > > 12 апр. 2024 г., в 15:38, Charlin S 
>>> написал(а):
>>> > > >
>>> > > > Hi Pavel,
>>> > > > Thank you for your email. --baseline argument not showing client
>>> node list, actually 1 server and 1 client node should shown
>>> > > >
>>> > > > 
>>> > > >
>>> > > > Thanks & Regards,
>>> > > > Charlin
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn 
>>> wrote:
>>> > > > control.sh is the replacement:
>>> > > > https://ignite.apache.org/docs/latest/tools/control-script
>>> > > >
>>> > > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah <
>>> rajiv.s...@gridgain.com> wrote:
>>> > > > Hi Charlin,
>>> > > >
>>> > > > I am working as a Principal Architect at GridGain.
>>> > > > Let me know if you would like to have a call to discuss your
>>> project and needs, so I can figure out how to help you.
>>> > > >
>>> > > > Regards,
>>> > > > Rajiv Shah
>>> > > >
>>> > > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S 
>>> wrote:
>>> > > > Hi All,
>>> > > > Currently I am using Ignite 2.10 and planning to upgrade Ignite
>>> 2.16 and found that
>>> > > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards.
>>> What is the alternative way for checking grids statistics and cache details
>>> without ignitevisorcmd tool.
>>> > > >
>>> > > > Thanks & Regards,
>>> > > > Charlin
>>> > > >
>>> > >
>>> >
>>>
>>>

Re: ignitevisorcmd tool - alternate option

[Stephen Darlington]

bin/control.sh --metric cache.SQL_PUBLIC_IGNITE

On Mon, 22 Apr 2024 at 10:06, Charlin S  wrote:

> Hi All,
> ./control.sh —system-view CACHES also not having cache records count.
> How to get cache count like visorcommand
>
> Thanks & Regards,
> Charlin
>
>
> On Mon, 15 Apr 2024 at 22:21, Николай Ижиков  wrote:
>
>> > Thanks for your email, able to get a list of caches like list . but the
>> result format is not easy to understand.>
>> System view command outputs table rows with the single line.
>> You can adjust formatting with the following:
>>
>> ./control.sh —system-view CACHES > output.txt
>>
>> Then view output.txt with the any editor, disable wrap lines option.
>>
>>
>>
>> > 15 апр. 2024 г., в 19:25, Stephen Darlington 
>> написал(а):
>> >
>> > What tool are you using?
>> >
>> > If you're using sqlline, you could do "!set output vertical" or only
>> select the columns you're interested in.
>> >
>> > On Mon, 15 Apr 2024 at 17:09, Charlin S  wrote:
>> > Hello Nizhikov,
>> > Thanks for your email, able to get a list of caches like list . but the
>> result format is not easy to understand.
>> >
>> >
>> > Thanks & Regards,
>> > Charlin
>> >
>> >
>> > On Mon, 15 Apr 2024 at 19:39, Николай Ижиков 
>> wrote:
>> > Hello, Charlin
>> >
>> > Looks like system view CACHES can help you.
>> >
>> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
>> >
>> >
>> > > 15 апр. 2024 г., в 09:30, Charlin S 
>> написал(а):
>> > >
>> > > Hi All,
>> > > Thank you for your email.
>> > > Still I am missing cache -scan result details like below (in
>> visorcmd).
>> > > 
>> > >  Is it possible to get results using   --cache scan list .   ?
>> > >
>> > > Thanks & Regards,
>> > > Charlin
>> > >
>> > >
>> > >
>> > > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков 
>> wrote:
>> > > Hello, Charlin
>> > >
>> > > Please, take a look at system views:
>> > >
>> > > NODES, BASELINE_NODES.
>> > >
>> > > You can query them by control.sh -
>> > >
>> > >
>> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
>> > >
>> > > control.sh --system-view nodes
>> > >
>> > >
>> > > > 12 апр. 2024 г., в 15:38, Charlin S 
>> написал(а):
>> > > >
>> > > > Hi Pavel,
>> > > > Thank you for your email. --baseline argument not showing client
>> node list, actually 1 server and 1 client node should shown
>> > > >
>> > > > 
>> > > >
>> > > > Thanks & Regards,
>> > > > Charlin
>> > > >
>> > > >
>> > > >
>> > > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn 
>> wrote:
>> > > > control.sh is the replacement:
>> > > > https://ignite.apache.org/docs/latest/tools/control-script
>> > > >
>> > > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah 
>> wrote:
>> > > > Hi Charlin,
>> > > >
>> > > > I am working as a Principal Architect at GridGain.
>> > > > Let me know if you would like to have a call to discuss your
>> project and needs, so I can figure out how to help you.
>> > > >
>> > > > Regards,
>> > > > Rajiv Shah
>> > > >
>> > > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S 
>> wrote:
>> > > > Hi All,
>> > > > Currently I am using Ignite 2.10 and planning to upgrade Ignite
>> 2.16 and found that
>> > > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards.
>> What is the alternative way for checking grids statistics and cache details
>> without ignitevisorcmd tool.
>> > > >
>> > > > Thanks & Regards,
>> > > > Charlin
>> > > >
>> > >
>> >
>>
>>

Re: ignitevisorcmd tool - alternate option

[Charlin S]

Hi All,
./control.sh —system-view CACHES also not having cache records count.
How to get cache count like visorcommand

Thanks & Regards,
Charlin


On Mon, 15 Apr 2024 at 22:21, Николай Ижиков  wrote:

> > Thanks for your email, able to get a list of caches like list . but the
> result format is not easy to understand.
> System view command outputs table rows with the single line.
> You can adjust formatting with the following:
>
> ./control.sh —system-view CACHES > output.txt
>
> Then view output.txt with the any editor, disable wrap lines option.
>
>
>
> > 15 апр. 2024 г., в 19:25, Stephen Darlington 
> написал(а):
> >
> > What tool are you using?
> >
> > If you're using sqlline, you could do "!set output vertical" or only
> select the columns you're interested in.
> >
> > On Mon, 15 Apr 2024 at 17:09, Charlin S  wrote:
> > Hello Nizhikov,
> > Thanks for your email, able to get a list of caches like list . but the
> result format is not easy to understand.
> >
> >
> > Thanks & Regards,
> > Charlin
> >
> >
> > On Mon, 15 Apr 2024 at 19:39, Николай Ижиков 
> wrote:
> > Hello, Charlin
> >
> > Looks like system view CACHES can help you.
> >
> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
> >
> >
> > > 15 апр. 2024 г., в 09:30, Charlin S 
> написал(а):
> > >
> > > Hi All,
> > > Thank you for your email.
> > > Still I am missing cache -scan result details like below (in
> visorcmd).
> > > 
> > >  Is it possible to get results using   --cache scan list .   ?
> > >
> > > Thanks & Regards,
> > > Charlin
> > >
> > >
> > >
> > > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков 
> wrote:
> > > Hello, Charlin
> > >
> > > Please, take a look at system views:
> > >
> > > NODES, BASELINE_NODES.
> > >
> > > You can query them by control.sh -
> > >
> > >
> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
> > >
> > > control.sh --system-view nodes
> > >
> > >
> > > > 12 апр. 2024 г., в 15:38, Charlin S 
> написал(а):
> > > >
> > > > Hi Pavel,
> > > > Thank you for your email. --baseline argument not showing client
> node list, actually 1 server and 1 client node should shown
> > > >
> > > > 
> > > >
> > > > Thanks & Regards,
> > > > Charlin
> > > >
> > > >
> > > >
> > > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn 
> wrote:
> > > > control.sh is the replacement:
> > > > https://ignite.apache.org/docs/latest/tools/control-script
> > > >
> > > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah 
> wrote:
> > > > Hi Charlin,
> > > >
> > > > I am working as a Principal Architect at GridGain.
> > > > Let me know if you would like to have a call to discuss your project
> and needs, so I can figure out how to help you.
> > > >
> > > > Regards,
> > > > Rajiv Shah
> > > >
> > > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S 
> wrote:
> > > > Hi All,
> > > > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16
> and found that
> > > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What
> is the alternative way for checking grids statistics and cache details
> without ignitevisorcmd tool.
> > > >
> > > > Thanks & Regards,
> > > > Charlin
> > > >
> > >
> >
>
>

Re: Ignite process memory usage continues to grow in docker

[Gianluca Bonetti]

Hello

You should give some information otherwise the problem statement is too
generic.
Information such as Ignite version, JVM version, JVM memory parameters, and
Docker deployment resources limits are required.

Cheers
Gianluca

On Sat, 20 Apr 2024 at 10:22, 38797715 <38797...@qq.com> wrote:

> Hi team,
>
> Start a simple Ignite process using Docker, which is the default
> configuration and does nothing. After a period of time, you will find that
> the memory occupied by this Ignite process increases until the OOM Killer
> is triggered.
>
> If Docker is not used and the Ignite process is started on the host, this
> problem does not exist.
>
> After testing, this issue is not related to the Docker version, JDK
> version, or Ignite version.
>
> Through monitoring, it can be seen that the JVM heap space, non-heap
> space, and offHeap space are all normal.
>
> Has anyone in the community encountered the same problem?
>

Ignite process memory usage continues to grow in docker

[38797715]

Hi team,

Start a simple Ignite process using Docker, which is the default 
configuration and does nothing. After a period of time, you will find 
that the memory occupied by this Ignite process increases until the OOM 
Killer is triggered.


If Docker is not used and the Ignite process is started on the host, 
this problem does not exist.


After testing, this issue is not related to the Docker version, JDK 
version, or Ignite version.


Through monitoring, it can be seen that the JVM heap space, non-heap 
space, and offHeap space are all normal.


Has anyone in the community encountered the same problem?

Re: CVE-2024-22243 - Spring Framework Vulnerability

[Pavel Tupitsyn]

Ignite is not affected.

The description says "Applications that use UriComponentsBuilder...", and
we do not use UriComponentsBuilder at all, not a single match in the source
code [1]

[1]
https://github.com/search?q=repo%3Aapache%2Fignite%20UriComponentsBuilder=code



On Thu, Feb 29, 2024 at 6:13 AM David Horton 
wrote:

> Hi Team,
>
> Could you please advise if Ignite 2.14/2.15 is vulnerable to
> https://spring.io/security/cve-2024-22243 and if so whether a patch is
> planned?
>
> Thanks.
>

Re: DataModelling in Ignite .NET with Inheritance.

[Pavel Tupitsyn]

Hi Satyajit,

Here you go:

using Apache.Ignite.Core;
using Apache.Ignite.Core.Cache;

using var ignite = Ignition.Start();
var cache = ignite.GetOrCreateCache("myCache");

cache[1] = new Base(1, "base-1");
cache[2] = new Derived(2, "derived-2", 42);

foreach (ICacheEntry entry in cache)
{
Console.WriteLine(entry);
}

public record Base(int Id, string Name);
public record Derived(int Id, string Name, long Foo) : Base(Id, Name);


Result:

CacheEntry [Key=1, Value=Base { Id = 1, Name = base-1 }]
CacheEntry [Key=2, Value=Derived { Id = 2, Name = derived-2, Foo = 42 }]


On Wed, Apr 17, 2024 at 3:45 PM  wrote:

> Hi  Pavel,
>
>
>
> Do  we  have  any  working example  with  Parent and Derived  class  data
> model  being saved in  Ignite ?.
>
>
>
> Regards
>
> Satyajit
>
> Barclays Execution Services Limited registered in England. Registered No.
> 1767980. Registered office: 1 Churchill Place, London, E14 5HP
>
> Barclays Execution Services Limited provides support and administrative
> services across Barclays group. Barclays Execution Services Limited is an
> appointed representative of Barclays Bank UK plc, Barclays Bank plc and
> Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays
> Bank plc are authorised by the Prudential Regulation Authority and
> regulated by the Financial Conduct Authority and the Prudential Regulation
> Authority. Clydesdale Financial Services Limited is authorised and
> regulated by the Financial Conduct Authority.
>
> This email and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this email
> in error, please notify the sender and immediately delete it and any
> attachments from your system. Do not copy, use, disclose or otherwise act
> on any part of this email or its attachments.
>
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this email may be monitored by the Barclays group for operational or
> business reasons.
>
> Any opinion or other information in this email or its attachments that
> does not relate to the business of the Barclays group is personal to the
> sender and is not given or endorsed by the Barclays group.
>
> Unless specifically indicated, this e-mail is not an offer to buy or sell
> or a solicitation to buy or sell any securities, investment products or
> other financial product or service, an official confirmation of any
> transaction, or an official statement of Barclays.
>

DataModelling in Ignite .NET with Inheritance.

[satyajit.mandal.barclays.com via user]

Hi  Pavel,

Do  we  have  any  working example  with  Parent and Derived  class  data model 
 being saved in  Ignite ?.

Regards
Satyajit

Barclays Execution Services Limited registered in England. Registered No. 
1767980. Registered office: 1 Churchill Place, London, E14 5HP

Barclays Execution Services Limited provides support and administrative 
services across Barclays group. Barclays Execution Services Limited is an 
appointed representative of Barclays Bank UK plc, Barclays Bank plc and 
Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank 
plc are authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale 
Financial Services Limited is authorised and regulated by the Financial Conduct 
Authority.

This email and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this email in error, please 
notify the sender and immediately delete it and any attachments from your 
system. Do not copy, use, disclose or otherwise act on any part of this email 
or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any internet communications by 
any third party, or from the transmission of any viruses. Replies to this email 
may be monitored by the Barclays group for operational or business reasons.

Any opinion or other information in this email or its attachments that does not 
relate to the business of the Barclays group is personal to the sender and is 
not given or endorsed by the Barclays group.

Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays.

Re: ignitevisorcmd tool - alternate option

[Charlin S]

Hi,
Thanks for your email,
/control.sh —system-view CACHES > output.txt works for now, I have not
started using sqlline.

Thanks & Regards,
Charlin


On Mon, 15 Apr 2024 at 22:21, Николай Ижиков  wrote:

> > Thanks for your email, able to get a list of caches like list . but the
> result format is not easy to understand.
> System view command outputs table rows with the single line.
> You can adjust formatting with the following:
>
> ./control.sh —system-view CACHES > output.txt
>
> Then view output.txt with the any editor, disable wrap lines option.
>
>
>
> > 15 апр. 2024 г., в 19:25, Stephen Darlington 
> написал(а):
> >
> > What tool are you using?
> >
> > If you're using sqlline, you could do "!set output vertical" or only
> select the columns you're interested in.
> >
> > On Mon, 15 Apr 2024 at 17:09, Charlin S  wrote:
> > Hello Nizhikov,
> > Thanks for your email, able to get a list of caches like list . but the
> result format is not easy to understand.
> >
> >
> > Thanks & Regards,
> > Charlin
> >
> >
> > On Mon, 15 Apr 2024 at 19:39, Николай Ижиков 
> wrote:
> > Hello, Charlin
> >
> > Looks like system view CACHES can help you.
> >
> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
> >
> >
> > > 15 апр. 2024 г., в 09:30, Charlin S 
> написал(а):
> > >
> > > Hi All,
> > > Thank you for your email.
> > > Still I am missing cache -scan result details like below (in
> visorcmd).
> > > 
> > >  Is it possible to get results using   --cache scan list .   ?
> > >
> > > Thanks & Regards,
> > > Charlin
> > >
> > >
> > >
> > > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков 
> wrote:
> > > Hello, Charlin
> > >
> > > Please, take a look at system views:
> > >
> > > NODES, BASELINE_NODES.
> > >
> > > You can query them by control.sh -
> > >
> > >
> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
> > >
> > > control.sh --system-view nodes
> > >
> > >
> > > > 12 апр. 2024 г., в 15:38, Charlin S 
> написал(а):
> > > >
> > > > Hi Pavel,
> > > > Thank you for your email. --baseline argument not showing client
> node list, actually 1 server and 1 client node should shown
> > > >
> > > > 
> > > >
> > > > Thanks & Regards,
> > > > Charlin
> > > >
> > > >
> > > >
> > > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn 
> wrote:
> > > > control.sh is the replacement:
> > > > https://ignite.apache.org/docs/latest/tools/control-script
> > > >
> > > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah 
> wrote:
> > > > Hi Charlin,
> > > >
> > > > I am working as a Principal Architect at GridGain.
> > > > Let me know if you would like to have a call to discuss your project
> and needs, so I can figure out how to help you.
> > > >
> > > > Regards,
> > > > Rajiv Shah
> > > >
> > > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S 
> wrote:
> > > > Hi All,
> > > > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16
> and found that
> > > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What
> is the alternative way for checking grids statistics and cache details
> without ignitevisorcmd tool.
> > > >
> > > > Thanks & Regards,
> > > > Charlin
> > > >
> > >
> >
>
>

Re: Support for Java records in cache

[Humphrey Lopez]

We have faced the same yesterday, I’m also curious if that will be supported in 
the future.

Humphrey 

> On 11 Apr 2024, at 20:12, Victor  wrote:
> 
> Hi
> 
> Using Ignite 2.16, it seems that it's unsupported yet to have a cache of 
> record classes. If so, two questions:
> 
> - is there ETA to support this out-of-the box?
> 
> - there's related github issue https://github.com/apache/ignite/issues/10846, 
> but how can I re-use this code -- not clear which Ignite API this code should 
> be using.
> 
> Thanks,
> 
> Victor
> 

Re: ignitevisorcmd tool - alternate option

[Николай Ижиков]

> Thanks for your email, able to get a list of caches like list . but the 
> result format is not easy to understand. output.txt

Then view output.txt with the any editor, disable wrap lines option.



> 15 апр. 2024 г., в 19:25, Stephen Darlington  
> написал(а):
> 
> What tool are you using?
> 
> If you're using sqlline, you could do "!set output vertical" or only select 
> the columns you're interested in.
> 
> On Mon, 15 Apr 2024 at 17:09, Charlin S  wrote:
> Hello Nizhikov,
> Thanks for your email, able to get a list of caches like list . but the 
> result format is not easy to understand.
> 
> 
> Thanks & Regards,
> Charlin
> 
> 
> On Mon, 15 Apr 2024 at 19:39, Николай Ижиков  wrote:
> Hello, Charlin
> 
> Looks like system view CACHES can help you.
> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
> 
> 
> > 15 апр. 2024 г., в 09:30, Charlin S  написал(а):
> > 
> > Hi All,
> > Thank you for your email.
> > Still I am missing cache -scan result details like below (in visorcmd). 
> > 
> >  Is it possible to get results using   --cache scan list .   ?
> > 
> > Thanks & Regards,
> > Charlin
> > 
> > 
> > 
> > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков  wrote:
> > Hello, Charlin
> > 
> > Please, take a look at system views:
> > 
> > NODES, BASELINE_NODES.
> > 
> > You can query them by control.sh - 
> > 
> > https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
> > 
> > control.sh --system-view nodes
> > 
> > 
> > > 12 апр. 2024 г., в 15:38, Charlin S  написал(а):
> > > 
> > > Hi Pavel,
> > > Thank you for your email. --baseline argument not showing client node 
> > > list, actually 1 server and 1 client node should shown
> > > 
> > > 
> > > 
> > > Thanks & Regards,
> > > Charlin
> > > 
> > > 
> > > 
> > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn  wrote:
> > > control.sh is the replacement:
> > > https://ignite.apache.org/docs/latest/tools/control-script
> > > 
> > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah  
> > > wrote:
> > > Hi Charlin,
> > > 
> > > I am working as a Principal Architect at GridGain.
> > > Let me know if you would like to have a call to discuss your project and 
> > > needs, so I can figure out how to help you.
> > > 
> > > Regards,
> > > Rajiv Shah
> > > 
> > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S  wrote:
> > > Hi All,
> > > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and 
> > > found that 
> > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is 
> > > the alternative way for checking grids statistics and cache details 
> > > without ignitevisorcmd tool.
> > > 
> > > Thanks & Regards,
> > > Charlin
> > > 
> > 
> 

Re: ignitevisorcmd tool - alternate option

[Stephen Darlington]

What tool are you using?

If you're using sqlline, you could do "!set output vertical" or only select
the columns you're interested in.

On Mon, 15 Apr 2024 at 17:09, Charlin S  wrote:

> Hello Nizhikov,
> Thanks for your email, able to get a list of caches like list . but the
> result format is not easy to understand.
> [image: image.png]
>
> Thanks & Regards,
> Charlin
>
>
> On Mon, 15 Apr 2024 at 19:39, Николай Ижиков  wrote:
>
>> Hello, Charlin
>>
>> Looks like system view CACHES can help you.
>>
>> https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches
>>
>>
>> > 15 апр. 2024 г., в 09:30, Charlin S 
>> написал(а):
>> >
>> > Hi All,
>> > Thank you for your email.
>> > Still I am missing cache -scan result details like below (in visorcmd).
>> > 
>> >  Is it possible to get results using   --cache scan list .   ?
>> >
>> > Thanks & Regards,
>> > Charlin
>> >
>> >
>> >
>> > On Fri, 12 Apr 2024 at 18:46, Николай Ижиков 
>> wrote:
>> > Hello, Charlin
>> >
>> > Please, take a look at system views:
>> >
>> > NODES, BASELINE_NODES.
>> >
>> > You can query them by control.sh -
>> >
>> >
>> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
>> >
>> > control.sh --system-view nodes
>> >
>> >
>> > > 12 апр. 2024 г., в 15:38, Charlin S 
>> написал(а):
>> > >
>> > > Hi Pavel,
>> > > Thank you for your email. --baseline argument not showing client node
>> list, actually 1 server and 1 client node should shown
>> > >
>> > > 
>> > >
>> > > Thanks & Regards,
>> > > Charlin
>> > >
>> > >
>> > >
>> > > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn 
>> wrote:
>> > > control.sh is the replacement:
>> > > https://ignite.apache.org/docs/latest/tools/control-script
>> > >
>> > > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah 
>> wrote:
>> > > Hi Charlin,
>> > >
>> > > I am working as a Principal Architect at GridGain.
>> > > Let me know if you would like to have a call to discuss your project
>> and needs, so I can figure out how to help you.
>> > >
>> > > Regards,
>> > > Rajiv Shah
>> > >
>> > > On Wed, Apr 10, 2024 at 8:01 AM Charlin S 
>> wrote:
>> > > Hi All,
>> > > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16
>> and found that
>> > > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What
>> is the alternative way for checking grids statistics and cache details
>> without ignitevisorcmd tool.
>> > >
>> > > Thanks & Regards,
>> > > Charlin
>> > >
>> >
>>
>>

Re: ignitevisorcmd tool - alternate option

[Николай Ижиков]

Hello, Charlin

Looks like system view CACHES can help you.
https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#caches


> 15 апр. 2024 г., в 09:30, Charlin S  написал(а):
> 
> Hi All,
> Thank you for your email.
> Still I am missing cache -scan result details like below (in visorcmd). 
> 
>  Is it possible to get results using   --cache scan list .   ?
> 
> Thanks & Regards,
> Charlin
> 
> 
> 
> On Fri, 12 Apr 2024 at 18:46, Николай Ижиков  wrote:
> Hello, Charlin
> 
> Please, take a look at system views:
> 
> NODES, BASELINE_NODES.
> 
> You can query them by control.sh - 
> 
> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
> 
> control.sh --system-view nodes
> 
> 
> > 12 апр. 2024 г., в 15:38, Charlin S  написал(а):
> > 
> > Hi Pavel,
> > Thank you for your email. --baseline argument not showing client node list, 
> > actually 1 server and 1 client node should shown
> > 
> > 
> > 
> > Thanks & Regards,
> > Charlin
> > 
> > 
> > 
> > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn  wrote:
> > control.sh is the replacement:
> > https://ignite.apache.org/docs/latest/tools/control-script
> > 
> > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah  wrote:
> > Hi Charlin,
> > 
> > I am working as a Principal Architect at GridGain.
> > Let me know if you would like to have a call to discuss your project and 
> > needs, so I can figure out how to help you.
> > 
> > Regards,
> > Rajiv Shah
> > 
> > On Wed, Apr 10, 2024 at 8:01 AM Charlin S  wrote:
> > Hi All,
> > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and 
> > found that 
> > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is the 
> > alternative way for checking grids statistics and cache details without 
> > ignitevisorcmd tool.
> > 
> > Thanks & Regards,
> > Charlin
> > 
> 

Re: Question regarding text search in ignite

[Pavel Tupitsyn]

Hi Satyajit, we (Ignite community members) are subscribed to Stackoverflow
too. I don't have anything to add to the existing answer there.

On Mon, Apr 15, 2024 at 8:09 AM  wrote:

> Hi  Pavel/Team,
>
>
>
> Is the  below  explanation  holds  good  from  your  side. Need some
> confirmation on  highlighted  line in  yellow.  We  are  not  using
> Native  persistence.  Our cluster is  in  memory  with  external  cache
> store enabled.
>
>
>
>
> https://stackoverflow.com/questions/70232020/ignite-search-query-not-returning-results-after-cluster-restart-with-native-pers
>
>
>
>
>
>
>
> UPD: in case of configured backups for a partitioned cache it should work
> as a regular index. For example if you add an additional node to the
> baseline topology you would see a rebalance
>  
> happening.
> Rebalance uses regular cache operations to insert entries. Lucene index
> would be built
> 
>  on
> the new node. On the contrary if you remove a node from a cluster you
> would still have a full copy of data including text indexes.
>
>
>
> Regards
>
> Satyajit
>
>
>
>
>
> Barclays Execution Services Limited registered in England. Registered No.
> 1767980. Registered office: 1 Churchill Place, London, E14 5HP
>
> Barclays Execution Services Limited provides support and administrative
> services across Barclays group. Barclays Execution Services Limited is an
> appointed representative of Barclays Bank UK plc, Barclays Bank plc and
> Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays
> Bank plc are authorised by the Prudential Regulation Authority and
> regulated by the Financial Conduct Authority and the Prudential Regulation
> Authority. Clydesdale Financial Services Limited is authorised and
> regulated by the Financial Conduct Authority.
>
> This email and any attachments are confidential and intended solely for
> the addressee and may also be privileged or exempt from disclosure under
> applicable law. If you are not the addressee, or have received this email
> in error, please notify the sender and immediately delete it and any
> attachments from your system. Do not copy, use, disclose or otherwise act
> on any part of this email or its attachments.
>
> Internet communications are not guaranteed to be secure or virus-free. The
> Barclays group does not accept responsibility for any loss arising from
> unauthorised access to, or interference with, any internet communications
> by any third party, or from the transmission of any viruses. Replies to
> this email may be monitored by the Barclays group for operational or
> business reasons.
>
> Any opinion or other information in this email or its attachments that
> does not relate to the business of the Barclays group is personal to the
> sender and is not given or endorsed by the Barclays group.
>
> Unless specifically indicated, this e-mail is not an offer to buy or sell
> or a solicitation to buy or sell any securities, investment products or
> other financial product or service, an official confirmation of any
> transaction, or an official statement of Barclays.
>

Re: ignitevisorcmd tool - alternate option

[Charlin S]

Hi All,
Thank you for your email.
Still I am missing cache -scan result details like below (in visorcmd).
[image: image.png]
* Is it possible to get results using  ** --cache scan list .  ** ?*

Thanks & Regards,
Charlin



On Fri, 12 Apr 2024 at 18:46, Николай Ижиков  wrote:

> Hello, Charlin
>
> Please, take a look at system views:
>
> NODES, BASELINE_NODES.
>
> You can query them by control.sh -
>
>
> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
>
> control.sh --system-view nodes
>
>
> > 12 апр. 2024 г., в 15:38, Charlin S  написал(а):
> >
> > Hi Pavel,
> > Thank you for your email. --baseline argument not showing client node
> list, actually 1 server and 1 client node should shown
> >
> > 
> >
> > Thanks & Regards,
> > Charlin
> >
> >
> >
> > On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn 
> wrote:
> > control.sh is the replacement:
> > https://ignite.apache.org/docs/latest/tools/control-script
> >
> > On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah 
> wrote:
> > Hi Charlin,
> >
> > I am working as a Principal Architect at GridGain.
> > Let me know if you would like to have a call to discuss your project and
> needs, so I can figure out how to help you.
> >
> > Regards,
> > Rajiv Shah
> >
> > On Wed, Apr 10, 2024 at 8:01 AM Charlin S 
> wrote:
> > Hi All,
> > Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and
> found that
> > ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is
> the alternative way for checking grids statistics and cache details without
> ignitevisorcmd tool.
> >
> > Thanks & Regards,
> > Charlin
> >
>
>

Question regarding text search in ignite

[satyajit.mandal.barclays.com via user]

Hi  Pavel/Team,

Is the  below  explanation  holds  good  from  your  side. Need some  
confirmation on  highlighted  line in  yellow.  We  are  not  using  Native  
persistence.  Our cluster is  in  memory  with  external  cache  store enabled.

https://stackoverflow.com/questions/70232020/ignite-search-query-not-returning-results-after-cluster-restart-with-native-pers



UPD: in case of configured backups for a partitioned cache it should work as a 
regular index. For example if you add an additional node to the baseline 
topology you would see a 
rebalance
 happening. Rebalance uses regular cache operations to insert entries. Lucene 
index would be 
built
 on the new node. On the contrary if you remove a node from a cluster you would 
still have a full copy of data including text indexes.

Regards
Satyajit



Barclays Execution Services Limited registered in England. Registered No. 
1767980. Registered office: 1 Churchill Place, London, E14 5HP

Barclays Execution Services Limited provides support and administrative 
services across Barclays group. Barclays Execution Services Limited is an 
appointed representative of Barclays Bank UK plc, Barclays Bank plc and 
Clydesdale Financial Services Limited. Barclays Bank UK plc and Barclays Bank 
plc are authorised by the Prudential Regulation Authority and regulated by the 
Financial Conduct Authority and the Prudential Regulation Authority. Clydesdale 
Financial Services Limited is authorised and regulated by the Financial Conduct 
Authority.

This email and any attachments are confidential and intended solely for the 
addressee and may also be privileged or exempt from disclosure under applicable 
law. If you are not the addressee, or have received this email in error, please 
notify the sender and immediately delete it and any attachments from your 
system. Do not copy, use, disclose or otherwise act on any part of this email 
or its attachments.

Internet communications are not guaranteed to be secure or virus-free. The 
Barclays group does not accept responsibility for any loss arising from 
unauthorised access to, or interference with, any internet communications by 
any third party, or from the transmission of any viruses. Replies to this email 
may be monitored by the Barclays group for operational or business reasons.

Any opinion or other information in this email or its attachments that does not 
relate to the business of the Barclays group is personal to the sender and is 
not given or endorsed by the Barclays group.

Unless specifically indicated, this e-mail is not an offer to buy or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or service, an official confirmation of any transaction, or 
an official statement of Barclays.

Re: ignitevisorcmd tool - alternate option

[Николай Ижиков]

Hello, Charlin

Please, take a look at system views:

NODES, BASELINE_NODES.

You can query them by control.sh - 

https://ignite.apache.org/docs/latest/tools/control-script#system-view-command

control.sh --system-view nodes


> 12 апр. 2024 г., в 15:38, Charlin S  написал(а):
> 
> Hi Pavel,
> Thank you for your email. --baseline argument not showing client node list, 
> actually 1 server and 1 client node should shown
> 
> 
> 
> Thanks & Regards,
> Charlin
> 
> 
> 
> On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn  wrote:
> control.sh is the replacement:
> https://ignite.apache.org/docs/latest/tools/control-script
> 
> On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah  wrote:
> Hi Charlin,
> 
> I am working as a Principal Architect at GridGain.
> Let me know if you would like to have a call to discuss your project and 
> needs, so I can figure out how to help you.
> 
> Regards,
> Rajiv Shah
> 
> On Wed, Apr 10, 2024 at 8:01 AM Charlin S  wrote:
> Hi All,
> Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and 
> found that 
> ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is the 
> alternative way for checking grids statistics and cache details without 
> ignitevisorcmd tool.
> 
> Thanks & Regards,
> Charlin
> 

Re: ignitevisorcmd tool - alternate option

[Charlin S]

Hi Pavel,
Thank you for your email. --baseline argument not showing client node list,
actually 1 server and 1 client node should shown

[image: image.png]

Thanks & Regards,
Charlin



On Wed, 10 Apr 2024 at 18:40, Pavel Tupitsyn  wrote:

> control.sh is the replacement:
> https://ignite.apache.org/docs/latest/tools/control-script
>
> On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah 
> wrote:
>
>> Hi Charlin,
>>
>> I am working as a Principal Architect at GridGain.
>> Let me know if you would like to have a call to discuss your project and
>> needs, so I can figure out how to help you.
>>
>> Regards,
>> Rajiv Shah
>>
>> On Wed, Apr 10, 2024 at 8:01 AM Charlin S  wrote:
>>
>>> Hi All,
>>> Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and
>>> found that
>>> ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is
>>> the alternative way for checking grids statistics and cache details without
>>> ignitevisorcmd tool.
>>>
>>> Thanks & Regards,
>>> Charlin
>>>
>>>

Re: Cache put event new value type

[Stephen Darlington]

You can always convert it back into a POJO using the deserialize method:

var y = x.deserialize();


On Thu, 11 Apr 2024 at 19:09, Victor  wrote:

> Hi
>
> In Ignite 2.16, I seeing that newVal method of cache event returns a
> BinaryObjectImpl. Is it possible to make it return actual user-defined
> type contained in cache, by some config value? Wasn't able to find
> relevant info in docs.
>
> Thanks,
> Victor
>
>

writeBehind and continousQuery

[Mike Wiesenberg]

Hello,
 When configured with (writeThrough and) writeBehind, does ignite only
deliver objects to continuous query listeners after the object has been
written to the persistence cache? It seems from my testing that is the
case, and that it shouldn't be.

Can someone point me to the source code where it writes/sends objects to
continuous query clients?

Thanks,
 Mike

Support for Java records in cache

[Victor]

Hi

Using Ignite 2.16, it seems that it's unsupported yet to have a cache of 
record classes. If so, two questions:


- is there ETA to support this out-of-the box?

- there's related github issue 
https://github.com/apache/ignite/issues/10846, but how can I re-use this 
code -- not clear which Ignite API this code should be using.


Thanks,

Victor

Cache put event new value type

[Victor]

Hi

In Ignite 2.16, I seeing that newVal method of cache event returns a 
BinaryObjectImpl. Is it possible to make it return actual user-defined 
type contained in cache, by some config value? Wasn't able to find 
relevant info in docs.


Thanks,
Victor

Re: ignitevisorcmd tool - alternate option

[Pavel Tupitsyn]

control.sh is the replacement:
https://ignite.apache.org/docs/latest/tools/control-script

On Wed, Apr 10, 2024 at 3:56 PM Rajiv Shah  wrote:

> Hi Charlin,
>
> I am working as a Principal Architect at GridGain.
> Let me know if you would like to have a call to discuss your project and
> needs, so I can figure out how to help you.
>
> Regards,
> Rajiv Shah
>
> On Wed, Apr 10, 2024 at 8:01 AM Charlin S  wrote:
>
>> Hi All,
>> Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and
>> found that
>> ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is
>> the alternative way for checking grids statistics and cache details without
>> ignitevisorcmd tool.
>>
>> Thanks & Regards,
>> Charlin
>>
>>

Re: ignitevisorcmd tool - alternate option

[Rajiv Shah]

Hi Charlin,

I am working as a Principal Architect at GridGain.
Let me know if you would like to have a call to discuss your project and
needs, so I can figure out how to help you.

Regards,
Rajiv Shah

On Wed, Apr 10, 2024 at 8:01 AM Charlin S  wrote:

> Hi All,
> Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and
> found that
> ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is
> the alternative way for checking grids statistics and cache details without
> ignitevisorcmd tool.
>
> Thanks & Regards,
> Charlin
>
>

ignitevisorcmd tool - alternate option

[Charlin S]

Hi All,
Currently I am using Ignite 2.10 and planning to upgrade Ignite 2.16 and
found that
ignitevisorcmd  tool had been removed from Ignite 2.15 onwards. What is the
alternative way for checking grids statistics and cache details without
ignitevisorcmd tool.

Thanks & Regards,
Charlin

RE: Use of distributed computing in C++

[Louis C]

Thanks, it is much clearer now !



De : Pavel Tupitsyn 
Envoyé : lundi 8 avril 2024 16:36
À : user@ignite.apache.org 
Objet : Re: Use of distributed computing in C++

I thought the question was about thin client, which can only run Java tasks.

The attached code will work from a C++ thick client or server node, the 
requirement is to invoke RegisterComputeFunc [1] on every server node 
beforehand.

[1] 
https://ignite.apache.org/releases/latest/cppdoc/classignite_1_1IgniteBinding.html#a25339becdaa6ea01c6ef2d4ec8da

On Mon, Apr 8, 2024 at 4:30 PM Louis C 
mailto:l...@outlook.fr>> wrote:
Thanks for your answer, it answers a part of my question.

But what about this code that is pure C++ ? (can be seen on the previous link I 
sent) :

[cid:ii_18ebe2192c3cb971f161]
How does one make sure that the server knows this task ?

Best regards,
Louis

De : Pavel Tupitsyn mailto:ptupit...@apache.org>>
Envoyé : lundi 8 avril 2024 11:34
À : user@ignite.apache.org 
mailto:user@ignite.apache.org>>
Objet : Re: Use of distributed computing in C++

С++ client can execute Compute tasks that are written in Java and deployed to 
the server nodes:

https://ignite.apache.org/releases/latest/cppdoc/classignite_1_1thin_1_1compute_1_1ComputeClient.html

On Fri, Apr 5, 2024 at 3:41 PM Louis C 
mailto:l...@outlook.fr>> wrote:
Hello everyone,

I was interested in the distributed computed in C++ in Ignite, as described 
here :
https://ignite.apache.org/docs/latest/distributed-computing/distributed-computing

I noted that the classes that will be executed must be known by the server, as 
said here :



In order to run tasks on the remote nodes, make sure the class definitions of 
the tasks are available on the nodes. You can do this in two ways:

  *   Add the classes to the classpath of the nodes;

  *   Enable peer class 
loading.

However these 2 points are mostly related to Java-based tasks, and I could not 
find anything regarding C++.
So my question will be : how can a C++ client share an execution task on the 
server nodes ? Is it transparent ?
Must we add a dll/.so on the server nodes ? In this case how to load this dll ?

Thanks in advance,
Louis C

Re: Use of distributed computing in C++

[Pavel Tupitsyn]

I thought the question was about thin client, which can only run Java tasks.

The attached code will work from a C++ thick client or server node, the
requirement is to invoke RegisterComputeFunc [1] on every server node
beforehand.

[1]
https://ignite.apache.org/releases/latest/cppdoc/classignite_1_1IgniteBinding.html#a25339becdaa6ea01c6ef2d4ec8da

On Mon, Apr 8, 2024 at 4:30 PM Louis C  wrote:

> Thanks for your answer, it answers a part of my question.
>
> But what about this code that is pure C++ ? (can be seen on the previous
> link I sent) :
>
>
> How does one make sure that the server knows this task ?
>
> Best regards,
> Louis
> --
> *De :* Pavel Tupitsyn 
> *Envoyé :* lundi 8 avril 2024 11:34
> *À :* user@ignite.apache.org 
> *Objet :* Re: Use of distributed computing in C++
>
> С++ client can execute Compute tasks that are written in Java and deployed
> to the server nodes:
>
>
> https://ignite.apache.org/releases/latest/cppdoc/classignite_1_1thin_1_1compute_1_1ComputeClient.html
>
> On Fri, Apr 5, 2024 at 3:41 PM Louis C  wrote:
>
> Hello everyone,
>
> I was interested in the distributed computed in C++ in Ignite, as
> described here :
>
> https://ignite.apache.org/docs/latest/distributed-computing/distributed-computing
>
> I noted that the classes that will be executed must be known by the
> server, as said here :
>
>
> *In order to run tasks on the remote nodes, make sure the class
> definitions of the tasks are available on the nodes. You can do this in two
> ways:*
>
>-
>
>*Add the classes to the classpath of the nodes;*
>-
>
>*Enable peer class loading
>
> .*
>
> However these 2 points are mostly related to Java-based tasks, and I could
> not find anything regarding C++.
> So my question will be : how can a C++ client share an execution task on
> the server nodes ? Is it transparent ?
> Must we add a dll/.so on the server nodes ? In this case how to load this
> dll ?
>
> Thanks in advance,
> Louis C
>
>

RE: Use of distributed computing in C++

[Louis C]

Thanks for your answer, it answers a part of my question.

But what about this code that is pure C++ ? (can be seen on the previous link I 
sent) :

[cid:7fd825a6-4269-4ded-80ea-530ed872a545]
How does one make sure that the server knows this task ?

Best regards,
Louis

De : Pavel Tupitsyn 
Envoyé : lundi 8 avril 2024 11:34
À : user@ignite.apache.org 
Objet : Re: Use of distributed computing in C++

С++ client can execute Compute tasks that are written in Java and deployed to 
the server nodes:

https://ignite.apache.org/releases/latest/cppdoc/classignite_1_1thin_1_1compute_1_1ComputeClient.html

On Fri, Apr 5, 2024 at 3:41 PM Louis C 
mailto:l...@outlook.fr>> wrote:
Hello everyone,

I was interested in the distributed computed in C++ in Ignite, as described 
here :
https://ignite.apache.org/docs/latest/distributed-computing/distributed-computing

I noted that the classes that will be executed must be known by the server, as 
said here :



In order to run tasks on the remote nodes, make sure the class definitions of 
the tasks are available on the nodes. You can do this in two ways:

  *   Add the classes to the classpath of the nodes;

  *   Enable peer class 
loading.

However these 2 points are mostly related to Java-based tasks, and I could not 
find anything regarding C++.
So my question will be : how can a C++ client share an execution task on the 
server nodes ? Is it transparent ?
Must we add a dll/.so on the server nodes ? In this case how to load this dll ?

Thanks in advance,
Louis C

Re: Use of distributed computing in C++

[Pavel Tupitsyn]

С++ client can execute Compute tasks that are written in Java and deployed
to the server nodes:

https://ignite.apache.org/releases/latest/cppdoc/classignite_1_1thin_1_1compute_1_1ComputeClient.html

On Fri, Apr 5, 2024 at 3:41 PM Louis C  wrote:

> Hello everyone,
>
> I was interested in the distributed computed in C++ in Ignite, as
> described here :
>
> https://ignite.apache.org/docs/latest/distributed-computing/distributed-computing
>
> I noted that the classes that will be executed must be known by the
> server, as said here :
>
>
> *In order to run tasks on the remote nodes, make sure the class
> definitions of the tasks are available on the nodes. You can do this in two
> ways:*
>
>-
>
>*Add the classes to the classpath of the nodes;*
>-
>
>*Enable peer class loading
>
> .*
>
> However these 2 points are mostly related to Java-based tasks, and I could
> not find anything regarding C++.
> So my question will be : how can a C++ client share an execution task on
> the server nodes ? Is it transparent ?
> Must we add a dll/.so on the server nodes ? In this case how to load this
> dll ?
>
> Thanks in advance,
> Louis C
>

Use of distributed computing in C++

[Louis C]

Hello everyone,

I was interested in the distributed computed in C++ in Ignite, as described 
here :
https://ignite.apache.org/docs/latest/distributed-computing/distributed-computing

I noted that the classes that will be executed must be known by the server, as 
said here :



In order to run tasks on the remote nodes, make sure the class definitions of 
the tasks are available on the nodes. You can do this in two ways:

  *   Add the classes to the classpath of the nodes;

  *   Enable peer class 
loading.

However these 2 points are mostly related to Java-based tasks, and I could not 
find anything regarding C++.
So my question will be : how can a C++ client share an execution task on the 
server nodes ? Is it transparent ?
Must we add a dll/.so on the server nodes ? In this case how to load this dll ?

Thanks in advance,
Louis C

Participate in the ASF 25th Anniversary Campaign

[Brian Proffitt]

Hi everyone,

As part of The ASF’s 25th anniversary campaign[1], we will be celebrating
projects and communities in multiple ways.

We invite all projects and contributors to participate in the following
ways:

* Individuals - submit your first contribution:
https://news.apache.org/foundation/entry/the-asf-launches-firstasfcontribution-campaign
* Projects - share your public good story:
https://docs.google.com/forms/d/1vuN-tUnBwpTgOE5xj3Z5AG1hsOoDNLBmGIqQHwQT6k8/viewform?edit_requested=true
* Projects - submit a project spotlight for the blog:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=278466116
* Projects - contact the Voice of Apache podcast (formerly Feathercast) to
be featured: https://feathercast.apache.org/help/
*  Projects - use the 25th anniversary template and the #ASF25Years hashtag
on social media:
https://docs.google.com/presentation/d/1oDbMol3F_XQuCmttPYxBIOIjRuRBksUjDApjd8Ve3L8/edit#slide=id.g26b0919956e_0_13

If you have questions, email the Marketing & Publicity team at
mark...@apache.org.

Peace,
BKP

[1] https://apache.org/asf25years/

[NOTE: You are receiving this message because you are a contributor to an
Apache Software Foundation project. The ASF will very occasionally send out
messages relating to the Foundation to contributors and members, such as
this one.]

Brian Proffitt
VP, Marketing & Publicity
VP, Conferences

Re: Failed to send TTL update request - Ignite 2.10

[Stephen Darlington]

Just a reminder that this list is run by volunteers, so we can't guarantee
a response in a given time. Commercial options are available if you need
that.

As for your question: is this the problem?
https://issues.apache.org/jira/browse/IGNITE-16118

On Wed, 3 Apr 2024 at 14:00, Charlin S  wrote:

> Hi All,
> could you please help me with this.
>
> Thanks & Regards,
> Charlin
>
>
>
> On Wed, 27 Mar 2024 at 18:12, Charlin S  wrote:
>
>> Hi All,
>> We are seeing recently Failed to send TTL update request error in Ignite
>> server log. What could be the problem?
>> Cache configuration includes : EagerTtl = true
>> Kindly advise on this.
>>
>> Thanks,
>> Charlin
>>
>>

Re: Failed to send TTL update request - Ignite 2.10

[Charlin S]

Hi All,
could you please help me with this.

Thanks & Regards,
Charlin



On Wed, 27 Mar 2024 at 18:12, Charlin S  wrote:

> Hi All,
> We are seeing recently Failed to send TTL update request error in Ignite
> server log. What could be the problem?
> Cache configuration includes : EagerTtl = true
> Kindly advise on this.
>
> Thanks,
> Charlin
>
>

Ignite 2.16 jetty logging at debug . Cannot turn off

[manikantannaren]

Environment:
Ignite version: 2.16
HTTP enabled - yes
Logging module - Log4J2
Execution Environment
 Containerized -Yes
  Base Image : Distroless 12 java
  JRE - JRE 17

I am using the Log4j Logging module and set logger for eclipse jetty to
Off/Error, but still see debug logs for jetty.  I do not see this issue
with Ignite 2.15
I also tried setting the JVM opt variable -DIGNITE_QUIET to true and false.
Still keep seeing debug lgs from jetty

log4j config
I added individual packages to try suppressing at per package level

  


  


  


How to turn off Logging for eclipse jetty
*Cheers*
Mani/Naren/Iyer
*The trick of walking on water is knowing where the stones are.*

Failed to send TTL update request - Ignite 2.10

[Charlin S]

Hi All,
We are seeing recently Failed to send TTL update request error in Ignite
server log. What could be the problem?
Cache configuration includes : EagerTtl = true
Kindly advise on this.

Thanks,
Charlin

Community Over Code NA 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

[ You are receiving this email as a subscriber to one or more ASF project
dev or user
  mailing lists and is not being sent to you directly. It is important that
we reach all of our
  users and contributors/committers so that they may get a chance to
benefit from this.
  We apologise in advance if this doesn't interest you but it is on topic
for the mailing
  lists of the Apache Software Foundation; and it is important please that
you do not
  mark this as spam in your email client. Thank You! ]

The Travel Assistance Committee (TAC) are pleased to announce that
travel assistance applications for Community over Code NA 2024 are now
open!

We will be supporting Community over Code NA, Denver Colorado in
October 7th to the 10th 2024.

TAC exists to help those that would like to attend Community over Code
events, but are unable to do so for financial reasons. For more info
on this years applications and qualifying criteria, please visit the
TAC website at < https://tac.apache.org/ >. Applications are already
open on https://tac-apply.apache.org/, so don't delay!

The Apache Travel Assistance Committee will only be accepting
applications from those people that are able to attend the full event.

Important: Applications close on Monday 6th May, 2024.

Applicants have until the the closing date above to submit their
applications (which should contain as much supporting material as
required to efficiently and accurately process their request), this
will enable TAC to announce successful applications shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a
diverse range of backgrounds; therefore, we encourage (as always)
anyone thinking about sending in an application to do so ASAP.

For those that will need a Visa to enter the Country - we advise you apply
now so that you have enough time in case of interview delays. So do not
wait until you know if you have been accepted or not.

We look forward to greeting many of you in Denver, Colorado , October 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

RE: Turning off deadlock detection

[Thomas Ketter via user]

Hi Ronak,
Make sure you don’t have ATOMIC table updates within your transaction.

Thomas

From: Stephen Darlington 
Sent: Monday, March 25, 2024 2:31 AM
To: user@ignite.apache.org
Subject: Re: Turning off deadlock detection

This is an EXTERNAL EMAIL. Stop and think before clicking a link or opening 
attachments.
Just a reminder that this list is run by volunteers. If you need responses in a 
given time, commercial options are available.

On Sat, 23 Mar 2024 at 17:50, Ronak Shah 
mailto:ronak.malav.s...@gmail.com>> wrote:
Ping again. Can someone answer please? - Ronak

On Mon, Mar 18, 2024 at 12:04 PM Ronak Shah 
mailto:ronak.malav.s...@gmail.com>> wrote:
Hi Ignite users,
I am hitting a situation in a scaled environment where if the transaction 
timeouts for whatever reason, the cluster goes in a deadlock detection mode, 
where it is taking even more time to holding up lock and creating snowball 
effect on queued up transactions before going in a completely dead state.

I am wondering if it is safe to deadlock detection to be turned off by making
IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS to 0

Based on the guide, this detection is only for the bookkeeping and it is safe 
to turned off.

Any guidance on that would be greatly appreciated.

Ronak
Please follow the hyperlink to important disclosures.
https://www.dodgeandcox.com/disclosures/email_disclosure_funds.html

Re: Turning off deadlock detection

[Stephen Darlington]

Just a reminder that this list is run by volunteers. If you need responses
in a given time, commercial options are available.

On Sat, 23 Mar 2024 at 17:50, Ronak Shah  wrote:

> Ping again. Can someone answer please? - Ronak
>
> On Mon, Mar 18, 2024 at 12:04 PM Ronak Shah 
> wrote:
>
>> Hi Ignite users,
>> I am hitting a situation in a scaled environment where if the transaction
>> timeouts for whatever reason, the cluster goes in a deadlock detection
>> mode, where it is taking even more time to holding up lock and creating
>> snowball effect on queued up transactions before going in a completely dead
>> state.
>>
>> I am wondering if it is safe to deadlock detection to be turned off by
>> making
>> IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS to 0
>>
>> Based on the guide, this detection is only for the bookkeeping and it is
>> safe to turned off.
>>
>> Any guidance on that would be greatly appreciated.
>>
>> Ronak
>>
>

Re: Turning off deadlock detection

[Ronak Shah]

Thanks Jeremy for the reply. Why does deadlock detection pause all other transaction though for a min? Shouldnt it be a low priority thread job compared to db transactions?RonakOn Mar 24, 2024, at 8:52 PM, Jeremy McMillan  wrote:https://ignite.apache.org/docs/latest/key-value-api/transactions#deadlock-detectionThe property you're asking about is for diagnostics to enable prevention of future deadlocks. Turning it off is fine if you already know or can find out another way what is deadlocked and why.On Sat, Mar 23, 2024 at 12:50 PM Ronak Shah  wrote:Ping again. Can someone answer please? - RonakOn Mon, Mar 18, 2024 at 12:04 PM Ronak Shah  wrote:Hi Ignite users,I am hitting a situation in a scaled environment where if the transaction timeouts for whatever reason, the cluster goes in a deadlock detection mode, where it is taking even more time to holding up lock and creating snowball effect on queued up transactions before going in a completely dead state.I am wondering if it is safe to deadlock detection to be turned off by making IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS to 0Based on the guide, this detection is only for the bookkeeping and it is safe to turned off. Any guidance on that would be greatly appreciated.Ronak

Re: Turning off deadlock detection

[Jeremy McMillan]

https://ignite.apache.org/docs/latest/key-value-api/transactions#deadlock-detection

The property you're asking about is for diagnostics to enable prevention of
future deadlocks. Turning it off is fine if you already know or can find
out another way what is deadlocked and why.

On Sat, Mar 23, 2024 at 12:50 PM Ronak Shah 
wrote:

> Ping again. Can someone answer please? - Ronak
>
> On Mon, Mar 18, 2024 at 12:04 PM Ronak Shah 
> wrote:
>
>> Hi Ignite users,
>> I am hitting a situation in a scaled environment where if the transaction
>> timeouts for whatever reason, the cluster goes in a deadlock detection
>> mode, where it is taking even more time to holding up lock and creating
>> snowball effect on queued up transactions before going in a completely dead
>> state.
>>
>> I am wondering if it is safe to deadlock detection to be turned off by
>> making
>> IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS to 0
>>
>> Based on the guide, this detection is only for the bookkeeping and it is
>> safe to turned off.
>>
>> Any guidance on that would be greatly appreciated.
>>
>> Ronak
>>
>

Re: Turning off deadlock detection

[Ronak Shah]

Ping again. Can someone answer please? - Ronak

On Mon, Mar 18, 2024 at 12:04 PM Ronak Shah 
wrote:

> Hi Ignite users,
> I am hitting a situation in a scaled environment where if the transaction
> timeouts for whatever reason, the cluster goes in a deadlock detection
> mode, where it is taking even more time to holding up lock and creating
> snowball effect on queued up transactions before going in a completely dead
> state.
>
> I am wondering if it is safe to deadlock detection to be turned off by
> making
> IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS to 0
>
> Based on the guide, this detection is only for the bookkeeping and it is
> safe to turned off.
>
> Any guidance on that would be greatly appreciated.
>
> Ronak
>

Re: Server node down due to ClassCastException: o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to o.a.i.i.GridJobExecuteRequest

[Gangaiah.Gundeboina.ril.com via user]

Hi,

Can we keep SYSTEM_WORKER_TERMINATION in ignoredFailureTypes, is there any 
impact. Want to ignore these casting exceptions instead of the server going 
down.


2024-03-16T18:37:15,313][ERROR][sys-stripe-56-#57%EDIFCustomerCCNDR%][] 
Critical system error detected. Will be handled accordingly to configured 
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0, 
super=AbstractFailureHandler [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED, 
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext 
[type=SYSTEM_WORKER_TERMINATION, err=java.lang.ClassCastException: 
o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to 
o.a.i.i.GridJobExecuteRequest]]

Thanks,
Gangaiah

From: Gangaiah Gundeboina 
Sent: 17 March 2024 15:26
To: user@ignite.apache.org ; Gangaiah Gundeboina 

Subject: Re: Server node down due to ClassCastException: 
o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to 
o.a.i.i.GridJobExecuteRequest

Hi Stephen/Mikhail,

We are getting this issue frequently and bit urgent, server node going out of 
the cluster.

Could you please help us.

Thanks,
Gangaiah

From: Gangaiah.Gundeboina.ril.com via user 
Sent: 16 March 2024 11:29
To: user@ignite.apache.org 
Subject: [External]Server node down due to ClassCastException: 
o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to 
o.a.i.i.GridJobExecuteRequest


Caution: The e-mail below is from an external source. Please do not open 
attachments or click links unless this email comes from a known sender and you 
know the content is safe.


Hi,

One of the 8 server node cluster down suddenly, printed error not that much 
helpful to find the reason. Given below the log entries, please help us here to 
find the reason.



2024-03-16T07:18:52,489][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=90c6ab62-a441-4cd3-8b6d-fbef550fbe4c, 
startPtr=FileWALPointer [idx=5463768, fileOff=51537417, len=56705], 
checkpointLockWait=0ms, checkpointLockHoldTime=21ms, 
walCpRecordFsyncDuration=4ms, pages=62810, reason='timeout']
2024-03-16T07:18:53,565][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint finished [cpId=90c6ab62-a441-4cd3-8b6d-fbef550fbe4c, pages=62810, 
markPos=FileWALPointer [idx=5463768, fileOff=51537417, len=56705], 
walSegmentsCleared=4, walSegmentsCovered=[5463764 - 5463767], 
markDuration=43ms, pagesWrite=491ms, fsync=585ms, total=1119ms]
2024-03-16T07:19:11,191][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463768, segIdx=8, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0008.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463768.wal]
2024-03-16T07:19:11,318][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0008.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463768.wal]
2024-03-16T07:19:33,988][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463769, segIdx=9, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0009.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463769.wal]
2024-03-16T07:19:34,121][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0009.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463769.wal]
2024-03-16T07:20:18,852][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463770, segIdx=0, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463770.wal]
2024-03-16T07:20:19,000][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463770.wal]
2024-03-16T07:21:15,373][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463771, segIdx=1, 

Turning off deadlock detection

[Ronak Shah]

Hi Ignite users,
I am hitting a situation in a scaled environment where if the transaction
timeouts for whatever reason, the cluster goes in a deadlock detection
mode, where it is taking even more time to holding up lock and creating
snowball effect on queued up transactions before going in a completely dead
state.

I am wondering if it is safe to deadlock detection to be turned off by
making
IGNITE_TX_DEADLOCK_DETECTION_MAX_ITERS to 0

Based on the guide, this detection is only for the bookkeeping and it is
safe to turned off.

Any guidance on that would be greatly appreciated.

Ronak

Re: Server node down due to ClassCastException: o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to o.a.i.i.GridJobExecuteRequest

[Gangaiah.Gundeboina.ril.com via user]

Hi Stephen/Mikhail,

We are getting this issue frequently and bit urgent, server node going out of 
the cluster.

Could you please help us.

Thanks,
Gangaiah

From: Gangaiah.Gundeboina.ril.com via user 
Sent: 16 March 2024 11:29
To: user@ignite.apache.org 
Subject: [External]Server node down due to ClassCastException: 
o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to 
o.a.i.i.GridJobExecuteRequest


Caution: The e-mail below is from an external source. Please do not open 
attachments or click links unless this email comes from a known sender and you 
know the content is safe.


Hi,

One of the 8 server node cluster down suddenly, printed error not that much 
helpful to find the reason. Given below the log entries, please help us here to 
find the reason.



2024-03-16T07:18:52,489][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=90c6ab62-a441-4cd3-8b6d-fbef550fbe4c, 
startPtr=FileWALPointer [idx=5463768, fileOff=51537417, len=56705], 
checkpointLockWait=0ms, checkpointLockHoldTime=21ms, 
walCpRecordFsyncDuration=4ms, pages=62810, reason='timeout']
2024-03-16T07:18:53,565][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint finished [cpId=90c6ab62-a441-4cd3-8b6d-fbef550fbe4c, pages=62810, 
markPos=FileWALPointer [idx=5463768, fileOff=51537417, len=56705], 
walSegmentsCleared=4, walSegmentsCovered=[5463764 - 5463767], 
markDuration=43ms, pagesWrite=491ms, fsync=585ms, total=1119ms]
2024-03-16T07:19:11,191][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463768, segIdx=8, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0008.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463768.wal]
2024-03-16T07:19:11,318][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0008.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463768.wal]
2024-03-16T07:19:33,988][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463769, segIdx=9, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0009.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463769.wal]
2024-03-16T07:19:34,121][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0009.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463769.wal]
2024-03-16T07:20:18,852][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463770, segIdx=0, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463770.wal]
2024-03-16T07:20:19,000][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463770.wal]
2024-03-16T07:21:15,373][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463771, segIdx=1, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0001.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463771.wal]
2024-03-16T07:21:15,500][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0001.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463771.wal]
2024-03-16T07:21:52,493][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=d12adda8-2202-4192-bbeb-f5083d3eabc9, 
startPtr=FileWALPointer [idx=5463772, fileOff=44231024, len=56705], 
checkpointLockWait=0ms, checkpointLockHoldTime=25ms, 
walCpRecordFsyncDuration=5ms, pages=61176, reason='timeout']
2024-03-16T07:21:53,433][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint finished [cpId=d12adda8-2202-4192-bbeb-f5083d3eabc9, pages=61176, 
markPos=FileWALPointer [idx=5463772, 

Server node down due to ClassCastException: o.a.i.i.processors.cache.distributed.near.GridNearGetRequest cannot be cast to o.a.i.i.GridJobExecuteRequest

[Gangaiah.Gundeboina.ril.com via user]

Hi,

One of the 8 server node cluster down suddenly, printed error not that much 
helpful to find the reason. Given below the log entries, please help us here to 
find the reason.



2024-03-16T07:18:52,489][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=90c6ab62-a441-4cd3-8b6d-fbef550fbe4c, 
startPtr=FileWALPointer [idx=5463768, fileOff=51537417, len=56705], 
checkpointLockWait=0ms, checkpointLockHoldTime=21ms, 
walCpRecordFsyncDuration=4ms, pages=62810, reason='timeout']
2024-03-16T07:18:53,565][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint finished [cpId=90c6ab62-a441-4cd3-8b6d-fbef550fbe4c, pages=62810, 
markPos=FileWALPointer [idx=5463768, fileOff=51537417, len=56705], 
walSegmentsCleared=4, walSegmentsCovered=[5463764 - 5463767], 
markDuration=43ms, pagesWrite=491ms, fsync=585ms, total=1119ms]
2024-03-16T07:19:11,191][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463768, segIdx=8, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0008.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463768.wal]
2024-03-16T07:19:11,318][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0008.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463768.wal]
2024-03-16T07:19:33,988][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463769, segIdx=9, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0009.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463769.wal]
2024-03-16T07:19:34,121][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0009.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463769.wal]
2024-03-16T07:20:18,852][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463770, segIdx=0, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463770.wal]
2024-03-16T07:20:19,000][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463770.wal]
2024-03-16T07:21:15,373][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463771, segIdx=1, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0001.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463771.wal]
2024-03-16T07:21:15,500][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied file 
[src=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0001.wal,
 
dst=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463771.wal]
2024-03-16T07:21:52,493][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint started [checkpointId=d12adda8-2202-4192-bbeb-f5083d3eabc9, 
startPtr=FileWALPointer [idx=5463772, fileOff=44231024, len=56705], 
checkpointLockWait=0ms, checkpointLockHoldTime=25ms, 
walCpRecordFsyncDuration=5ms, pages=61176, reason='timeout']
2024-03-16T07:21:53,433][INFO 
][db-checkpoint-thread-#556%EDIFCustomerMAINDR%][GridCacheDatabaseSharedManager]
 Checkpoint finished [cpId=d12adda8-2202-4192-bbeb-f5083d3eabc9, pages=61176, 
markPos=FileWALPointer [idx=5463772, fileOff=44231024, len=56705], 
walSegmentsCleared=4, walSegmentsCovered=[5463768 - 5463771], 
markDuration=45ms, pagesWrite=485ms, fsync=454ms, total=984ms]
2024-03-16T07:22:12,689][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Starting to copy WAL segment [absIdx=5463772, segIdx=2, 
origFile=/datastore1/wal/node00-34dda35b-606f-4124-936e-7b1a01531043/0002.wal,
 
dstFile=/datastore1/archive/node00-34dda35b-606f-4124-936e-7b1a01531043/05463772.wal]
2024-03-16T07:22:12,855][INFO 
][wal-file-archiver%EDIFCustomerMAINDR-#466%EDIFCustomerMAINDR%][FileWriteAheadLogManager]
 Copied 

Questions about H2 / Calcite limitations

[BELMONTE Loic via user]

Hello,

I encountered some errors while trying to build an SQL request and I would 
appreciate your input on it.

Using H2 engine, I tried to have a subquery inside a subquery and there is an 
exception about unique alias being null.
Something like:
select ... from ( select ... from ( select ... from table) )
Is this a limitation on the number of subqueries? a bug?
I'm doing this to be able to reuse formulas, I don't really need subqueries, is 
there a better way to do that?

Using Calcite engine, this limitation does not seem to exist, but I had another 
exception (without much details except that it failed) when trying to do more 
than one join with subqueries:
with sq1 as ( select * from ( values ... ) )
with sq2 as ( select * from ( values ... ) )
select ... from table
left join sq1 on ...
left join sq2 on ...
Am I doing something wrong?

Also, is there a timeline for Calcite official release (out of beta, I cannot 
find the info)?

Thanks in advance,
Loïc
This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential. 
If you receive this message in error,or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose, 
dissemination or disclosure, either whole or partial, is prohibited. Since the 
internet 
cannot guarantee the integrity of this message which may not be reliable, BNP 
PARIBAS 
(and its subsidiaries) shall not be liable for the message if modified, changed 
or falsified. 
Do not print this message unless it is necessary, consider the environment.

--

Ce message et toutes les pieces jointes (ci-apres le "message") 
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de 
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite. L'Internet ne permettant pas 
d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas 
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans 
l'hypothese
ou il aurait ete modifie, deforme ou falsifie. 
N'imprimez ce message que si necessaire, pensez a l'environnement.

Re: Performance Issue at Ignite Level

[Stephen Darlington]

+ user mailing list
- developer mailing list

This question would be better addressed to the user mailing list.

There are a number of causes of "long JVM pauses,” so it’s difficult to be 
prescriptive. I’d start by logging more information about Java’s garbage 
collection.

More information in the documentation here: 
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning#generic-gc-settings

Given the data provided, I’d say your heap space is likely excessive. Having 
more heap space isn’t necessarily better.

Regards,
Stephen

> On 7 Mar 2024, at 14:54, Kalwakuntla, Srinivas 
>  wrote:
> 
> Dear Ignite Team,
> 
> Hope this email finds your well !
> 
> Reaching out to you, as currently we are facing performance issue with Apache 
> Ignite. Our application is running on Azure Kubernetes (v1.27.1), which has 
> 24 nodes of size "Standard_F64s_v2" (handling roughly 13million of records).
> Frequently we are getting "[WARNING][jvm-pause-detector-worker][IgniteKernal] 
> Possible too long JVM pause:  milliseconds",  while performing any 
> operations such as reading, encoding etc.
> 
> Here below is the system information:
> 
> System Information (Apache Ignite Clusters)
> Heap size: 32GB out of 64GB of memory
> CPUs:  Standard_F64s_v2
> The number of server instances: 24
> IOWait: within normal range
> IOPS: 10k-600K per hr
> JDK: Oracle JDK8, 1.8.0_281
> APACHE IGNITE - 2.14.0
> 
> GC configuration in ignite.sh:
> 
> XX:-UseContainerSupport
> -XX:+AlwaysPreTouch
> -XX:+UseG1GC
> -XX:+ScavengeBeforeFullGC
>  -XX:+DisableExplicitGC"
> 
> Please assist us in identifying the underlying source of this problem.
> Thank you,
> Srinivas
> 

Memory Efficient keys only read

[Dinakar Devineni]

Hi,

I have a 4 server node cluster with caches  are on heap.

Whenever i try to get keys using a scan query or sql field query the heap
usage increases drastically and drops down in few minutes as if both the
queries are loading all respective cache entries as copies in response to
the keys only request.

A get all keys request when cluster is under load with significant heap
usage would crash the nodes with OOM.


Is there any other efficient way to get all keys other than scan query that
iterates over cache entries or sql query?


How best to estimate the heap size requirement for handling get all keys
type requests.?


Is there any community project for reading and displaying cache entries
other than the old ignite web console?

Thanks
Dina

Re: Spring Native support

[Pavel Tupitsyn]

Have a look at [1], there is a POC linked [2]

[1] https://www.mail-archive.com/dev@ignite.apache.org/msg53182.html
[2] https://github.com/scottmf/graalvm-ignite

On Fri, Mar 1, 2024 at 8:01 AM Kramer  wrote:

> I believe this is not supported with Ignite 2.x due to Native Buffer
> access. It will only be part of Ignite 3 which is still Beta.
>
> I haven't tested it myself though, so my comment should be confirmed by
> others.
> On 2/29/24, 14:14 Dinakar Devineni  wrote:
>
>> Hi,
>>
>>
>>
>> Has  anyone tried   spring  native  image  with   ignite?  If  so  is it
>> efficient  and what  are  the  pros and cons.
>>
>> Spring Native documentation
>> 
>>
>>
>>
>>
>>
>> Thanks
>>
>> Dina
>>
>

Re: Spring Native support

[Kramer]

 
 I believe this is not supported with Ignite 2.x due to Native Buffer access. It will only be part of Ignite 3 which is still Beta.I haven't tested it myself though, so my comment should be confirmed by others.On 2/29/24, 14:14 Dinakar Devineni  wrote:

  
   Hi,
    
   Has  anyone tried   spring  native  image  with   ignite?  If  so  is it  efficient  and what  are  the  pros and cons.
   Spring Native documentation
    
    
   Thanks
   Dina
  
 

Re: Control center open source

[Stephen Darlington]

You would need to test it to find out.

On Thu, 29 Feb 2024 at 12:03, Dinakar Devineni  wrote:

> Does that  even  work  with the  newer versions of  ignite?
>
>
>
> *From: *Stephen Darlington 
> *Sent: *Thursday, February 29, 2024 4:45 AM
> *To: *user@ignite.apache.org
> *Subject: *Re: Control center open source
>
>
>
> The community used to maintain Web Console. You might be able to get that
> running again?
>
>
>
> On Thu, 29 Feb 2024 at 04:08, Dinakar Devineni  wrote:
>
> Hi ,
>
>
>
> Is there ant grid gain control center open source alternative.
>
> Is there any other community project?
>
>
>
> Thanks
>
> Dina
>
>
>

Spring Native support

[Dinakar Devineni]

Hi, Has  anyone tried   spring  native  image  with   ignite?  If  so  is it  efficient  and what  are  the  pros and cons.Spring Native documentation  ThanksDina

RE: Control center open source

[Dinakar Devineni]

Does that  even  work  with the  newer versions of  ignite? From: Stephen DarlingtonSent: Thursday, February 29, 2024 4:45 AMTo: user@ignite.apache.orgSubject: Re: Control center open source The community used to maintain Web Console. You might be able to get that running again?  On Thu, 29 Feb 2024 at 04:08, Dinakar Devineni  wrote:Hi , Is there ant grid gain control center open source alternative.Is there any other community project? ThanksDina 

Re:

[Stephen Darlington]

You can add a filter to your log exporter, so that only the metrics you're
interested in are shared.

"Expensive" might be the wrong word to explain the overhead in enabling
metrics. Enabling metrics does use more resources than not, but it's
usually worth it. In general, you can't put a system into production if
it's not observable, and metrics are a key part of that.

On Thu, 29 Feb 2024 at 04:18, Dinakar Devineni  wrote:

>
> Hi,
>
> Regarding new metrics system, when configure to use log exporter, the
> metrics are being printed for a cache and again as cache group for the same
> cache, even when cache groups are configured? Is it a default behavior, if
> so how to fix it, so that only cache metrics are collected.
>
> Also documentation says that enabling metrics is expensive, by that do
> they mean its going to impact the performance of clusters or just limited
> to resource utilization?
>
> Thanks
> Dina
>
>
>

Re: Control center open source

[Stephen Darlington]

The community used to maintain Web Console. You might be able to get that
running again?

On Thu, 29 Feb 2024 at 04:08, Dinakar Devineni  wrote:

> Hi ,
>
> Is there ant grid gain control center open source alternative.
> Is there any other community project?
>
> Thanks
> Dina
>

Re: Performance

[Stephen Darlington]

There's not much overhead simply by enabling SQL, but there's obviously a
cost to maintaining any indexes you create. Normally the cost of
maintaining those indexes is more than offset by improvements in query
performance. But the only real way to tell for your use case is to
benchmark it.

On Wed, 28 Feb 2024 at 21:58, Dinakar Devineni  wrote:

>
>
> Hi,
>
>
>
> I’m planning to enable and use SQL API  for existing  Caches  by  adding
> all fields are  quarriable fields.  Will this  affect  the  performance of
> Key-Value  API Cache  gets & puts.
>
> And are there any side affects, like  increased  memory usage, reduced
> performance of cluster using  SQL API, that  one should be aware of  before
> promoting it?
>
>
>
> Ignite Version : 2.14.0
>
>
>
>
>
> Thanks
>
> dina
>

[no subject]

[Dinakar Devineni]

Hi,

Regarding new metrics system, when configure to use log exporter, the
metrics are being printed for a cache and again as cache group for the same
cache, even when cache groups are configured? Is it a default behavior, if
so how to fix it, so that only cache metrics are collected.

Also documentation says that enabling metrics is expensive, by that do they
mean its going to impact the performance of clusters or just limited to
resource utilization?

Thanks
Dina

CVE-2024-22243 - Spring Framework Vulnerability

[David Horton]

Hi Team,

Could you please advise if Ignite 2.14/2.15 is vulnerable to
https://spring.io/security/cve-2024-22243 and if so whether a patch is
planned?

Thanks.