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.

Control center open source

[Dinakar Devineni]

Hi ,

Is there ant grid gain control center open source alternative.
Is there any other community project?

Thanks
Dina

Performance

[Dinakar Devineni]

 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

Re: Data loss in an Ignite application

[Stephen Darlington]

Glad you got to the bottom of it!

On Sat, 24 Feb 2024 at 00:19, Aleksej Avrutin  wrote:

> Stephen,
>
> Thank you for the message. At last, I've found the root cause of the
> issue. It was an application bug (expected) but it wasn't the most apparent
> one. Out of despair I decided to check all the components of the
> application including Ignite. The good thing is that now I have better
> knowledge of how to troubleshoot issues like this.
>
> My best,
> Alex Avrutin
>
>
> On Fri, Feb 23, 2024 at 10:38 AM Stephen Darlington <
> sdarling...@apache.org> wrote:
>
>> Is there a pattern to the lost records? Is it old records? Records for a
>> particular customer? Records stored on a specific node or partition?
>>
>> On Thu, 22 Feb 2024 at 21:14, Aleksej Avrutin 
>> wrote:
>>
>>> Jeremy,
>>>
>>> Thank you for the response. I reviewed cache properties using GG Control
>>> Center and there was nothing in the cache props that would lead me to the
>>> conclusion that any expiry policy/TTL is set up for the cache. It wasn't
>>> set on the operation level, either.
>>>
>>> I decided to delete the cache entirely and re-create it. Tomorrow I'll
>>> check if it helps.
>>>
>>> My best,
>>> Alex Avrutin
>>>
>>>
>>> On Thu, Feb 22, 2024 at 3:56 AM Jeremy McMillan <
>>> jeremy.mcmil...@gridgain.com> wrote:
>>>
 First, logging should be configured to at least WARN level if not INFO.

 Ignite manages data internally at the page level. If you see errors
 about pages, it is low, low level ignite problems. The next level up is
 partitions. Errors involving partitions are mid low level ignite problems.
 The next level up is caches. Errors at the cache level are mid to high
 level problems. The next level is cache records. Errors in cache record
 handling are high level of abstraction, and the next level is client
 application operations.

 The lower level of abstraction the errors appear, the less chance
 operations in general will succeed. Since the cache appears to operate
 mostly as expected, and there are no obvious errors in the ignite logs,
 most likely there is some client side logic which is deleting records, and
 ignite does not consider this behavior to be in error.

 I would recommend fine tuning cache delete method log coverage. First
 identify if the deletion is happening on a client connection thread pool or
 a thread for server initiated operations.

 My guess is that a client is connecting, getting a cache object, and
 then setting expiration on that cache connection so that all cache adds
 under that cache connection will have expiration applied to them.


 https://ignite.apache.org/docs/2.14.0/configuring-caches/expiry-policies#configuration

 "You can also change or set Expiry Policy for individual cache
 operations. This policy is used for each operation invoked on the returned
 cache instance."


 https://ignite.apache.org/releases/latest/dotnetdoc/api/Apache.Ignite.Core.Client.Cache.ICacheClient-2.html?q=withExpiryPolicy#Apache_Ignite_Core_Client_Cache_ICacheClient_2_WithExpiryPolicy_Apache_Ignite_Core_Cache_Expiry_IExpiryPolicy_

 On Wed, Feb 21, 2024, 19:17 Aleksej Avrutin 
 wrote:

> Hello,
>
> A couple of days ago I encountered a strange phenomenon in our
> application based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1
> backup per cache).
> Data in a cache started disappearing for seemingly no reason and the
> amount of records could be halved (220K to 108K) overnight. I spent a
> couple of days trying to find a problem in the application, crunched
> hundreds megabytes of application logs but didn't manage to find a reason
> to blame the application. Retention/TTL is not set for the cache. Apache
> Ignite logs with the option -DIGNITE_QUIET=false also don't reveal any
> anomalies (or I don't know what to look for). The data shares are expected
> to be durable (based on Azure Disk) and we never had any issues with them.
> RAM utilisation is normal and there's plenty of available RAM.
> The Ignite cluster is hosted in a 3 node Kubernetes cluster on Azure.
>
> The question is: how would you recommend investigating issues like
> this? What metrics and logs can I check? Is it possible to log and track
> individual Remove() operations as well as SQL queries at Ignite engine
> level?
>
> The application has been working on Ignite for years already and we
> didn't encounter data loss at such scales before. It's possible that the
> app wasn't used so extensively before as it is now and the problem left
> unnoticed.
>
> My best,
> Alex Avrutin
>

Re: Data loss in an Ignite application

[Aleksej Avrutin]

Stephen,

Thank you for the message. At last, I've found the root cause of the issue.
It was an application bug (expected) but it wasn't the most apparent one.
Out of despair I decided to check all the components of the application
including Ignite. The good thing is that now I have better knowledge of how
to troubleshoot issues like this.

My best,
Alex Avrutin


On Fri, Feb 23, 2024 at 10:38 AM Stephen Darlington 
wrote:

> Is there a pattern to the lost records? Is it old records? Records for a
> particular customer? Records stored on a specific node or partition?
>
> On Thu, 22 Feb 2024 at 21:14, Aleksej Avrutin 
> wrote:
>
>> Jeremy,
>>
>> Thank you for the response. I reviewed cache properties using GG Control
>> Center and there was nothing in the cache props that would lead me to the
>> conclusion that any expiry policy/TTL is set up for the cache. It wasn't
>> set on the operation level, either.
>>
>> I decided to delete the cache entirely and re-create it. Tomorrow I'll
>> check if it helps.
>>
>> My best,
>> Alex Avrutin
>>
>>
>> On Thu, Feb 22, 2024 at 3:56 AM Jeremy McMillan <
>> jeremy.mcmil...@gridgain.com> wrote:
>>
>>> First, logging should be configured to at least WARN level if not INFO.
>>>
>>> Ignite manages data internally at the page level. If you see errors
>>> about pages, it is low, low level ignite problems. The next level up is
>>> partitions. Errors involving partitions are mid low level ignite problems.
>>> The next level up is caches. Errors at the cache level are mid to high
>>> level problems. The next level is cache records. Errors in cache record
>>> handling are high level of abstraction, and the next level is client
>>> application operations.
>>>
>>> The lower level of abstraction the errors appear, the less chance
>>> operations in general will succeed. Since the cache appears to operate
>>> mostly as expected, and there are no obvious errors in the ignite logs,
>>> most likely there is some client side logic which is deleting records, and
>>> ignite does not consider this behavior to be in error.
>>>
>>> I would recommend fine tuning cache delete method log coverage. First
>>> identify if the deletion is happening on a client connection thread pool or
>>> a thread for server initiated operations.
>>>
>>> My guess is that a client is connecting, getting a cache object, and
>>> then setting expiration on that cache connection so that all cache adds
>>> under that cache connection will have expiration applied to them.
>>>
>>>
>>> https://ignite.apache.org/docs/2.14.0/configuring-caches/expiry-policies#configuration
>>>
>>> "You can also change or set Expiry Policy for individual cache
>>> operations. This policy is used for each operation invoked on the returned
>>> cache instance."
>>>
>>>
>>> https://ignite.apache.org/releases/latest/dotnetdoc/api/Apache.Ignite.Core.Client.Cache.ICacheClient-2.html?q=withExpiryPolicy#Apache_Ignite_Core_Client_Cache_ICacheClient_2_WithExpiryPolicy_Apache_Ignite_Core_Cache_Expiry_IExpiryPolicy_
>>>
>>> On Wed, Feb 21, 2024, 19:17 Aleksej Avrutin 
>>> wrote:
>>>
 Hello,

 A couple of days ago I encountered a strange phenomenon in our
 application based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1
 backup per cache).
 Data in a cache started disappearing for seemingly no reason and the
 amount of records could be halved (220K to 108K) overnight. I spent a
 couple of days trying to find a problem in the application, crunched
 hundreds megabytes of application logs but didn't manage to find a reason
 to blame the application. Retention/TTL is not set for the cache. Apache
 Ignite logs with the option -DIGNITE_QUIET=false also don't reveal any
 anomalies (or I don't know what to look for). The data shares are expected
 to be durable (based on Azure Disk) and we never had any issues with them.
 RAM utilisation is normal and there's plenty of available RAM.
 The Ignite cluster is hosted in a 3 node Kubernetes cluster on Azure.

 The question is: how would you recommend investigating issues like
 this? What metrics and logs can I check? Is it possible to log and track
 individual Remove() operations as well as SQL queries at Ignite engine
 level?

 The application has been working on Ignite for years already and we
 didn't encounter data loss at such scales before. It's possible that the
 app wasn't used so extensively before as it is now and the problem left
 unnoticed.

 My best,
 Alex Avrutin

>>>

Re: Data loss in an Ignite application

[Stephen Darlington]

Is there a pattern to the lost records? Is it old records? Records for a
particular customer? Records stored on a specific node or partition?

On Thu, 22 Feb 2024 at 21:14, Aleksej Avrutin  wrote:

> Jeremy,
>
> Thank you for the response. I reviewed cache properties using GG Control
> Center and there was nothing in the cache props that would lead me to the
> conclusion that any expiry policy/TTL is set up for the cache. It wasn't
> set on the operation level, either.
>
> I decided to delete the cache entirely and re-create it. Tomorrow I'll
> check if it helps.
>
> My best,
> Alex Avrutin
>
>
> On Thu, Feb 22, 2024 at 3:56 AM Jeremy McMillan <
> jeremy.mcmil...@gridgain.com> wrote:
>
>> First, logging should be configured to at least WARN level if not INFO.
>>
>> Ignite manages data internally at the page level. If you see errors about
>> pages, it is low, low level ignite problems. The next level up is
>> partitions. Errors involving partitions are mid low level ignite problems.
>> The next level up is caches. Errors at the cache level are mid to high
>> level problems. The next level is cache records. Errors in cache record
>> handling are high level of abstraction, and the next level is client
>> application operations.
>>
>> The lower level of abstraction the errors appear, the less chance
>> operations in general will succeed. Since the cache appears to operate
>> mostly as expected, and there are no obvious errors in the ignite logs,
>> most likely there is some client side logic which is deleting records, and
>> ignite does not consider this behavior to be in error.
>>
>> I would recommend fine tuning cache delete method log coverage. First
>> identify if the deletion is happening on a client connection thread pool or
>> a thread for server initiated operations.
>>
>> My guess is that a client is connecting, getting a cache object, and then
>> setting expiration on that cache connection so that all cache adds under
>> that cache connection will have expiration applied to them.
>>
>>
>> https://ignite.apache.org/docs/2.14.0/configuring-caches/expiry-policies#configuration
>>
>> "You can also change or set Expiry Policy for individual cache
>> operations. This policy is used for each operation invoked on the returned
>> cache instance."
>>
>>
>> https://ignite.apache.org/releases/latest/dotnetdoc/api/Apache.Ignite.Core.Client.Cache.ICacheClient-2.html?q=withExpiryPolicy#Apache_Ignite_Core_Client_Cache_ICacheClient_2_WithExpiryPolicy_Apache_Ignite_Core_Cache_Expiry_IExpiryPolicy_
>>
>> On Wed, Feb 21, 2024, 19:17 Aleksej Avrutin 
>> wrote:
>>
>>> Hello,
>>>
>>> A couple of days ago I encountered a strange phenomenon in our
>>> application based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1
>>> backup per cache).
>>> Data in a cache started disappearing for seemingly no reason and the
>>> amount of records could be halved (220K to 108K) overnight. I spent a
>>> couple of days trying to find a problem in the application, crunched
>>> hundreds megabytes of application logs but didn't manage to find a reason
>>> to blame the application. Retention/TTL is not set for the cache. Apache
>>> Ignite logs with the option -DIGNITE_QUIET=false also don't reveal any
>>> anomalies (or I don't know what to look for). The data shares are expected
>>> to be durable (based on Azure Disk) and we never had any issues with them.
>>> RAM utilisation is normal and there's plenty of available RAM.
>>> The Ignite cluster is hosted in a 3 node Kubernetes cluster on Azure.
>>>
>>> The question is: how would you recommend investigating issues like this?
>>> What metrics and logs can I check? Is it possible to log and track
>>> individual Remove() operations as well as SQL queries at Ignite engine
>>> level?
>>>
>>> The application has been working on Ignite for years already and we
>>> didn't encounter data loss at such scales before. It's possible that the
>>> app wasn't used so extensively before as it is now and the problem left
>>> unnoticed.
>>>
>>> My best,
>>> Alex Avrutin
>>>
>>

Re: Data loss in an Ignite application

[Aleksej Avrutin]

Jeremy,

Thank you for the response. I reviewed cache properties using GG Control
Center and there was nothing in the cache props that would lead me to the
conclusion that any expiry policy/TTL is set up for the cache. It wasn't
set on the operation level, either.

I decided to delete the cache entirely and re-create it. Tomorrow I'll
check if it helps.

My best,
Alex Avrutin


On Thu, Feb 22, 2024 at 3:56 AM Jeremy McMillan <
jeremy.mcmil...@gridgain.com> wrote:

> First, logging should be configured to at least WARN level if not INFO.
>
> Ignite manages data internally at the page level. If you see errors about
> pages, it is low, low level ignite problems. The next level up is
> partitions. Errors involving partitions are mid low level ignite problems.
> The next level up is caches. Errors at the cache level are mid to high
> level problems. The next level is cache records. Errors in cache record
> handling are high level of abstraction, and the next level is client
> application operations.
>
> The lower level of abstraction the errors appear, the less chance
> operations in general will succeed. Since the cache appears to operate
> mostly as expected, and there are no obvious errors in the ignite logs,
> most likely there is some client side logic which is deleting records, and
> ignite does not consider this behavior to be in error.
>
> I would recommend fine tuning cache delete method log coverage. First
> identify if the deletion is happening on a client connection thread pool or
> a thread for server initiated operations.
>
> My guess is that a client is connecting, getting a cache object, and then
> setting expiration on that cache connection so that all cache adds under
> that cache connection will have expiration applied to them.
>
>
> https://ignite.apache.org/docs/2.14.0/configuring-caches/expiry-policies#configuration
>
> "You can also change or set Expiry Policy for individual cache operations.
> This policy is used for each operation invoked on the returned cache
> instance."
>
>
> https://ignite.apache.org/releases/latest/dotnetdoc/api/Apache.Ignite.Core.Client.Cache.ICacheClient-2.html?q=withExpiryPolicy#Apache_Ignite_Core_Client_Cache_ICacheClient_2_WithExpiryPolicy_Apache_Ignite_Core_Cache_Expiry_IExpiryPolicy_
>
> On Wed, Feb 21, 2024, 19:17 Aleksej Avrutin  wrote:
>
>> Hello,
>>
>> A couple of days ago I encountered a strange phenomenon in our
>> application based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1
>> backup per cache).
>> Data in a cache started disappearing for seemingly no reason and the
>> amount of records could be halved (220K to 108K) overnight. I spent a
>> couple of days trying to find a problem in the application, crunched
>> hundreds megabytes of application logs but didn't manage to find a reason
>> to blame the application. Retention/TTL is not set for the cache. Apache
>> Ignite logs with the option -DIGNITE_QUIET=false also don't reveal any
>> anomalies (or I don't know what to look for). The data shares are expected
>> to be durable (based on Azure Disk) and we never had any issues with them.
>> RAM utilisation is normal and there's plenty of available RAM.
>> The Ignite cluster is hosted in a 3 node Kubernetes cluster on Azure.
>>
>> The question is: how would you recommend investigating issues like this?
>> What metrics and logs can I check? Is it possible to log and track
>> individual Remove() operations as well as SQL queries at Ignite engine
>> level?
>>
>> The application has been working on Ignite for years already and we
>> didn't encounter data loss at such scales before. It's possible that the
>> app wasn't used so extensively before as it is now and the problem left
>> unnoticed.
>>
>> My best,
>> Alex Avrutin
>>
>

Re: Data loss in an Ignite application

[Jeremy McMillan]

First, logging should be configured to at least WARN level if not INFO.

Ignite manages data internally at the page level. If you see errors about
pages, it is low, low level ignite problems. The next level up is
partitions. Errors involving partitions are mid low level ignite problems.
The next level up is caches. Errors at the cache level are mid to high
level problems. The next level is cache records. Errors in cache record
handling are high level of abstraction, and the next level is client
application operations.

The lower level of abstraction the errors appear, the less chance
operations in general will succeed. Since the cache appears to operate
mostly as expected, and there are no obvious errors in the ignite logs,
most likely there is some client side logic which is deleting records, and
ignite does not consider this behavior to be in error.

I would recommend fine tuning cache delete method log coverage. First
identify if the deletion is happening on a client connection thread pool or
a thread for server initiated operations.

My guess is that a client is connecting, getting a cache object, and then
setting expiration on that cache connection so that all cache adds under
that cache connection will have expiration applied to them.

https://ignite.apache.org/docs/2.14.0/configuring-caches/expiry-policies#configuration

"You can also change or set Expiry Policy for individual cache operations.
This policy is used for each operation invoked on the returned cache
instance."

https://ignite.apache.org/releases/latest/dotnetdoc/api/Apache.Ignite.Core.Client.Cache.ICacheClient-2.html?q=withExpiryPolicy#Apache_Ignite_Core_Client_Cache_ICacheClient_2_WithExpiryPolicy_Apache_Ignite_Core_Cache_Expiry_IExpiryPolicy_

On Wed, Feb 21, 2024, 19:17 Aleksej Avrutin  wrote:

> Hello,
>
> A couple of days ago I encountered a strange phenomenon in our application
> based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1 backup per
> cache).
> Data in a cache started disappearing for seemingly no reason and the
> amount of records could be halved (220K to 108K) overnight. I spent a
> couple of days trying to find a problem in the application, crunched
> hundreds megabytes of application logs but didn't manage to find a reason
> to blame the application. Retention/TTL is not set for the cache. Apache
> Ignite logs with the option -DIGNITE_QUIET=false also don't reveal any
> anomalies (or I don't know what to look for). The data shares are expected
> to be durable (based on Azure Disk) and we never had any issues with them.
> RAM utilisation is normal and there's plenty of available RAM.
> The Ignite cluster is hosted in a 3 node Kubernetes cluster on Azure.
>
> The question is: how would you recommend investigating issues like this?
> What metrics and logs can I check? Is it possible to log and track
> individual Remove() operations as well as SQL queries at Ignite engine
> level?
>
> The application has been working on Ignite for years already and we didn't
> encounter data loss at such scales before. It's possible that the app
> wasn't used so extensively before as it is now and the problem left
> unnoticed.
>
> My best,
> Alex Avrutin
>

Data loss in an Ignite application

[Aleksej Avrutin]

Hello,

A couple of days ago I encountered a strange phenomenon in our application
based on Apache Ignite .Net 2.14 with persistence (3 nodes, 1 backup per
cache).
Data in a cache started disappearing for seemingly no reason and the amount
of records could be halved (220K to 108K) overnight. I spent a couple of
days trying to find a problem in the application, crunched hundreds
megabytes of application logs but didn't manage to find a reason to
blame the application. Retention/TTL is not set for the cache. Apache
Ignite logs with the option -DIGNITE_QUIET=false also don't reveal any
anomalies (or I don't know what to look for). The data shares are expected
to be durable (based on Azure Disk) and we never had any issues with them.
RAM utilisation is normal and there's plenty of available RAM.
The Ignite cluster is hosted in a 3 node Kubernetes cluster on Azure.

The question is: how would you recommend investigating issues like this?
What metrics and logs can I check? Is it possible to log and track
individual Remove() operations as well as SQL queries at Ignite engine
level?

The application has been working on Ignite for years already and we didn't
encounter data loss at such scales before. It's possible that the app
wasn't used so extensively before as it is now and the problem left
unnoticed.

My best,
Alex Avrutin

RE: Re: Question about REST/C++ client

[Louis C]

 Ah ok, I understand better.


Thanks for your answer.


On 2024/02/19 11:05:04 Stephen Darlington wrote:
> Ah, the trick you're missing is that the "incr" REST API doesn't (directly)
> use a cache. Instead it uses an Atomic Sequence:
> https://ignite.apache.org/docs/latest/data-structures/atomic-types
>
> On Wed, 14 Feb 2024 at 17:38, Louis C  wrote:
>
> > Hello,
> >
> > Thanks for your answers Igor and Stephen.
> > Igor, to answer your question to the second point I used the same term as
> > used in the Rest API, but indeed it more or less what you said (even if
> > in this API we do not have to retrieve explicitely the base value).
> > Best regards,
> > Louis
> > --
> > *De :* Stephen Darlington 
> > *Envoyé :* mardi 13 février 2024 11:22
> > *À :* user@ignite.apache.org 
> > *Objet :* Re: Question about REST/C++ client
> >
> > The easy answer to the "50 gets in parallel" is to use GetAll.
> >
> > On Tue, 13 Feb 2024 at 09:54, Igor Sapego  wrote:
> >
> > 1. There is no such API. Seems like a weird error in documentation. We
> > will fix it. If you want to make 50 gets in parallel, I think it's better
> > to run 50 clients with the current API. You can use the same client too,
> > but it may be slower, depending on how many nodes you have in a cluster.
> > 2. What do you mean by increments? Do you mean getting value, modifying it
> > and putting it back?
> > 3. Atomics are faster in most cases (ReplaceIfEquals). Yes, there is a
> > real overhead for transactions, though how big it is depends on the
> > transaction isolation level.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Thu, Feb 8, 2024 at 5:05 PM Louis C  wrote:
> >
> >
> > Hello,
> >
> > I am trying to use/test Apache Ignite for a particular use case. For
> > background reference, my use case of Ignite is to do 100Ks (to begin with)
> > of "Gets" and of "increments" of values that will be stored in probably
> > multiple caches in Apache Ignite.
> > I read the Ignite documentation, but I couldn't figure out things in the
> > C++ API side.
> >
> >
> >1. I have read in the documentation
> >
> > 
> >
> > that
> >there is a "GetAsync" method in C++ client. But I could not find it in 
> > the
> >code. Is it a deprecated API ? If so, let's imagine I want to do multiple
> >calls in parallel (let's say 50 for instance), how can I achieve this ? 
> > Can
> >I just call multiple "Get"s in parallel in my threads without any 
> > problem ?
> >Must I create a client for each thread ? There does not seem to be 
> > anything
> >related to thread safety of these methods in the doc...
> >2. Does doing 100K "increments" of values in a cache seem achievable
> >on an Ignite cluster of a single node (let's say the CPU is a last gen i7
> >with 8 physical cores)? The problem that I have is that I have very good
> >performances (+100K "gets") using the batch methods of the Rest API, but 
> > no
> >batch method exist for "increments", and the overhead of each http call
> >cripples the performance to a few 1000s/s. What would be the "best" way 
> > of
> >achieving this (preferably in C++ or Rest API, but I am open to Java too 
> > )?
> >3. Related but a bit different : if I want to add a value to an
> >existing one in the store (doing an "increment"), would it be (in 
> > general)
> >faster to do it using the "transaction" mode or to use the
> >"ReplaceIfEquals" methods (in general I do not update the same values in
> >the same time) ? Is there a real overhead for transactions ?
> >
> >
> > Thanks in advance
> >
> > Louis
> >
> >
>

Community Over Code Asia 2024 Travel Assistance Applications now open!

[Gavin McDonald]

Hello to all users, contributors and Committers!

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

We will be supporting Community over Code Asia, Hangzhou, China
July 26th - 28th, 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 year's 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 Friday, May 10th, 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 to
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 Hangzhou, China in July, 2024!

Kind Regards,

Gavin

(On behalf of the Travel Assistance Committee)

Cannot Find memory.nonheap.max

[y]

Hello Everyone,

When using prometheus to monitor the ignite(ver. 2.13), I cannot find the 
parameter ‘sys_memory_nonheap_max’ . It seems that this parameter is available 
in the official documentation. How to solve this problem？Thanks.

Tiany Hu，
2024/2/20

Re: Question about REST/C++ client

[Stephen Darlington]

Ah, the trick you're missing is that the "incr" REST API doesn't (directly)
use a cache. Instead it uses an Atomic Sequence:
https://ignite.apache.org/docs/latest/data-structures/atomic-types

On Wed, 14 Feb 2024 at 17:38, Louis C  wrote:

> Hello,
>
> Thanks for your answers Igor and Stephen.
> Igor, to answer your question to the second point I used the same term as
> used in the Rest API, but indeed it more or less what you said (even if
> in this API we do not have to retrieve explicitely the base value).
> Best regards,
> Louis
> --
> *De :* Stephen Darlington 
> *Envoyé :* mardi 13 février 2024 11:22
> *À :* user@ignite.apache.org 
> *Objet :* Re: Question about REST/C++ client
>
> The easy answer to the "50 gets in parallel" is to use GetAll.
>
> On Tue, 13 Feb 2024 at 09:54, Igor Sapego  wrote:
>
> 1. There is no such API. Seems like a weird error in documentation. We
> will fix it. If you want to make 50 gets in parallel, I think it's better
> to run 50 clients with the current API. You can use the same client too,
> but it may be slower, depending on how many nodes you have in a cluster.
> 2. What do you mean by increments? Do you mean getting value, modifying it
> and putting it back?
> 3. Atomics are faster in most cases (ReplaceIfEquals). Yes, there is a
> real overhead for transactions, though how big it is depends on the
> transaction isolation level.
>
> Best Regards,
> Igor
>
>
> On Thu, Feb 8, 2024 at 5:05 PM Louis C  wrote:
>
>
> Hello,
>
> I am trying to use/test Apache Ignite for a particular use case. For
> background reference, my use case of Ignite is to do 100Ks (to begin with)
> of "Gets" and of "increments" of values that will be stored in probably
> multiple caches in Apache Ignite.
> I read the Ignite documentation, but I couldn't figure out things in the
> C++ API side.
>
>
>1. I have read in the documentation
>
> 
>
> that
>there is a "GetAsync" method in C++ client. But I could not find it in the
>code. Is it a deprecated API ? If so, let's imagine I want to do multiple
>calls in parallel (let's say 50 for instance), how can I achieve this ? Can
>I just call multiple "Get"s in parallel in my threads without any problem ?
>Must I create a client for each thread ? There does not seem to be anything
>related to thread safety of these methods in the doc...
>2. Does doing 100K "increments" of values in a cache seem achievable
>on an Ignite cluster of a single node (let's say the CPU is a last gen i7
>with 8 physical cores)? The problem that I have is that I have very good
>performances (+100K "gets") using the batch methods of the Rest API, but no
>batch method exist for "increments", and the overhead of each http call
>cripples the performance to a few 1000s/s. What would be the "best" way of
>achieving this (preferably in C++ or Rest API, but I am open to Java too )?
>3. Related but a bit different : if I want to add a value to an
>existing one in the store (doing an "increment"), would it be (in general)
>faster to do it using the "transaction" mode or to use the
>"ReplaceIfEquals" methods (in general I do not update the same values in
>the same time) ? Is there a real overhead for transactions ?
>
>
> Thanks in advance
>
> Louis
>
>

Ignite 2.11.1 IllegalStateException

[Surajeet Dev]

I am running Ignite 2.11.1 with persistence enabled in a 3 node cluster.

After each of the machines were rebooted , one at a time with 4 mins
interval between each reboot , the Ignite client started reporting the
below error  while publishing( I am using thick client with datastreamer)






*Caused by: org.apache.ignite.IgniteIllegalStateException: Grid is in
invalid state to perform this operation. It either not started yet or has
already being or have stopped [igniteInstanceName=,
state=STOPPED] at
org.apache.ignite.internal.GridKernalGatewayImpl.illegalState(GridKernalGatewayImpl.java:202)
~[ignition-igup.jar:3.67] at
org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:96)
~[ignition-igup.jar:3.67] at
org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.guard(IgniteBinaryImpl.java:193)
~[ignition-igup.jar:3.67] at
org.apache.ignite.internal.processors.cache.binary.IgniteBinaryImpl.builder(IgniteBinaryImpl.java:76)
~[ignition-igup.jar:3.67]*
I do not see any exception in server logs , and the server nodes are in
ACTIVE state

What could be the reason?
(Before the machine reboot , the client was able to publish)

Ignite 2.11.1 (Checkpoint during Shutdown)

[Surajeet Dev]

I have Ignite Grid (2.11.1) with shutDownPolicy as "GRACEFUL"

I see that when the shutdown hook is invoked , it starts Checkpoint but it
never finishes.
When the Grid is started next time , it prints that checkpointing stopped
in the middle and goes ahead to finish the checkpointing

Is this behaviour expected? ( that checkpointing will start but not finish
when shutDownHook is invoked)

Regards
Surajeet

Issue getting List from cache

[manikantannaren]

*Env:*
 Version of ignite server and thick client : 2.16
 Client type: Thick client


*Describe the issue*
1. One cache (data region) used for multiple types of objects viz. standard
Java objects, primitives and User written object (see example below)
2. Cannot use different caches for different object types  - restriction
placed by framework(proprietary)
3. When retrieving individual objects, I am able to retrieve deserialised
version of BinaryObjectImpl using the deserialize method
4. But when retrieving a List or map of custom object, the contents of list
and map have BinaryObjectImpl.
*Question*
1. Is it possible to store and retrieve my object types without having to
play with BinaryObjectImpl
2. How is Ignite able to deserialise collections of Standard java objects
like List of dates for example


Example class
public class NonStandardJavaObject implements Serializable{
private Serializable v1;
private Serializable v2;

}

Exception when retriving and using list of above class
List myentries = cache.get("somekey")
myentries.foreach throws a class cast exception
class org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
class somepackage.NonStandardJavaObject
*Cheers*
Mani/Naren/Iyer
*The trick of walking on water is knowing where the stones are.*

RE: Question about REST/C++ client

[Louis C]

Hello,

Thanks for your answers Igor and Stephen.
Igor, to answer your question to the second point I used the same term as used 
in the Rest API[cid:ab48a0d9-3170-457d-a922-c37cacd9171f], but indeed it more 
or less what you said (even if in this API we do not have to retrieve 
explicitely the base value).
Best regards,
Louis

De : Stephen Darlington 
Envoyé : mardi 13 février 2024 11:22
À : user@ignite.apache.org 
Objet : Re: Question about REST/C++ client

The easy answer to the "50 gets in parallel" is to use GetAll.

On Tue, 13 Feb 2024 at 09:54, Igor Sapego 
mailto:isap...@apache.org>> wrote:
1. There is no such API. Seems like a weird error in documentation. We will fix 
it. If you want to make 50 gets in parallel, I think it's better to run 50 
clients with the current API. You can use the same client too, but it may be 
slower, depending on how many nodes you have in a cluster.
2. What do you mean by increments? Do you mean getting value, modifying it and 
putting it back?
3. Atomics are faster in most cases (ReplaceIfEquals). Yes, there is a real 
overhead for transactions, though how big it is depends on the transaction 
isolation level.

Best Regards,
Igor


On Thu, Feb 8, 2024 at 5:05 PM Louis C 
mailto:l...@outlook.fr>> wrote:

Hello,

I am trying to use/test Apache Ignite for a particular use case. For background 
reference, my use case of Ignite is to do 100Ks (to begin with) of "Gets" and 
of "increments" of values that will be stored in probably multiple caches in 
Apache Ignite.
I read the Ignite documentation, but I couldn't figure out things in the C++ 
API side.


  1.
I have read in the 
documentation
  
that there is a "GetAsync" method in C++ client. But I could not find it in the 
code. Is it a deprecated API ? If so, let's imagine I want to do multiple calls 
in parallel (let's say 50 for instance), how can I achieve this ? Can I just 
call multiple "Get"s in parallel in my threads without any problem ? Must I 
create a client for each thread ? There does not seem to be anything related to 
thread safety of these methods in the doc...
  2.
Does doing 100K "increments" of values in a cache seem achievable on an Ignite 
cluster of a single node (let's say the CPU is a last gen i7 with 8 physical 
cores)? The problem that I have is that I have very good performances (+100K 
"gets") using the batch methods of the Rest API, but no batch method exist for 
"increments", and the overhead of each http call cripples the performance to a 
few 1000s/s. What would be the "best" way of achieving this (preferably in C++ 
or Rest API, but I am open to Java too )?
  3.
Related but a bit different : if I want to add a value to an existing one in 
the store (doing an "increment"), would it be (in general) faster to do it 
using the "transaction" mode or to use the "ReplaceIfEquals" methods (in 
general I do not update the same values in the same time) ? Is there a real 
overhead for transactions ?

Thanks in advance

Louis

RE: Ignite transactions

[Нестрогаев Андрей Викторович]

Hi, Zhenya, thanks for the answer

The real cases as this

CASE1
tx.start() — thread1
cache1.put|get  — thread1
log operation cache1.put

cache2.put|get  — thread1
log operation cache2.put
tx.commit — thread1

all good.

CASE2
tx.start() — thread1
cache1.put|get  — thread1
log operation cache1.put

cache2.put|get  — thread1
error when cache2.put
tx.rollback
exit

log operation cache2.put
tx.commit — thread1

and in case 2, it is necessary that a record of « log operation cache1.put» is 
remain

Нестрогаев Андрей

From: Zhenya Stanilovsky via user 
Sent: Wednesday, February 14, 2024 4:00 PM
To: user@ignite.apache.org
Subject: Re: Ignite transactions

Hi, Andrey
tx.start() — thread1
cache1.put|get  — thread1
cache2.put|get  — thread1
tx.commit — thread1
log operation
i didn`t see the problem here



Thanks Pavel!



  1.  According to business logic, I must transactionally change the values in 
2 caches; in the course of my actions, I must log all these actions in the 3rd 
cache (protocol of my actions). So, it doesn’t matter whether my changes in 
these first two caches end up being a success (commit) or an error (rollback), 
I want the protocol of my actions to be preserved anyway. Based on your 
answers, I can assume that I can use either queues or a separate thread for 
these purposes.



Нестрогаев Андрей



From: Pavel Tupitsyn >
Sent: Wednesday, February 14, 2024 12:13 PM
To: user@ignite.apache.org
Subject: Re: Ignite transactions



1. Not sure I understand

2. Messaging is not transactional

3. No

4. No, transactions are tied to a specific thread



On Wed, Feb 14, 2024 at 11:01AM Нестрогаев Андрей Викторович 
>
 wrote:

Hi All,



Maybe someone has already researched these questions:

1. How can you organize nested/autonomous transactions in ignite? For example, 
for the purpose of writing a protocol to another cache, so that the protocol is 
saved regardless of the result of the main transaction.

2. If you use Messaging in ignite within a transaction, does it take it into 
account, or is the message sent without taking into account the transaction?

3. Does a transaction started on the current node extend to the code sent to 
another node (IgniteRunnable, IgniteClosure)?

4. Does a transaction span another thread started from current?



Thanks for the help in advance.



Andrey

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в нем 
информация, или любые  приложения к нему,  не является официальной позицией АО 
«ФлексСофт» и не влечет финансовые или иные обязательства АО «ФлексСофт»; не 
могут использоваться и не являются какого-либо рода офертой,  акцептом оферты, 
или предложением делать оферты, или совершать акцепт оферты, не является 
рекламой или профессиональным советом,  прогнозом любых событий,  если иное 
прямо не предусмотрено в настоящем сообщении или любых приложениях к нему. АО 
«ФлексСофт» не несет ответственность за любые прямые или косвенные убытки от 
использования получателем или иным лицом сведений настоящего сообщения и/или 
приложений к нему.
Информация, передаваемая по сети Интернет, без использования технических 
средств защиты, является не защищенной от противоправных действий третьих лиц и 
может содержать вредоносные программные средства. АО «ФлексСофт» не несет 
ответственности за данные действия.

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего 

Re: Ignite transactions

[Zhenya Stanilovsky via user]

Hi, Andrey
tx.start() — thread1
cache1.put|get  — thread1
cache2.put|get  — thread1
tx.commit — thread1
log operation 
i didn`t see the problem here 
 
>Thanks Pavel!
> 
>*  According to business logic, I must transactionally change the values in 2 
>caches; in the course of my actions, I must log all these actions in the 3rd 
>cache (protocol of my actions). So, it doesn’t matter whether my changes in 
>these first two caches end up being a success (commit) or an error (rollback), 
>I want the protocol of my actions to be preserved anyway. Based on your 
>answers, I can assume that I can use either queues or a separate thread for 
>these purposes.
> 
>Нестрогаев Андрей
> 
>From: Pavel Tupitsyn < ptupit...@apache.org >
>Sent: Wednesday, February 14, 2024 12:13 PM
>To: user@ignite.apache.org
>Subject: Re: Ignite transactions
> 
>1. Not sure I understand
>2. Messaging is not transactional
>3. No
>4. No, transactions are tied to a specific thread
> 
>On Wed, Feb 14, 2024 at 11:01AM Нестрогаев Андрей Викторович < 
>a.nestrog...@flexsoft.com > wrote:
>>Hi All, 
>> 
>>Maybe someone has already researched these questions: 
>>1. How can you organize nested/autonomous transactions in ignite? For 
>>example, for the purpose of writing a protocol to another cache, so that the 
>>protocol is saved regardless of the result of the main transaction. 
>>2. If you use Messaging in ignite within a transaction, does it take it into 
>>account, or is the message sent without taking into account the transaction? 
>>3. Does a transaction started on the current node extend to the code sent to 
>>another node (IgniteRunnable , IgniteClosure )?
>>4. Does a transaction span another thread started from current ?
>> 
>>Thanks for the help in advance.
>> 
>>Andrey
>>Настоящее  сообщение или любые приложения к нему могут содержать 
>>конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
>>принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
>>согласования с АО «ФлексСофт» является нарушением законодательства Российской 
>>Федерации. Любое действие, направленное на копирование, передачу, 
>>распространение каким-либо образом и с помощью каких-либо средств как самого 
>>письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
>>запрещено. Отправитель настоящего сообщения не несет ответственность за 
>>точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
>>также за своевременность ее получения. Если Вы получили настоящее сообщение 
>>по ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и 
>>любые копии с Вашего компьютера. Настоящее электронное сообщение и 
>>содержащаяся в нем информация, или любые  приложения к нему,  не является 
>>официальной позицией АО «ФлексСофт» и не влечет финансовые или иные 
>>обязательства АО «ФлексСофт»; не могут использоваться и не являются 
>>какого-либо рода офертой,  акцептом оферты, или предложением делать оферты, 
>>или совершать акцепт оферты, не является рекламой или профессиональным 
>>советом,  прогнозом любых событий,  если иное прямо не предусмотрено в 
>>настоящем сообщении или любых приложениях к нему. АО «ФлексСофт» не несет 
>>ответственность за любые прямые или косвенные убытки от использования 
>>получателем или иным лицом сведений настоящего сообщения и/или приложений к 
>>нему.
>>Информация, передаваемая по сети Интернет, без использования технических 
>>средств защиты, является не защищенной от противоправных действий третьих лиц 
>>и может содержать вредоносные программные средства. АО «ФлексСофт» не несет 
>>ответственности за данные действия.
>Настоящее  сообщение или любые приложения к нему могут содержать 
>конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
>принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
>согласования с АО «ФлексСофт» является нарушением законодательства Российской 
>Федерации. Любое действие, направленное на копирование, передачу, 
>распространение каким-либо образом и с помощью каких-либо средств как самого 
>письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
>запрещено. Отправитель настоящего сообщения не несет ответственность за 
>точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
>также за своевременность ее получения. Если Вы получили настоящее сообщение по 
>ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
>копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в 
>нем информация, или любые  приложения к нему,  не является официальной 
>позицией АО «ФлексСофт» и не влечет финансовые или иные обязательства АО 
>«ФлексСофт»; не могут использоваться и не являются какого-либо рода офертой,  
>акцептом оферты, или предложением делать оферты, или совершать акцепт оферты, 
>не является рекламой или профессиональным советом,  прогнозом любых событий,  
>если иное прямо не предусмотрено в настоящем 

RE: Ignite transactions

[jay.ethan]

>  1. Perhaps in earlier versions I could use the atomic cache to record the 
> protocol, …

 

That’s exactly what we used to do for the exact use case you mentioned. 

 

Unfortunately, this is not possible since atomic cache operations are not 
allowed inside transactions anymore. 

 

Does anyone have a solution / workaround? We haven’t been able to find an 
alternative so far.

 

Jay

 

 

 

From: Нестрогаев Андрей Викторович  
Sent: Wednesday, 14 February 2024 10:41
To: 'user@ignite.apache.org' 
Subject: RE: Ignite transactions

 

1.  Perhaps in earlier versions I could use the atomic cache to record the 
protocol, but in the latest version, using the atomic cache inside a 
transaction leads to an error.

 

Andyrey

 

From: Нестрогаев Андрей Викторович 
Sent: Wednesday, February 14, 2024 12:35 PM
To: user@ignite.apache.org  
Subject: RE: Ignite transactions

 

Thanks Pavel!

 

1.  According to business logic, I must transactionally change the values 
in 2 caches; in the course of my actions, I must log all these actions in the 
3rd cache (protocol of my actions). So, it doesn’t matter whether my changes in 
these first two caches end up being a success (commit) or an error (rollback), 
I want the protocol of my actions to be preserved anyway. Based on your 
answers, I can assume that I can use either queues or a separate thread for 
these purposes.

 

Нестрогаев Андрей

 

From: Pavel Tupitsyn mailto:ptupit...@apache.org> > 
Sent: Wednesday, February 14, 2024 12:13 PM
To: user@ignite.apache.org  
Subject: Re: Ignite transactions

 

1. Not sure I understand

2. Messaging is not transactional

3. No

4. No, transactions are tied to a specific thread

 

On Wed, Feb 14, 2024 at 11:01 AM Нестрогаев Андрей Викторович 
mailto:a.nestrog...@flexsoft.com> > wrote:

Hi All, 

 

Maybe someone has already researched these questions: 

1. How can you organize nested/autonomous transactions in ignite? For example, 
for the purpose of writing a protocol to another cache, so that the protocol is 
saved regardless of the result of the main transaction. 

2. If you use Messaging in ignite within a transaction, does it take it into 
account, or is the message sent without taking into account the transaction? 

3. Does a transaction started on the current node extend to the code sent to 
another node (IgniteRunnable, IgniteClosure)?

4. Does a transaction span another thread started from current?

 

Thanks for the help in advance.

 

Andrey

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в нем 
информация, или любые  приложения к нему,  не является официальной позицией АО 
«ФлексСофт» и не влечет финансовые или иные обязательства АО «ФлексСофт»; не 
могут использоваться и не являются какого-либо рода офертой,  акцептом оферты, 
или предложением делать оферты, или совершать акцепт оферты, не является 
рекламой или профессиональным советом,  прогнозом любых событий,  если иное 
прямо не предусмотрено в настоящем сообщении или любых приложениях к нему. АО 
«ФлексСофт» не несет ответственность за любые прямые или косвенные убытки от 
использования получателем или иным лицом сведений настоящего сообщения и/или 
приложений к нему.
Информация, передаваемая по сети Интернет, без использования технических 
средств защиты, является не защищенной от противоправных действий третьих лиц и 
может содержать вредоносные программные средства. АО «ФлексСофт» не несет 
ответственности за данные действия.

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи 

RE: Ignite transactions

[Нестрогаев Андрей Викторович]

  1.  Perhaps in earlier versions I could use the atomic cache to record the 
protocol, but in the latest version, using the atomic cache inside a 
transaction leads to an error.

Andyrey

From: Нестрогаев Андрей Викторович
Sent: Wednesday, February 14, 2024 12:35 PM
To: user@ignite.apache.org
Subject: RE: Ignite transactions

Thanks Pavel!


  1.  According to business logic, I must transactionally change the values in 
2 caches; in the course of my actions, I must log all these actions in the 3rd 
cache (protocol of my actions). So, it doesn’t matter whether my changes in 
these first two caches end up being a success (commit) or an error (rollback), 
I want the protocol of my actions to be preserved anyway. Based on your 
answers, I can assume that I can use either queues or a separate thread for 
these purposes.

Нестрогаев Андрей

From: Pavel Tupitsyn mailto:ptupit...@apache.org>>
Sent: Wednesday, February 14, 2024 12:13 PM
To: user@ignite.apache.org
Subject: Re: Ignite transactions

1. Not sure I understand
2. Messaging is not transactional
3. No
4. No, transactions are tied to a specific thread

On Wed, Feb 14, 2024 at 11:01 AM Нестрогаев Андрей Викторович 
mailto:a.nestrog...@flexsoft.com>> wrote:
Hi All,

Maybe someone has already researched these questions:
1. How can you organize nested/autonomous transactions in ignite? For example, 
for the purpose of writing a protocol to another cache, so that the protocol is 
saved regardless of the result of the main transaction.
2. If you use Messaging in ignite within a transaction, does it take it into 
account, or is the message sent without taking into account the transaction?
3. Does a transaction started on the current node extend to the code sent to 
another node (IgniteRunnable, IgniteClosure)?
4. Does a transaction span another thread started from current?

Thanks for the help in advance.

Andrey

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в нем 
информация, или любые  приложения к нему,  не является официальной позицией АО 
«ФлексСофт» и не влечет финансовые или иные обязательства АО «ФлексСофт»; не 
могут использоваться и не являются какого-либо рода офертой,  акцептом оферты, 
или предложением делать оферты, или совершать акцепт оферты, не является 
рекламой или профессиональным советом,  прогнозом любых событий,  если иное 
прямо не предусмотрено в настоящем сообщении или любых приложениях к нему. АО 
«ФлексСофт» не несет ответственность за любые прямые или косвенные убытки от 
использования получателем или иным лицом сведений настоящего сообщения и/или 
приложений к нему.
Информация, передаваемая по сети Интернет, без использования технических 
средств защиты, является не защищенной от противоправных действий третьих лиц и 
может содержать вредоносные программные средства. АО «ФлексСофт» не несет 
ответственности за данные действия.

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в нем 
информация, или любые  приложения к нему,  не является официальной позицией АО 
«ФлексСофт» и не влечет финансовые или иные обязательства АО «ФлексСофт»; не 
могут использоваться и не являются какого-либо рода офертой,  акцептом оферты, 
или предложением делать оферты, или совершать акцепт оферты, не является 
рекламой или профессиональным 

RE: Ignite transactions

[Нестрогаев Андрей Викторович]

Thanks Pavel!


  1.  According to business logic, I must transactionally change the values in 
2 caches; in the course of my actions, I must log all these actions in the 3rd 
cache (protocol of my actions). So, it doesn’t matter whether my changes in 
these first two caches end up being a success (commit) or an error (rollback), 
I want the protocol of my actions to be preserved anyway. Based on your 
answers, I can assume that I can use either queues or a separate thread for 
these purposes.

Нестрогаев Андрей

From: Pavel Tupitsyn 
Sent: Wednesday, February 14, 2024 12:13 PM
To: user@ignite.apache.org
Subject: Re: Ignite transactions

1. Not sure I understand
2. Messaging is not transactional
3. No
4. No, transactions are tied to a specific thread

On Wed, Feb 14, 2024 at 11:01 AM Нестрогаев Андрей Викторович 
mailto:a.nestrog...@flexsoft.com>> wrote:
Hi All,

Maybe someone has already researched these questions:
1. How can you organize nested/autonomous transactions in ignite? For example, 
for the purpose of writing a protocol to another cache, so that the protocol is 
saved regardless of the result of the main transaction.
2. If you use Messaging in ignite within a transaction, does it take it into 
account, or is the message sent without taking into account the transaction?
3. Does a transaction started on the current node extend to the code sent to 
another node (IgniteRunnable, IgniteClosure)?
4. Does a transaction span another thread started from current?

Thanks for the help in advance.

Andrey

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в нем 
информация, или любые  приложения к нему,  не является официальной позицией АО 
«ФлексСофт» и не влечет финансовые или иные обязательства АО «ФлексСофт»; не 
могут использоваться и не являются какого-либо рода офертой,  акцептом оферты, 
или предложением делать оферты, или совершать акцепт оферты, не является 
рекламой или профессиональным советом,  прогнозом любых событий,  если иное 
прямо не предусмотрено в настоящем сообщении или любых приложениях к нему. АО 
«ФлексСофт» не несет ответственность за любые прямые или косвенные убытки от 
использования получателем или иным лицом сведений настоящего сообщения и/или 
приложений к нему.
Информация, передаваемая по сети Интернет, без использования технических 
средств защиты, является не защищенной от противоправных действий третьих лиц и 
может содержать вредоносные программные средства. АО «ФлексСофт» не несет 
ответственности за данные действия.

Настоящее  сообщение или любые приложения к нему могут содержать 
конфиденциальную информацию и другую информацию, защищаемую от раскрытия и 
принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без 
согласования с АО «ФлексСофт» является нарушением законодательства Российской 
Федерации. Любое действие, направленное на копирование, передачу, 
распространение каким-либо образом и с помощью каких-либо средств как самого 
письма, так и информации, содержащейся в нем (в том числе в виде приложений), 
запрещено. Отправитель настоящего сообщения не несет ответственность за 
точность и полноту передачи информации, содержащейся в настоящем сообщении, а 
также за своевременность ее получения. Если Вы получили настоящее сообщение по 
ошибке, пожалуйста, сообщите об этом отправителю, а затем удалите его и любые 
копии с Вашего компьютера. Настоящее электронное сообщение и содержащаяся в нем 
информация, или любые  приложения к нему,  не является официальной позицией АО 
«ФлексСофт» и не влечет финансовые или иные обязательства АО «ФлексСофт»; не 
могут использоваться и не являются какого-либо рода офертой,  акцептом оферты, 
или предложением делать оферты, или совершать акцепт оферты, не является 
рекламой или профессиональным советом,  прогнозом любых событий,  если иное 
прямо не предусмотрено в настоящем сообщении или любых приложениях к нему. АО 
«ФлексСофт» не несет ответственность за любые прямые или косвенные убытки от 
использования получателем или иным лицом сведений настоящего сообщения и/или 
приложений к нему.
Информация, передаваемая по сети Интернет, без использования технических 
средств защиты, 

Re: Ignite transactions

[Pavel Tupitsyn]

1. Not sure I understand
2. Messaging is not transactional
3. No
4. No, transactions are tied to a specific thread

On Wed, Feb 14, 2024 at 11:01 AM Нестрогаев Андрей Викторович <
a.nestrog...@flexsoft.com> wrote:

> Hi All,
>
>
>
> Maybe someone has already researched these questions:
>
> 1. How can you organize nested/autonomous transactions in ignite? For
> example, for the purpose of writing a protocol to another cache, so that
> the protocol is saved regardless of the result of the main transaction.
>
> 2. If you use Messaging in ignite within a transaction, does it take it
> into account, or is the message sent without taking into account the
> transaction?
>
> 3. Does a transaction started on the current node extend to the code sent
> to another node (IgniteRunnable, IgniteClosure)?
>
> 4. Does a transaction span another thread started from current?
>
>
>
> Thanks for the help in advance.
>
>
>
> Andrey
>
>
> *Настоящее  сообщение или любые приложения к нему могут содержать
> конфиденциальную информацию и другую информацию, защищаемую от раскрытия и
> принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без
> согласования с АО «ФлексСофт» является нарушением законодательства
> Российской Федерации. Любое действие, направленное на копирование,
> передачу, распространение каким-либо образом и с помощью каких-либо средств
> как самого письма, так и информации, содержащейся в нем (в том числе в виде
> приложений), запрещено. Отправитель настоящего сообщения не несет
> ответственность за точность и полноту передачи информации, содержащейся в
> настоящем сообщении, а также за своевременность ее получения. Если Вы
> получили настоящее сообщение по ошибке, пожалуйста, сообщите об этом
> отправителю, а затем удалите его и любые копии с Вашего компьютера.
> Настоящее электронное сообщение и содержащаяся в нем информация, или любые
> приложения к нему,  не является официальной позицией АО «ФлексСофт» и не
> влечет финансовые или иные обязательства АО «ФлексСофт»; не могут
> использоваться и не являются какого-либо рода офертой,  акцептом оферты,
> или предложением делать оферты, или совершать акцепт оферты, не является
> рекламой или профессиональным советом,  прогнозом любых событий,  если иное
> прямо не предусмотрено в настоящем сообщении или любых приложениях к нему.
> АО «ФлексСофт» не несет ответственность за любые прямые или косвенные
> убытки от использования получателем или иным лицом сведений настоящего
> сообщения и/или приложений к нему. Информация, передаваемая по сети
> Интернет, без использования технических средств защиты, является не
> защищенной от противоправных действий третьих лиц и может содержать
> вредоносные программные средства. АО «ФлексСофт» не несет ответственности
> за данные действия.*
>