Re: Rolling Update

[Stephen Darlington]

The baseline topology is still A Thing with memory--only clusters. The
difference is that auto-adjust is enabled by default. But yes, in short you
don't need to worry about the baseline if you don't use native persistence.

On Thu, 12 Sept 2024 at 21:21, Humphrey  wrote:

> And about baseline topology, that is only for when you using storage
> right? When using only in memory you don’t have baseline topology but just
> a cluster with pods.
>
> I’ll incorporate the check if the node has joined the cluster.
>
> On 10 Sep 2024, at 23:13, Jeremy McMillan  wrote:
>
> 
> Your pod flag should check baseline topology to see if it has fully joined
> the cluster AND that rebalancing has BOTH started and finished.
>
> There is a race condition if the pod does not immediately join the
> cluster, but checks to see if the cluster is balanced and THEN joins the
> cluster, triggering another rebalance after it's already reported that it
> is ready.
>
> Try to control for that.
>
> On Tue, Sep 10, 2024 at 3:01 AM Humphrey Lopez  wrote:
>
>> Thanks, seems a bit complicated. When I have more time I'll try that
>> approach.
>> For now we still going to (mis) use the Readiness probe to wait for the
>> rebalancing in a smart way. When the pod starts we have a flag that is set
>> to False, then the pod won't get ready until the cluster is rebalanced.
>> When the status of the cluster is rebalanced the pod will get the state to
>> ready and the flag will be set to true. Next Rebalancing triggered by
>> another pod will not affect the already running pod cause the flag will be
>> True.
>>
>> Let's see if this will wait long enough for the cluster to be in a stable
>> phase.
>>
>> Humphrey
>>
>> Op ma 9 sep 2024 om 17:34 schreef Jeremy McMillan :
>>
>>> An operator as I understand it, is just a pod that interacts with your
>>> application and Kubernetes API server as necessary to do what you might be
>>> doing manually.
>>>
>>> https://kubernetes.io/docs/concepts/extend-kubernetes/operator/
>>> https://kubernetes.io/docs/reference/using-api/client-libraries/
>>>
>>> You might start by creating an admin-pod with Ignite control.sh,
>>> sqlline.sh, thin client, etc. tools PLUS kubectl or some other Kubernetes
>>> API client that you can exec into and manually perform all of the rolling
>>> update steps. Once you know you have all the tools and steps complete, you
>>> can try adding scripts to the pod to automate sequences of steps. Then once
>>> the scripts are fairly robust and complete, you can use the admin-pod as a
>>> basis for Kubernetes Job definitions. It's up to you whether you'd like to
>>> continue integrating with Kubernetes further. Next steps would be to create
>>> a CustomResourceDefinition instead of using Kubernetes Job, or
>>> writing/adding a Kubernetes compatible API that does what your Job command
>>> line startup does, but with more control over parameters.
>>>
>>> Please share your results once you've got things working. Best of luck!
>>>
>>> On Fri, Sep 6, 2024 at 10:15 AM Humphrey  wrote:
>>>
 Thanks for the explanation, is there any operator ready for use? Is it
 hard to create own Operator if it doesn’t exist yet?

 Thanks

 On 5 Sep 2024, at 19:39, Jeremy McMillan  wrote:

 
 It is correct for an operator, but not correct for readiness probe.
 It's not your understanding of Ignite metrics. It is your understanding of
 Kubernetes.
 Kubernetes rolling update logic assumes all of your service backend
 nodes are completely independent, but you have chosen a readiness probe
 which reflects how nodes are interacting and interdependent.

 Hypothetically:
   We have bounced one node, and it has rejoined the cluster, and is
 rebalancing.
   If Kubernetes probes this node for readiness, we fail because we are
 rebalancing. The scheduler will block progress of the rolling update.
   If Kubernetes probes any other node for readiness, it will fail
 because we are rebalancing. The scheduler will remove this node from any
 services.
   All the nodes will reflect the state of the cluster: rebalancing.
   No nodes will remain in the service backend. If you are using the
 Kubernetes discovery SPI, the restarted node will find itself unable to
 discover any peers.

 The problem is that Kubernetes interprets the readiness probe as a NODE
 STATE. The cluster.rebalanced metric is a CLUSTER STATE.

 If you had a Kubernetes job that executes Kubectl commands from within
 the cluster, looping over the pods in a StatefulSet and restarting them, it
 would make perfect sense to check cluster.rebalanced and block until
 rebalancing finishes, but Kubernetes does something different with
 readiness probes based on some assumptions about clustering which do not
 apply to Ignite.

 On Thu, Sep 5, 2024 at 11:29 AM Humphrey Lopez 
 wrote:

> Yes I’m trying to read the cluste

Re: Query regarding Apache ignite open source

[Stephen Darlington]

Ignite has the Apache 2.0 Licence (
https://github.com/apache/ignite/blob/master/LICENSE) which is an approved
"open source" licence (https://opensource.org/license/apache-2-0).

There are distributions of Ignite with more restrictive licences, and they
may have additional features or different release schedules.

On Tue, 20 Aug 2024 at 11:06, Mahesh yadavalli 
wrote:

> Hi,
> I would like to know if Apache ignite is completely open source. If not,
> what features are not covered in the free/community version?
>
> Thank you!
>

Re: Ignite 2.16 entry processors sometimes execute twice

[Stephen Darlington]

Do you see the same behaviour with older versions of Ignite, or is this
unique to 2.16?

On Tue, 9 Jul 2024 at 21:34, Raymond Liu  wrote:

> Hi all,
>
> We're encountering an issue where entry processors execute twice.
> Executing twice is a problem for us because, for easier optimization, we
> would like our entry processors *not* to be idempotent.
>
> Here is a sample self-contained junit test on Github which demonstrates
> this issue: https://github.com/Philosobyte/ignite
> -duplicate-processing-test/blob/main/src/test/java/com/philosobyte/igniteduplicateprocessingtest/DuplicateProcessingTest.java
>
>
> (in case that link doesn't work, my github username is Philosobyte and the
> project is called "ignite-duplicate-processing-test")
>
> When the test is run, it will log two executions instead of just one.
>
> To rule out the entry processor executing on both a primary and backup
> partition, I set the number of backups to 0. I've also set atomicityMode to
> ATOMIC.
>
> Does anyone have any ideas about why this might happen?
>
> Thank you,
> Raymond
>

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

[Stephen Darlington]

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

There are two answers to your question:

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


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

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


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

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

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

Re: 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&D 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

[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
>
>
>
>
>
>
>

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

[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: 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
>
>

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: 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: 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
> 

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
>
>
>

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
>

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

[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: 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
>
> <https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations>
>
> <https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations>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: Question about REST/C++ client

[Stephen Darlington]

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
>>
>

Re: ignite + external database

[Stephen Darlington]

>
> 5. Ignite seems to have to know which partitions are lost, and in theory
> it doesn’t cost him anything to place these partitions on the remaining
> nodes (rebalancing) and execute the loadCache for lost partitions.


Yes, Ignite knows which partitions have been lost. "Reset lost partitions"
rebalances those lost partitions. But you can't, at least in general, do a
loadCache for a partition. Given a record, I can tell you which partition
it belongs to. But the reverse is not true. Given a partition, it's not
easy to say which records belong in it.

On Tue, 6 Feb 2024 at 19:03, Нестрогаев Андрей Викторович <
a.nestrog...@flexsoft.com> wrote:

> Thanks Stephen,
>
>
>
> 2. «You can, actually, enable persistence and connect to a third-party
> data store» - is this feature is not the same as using “external database”?
> coude you please give the link to the documentation
>
>
>
> 5. Ignite seems to have to know which partitions are lost, and in theory
> it doesn’t cost him anything to place these partitions on the remaining
> nodes (rebalancing) and execute the loadCache for lost partitions.
>
>
>
> Andrey
>
>
>
> *From:* Stephen Darlington 
> *Sent:* Tuesday, February 6, 2024 9:09 PM
> *To:* user@ignite.apache.org
> *Subject:* Re: ignite + external database
>
>
>
>1. With a memory-only cluster, Ignite does not store any persistent
>information. You'd need to save your table definitions somewhere yourself
>2. If it saved data, it would be a database rather than an in-memory
>data grid! You can, actually, enable persistence and connect to a
>third-party data store. It would, however, persistent the data, not just
>the metadata
>3. Data is rebalanced between Ignite nodes
>4. Assuming you're using the built-in JDBC Cache Store implementation,
>it basically does a "SELECT * FROM table" on each node and discards any
>data that should be stored elsewhere
>5. You'd get "lost partitions." Restoring the missing data is up to
>you. Kind of by definition, Ignite has lost some data and it doesn't know
>what it's missing
>
>
>
> On Tue, 6 Feb 2024 at 16:09, Нестрогаев Андрей Викторович <
> a.nestrog...@flexsoft.com> wrote:
>
> Hi All, I'm trying to use ignite (2.16) as an In-memory data grid
> (read-through / write-through caches), i.e. case described here
> https://ignite.apache.org/use-cases/in-memory-data-grid.html
>
>
>
> Several questions arose:
> 1. How is it recommended to store metadata for caches created dynamically
> during the life of the cluster so that they survive a complete reboot of
> the cluster?
> 2. Why can’t ignite save this cache metadata, just as it saves information
> about the base topology when we configure default data region to use
> persistence?
> 3. If a new node is joined to the base topology, how does rebalancing
> occur: is some data moved from other nodes, or are caches on the new node
> loaded from the database?
> 4. How does the initial loading of the partitioned cache from the database
> occur: each node loads they data it itself, or loads the node on which
> loadCache was initiated, or something else?
> 5. If both the primary node and backup node “died” at the same time, how
> will the cluster be restored and data loaded from the database?
>
>
>
> Thanks for the help in advance.
>
>
>
> Andrey.
>
> *Настоящее  сообщение или любые приложения к нему могут содержать
> конфиденциальную информацию и другую информацию, защищаемую от раскрытия и
> принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без
> согласования с АО «ФлексСофт» является нарушением законодательства
> Российской Федерации. Любое действие, направленное на копирование,
> передачу, распространение каким-либо образом и с помощью каких-либо средств
> как самого письма, так и информации, содержащейся в нем (в том числе в виде
> приложений), запрещено. Отправитель настоящего сообщения не несет
> ответственность за точность и полноту передачи информации, содержащейся в
> настоящем сообщении, а также за своевременность ее получения. Если Вы
> получили настоящее сообщение по ошибке, пожалуйста, сообщите об этом
> отправителю, а затем удалите его и любые копии с Вашего компьютера.
> Настоящее электронное сообщение и содержащаяся в нем информация, или любые
> приложения к нему,  не является официальной позицией АО «ФлексСофт» и не
> влечет финансовые или иные обязательства АО «ФлексСофт»; не могут
> использоваться и не являются какого-либо рода офертой,  акцептом оферты,
> или предложением делать оферты, или совершать акцепт оферты, не является
> рекламой или профессиональным советом,  прогно

Re: ignite + external database

[Stephen Darlington]

   1. With a memory-only cluster, Ignite does not store any persistent
   information. You'd need to save your table definitions somewhere yourself
   2. If it saved data, it would be a database rather than an in-memory
   data grid! You can, actually, enable persistence and connect to a
   third-party data store. It would, however, persistent the data, not just
   the metadata
   3. Data is rebalanced between Ignite nodes
   4. Assuming you're using the built-in JDBC Cache Store implementation,
   it basically does a "SELECT * FROM table" on each node and discards any
   data that should be stored elsewhere
   5. You'd get "lost partitions." Restoring the missing data is up to you.
   Kind of by definition, Ignite has lost some data and it doesn't know what
   it's missing


On Tue, 6 Feb 2024 at 16:09, Нестрогаев Андрей Викторович <
a.nestrog...@flexsoft.com> wrote:

> Hi All, I'm trying to use ignite (2.16) as an In-memory data grid
> (read-through / write-through caches), i.e. case described here
> https://ignite.apache.org/use-cases/in-memory-data-grid.html
>
>
>
> Several questions arose:
> 1. How is it recommended to store metadata for caches created dynamically
> during the life of the cluster so that they survive a complete reboot of
> the cluster?
> 2. Why can’t ignite save this cache metadata, just as it saves information
> about the base topology when we configure default data region to use
> persistence?
> 3. If a new node is joined to the base topology, how does rebalancing
> occur: is some data moved from other nodes, or are caches on the new node
> loaded from the database?
> 4. How does the initial loading of the partitioned cache from the database
> occur: each node loads they data it itself, or loads the node on which
> loadCache was initiated, or something else?
> 5. If both the primary node and backup node “died” at the same time, how
> will the cluster be restored and data loaded from the database?
>
>
>
> Thanks for the help in advance.
>
>
>
> Andrey.
>
>
> *Настоящее  сообщение или любые приложения к нему могут содержать
> конфиденциальную информацию и другую информацию, защищаемую от раскрытия и
> принадлежащую АО «ФлексСофт». Ее разглашение или иное использование без
> согласования с АО «ФлексСофт» является нарушением законодательства
> Российской Федерации. Любое действие, направленное на копирование,
> передачу, распространение каким-либо образом и с помощью каких-либо средств
> как самого письма, так и информации, содержащейся в нем (в том числе в виде
> приложений), запрещено. Отправитель настоящего сообщения не несет
> ответственность за точность и полноту передачи информации, содержащейся в
> настоящем сообщении, а также за своевременность ее получения. Если Вы
> получили настоящее сообщение по ошибке, пожалуйста, сообщите об этом
> отправителю, а затем удалите его и любые копии с Вашего компьютера.
> Настоящее электронное сообщение и содержащаяся в нем информация, или любые
> приложения к нему,  не является официальной позицией АО «ФлексСофт» и не
> влечет финансовые или иные обязательства АО «ФлексСофт»; не могут
> использоваться и не являются какого-либо рода офертой,  акцептом оферты,
> или предложением делать оферты, или совершать акцепт оферты, не является
> рекламой или профессиональным советом,  прогнозом любых событий,  если иное
> прямо не предусмотрено в настоящем сообщении или любых приложениях к нему.
> АО «ФлексСофт» не несет ответственность за любые прямые или косвенные
> убытки от использования получателем или иным лицом сведений настоящего
> сообщения и/или приложений к нему. Информация, передаваемая по сети
> Интернет, без использования технических средств защиты, является не
> защищенной от противоправных действий третьих лиц и может содержать
> вредоносные программные средства. АО «ФлексСофт» не несет ответственности
> за данные действия.*
>

Re: Regarding client and server side metrics

[Stephen Darlington]

Most of the metrics are about the node you're talking about rather than the
cluster as a whole. When you're talking about a distributed system, is a
"get" a client or a server operation? A bit of both, right?

On Mon, 29 Jan 2024 at 14:05, Godfather  wrote:

> Hi Community ,
> I have configured my application with ignite in client mode.I have a
> wrapper  around Ignite APIs that provide some out of the box atomic
> functionality. I have enabled the cache metrics and after performing some
> cache operation I can see that at server node the metrics related to
> cachehits, cacheputs are updating and at server side the metrics such as
> GetTimeTotal, PutTimeTotal , GetAllTime are updating .
> Is this normal to update some metrics at client side and some metrics at
> server side ?
> Is there any list by which we can differentiate client side metrics and
> server side metrics ?
>
>

Re: Regarding Backup activity between ignite nodes

[Stephen Darlington]

Most of your questions are answered in the documentation:
https://ignite.apache.org/docs/latest/configuring-caches/configuring-backups

On Tue, 23 Jan 2024 at 10:52, Patil, Yashodhan  wrote:

>
>
> Hi All,
>
>
> We have our application configured with ignite(2.16) in client mode which
> allows us to communicate with ignite server .
>
>
>
>1. I have configured some backups for ignite nodes and I am wondering
>how the backup activity works between ignite nodes ?
>2. Let’s say if I perform any cache operation on primary partition
>node then how come other backup ignite nodes backs up the data from primary
>node ?
>3. Is there any ignite metrics available for backup/sync which can
>tell what is happening with backup ?
>4. Is backup activity asynchronous ?
>
>

Re: Apache ignite 2.16

[Stephen Darlington]

Moving to Java 21 has its own risks, and the chances of you being affected
by this vulnerability seem pretty low ("This vulnerability does not apply
to Java deployments, typically in servers, that load and run only trusted
code"). In any case, I am told that the ML extension is in the process of
being released.

On Mon, 22 Jan 2024 at 16:35, Angelo Immediata  wrote:

> in my case i'm concerned to
> https://nvd.nist.gov/vuln/detail/CVE-2024-20932
>
> Il giorno lun 22 gen 2024 alle ore 16:11 Stephen Darlington <
> sdarling...@apache.org> ha scritto:
>
>> What vulnerability is fixed in Java 21 but not 17?
>>
>> On Mon, 22 Jan 2024 at 14:30, Angelo Immediata 
>> wrote:
>>
>>> hello Stephen Darlington
>>> Any news about ignite-ml-ext maven dependency?
>>> For security reason we upgraded to the openJDK 21 but ignite master node
>>> (version 2.15) failed to start, so we had to upgrade ignite version to the
>>> 2.16
>>> Now we have the issue that we canìt find anywhere the machine learning
>>> maven dependency
>>>
>>> Can you help us?
>>> Thnx
>>>
>>> Il giorno gio 11 gen 2024 alle ore 10:24 Stephen Darlington <
>>> sdarling...@apache.org> ha scritto:
>>>
>>>> Yes and no. As per the release notes, "The ignite-ml and cassandra
>>>> modules have been migrated to the Ignite extensions." This means that
>>>> you'll need to add the "ignite-ml-ext" dependency (rather than
>>>> "ignite-ml"). However, it appears that the new module has not yet been
>>>> released. In short, there will be a new version of ignite-ml, but it's not
>>>> available at the moment.
>>>>
>>>> On Thu, 11 Jan 2024 at 08:59, Angelo Immediata 
>>>> wrote:
>>>>
>>>>> hello everybody
>>>>>
>>>>> I'm using ignite 2.15; I want to upgrade to apache ignite 2.16
>>>>> Sadly I can't find version 2.16 of ignite-ml in any maven repository
>>>>> Is this correct? Is there no 2.16 version of ignite-ml?
>>>>>
>>>>> Angelo
>>>>>
>>>>

Re: Apache ignite 2.16

[Stephen Darlington]

What vulnerability is fixed in Java 21 but not 17?

On Mon, 22 Jan 2024 at 14:30, Angelo Immediata  wrote:

> hello Stephen Darlington
> Any news about ignite-ml-ext maven dependency?
> For security reason we upgraded to the openJDK 21 but ignite master node
> (version 2.15) failed to start, so we had to upgrade ignite version to the
> 2.16
> Now we have the issue that we canìt find anywhere the machine learning
> maven dependency
>
> Can you help us?
> Thnx
>
> Il giorno gio 11 gen 2024 alle ore 10:24 Stephen Darlington <
> sdarling...@apache.org> ha scritto:
>
>> Yes and no. As per the release notes, "The ignite-ml and cassandra
>> modules have been migrated to the Ignite extensions." This means that
>> you'll need to add the "ignite-ml-ext" dependency (rather than
>> "ignite-ml"). However, it appears that the new module has not yet been
>> released. In short, there will be a new version of ignite-ml, but it's not
>> available at the moment.
>>
>> On Thu, 11 Jan 2024 at 08:59, Angelo Immediata 
>> wrote:
>>
>>> hello everybody
>>>
>>> I'm using ignite 2.15; I want to upgrade to apache ignite 2.16
>>> Sadly I can't find version 2.16 of ignite-ml in any maven repository
>>> Is this correct? Is there no 2.16 version of ignite-ml?
>>>
>>> Angelo
>>>
>>

Re: Regadring metrics export through jmx exporter

[Stephen Darlington]

Scaping the metrics isn't "free." There's a cost in Ignite to create them
and there's a cost in Prometheus to store them.

It's a good idea to only request those you need.

On Thu, 18 Jan 2024 at 05:08, Godfather  wrote:

> Unfortunately we can not switch to OpenCensus.
> And Yes , I have around 27 cache and I am using jmx-exporter version
> 0.16.1 .
> I noticed that when I use whitelistObjectNames with Mbeans that I want to
> scrap then it works blazingly fast (within 1 to 2 seconds !!)
> do you recommend using whitelistObjectNames or is there any other
> workaround for this issue ?
>
> On Wed, Jan 17, 2024 at 3:23 PM Stephen Darlington 
> wrote:
>
>> I think the preference would be to use the OpenCensus exporter when using
>> Prometheus, but the JMX converter should work. Do you have a lot of caches?
>> I've seen lengthy "scrapes" when there are large numbers of caches.
>>
>> On Wed, 17 Jan 2024 at 05:14, Godfather  wrote:
>>
>>> Hello Community ,
>>> I recently upgraded to ignite 2.16 and the previous problem of jmx
>>> metrics not being exported is now resolved in 2.16 .
>>> However now i am trying to export ignite cache metrics , jmv metrics ,
>>> Partition Map Exchange metrics ,Compute Jobs metrics ,Thread Pools metrics
>>> , Communication metrics,  IODiscovery , IOCluster metrics with my custom
>>> rules .
>>> I am noticing large delay while metrics scrap (scrapinterval is 3
>>> minutes and scraptimeout is 2 minutes )
>>>
>>> Is it normal to take this much time to scrap metrics through prometheus
>>> jmx-exporter ?
>>> Is there any way to reduce scrap time ?
>>>
>>>
>>> sample rule for exporting cache metrics
>>> - pattern: "org.apache>> name=(.*)><>(Cache.*):"
>>>
>>

Re: Long-Term Java 8 support / Ignite 3 roadmap

[Stephen Darlington]

Other than the thread that Roman noted, I'm not aware of any specific plans
to move away from Java 8 for Ignite 2.x. As a community-driven project,
there are no guarantees but you'll probably be okay for a year or so.
Worst case, you can build your own Java 8-compatible version.

Having said that, the Java community as a whole seems to be quite rapidly
moving away from it. Many active projects have already dropped support.
Java 8 has not had mainstream support for a couple of years already.
Hopefully you have plans to migrate to something newer.

On Wed, 17 Jan 2024 at 14:27, Max Shultz  wrote:

> Hi Stephen, we were planning on implementing Ignite / GridGain in one of
> our projects, but we can’t do that if they are going to be dropping Java 8
> support in the next year for example. We are looking for something that
> will continue to support Java 8 for the next couple of years at least.
>
>
>
> *From:* Stephen Darlington 
> *Sent:* Wednesday, January 17, 2024 4:48 AM
> *To:* user@ignite.apache.org
> *Subject:* [EXTERNAL] Re: Long-Term Java 8 support / Ignite 3 roadmap
>
>
>
> Max, are you worried that Ignite will or won't drop Java 8 support?
>
>
>
> On Tue, 16 Jan 2024 at 17:39, Roman Puchkovskiy <
> roman.puchkovs...@gmail.com> wrote:
>
> Hi Max.
>
> I'm working at GridGain, so I think the best thing I could do to help
> you is to suggest contacting GridGain representatives, but you already
> did it.
>
> вт, 16 янв. 2024 г. в 19:21, Max Shultz :
> >
> > Hi Roman, thanks for the information. Do you know if GridGain is
> planning on having long-term Java 8 support? (I did reach out to them as
> well, but just curious if anyone here knows)
> >
> > Thanks,
> >
> >  - Max
> >
> > -Original Message-
> > From: Roman Puchkovskiy 
> > Sent: Tuesday, January 9, 2024 11:50 AM
> > To: user@ignite.apache.org
> > Subject: [EXTERNAL] Re: Long-Term Java 8 support / Ignite 3 roadmap
> >
> > Hi Max.
> >
> > As for Ignite 2, there are discussions (like this:
> > https://lists.apache.org/thread/v81wt7xzvrk6o04sb2k4fmydctqgtjlg )
> > about raising the minimum Java version used to compile the project to
> > 11 (that is, dropping support for Java 8-10).
> >
> > Ignite 3 does not support Java 8, it can be built (and run) minimally
> > on Java 11.
> >
> > вт, 9 янв. 2024 г. в 20:19, Max Shultz :
> > >
> > > Hi, I wanted to ask how long Apache Ignite plans on supporting Java 8.
> > >
> > >
> > >
> > > In the docs for Ignite 2.16.0, it says: “Ignite was officially tested
> on … JDK 8, 11, or 17”
> > >
> > >
> > >
> > > But in the docs for Ignite 3 beta, it says “Ignite 3.0 Beta was
> officially tested on: JDK 11 and later”
> > >
> > >
> > > When Ignite 3 comes out, will it replace Ignite 2 and drop Java 8
> support? Is there a roadmap for Ignite 3’s release?
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > - Max Shultz
>
> --
>
> This e-mail and any attachments may contain information that is
> confidential to Ross Video.
>
> If you are not the intended recipient, please notify me immediately by
> replying to this message. Please also delete all copies. Thank you.
>

Re: Regadring metrics export through jmx exporter

[Stephen Darlington]

I think the preference would be to use the OpenCensus exporter when using
Prometheus, but the JMX converter should work. Do you have a lot of caches?
I've seen lengthy "scrapes" when there are large numbers of caches.

On Wed, 17 Jan 2024 at 05:14, Godfather  wrote:

> Hello Community ,
> I recently upgraded to ignite 2.16 and the previous problem of jmx metrics
> not being exported is now resolved in 2.16 .
> However now i am trying to export ignite cache metrics , jmv metrics ,
> Partition Map Exchange metrics ,Compute Jobs metrics ,Thread Pools metrics
> , Communication metrics,  IODiscovery , IOCluster metrics with my custom
> rules .
> I am noticing large delay while metrics scrap (scrapinterval is 3 minutes
> and scraptimeout is 2 minutes )
>
> Is it normal to take this much time to scrap metrics through prometheus
> jmx-exporter ?
> Is there any way to reduce scrap time ?
>
>
> sample rule for exporting cache metrics
> - pattern: "org.apache<>(Cache.*):"
>

Re: Long-Term Java 8 support / Ignite 3 roadmap

[Stephen Darlington]

Max, are you worried that Ignite will or won't drop Java 8 support?

On Tue, 16 Jan 2024 at 17:39, Roman Puchkovskiy 
wrote:

> Hi Max.
>
> I'm working at GridGain, so I think the best thing I could do to help
> you is to suggest contacting GridGain representatives, but you already
> did it.
>
> вт, 16 янв. 2024 г. в 19:21, Max Shultz :
> >
> > Hi Roman, thanks for the information. Do you know if GridGain is
> planning on having long-term Java 8 support? (I did reach out to them as
> well, but just curious if anyone here knows)
> >
> > Thanks,
> >
> >  - Max
> >
> > -Original Message-
> > From: Roman Puchkovskiy 
> > Sent: Tuesday, January 9, 2024 11:50 AM
> > To: user@ignite.apache.org
> > Subject: [EXTERNAL] Re: Long-Term Java 8 support / Ignite 3 roadmap
> >
> > Hi Max.
> >
> > As for Ignite 2, there are discussions (like this:
> > https://lists.apache.org/thread/v81wt7xzvrk6o04sb2k4fmydctqgtjlg )
> > about raising the minimum Java version used to compile the project to
> > 11 (that is, dropping support for Java 8-10).
> >
> > Ignite 3 does not support Java 8, it can be built (and run) minimally
> > on Java 11.
> >
> > вт, 9 янв. 2024 г. в 20:19, Max Shultz :
> > >
> > > Hi, I wanted to ask how long Apache Ignite plans on supporting Java 8.
> > >
> > >
> > >
> > > In the docs for Ignite 2.16.0, it says: “Ignite was officially tested
> on … JDK 8, 11, or 17”
> > >
> > >
> > >
> > > But in the docs for Ignite 3 beta, it says “Ignite 3.0 Beta was
> officially tested on: JDK 11 and later”
> > >
> > >
> > > When Ignite 3 comes out, will it replace Ignite 2 and drop Java 8
> support? Is there a roadmap for Ignite 3’s release?
> > >
> > >
> > >
> > > Thanks!
> > >
> > >
> > >
> > > - Max Shultz
> >
> > --
> >
> > This e-mail and any attachments may contain information that is
> confidential to Ross Video.
> >
> > If you are not the intended recipient, please notify me immediately by
> replying to this message. Please also delete all copies. Thank you.
>

Re: Apache ignite 2.16

[Stephen Darlington]

Yes and no. As per the release notes, "The ignite-ml and cassandra modules
have been migrated to the Ignite extensions." This means that you'll need
to add the "ignite-ml-ext" dependency (rather than "ignite-ml"). However,
it appears that the new module has not yet been released. In short, there
will be a new version of ignite-ml, but it's not available at the moment.

On Thu, 11 Jan 2024 at 08:59, Angelo Immediata  wrote:

> hello everybody
>
> I'm using ignite 2.15; I want to upgrade to apache ignite 2.16
> Sadly I can't find version 2.16 of ignite-ml in any maven repository
> Is this correct? Is there no 2.16 version of ignite-ml?
>
> Angelo
>

Re: Info about time series support

[Stephen Darlington]

Normally we recommend using thin-clients if you can. Though, in this case,
using a thick-client makes your life easier. Thick clients can deploy Java
code for you.

There are a few different ways to do it. The "easy" option is to just
deploy the JAR files to the server nodes "manually." You could also
consider peer class loading (
https://ignite.apache.org/docs/2.11.1/code-deployment/peer-class-loading),
which is where the client automatically sends classes to the remote nodes.
Or UriDeployment (
https://ignite.apache.org/docs/2.11.1/code-deployment/deploying-user-code),
where Ignite copies the Jar files from a central location. GridGain's
Control Center (not open source) is also able to deploy code.

On Fri, 5 Jan 2024 at 14:04, Angelo Immediata  wrote:

> hello Gianluca and all
>
> Regarding to thin client, in my architecture I avoided to use thin
> clients; I'm using thick clients; so if python is supported only in "thin
> client" mode, I'd prefer to avoid it
>
> Regarding distributed computing, I didn't see it but it seems to be
> interesting but something is missing me. Let's suppose I want to use djl
> https://djl.ai/ and its timeseries support (
> https://djl.ai/extensions/timeseries/) I can use the distributed
> computing; as far as I understood the distributed computing allows to me to
> distribute computations across all my cluster nodes. Now I'm using thick
> clients, this means my java application is remotely connected to the apache
> ignite "master nodes"; in distributed computing I should execute the
> computation on master nodes but if I use a custom dependency (e.g. djl) how
> can these master remote nodes execute the computation if they don't have
> the libraries?
> Am I missing anything?
>
> Thank you
> Angelo
>
> Il giorno ven 5 gen 2024 alle ore 14:24 Gianluca Bonetti <
> gianluca.bone...@gmail.com> ha scritto:
>
>> Hello Jagat
>>
>> There are Ignite thin clients for a number of languages, including Python.
>> For a full list of functionalities and comparison, please always refer to
>> the official documentation.
>>
>> https://ignite.apache.org/docs/latest/thin-clients/getting-started-with-thin-clients
>>
>> All thin clients should perform around the same in tasks such as storing
>> and retrieving data as they use the Apache Ignite binary protocol.
>> As you know performance also varies case by case, because of different
>> setups, configurations, and versions of software/frameworks/libraries
>> being used, and of course the performance of the code that you will write
>> yourself.
>>
>> For my specific use cases, Apache Ignite always performed extremely well.
>> As I don't know anything about your project, there are far too many
>> possible variables to be able to reduce to a yes/no answer.
>> The advice is to run your own benchmarks on your infrastructure to get
>> some meaningful figures for your specific project and infrastructure.
>>
>> Cheers
>> Gianluca Bonetti
>>
>> On Fri, 5 Jan 2024 at 12:40, Jagat Singh  wrote:
>>
>>> Hi Gianluna,
>>>
>>> Does the Python client miss any functionality or performance compared to
>>> Java?
>>>
>>> Thanks
>>>
>>> On Fri, 5 Jan 2024 at 15:55, Gianluca Bonetti <
>>> gianluca.bone...@gmail.com> wrote:
>>>
 Hello Angelo

 It seems to be an interesting use case for Ignite.

 However, you should consider what Ignite is, and what is not.
 Essentially, Ignite is a distributed in-memory
 database/cache/grid/etc...
 It also has some distributed computing API capabilities.

 You can store data easily in Ignite, and consume data by your code
 written in Java.
 You can also use Python since there is a Python Ignite Client available
 if it makes your time series analysis easier.
 You can also use the Ignite Computing API to execute code on your
 cluster
 https://ignite.apache.org/docs/latest/distributed-computing/distributed-computing
 but in this case I think Python is not supported.

 Cheers
 Gianluca Bonetti

 On Fri, 5 Jan 2024 at 08:52, Angelo Immediata 
 wrote:

> I'm pretty new to Apache Ignite
>
>
> I asked this also on stackoverflow (
> https://stackoverflow.com/questions/77667648/apache-ignite-time-series-forecasting)
> but I received no answer
>
> I need to make some forecasting analysis
>
> Basically I can collect data in Ignite in real time. Ignite will store
> data in its own caches
>
> Now I need to make some forecasting showing me the distribution of
> data in the next X months/years by starting from observed and collected
> data.
>
> As far as I know, this kind of forecasting can be realized by time
> series forecasting. In Ignite I see no time series based algorithm. Am I
> right?
>
> If I'm correct I may use or tensor flow or Deep Java Library. But in
> this case what I don't understand is: where should I use these libraries?
> Inside my thick client microse

Re: Extend DefaultReplicationPolicy for MirrorSourceConnector / MirrorMaker

[Stephen Darlington]

Hi, this is the user mailing list for the Apache Ignite project. This page
shows the various Kafka email lists: https://kafka.apache.org/contact.html

Regards,
Stephen

On Mon, 11 Dec 2023 at 15:11, astronaut37  wrote:

> Hi Guys,
> we have an already running Kakfa Connector Cluster.
> I want to add a MirrorSourceConnector with a custom replication policy:
> -
> curl --request POST \
>   --url http://localhost:9083/connectors \
>   --header 'Accept: application/json' \
>   --header 'Content-Type: application/json' \
>   --data '{
>"name" : "cluster-source",
> "config":{
> "connector.class": "org.apache.kafka.connect.mirror.MirrorSourceConnector",
> ...
> "replication.policy.class" : "org.example.CustomReplicationPolicy",
> ...
> }
> }'
> -
> This leads to an error:
> -
> {
> "error_code": 400,
> "message": "Connector configuration is invalid and contains the following
> 1 error(s):\nInvalid value org.example.CustomReplicationPolicy for
> configuration replication.policy.class: Class
> org.example.CustomReplicationPolicy could not be found.\nYou can also find
> the above list of errors at the endpoint
> `/connector-plugins/{connectorType}/config/validate`"
> }
> -
> I added the jar which contains CustomReplicationPolicy to the /lib path
> but it won't work.
>
> How can I use my CustomReplicationPolicy with the MirrorSourceConnector?
> I'm using Kafka 2.8.
> Setting up the MirrorMaker with /bin/connect-mirror-maker.sh and the jar
> file in /lib works, but unfortunately I have to configure the mirror maker
> connectors one by one in our enviroment.
>
> BR
> Toni
>

Re: RE: Uneven offheap memory distribution among cluster server nodes

[Stephen Darlington]

There's a really nice blog on why this is the correct advice:
https://www.gridgain.com/resources/blog/data-distribution-in-apache-ignite

"To achieve optimal key and partition distribution across nodes, it is
important to ensure that the number of partitions is significantly greater
than the number of nodes, and the number of keys is significantly greater
than the number of partitions."

On Sat, 2 Dec 2023 at 17:59, Aleksandr Nikolaev 
wrote:

>
> To get a more even distribution of partitions, you should increase their
> number.
>
>
> On 2023/11/17 08:45:30 "Gangaiah.Gundeboina.ril.com via user" wrote:
>  > Any suggestions to improve the distribution.
>  >
>  > On 2023/10/18 18:51:43 "Gangaiah.Gundeboina.ril.com via user" wrote:
>  > > Hi,
>  > >
>  > > We have 8 nodes in cluster, each sever having 2tb size. Could see
> offheap memory huge difference among nodes, got to know it's because of
> uneven distribution of partitions. We have around 40 caches having set
> 128 partitions and replication is one for each cache. Below are number
> of partitions each sever having for one of the cache including backup
> ones. Want to correct the distribution, any suggestions?.
>  > >
>  > > Node1: 28
>  > > Node2: 37
>  > > Node3: 36
>  > > Node4: 39
>  > > Node5: 42
>  > > Node6: 35
>  > > Node7: 30
>  > > Node8: 33
>  > >
>  > > [cid:6383480e-22b1-40d4-a789-518471fc8de0]
>  > >
>  > >
>  > > Regards,
>  > > Gangaiah
>  > > "Confidentiality Warning: This message and any attachments are
> intended only for the use of the intended recipient(s).
>  > > are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
>  > > review. re-transmission. conversion to hard copy. copying.
> circulation or other use of this message and any attachments is
>  > > strictly prohibited. If you are not the intended recipient. please
> notify the sender immediately by return email.
>  > > and delete this message and any attachments from your system.
>  > >
>  > > Virus Warning: Although the company has taken reasonable
> precautions to ensure no viruses are present in this email.
>  > > The company cannot accept responsibility for any loss or damage
> arising from the use of this email or attachment."
>  > >
>  > "Confidentiality Warning: This message and any attachments are
> intended only for the use of the intended recipient(s).
>  > are confidential and may be privileged. If you are not the intended
> recipient. you are hereby notified that any
>  > review. re-transmission. conversion to hard copy. copying.
> circulation or other use of this message and any attachments is
>  > strictly prohibited. If you are not the intended recipient. please
> notify the sender immediately by return email.
>  > and delete this message and any attachments from your system.
>  >
>  > Virus Warning: Although the company has taken reasonable precautions
> to ensure no viruses are present in this email.
>  > The company cannot accept responsibility for any loss or damage
> arising from the use of this email or attachment."
>  >
>  >
>

Re: Local node SEGMENTED help with logs

[Stephen Darlington]

The most common cause of a segmented cluster is not the network but your
Java garbage collection configuration. Do you see any "Long JVM pause"
warnings in your logs before the problem occurs?

On Wed, 8 Nov 2023 at 08:48, Alan Rose  wrote:

>
> I am hoping someone can help me understand some log entries better.
> I have two ignite nodes A & B running in linux containers that appear to
> have a network issue that result in node A restarting approx 5 seconds
> later.
> From the logs Node B states about Node A
>"Previous node alive status [alive=false,
> checkPreviousNodeId=fb9c943e-aa4a-4e6c-ae00-1df5212a3f3f,
> actualPreviousNode=TcpDiscoveryNode
> [id=58424f0b-e77f-4127-835a-4274f57955a1,
> consistentId=5faca106-0c39-45ab-8c64-f38df8910238, etc.
> What is this line telling me about Node A?
>
> I then get
>  "Node FAILED: TcpDiscoveryNode ..etc"
> and  "Close incoming connection, unknown node..?" I think talking about
> node A
>
> Node A log states
>Failed to send message to remote node [node=TcpDiscoveryNode [id= etc
>but it does appear to be able to ping node B Ok
> within 5 second I see in Node A log
>   Node is out of topology (probably, due to short-time network problems).
>Local node SEGMENTED: TcpDiscoveryNode [id=58 etc
>  finally there is a restart of the node A.
> I see no other evidence of a network issue. Is there something I can
> configure, so it is not so quick to timeout
> The only thing I see in the log at startup around 5 seconds
> is netTimeout=5000
>
>
>
>
>
> --
> *Alan Rose*
> *Senior Software Engineer. *
>
> *CCSS Team Merino*
> *Trimble Navigation New Zealand Limited*
> P O Box 8729, Riccarton, Christchurch 8440 , New Zealand
> +64 3 9635616 Ext 604016
>
>

Re: Why wpuld a client node error cause server node to shut off?

[Stephen Darlington]

There are lots of "throttling" warnings. It could be as simple as your
cluster is at its limit. Faster or more disks might help, as might scaling
out. The other is that you've enabled write throttling.
Counter-intuitively, you might want to *dis*able that. It'll still do write
throttling, just using a different algorithm.

On Tue, 31 Oct 2023 at 15:35, John Smith  wrote:

> I understand you have no time and I have also followed that link. My nodes
> are 32GB and I have allocated 8GB for heap and some for off-heap. So I'm
> def not hitting some ceiling where it needs to try to force some huge
> garbage collection.
>
> What 'i'm asking based on the config and stats I gave do you see anything
> that sticks out in those configs not the logs?
>
> On Tue, Oct 31, 2023 at 10:42 AM Stephen Darlington <
> sdarling...@apache.org> wrote:
>
>> No, sorry, the issue is that I don't have the time to go through 25,000
>> lines of log file. As I said, your cluster had network or long JVM pause
>> issues, probably the latter:
>>
>> [21:37:12,517][WARNING][jvm-pause-detector-worker][IgniteKernal%xx]
>> Possible too long JVM pause: 63356 milliseconds.
>>
>> When nodes are continually talking to one another, no Ignite code being
>> executed for over a minute is going to be a *big* problem. You need to
>> tune your JVM. There are some hints in the documentation:
>> https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning
>>
>>
>> On Tue, 31 Oct 2023 at 13:16, John Smith  wrote:
>>
>>> Does any of this infor help? I included what we do more or less plus
>>> stats and configs.
>>>
>>> There are 9 caches of which the biggest one is 5 million records
>>> (partitioned with 1 backup), the key is String (11 chars) and the value
>>> integer.
>>>
>>> The rest are replicated and some partitioned but max a few thousand
>>> records at best.
>>>
>>> The nodes are 32GB here is the output of the free -m
>>>
>>>   totalusedfree  shared  buff/cache
>>> available
>>> Mem:  321672521   26760   02885
>>>   29222
>>> Swap:  2047   02047
>>>
>>> And here is node stats:
>>>
>>> Time of the snapshot: 2023-10-31 13:08:56
>>>
>>> +-+
>>> | ID  | e8044c1a-6e0d-4f94-9a04-0711a3d7fc6e
>>>  |
>>> | ID8 | E8044C1A
>>>  |
>>> | Consistent ID   | b14350a9-6963-442c-9529-14f70f95a6d9
>>>  |
>>> | Node Type   | Server
>>>  |
>>> | Order   | 2660
>>>  |
>>> | Address (0) | xx
>>> |
>>> | Address (1) | 127.0.0.1
>>>   |
>>> | Address (2) | 0:0:0:0:0:0:0:1%lo
>>>  |
>>> | OS info | Linux amd64 4.15.0-197-generic
>>>  |
>>> | OS user | ignite
>>>  |
>>> | Deployment mode | SHARED
>>>  |
>>> | Language runtime| Java Platform API Specification ver. 1.8
>>>  |
>>> | Ignite version  | 2.12.0
>>>  |
>>> | Ignite instance name| xx
>>>   |
>>> | JRE information | HotSpot 64-Bit Tiered Compilers
>>>   |
>>> | JVM start time  | 2023-09-29 14:50:39
>>>   |
>>> | Node start time | 2023-09-29 14:54:34
>>>   |
>>> | Up time | 09:28:57.946
>>>  |
>>> | CPUs| 4
>>>   |
>>> | Last metric update  | 2023-10-31 13:07:49
>>>   |
>>> | Non-loopback IPs| xx, xx |
>>> | Enabled MACs| xx
>>> |
>>> | Maximum active jobs | 1
>>>   |
>>> | Current active jobs | 0
>>>   |
>>> | Average active jobs | 0.01
>>>  |
>>> | Maximum waiting jobs| 0
>>>   |
>>> | Current waiting jobs| 0
>>>   |
>>> | Average waiting jobs| 0.00
>>>  |
>

Re: Why wpuld a client node error cause server node to shut off?

[Stephen Darlington]

 |
> | Current daemon thread count | 15
>|
>
> +-+
>
> Data region metrics:
>
> +==+
> |   Name   | Page size |   Pages|Memory |
>  Rates   | Checkpoint buffer | Large entries |
>
> +==+
> | Default_Region   | 0 | Total:  307665 | Total:  1gb   |
> Allocation: 0.00 | Pages: 0  | 0.00% |
> |  |   | Dirty:  0  | In RAM: 0 |
> Eviction:   0.00 | Size:  0  |   |
> |  |   | Memory: 0  |   |
> Replace:0.00 |   |   |
> |  |   | Fill factor: 0.00% |   |
>  |   |   |
>
> +--+---++---+--+---+---+
> | metastoreMemPlc  | 0 | Total:  57 | Total:  228kb |
> Allocation: 0.00 | Pages: 0  | 0.00% |
> |  |   | Dirty:  0  | In RAM: 0 |
> Eviction:   0.00 | Size:  0  |   |
> |  |   | Memory: 0  |   |
> Replace:0.00 |   |   |
> |  |   | Fill factor: 0.00% |   |
>  |   |   |
>
> +--+---++---+--+---+---+
> | sysMemPlc| 0 | Total:  5  | Total:  20kb  |
> Allocation: 0.00 | Pages: 0  | 0.00% |
> |  |   | Dirty:  0  | In RAM: 0 |
> Eviction:   0.00 | Size:  0  |   |
> |  |   | Memory: 0  |   |
> Replace:0.00 |   |   |
> |  |   | Fill factor: 0.00% |   |
>  |   |   |
>
> +--+---++---+--+---+---+
> | TxLog| 0 | Total:  0  | Total:  0 |
> Allocation: 0.00 | Pages: 0  | 0.00% |
> |  |   | Dirty:  0  | In RAM: 0 |
> Eviction:   0.00 | Size:  0  |   |
> |  |   | Memory: 0  |   |
> Replace:0.00 |   |   |
> |  |   | Fill factor: 0.00% |   |
>  |   |   |
>
> +--+---++---+--+---+---+
> | volatileDsMemPlc | 0 | Total:  0  | Total:  0 |
> Allocation: 0.00 | Pages: 0  | 0.00% |
> |  |   | Dirty:  0  | In RAM: 0 |
> Eviction:   0.00 | Size:  0  |   |
> |  |   | Memory: 0  |   |
> Replace:0.00 |   |   |
> |  |   | Fill factor: 0.00% |   |
>  |   |   |
>
> +--+
>
> Server nodes config...
>
> if [ -z "$JVM_OPTS" ] ; then
> JVM_OPTS="-Xms8g -Xmx8g -server -XX:MaxMetaspaceSize=256m"
> fi
>
> #
> # Uncomment the following GC settings if you see spikes in your throughput
> due to Garbage Collection.
> #
> # JVM_OPTS="$JVM_OPTS -XX:+UseG1GC"
> JVM_OPTS="$JVM_OPTS -XX:+AlwaysPreTouch -XX:+UseG1GC
> -XX:+ScavengeBeforeFullGC -XX:+DisableExplicitGC
> -XX:MaxDirectMemorySize=256m"
>
> And we use this as our persistence config...
>
>   
>  class="org.apache.ignite.configuration.DataStorageConfiguration">
>   
>
>   
>   
>  class="org.apache.ignite.configuration.DataRegionConfiguration">
>   
>
>   
>   
> 
>   
> 
>   
>
> On Tue, Oct 31, 2023 at 5:27 AM Stephen Darlington 
> wrote:
>
>> There's a lot going on in that log file. It makes it difficult to tell
>> what *the* issue is. You have lots of nodes leaving (and joining) the
>> cluster, including server nodes. You have lost partitions and long JVM
>> pauses. I suspect the real cause of this node shutting down was that it
>> became segmented.
>>
>> Chances are the issue is either a genuine network issue or the long JVM
>> pauses -- which means that the nodes are not talking to each other --
>> caused the cluster to fall apart.
>>
>

Re: Why wpuld a client node error cause server node to shut off?

[Stephen Darlington]

There's a lot going on in that log file. It makes it difficult to tell what
*the* issue is. You have lots of nodes leaving (and joining) the cluster,
including server nodes. You have lost partitions and long JVM pauses. I
suspect the real cause of this node shutting down was that it became
segmented.

Chances are the issue is either a genuine network issue or the long JVM
pauses -- which means that the nodes are not talking to each other --
caused the cluster to fall apart.

Re: Why wpuld a client node error cause server node to shut off?

[Stephen Darlington]

It wouldn't. We'd need to see more of the logs to determine what the
problem was.

On Mon, 30 Oct 2023 at 15:12, John Smith  wrote:

> Hi I see this error message on the server node...
>
> [21:37:20,310][SEVERE][query-#2884155%raange%][GridMapQueryExecutor]
> Failed to send message.
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Failed to send message (node left topology): TcpDiscoveryNode
> [id=d6a33cc0-59e7-452d-a516-730e4c89c29e,
> consistentId=d6a33cc0-59e7-452d-a516-730e4c89c29e, addrs=ArrayList
> [127.0.0.1, xx], sockAddrs=HashSet [/127.0.0.1:0, /xx:0],
> discPort=0, order=1573, intOrder=803, lastExchangeTime=1677567347200,
> loc=false, ver=2.12.0#20220108-sha1:b1289f75, isClient=true]
>
> Why would that cause the server to shut off?
>

Re: Re: Parallel execution CreateTable

[Stephen Darlington]

There's a lot going on there, and I don't have the time to fully analyse,
but I will note a few things:

   - You have a lot of very poorly optimised queries (full table scans)
   - I see a few "long JVM pauses" which suggests poorly configured garbage
   collector
   - Ignite is not designed for large numbers of cache
   creation/destruction. Lots of simultaneous queries are fine, because those
   do not require a global lock
   - If you need to create a lot of caches at once, you can use XML or a
   programming language and use the createCaches() method



On Tue, 17 Oct 2023 at 10:43, y  wrote:

>
> Here is cluster log（from one node） and createtable sql（Appendix）.
> The Cluster has 10 nodes and do stress testing with 50 thread .It means
> there 50 query or createtable operations at the same time. Notice that when
> create table，the cluster node log has many ‘Thread - WAITING’. That's not
> normal, right?
>
>
>
> At 2023-10-17 15:19:33, "Stephen Darlington" 
> wrote:
>
> Can you share some more information about your cluster? There is no way
> that creating a cache should take so long.
>
> On Tue, 17 Oct 2023 at 03:51, y  wrote:
>
>> Hello.
>> Everyone！
>>
>>   Creating table statements is executed synchronously and will block
>> other DDL statements.  There are serious performance issues in concurrent
>> environments. It takes one minute to create one table.
>>If there is any way to solve this problem, such as changing it to
>> serial execution？
>>
>>
>> Thanks,
>>
>> Tianyu-Hu
>>
>>
>>
>>
>

Re: Parallel execution CreateTable

[Stephen Darlington]

Can you share some more information about your cluster? There is no way
that creating a cache should take so long.

On Tue, 17 Oct 2023 at 03:51, y  wrote:

> Hello.
> Everyone！
>
>   Creating table statements is executed synchronously and will block other
> DDL statements.  There are serious performance issues in concurrent
> environments. It takes one minute to create one table.
>If there is any way to solve this problem, such as changing it to
> serial execution？
>
>
> Thanks,
>
> Tianyu-Hu
>
>
>
>

Re: Different sizes of the same dataregion across multiple nodes?

[Stephen Darlington]

Yes. It's not a good idea in general, but as a temporary measure while
upgrading it's not a problem.

On Mon, 9 Oct 2023 at 09:08, kimec.ethome.sk  wrote:

> Hello,
>
> is it possible to configure different size of the same dataregion across
> multiple nodes? We need to increase the region size in production
> environment and would like to increase it node by node so that we have
> no down time. I have not found any info on this in the documentation.
> Should this be possible? Caches occupying the dataregion are mostly
> replicated or distributed with 1 back up.
>
> We tried to do something similar a year ago and the whole cluster died.
> Unfortunately, I do not remember what was the exact cause back then. We
> are now assessing how to approach this correctly.
>
> Kind regards,
>
> Kamil
>

Re: Ignite 2.12.0 Thick Client node filter issue

[Stephen Darlington]

Can you share your service configuration? The default node filter will only
deploy services on server nodes.

On Thu, 5 Oct 2023 at 15:03, Greg Sylvain  wrote:

>
> This does not happen with thin clients.
>
> I switched our Ignite 2.12.0 service cluster to using Thick clients
> instead of Thin as a result of performance testing.
>
> The performance is better and more consistent.  However, whenever a
> ServerNode drops out and rejoins the cluster, the Thick clients participate
> in the Node Filtering of services
> (IgnitePerdicateX::applyx(ClusterNode) (Line: 1080)
>
> Even with all of these Thick Clients are clearly identified as clients
> (isClient == true).
>
> Is there any way, include the derived apply method to check to see it is
> being run on a ServerNode or a ClientNode?  It already checks to see if the
> ClusterNode argument to the method is a client.
>
> THanks in advance.
> Greg
>
>

Re: Question about JDBC polymorphism

[Stephen Darlington]

The most straightforward answer might just be to create views in
your source database. Out of the box, the cache store is really designed
for a 1:1 mapping between table and cache. You *can* do more complex
mappings, but it may require coding.

On Wed, 6 Sept 2023 at 09:46, Bram Biesbrouck <
bram.biesbro...@reinvention.be> wrote:

> Hi all,
>
> I've been experimenting with Ignite over the past months and took an
> unexpected (pleasant) deep dive.
>
> Right now, I'm fiddling around with write-through and read-through, but
> I'm stuck on one feature I'd really want to find a solution for database
> table discriminator values and mapping them to a polymorph class hierarchy.
>
> In a way, I'm looking for an Ignite alternative to JPA's
> @DiscriminatorColumn
> 
> annotation that creates different classes from records with different
> column constants. Or just something similar. Documentation or examples of
> support for polymorphism in general maybe?
>
> I've started using low level configuration with JdbcType, QueryEntity and
> complex keys, but I can't seem to find an acceptable solution to load
> database records (from a single table) into different caches (or a single
> cache with different binaries of distinct classes).
>
> Any help or pointers in the right direction?
> Do I need to write a custom Marchaller maybe?
>
> b.
>  *Creative engineering & inventions*
> Check our latest projects!  *Bram Biesbrouck*
> bram.biesbro...@reinvention.be
> +32 486 118280 <0032%20486%20118280>
>

Re: Basic cache statistics for Ignite clusters deployed on Kubernetes

[Stephen Darlington]

A good place to start would be the monitoring section of the documentation:
https://ignite.apache.org/docs/latest/monitoring-metrics/intro

You can use JMX, OpenCensus, some of the system views; deploying on
Kubernetes doesn't change any of that.

Control.sh, as you suggest, can be used for *ad hoc* inspection. More
information here:
https://ignite.apache.org/docs/latest/tools/control-script#metric-command

Maybe use the system views to find the names of the metrics (select name
from sys.metrics) and use control.sh to view them?


On Wed, 6 Sept 2023 at 08:23, Mateusz K  wrote:

> Hi,
>
> We have a cluster running on Apache Ignite 2.15 version on Kubernetes.
> Could you please advise how to obtain basic cache and cluster nodes
> statistics using control.sh script? Ignite Visor is no longer an option (it
> used to be sufficient for basic insights).
>
> I've raised https://github.com/apache/ignite/issues/10834 for the same
> back in July but it has been missed. What are our alternatives (including
> paid ones) you would recommend?
>
> Kind regards,
> Mateusz Kapturski
>

Re: An issue about the expiration time of item level cache

[Stephen Darlington]

In practice, I've not seen a use case where retrieving the TTL is required.
Depending on what you want to do, there are likely to be workarounds.

Regards,
Stephen

On Thu, 31 Aug 2023 at 01:51, Mengyu Jing  wrote:

> Hi, Stephen Darlington
>
>
>
> I don't have any use cases yet, I just want to know how to obtain the
> expiration time of each cache entry.
>
> Thank you for your reply!
>
>
>
> 从 Windows 版邮件 <https://go.microsoft.com/fwlink/?LinkId=550986>发送
>
>
>
> *发件人: *Stephen Darlington 
> *发送时间: *2023年8月29日 20:46
> *收件人: *user@ignite.apache.org
> *主题: *Re: An issue about the expiration time of item level cache
>
>
>
> There is a ticket for this (
> https://issues.apache.org/jira/browse/IGNITE-7641) but there is currently
> no API.
>
>
>
> What’s your use case?
>
>
>
> On 29 Aug 2023, at 13:20, Mengyu Jing  wrote:
>
>
>
> Hi, igniters:
>
>
>
> I would like to ask some questions about Ignite. Is there a ready-made
> method for Ignite to retrieve the expiration time set for a key in the
> cache? Or is there a method to find the TTL of a certain key? I never found
> it in the document.
>
>
>
> Thank you!
>
>
>
> 从 Windows 版邮件 <https://go.microsoft.com/fwlink/?LinkId=550986>发送
>
>
>
>
>

Re: An issue about the expiration time of item level cache

[Stephen Darlington]

There is a ticket for this (https://issues.apache.org/jira/browse/IGNITE-7641) 
but there is currently no API.

What’s your use case? 

> On 29 Aug 2023, at 13:20, Mengyu Jing  wrote:
> 
> Hi, igniters:
>  
> I would like to ask some questions about Ignite. Is there a ready-made method 
> for Ignite to retrieve the expiration time set for a key in the cache? Or is 
> there a method to find the TTL of a certain key? I never found it in the 
> document.
>  
> Thank you!
>  
> 从 Windows 版邮件 发送

Re: Recomendations on stack config

[Stephen Darlington]

First, Calcite support is still considered beta-quality, so that might be a 
factor.

However, more likely is your memory usage. A query like this would need a lot 
of Java heap space, so you would need to tune your garbage collector.

> On 9 Aug 2023, at 15:48, Maxim Baglay  wrote:
> 
> Hi,
> Experiencing performance problems on writing data to Ignite stack with next 
> queries
> 
> MERGE INTO ... VALUES ((...)...) ON () WHEN MATCHED THEN UPDATE SET ... WHEN 
> NOT MATCHED THEN INSERT ... VALUES (...)
> 
> with 1-2 values it takes about 100-150ms in average (and growing to 600-700ms 
> and more) when expected to be under 10ms. Average execution time constantly 
> grows.
> 
> Additional details:
> Connecting as thin jdbc client.
> Use Calcite as query engine.
> Ingite stack has 40 data nodes.
> Stack sync is done with zookeeper.
> Connecting using r53 address.
> The table is partitioned with 1 backup.
> Query execution time are from SYS.SQL_QUERY_HISTORY
> 
> The questions here are:
> why this query takes so much time?
> and what are recomendations for stack to save dozens of millions of rows 
> (amount of nodes, amount of CPUs, heap size...)?
> 
> Tried to turn off persistance - that didn't change exectuion time
> Tried to use partitionAwareness=true - that didn't change exectuion time
> Tried to set skipReducerOnUpdate tp true - that didn't help
> Tried providing full set of nodes in connection string instead of r53 - that 
> didn't help
> 
> Thanks in advance for the help!

Re: Ignite Off Heap memory keeps growing

[Stephen Darlington]

There is no such thing as an on-heap-only cache. If you store data in Ignite, 
it’s off-heap. On-heap caches, if enabled, are in addition to the off-heap 
cache, a cache of a cache. Most use cases do not benefit from having an on-heap 
cache.

> On 4 Aug 2023, at 03:06, Dinakar Devineni  wrote:
> 
> Hi,
>  
> I  have  a  Ignite  V2.14 cluster   with  all on-heap caches configured 
> without  any  eviction policy.  
> I’m trying to  understand why the off  heap  data region keeps  growing ?
> I  was  only  expecting  Heap  usage  to  go up as onheap  caches  are  
> populated, but   Off Heap  and  Data region  memory was  used.
>  
> Does the  onheap cache used memory  accounts towards Data Region capacity?
>  
>  
> No. of Nodes:   3
> Max Heap : 30 G
> Average Heap usage  on the  Node: 12 G
> Data Region  Capacity : 25G  per Node
> Total Data Region Capacity: 75G
> Average Data Region Usage Per Node: 10 G
>  
> Ignite cluster is running on  Kubernetes.
> No  Persistence enabled. No  Off heap  caches  configured.
>  
>  
> Thanks and appreciate your response
> D

Re: Read Write through cache

[Stephen Darlington]

Ignite is horizontally scalable. It can use as much memory as you have. 1Tb 
isn’t that much; I know of people with over 20Tb of data in memory. If you 
don’t want to keep everything in memory, you can use native persistence and 
keep less used data only on disk.

> On 19 Jul 2023, at 11:52, Arunima Barik  wrote:
> 
> My data is around 1TB huge
> 
> I don't think so much can be loaded into memory
> Plus my data is in parquet files. So loading it to spark and writing to 
> Ignite is very time consuming. 
> 
> Any thoughts on this please. 
> 
> Regards
> 
> On Wed, 19 Jul, 2023, 2:14 pm Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> A more common approach would be that Ignite has all your data and Spark has 
>> a subset. Ignite SQL is generally faster than Spark SQL, since it can use 
>> indexes, etc. But it’s not magic; it can’t query data it doesn’t know about.
>> 
>>> On 19 Jul 2023, at 04:40, Arunima Barik >> <mailto:arunimabari...@gmail.com>> wrote:
>>> 
>>> How does write through work? I mean if I add a row in Ignite dataframe, how 
>>> does it reflect to spark? 
>>> 
>>> I have 50 rows in Ignite and all 100 rows in Spark. 
>>> If I perform a union all, wont the performance degrade? 
>>> I mean if will get slower than just querying spark
>>> 
>>> On Tue, 18 Jul, 2023, 10:43 pm Stephen Darlington, 
>>> mailto:stephen.darling...@gridgain.com>> 
>>> wrote:
>>>> Write through works regardless of how you insert data into Ignite.
>>>> 
>>>> I’m not clear what you mean by federated query. Are the records in Spark a 
>>>> subset of those in the cache?
>>>> 
>>>> Assuming not, create a data frame with a SQL query against Ignite. Create 
>>>> a data frame with a SQL query against your Spark data frame. Union 
>>>> together.
>>>> 
>>>> > On 13 Jul 2023, at 08:27, Arunima Barik >>> > <mailto:arunimabari...@gmail.com>> wrote:
>>>> > 
>>>> > Hello Team
>>>> > 
>>>> > I want to build a read write through Ignite cache over Spark
>>>> > 
>>>> > If I have 50 rows in the cache and entire 100 row data in spark then how 
>>>> > can I use federated queries? 
>>>> > 
>>>> > Also, how to perform write through using Sql queries? 
>>>> > 
>>>> > Regards
>>>> > Arunima
>>>> 
>> 

Re: Read Write through cache

[Stephen Darlington]

A more common approach would be that Ignite has all your data and Spark has a 
subset. Ignite SQL is generally faster than Spark SQL, since it can use 
indexes, etc. But it’s not magic; it can’t query data it doesn’t know about.

> On 19 Jul 2023, at 04:40, Arunima Barik  wrote:
> 
> How does write through work? I mean if I add a row in Ignite dataframe, how 
> does it reflect to spark? 
> 
> I have 50 rows in Ignite and all 100 rows in Spark. 
> If I perform a union all, wont the performance degrade? 
> I mean if will get slower than just querying spark
> 
> On Tue, 18 Jul, 2023, 10:43 pm Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> Write through works regardless of how you insert data into Ignite.
>> 
>> I’m not clear what you mean by federated query. Are the records in Spark a 
>> subset of those in the cache?
>> 
>> Assuming not, create a data frame with a SQL query against Ignite. Create a 
>> data frame with a SQL query against your Spark data frame. Union together.
>> 
>> > On 13 Jul 2023, at 08:27, Arunima Barik > > <mailto:arunimabari...@gmail.com>> wrote:
>> > 
>> > Hello Team
>> > 
>> > I want to build a read write through Ignite cache over Spark
>> > 
>> > If I have 50 rows in the cache and entire 100 row data in spark then how 
>> > can I use federated queries? 
>> > 
>> > Also, how to perform write through using Sql queries? 
>> > 
>> > Regards
>> > Arunima
>> 

Re: Ignite SQL

[Stephen Darlington]

Why you would have Ignite, a horizontally scalable, in-memory database, to 
store 100 records?

> On 19 Jul 2023, at 04:37, Arunima Barik  wrote:
> 
> I have a huge dataset and I am keeping few (say 100) rows in Ignite and the 
> entire dataset remains in Spark
> 
> When I query Ignite I want to write an Sql query to perform the same. 
> 
> Does option 1 still hold good? 
> 
> On Tue, 18 Jul, 2023, 10:40 pm Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> “Correct” is hard to quantify without knowing your use case, but option 1 is 
>> probably what you want. Spark pushes down SQL execution to Ignite, so you 
>> get all the distribution, use of indexes, etc. 
>> 
>> > On 14 Jul 2023, at 16:12, Arunima Barik > > <mailto:arunimabari...@gmail.com>> wrote:
>> > 
>> > Hello team
>> > 
>> > What is the correct way out of these? 
>> > 
>> > 1. Write a spark dataframe to ignite
>> > Read the same back and perform spark.sql() on that
>> > 
>> > 2. Write the spark dataframe to ignite
>> > Connect to server via a thin client
>> > Perform client.sql() 
>> > 
>> > Regards
>> > Arunima
>> 

Re: Read Write through cache

[Stephen Darlington]

Write through works regardless of how you insert data into Ignite.

I’m not clear what you mean by federated query. Are the records in Spark a 
subset of those in the cache?

Assuming not, create a data frame with a SQL query against Ignite. Create a 
data frame with a SQL query against your Spark data frame. Union together.

> On 13 Jul 2023, at 08:27, Arunima Barik  wrote:
> 
> Hello Team
> 
> I want to build a read write through Ignite cache over Spark
> 
> If I have 50 rows in the cache and entire 100 row data in spark then how can 
> I use federated queries? 
> 
> Also, how to perform write through using Sql queries? 
> 
> Regards
> Arunima

Re: Ignite SQL

[Stephen Darlington]

“Correct” is hard to quantify without knowing your use case, but option 1 is 
probably what you want. Spark pushes down SQL execution to Ignite, so you get 
all the distribution, use of indexes, etc. 

> On 14 Jul 2023, at 16:12, Arunima Barik  wrote:
> 
> Hello team
> 
> What is the correct way out of these? 
> 
> 1. Write a spark dataframe to ignite
> Read the same back and perform spark.sql() on that
> 
> 2. Write the spark dataframe to ignite
> Connect to server via a thin client
> Perform client.sql() 
> 
> Regards
> Arunima

Re: OOM

[Stephen Darlington]

https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning#java-heap-and-gc-tuning

> On 12 Jul 2023, at 17:29, Arunima Barik  wrote:
> 
> java.lang.OutOfMemory
> 
> On Wed, 12 Jul, 2023, 8:54 pm Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> Is it java.lang.OutOfMemoryException or an IgniteOutOfMemoryException?
>> 
>> > On 12 Jul 2023, at 16:19, Arunima Barik > > <mailto:arunimabari...@gmail.com>> wrote:
>> > 
>> > I have enabled Page eviction to Random-2-LRU for default region
>> > 
>> > Still whenever I write a big Spark DataFrame to Ignite 
>> > Like spark_df.write.format("ignite") 
>> > It is throwing Java OOM error
>> > 
>> > Why so.. Can anyone please tell me. 
>> > 
>> > Regards
>> > Arunima Barik
>> 

Re: OOM

[Stephen Darlington]

Is it java.lang.OutOfMemoryException or an IgniteOutOfMemoryException?

> On 12 Jul 2023, at 16:19, Arunima Barik  wrote:
> 
> I have enabled Page eviction to Random-2-LRU for default region
> 
> Still whenever I write a big Spark DataFrame to Ignite 
> Like spark_df.write.format("ignite") 
> It is throwing Java OOM error
> 
> Why so.. Can anyone please tell me. 
> 
> Regards
> Arunima Barik

Re: Increase in chattiness among server Ignite nodes after upgrade from 2.8 to 2.14

[Stephen Darlington]

How are you defining “chatty”?

> On 10 Jul 2023, at 13:33, kimec.ethome.sk  wrote:
> 
> Greetings,
> 
> we have recently upgraded Ignite server nodes from 2.8 to 2.14 and we see a 
> ten fold increase in cluster chattiness.
> Since 2.8 was quite old, I assume there may have been some announcement about 
> protocol changes but I could not find any info on my own.
> 
> Is this the expected behavior?
> 
> Kind regards,
> 
> Kamil

Re: Concurrently update some keys

[Stephen Darlington]

I think Gianluca gave you a great answer. What updates are you hoping for?

> On 5 Jul 2023, at 13:43, Ajay Babu  wrote:
> 
> Hello Team,
> 
> Any update here.
> 
> Thanks & Regards
> Ajay Babu Maguluri.
> 
> 
> On Thu, Mar 9, 2023 at 6:51 PM Ajay Babu  <mailto:ajay.b...@6dtech.co.in>> wrote:
>> Hello Team,
>> 
>> Any update?
>> 
>> Thanks & Regards
>> 
>> Ajay Babu Maguluri
>> 
>> 
>> On Fri, Jun 24, 2022 at 1:31 PM Gianluca Bonetti > <mailto:gianluca.bone...@gmail.com>> wrote:
>>> Hello
>>> 
>>> Unfortunately reiterating the question won't help.
>>> If you have no positive answer in days, it means there's no such features 
>>> in the making.
>>> Also this is a community-based mailing list, it's not a commercial support 
>>> service and there's no ETA for tickets, just best efforts from the Apache 
>>> Ignite team who is actually doing an amazing job with development and 
>>> support.
>>> 
>>> SQL transactions are still marked as beta, so you really shouldn't rely on 
>>> beta software for your work which seems to be urgent, and not even plan on 
>>> top of beta features.
>>> I think the focus is on the 3.0 release and features with lower user demand 
>>> will be postponed.
>>> Please remember free software is provided "as is" and with no guarantee of 
>>> "fitness for a particular purpose".
>>> 
>>> Your alternatives are...
>>> - switch to key/value approach (widely used, super fast, and rock solid)
>>> - if you have extra developer resources, contribute to development
>>> - get a support subscription from GridGain (I don't work for that company) 
>>> and push for developing that feature as a paying customer of the 
>>> commercially supported version
>>> - if you have a wealthy end customer you're developing for, ask them to 
>>> fund development by GridGain developers, extra developers of your own, or a 
>>> bountysource
>>> 
>>> I know I am not being particularly helpful on the specific topic, but I 
>>> just wanted to help in sorting out what options you have out there.
>>> 
>>> Thank you
>>> Cheers
>>> Gianluca
>>> 
>>> On Fri, 24 Jun 2022 at 08:14, Ajay Babu >> <mailto:ajay.b...@6dtech.co.in>> wrote:
>>>> Hello Team,
>>>> 
>>>> Please update.
>>>> Any roadmap will be  solved in upcoming releases.
>>>> In case of exception, if we want to re-try any specific exception type 
>>>> will throw, so that will catch and do the re-try specific case.
>>>> Br,
>>>> Ajay Babu Maguluri.
>>>> 
>>>> On Thu, Jun 23, 2022 at 11:56 AM Ajay Babu >>> <mailto:ajay.b...@6dtech.co.in>> wrote:
>>>>> Hello Team,
>>>>> 
>>>>> Please update.
>>>>> Any roadmap will be  solved in upcoming releases.
>>>>> In case of exception, if we want to re-try any specific exception type 
>>>>> will throw, so that will catch and do the re-try.
>>>>> Br,
>>>>> Ajay Babu Maguluri.
>>>>> 
>>>>> 
>>>>> On Wed, Jun 22, 2022 at 11:53 PM Ajay Babu >>>> <mailto:ajay.b...@6dtech.co.in>> wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Any roadmap will be  solved in upcoming releases.
>>>>>> 
>>>>>> Br
>>>>>> Ajay Babu Maguluri.
>>>>>> 
>>>>>> 
>>>>>> On Wed, Jun 22, 2022 at 11:34 PM Николай Ижиков >>>>> <mailto:nizhi...@apache.org>> wrote:
>>>>>>> Hello.
>>>>>>> 
>>>>>>> Ignite SQL is not transactional [1] [2]
>>>>>>> It seems this exception are expected.
>>>>>>> 
>>>>>>> For transactional updates [3] you should use key-value API.
>>>>>>> 
>>>>>>> [1] https://ignite.apache.org/docs/latest/sql-reference/transactions
>>>>>>> [2] https://ignite.apache.org/docs/latest/transactions/mvcc
>>>>>>> [3] https://ignite.apache.org/docs/latest/key-value-api/transactions
>>>>>>> 
>>>>>>>> 22 июня 2022 г., в 20:59, Ajay Babu >>>>>>> <mailto:ajay.b...@6dtech.co

Re: Starting Ignite Nodes

[Stephen Darlington]

You probably don’t want an Ignite server node on each of your Spark workers. 
When you connect to Ignite in your Spark code, it will automatically start up 
an Ignite thick-client node.

> On 3 Jul 2023, at 19:24, Arunima Barik  wrote:
> 
> Great
> Thanks for the suggestion
> 
> On Mon, 3 Jul, 2023, 11:23 pm Thomas Kramer,  > wrote:
>> Why can you then not do the same for the Ignite nodes? You create a 
>> start-ignite-nodes.sh script that has all the host addresses and then run a 
>> command like "ssh  start-ignite.sh" for all host ip addresses. 
>> This of course is most efficient if you have exchanged ssh keys between the 
>> servers so you don't need to login.
>> 
>> 
>> 
>> On 03.07.23 18:43, Arunima Barik wrote:
>>> We are not using Docker currently. 
>>> 
>>> The java implementation starts only 1 node right. I require many nodes and 
>>> that too on different hosts. 
>>> 
>>> Regarding how I start the Spark workers.. So I run the start-workers.sh 
>>> script and I have already defined all host addresses in workers config 
>>> file. 
>>> 
>>> On Mon, 3 Jul, 2023, 8:51 pm Gianluca Bonetti, >> > wrote:
 Hello Arunima
 
 I suppose you run Spark in containers so you can create a custom Docker 
 image to start Apache Ignite.
 
 You can also start the server nodes programmatically by Java code.
 
 Cheers
 Gianluca
 
 On Mon, 3 Jul 2023 at 16:03, Arunima Barik >>> > wrote:
> I have around 20 spark worker nodes running on different hosts
> 
> I need to start an Ignite node on every such spark worker 
> 
> I know that we can ssh into that host and run ignite.sh script to start 
> the node
> 
> Is there a simpler way to do so .. 
> Without having to ssh into 20 hosts manually?? 
> 
> Regards
> Arunima

Re: Ignite for Parquet files

[Stephen Darlington]

Ignite can use RDDs or DataFrames. If you’re using a DataFrame, that’s the way 
to do it. Depending on how you configure it, it will create or use an existing 
table/cache in Ignite.

> On 3 Jul 2023, at 13:31, Arunima Barik  wrote:
> 
> I am reading a parquet file using Spark dataframe as df
> 
> I want to write some part of this data to ignite cache 
> 
> Assume I want to write df2 to the cache
> 
> I used df2.write.format('ignite') 
> Is there a better way to do this or this is the only way?? 
> 
> Regards
> Arunima
> 
> On Mon, 3 Jul, 2023, 1:19 pm Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> Commercial options are available, but otherwise help would generally be 
>> limited to email lists and Stack Overflow.
>> 
>>> On 1 Jul 2023, at 06:59, Arunima Barik >> <mailto:arunimabari...@gmail.com>> wrote:
>>> 
>>> Are there any provisions wherein I can discuss about my project 
>>> implementation with someone from the Ignite team to clarify some doubts? 
>>> 
>>> Preferably through a small online meet? 
>>> 
>>> Regards
>>> Arunima
>>> 
>>> On Sat, 1 Jul, 2023, 12:03 am Jeremy McMillan, 
>>> mailto:jeremy.mcmil...@gridgain.com>> wrote:
>>>> Python doesn't at this time go anywhere near Ignite CacheStore. You would 
>>>> need to implement the CacheStore in Java or some other language which 
>>>> compiles to JVM runtime/jar. There's a talk from the most recent summit on 
>>>> using Groovy, if you want a higher level language than Java, but 
>>>> theoretically you could use Jython (if you are willing to experiment and 
>>>> can find a compatible JVM that runs both Ignite and Jython).
>>>> 
>>>> Ignite can operate like a federated query proxy if different caches are 
>>>> implemented with different external persistence for each cache. CacheStore 
>>>> is the interface Ignite would use to send a cache miss to a backend 
>>>> database. In your original question you intended to use Parquet files as a 
>>>> backend database, but Ignite does not (yet) provide one for Parquet. If 
>>>> someone were to donate a supportable Java implementation, I suspect the 
>>>> community would adopt and support it. Since Parquet is columnar, I also 
>>>> suspect it would need to target Ignite 3 to adopt conventions around 
>>>> columnar data, and then might be backported to Ignite 2.
>>>> 
>>>> 
>>>> On Fri, Jun 30, 2023 at 12:13 PM Arunima Barik >>> <mailto:arunimabari...@gmail.com>> wrote:
>>>>> Which do you think would be a better option? 
>>>>> 
>>>>> Federated queries or CacheStore
>>>>> 
>>>>> And is CacheStore supported in Python? 
>>>>> 
>>>>> On Fri, 30 Jun, 2023, 1:50 pm Stephen Darlington, 
>>>>> >>>> <mailto:stephen.darling...@gridgain.com>> wrote:
>>>>>> You’d need to implement your own Cache Store. 
>>>>>> https://ignite.apache.org/docs/latest/persistence/custom-cache-store
>>>>>> 
>>>>>>> On 30 Jun 2023, at 06:46, Arunima Barik >>>>>> <mailto:arunimabari...@gmail.com>> wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> -- Forwarded message -
>>>>>>> From: Arunima Barik >>>>>> <mailto:arunimabari...@gmail.com>>
>>>>>>> Date: Fri, 30 Jun, 2023, 10:52 am
>>>>>>> Subject: Ignite for Parquet files
>>>>>>> To: mailto:user@ignite.apache.org>>
>>>>>>> 
>>>>>>> 
>>>>>>> Hello Team
>>>>>>> 
>>>>>>> I have my data stored as parquet files. I want a caching layer on top 
>>>>>>> of this existing file system. I am going to use Ignite for that but I 
>>>>>>> do not need native persistence for that. 
>>>>>>> 
>>>>>>> I want that any changes to database should be reflected in both cache 
>>>>>>> and file. 
>>>>>>> And same for read queries. It should automatically read from disk if 
>>>>>>> data is not present in cache. 
>>>>>>> 
>>>>>>> I want to do all this is python. Please let me know how the same can be 
>>>>>>> done. 
>>>>>>> Resources if any as well. 
>>>>>>> 
>>>>>>> Thank you and looking forward to hearing from you. 
>>>>>>> 
>>>>>>> Regard, 
>>>>>>> Arunima Barik
>>>>>> 
>> 

Re: Ignite for Parquet files

[Stephen Darlington]

This is a community user forum where people are volunteering their time. I’m 
afraid you can’t expect immediate responses.

> On 4 Jul 2023, at 08:31, Arunima Barik  wrote:
> 
> Any updates on this please...
> 
> On Mon, 3 Jul 2023 at 18:01, Arunima Barik  <mailto:arunimabari...@gmail.com>> wrote:
>> I am reading a parquet file using Spark dataframe as df
>> 
>> I want to write some part of this data to ignite cache 
>> 
>> Assume I want to write df2 to the cache
>> 
>> I used df2.write.format('ignite') 
>> Is there a better way to do this or this is the only way?? 
>> 
>> Regards
>> Arunima
>> 
>> On Mon, 3 Jul, 2023, 1:19 pm Stephen Darlington, 
>> mailto:stephen.darling...@gridgain.com>> 
>> wrote:
>>> Commercial options are available, but otherwise help would generally be 
>>> limited to email lists and Stack Overflow.
>>> 
>>>> On 1 Jul 2023, at 06:59, Arunima Barik >>> <mailto:arunimabari...@gmail.com>> wrote:
>>>> 
>>>> Are there any provisions wherein I can discuss about my project 
>>>> implementation with someone from the Ignite team to clarify some doubts? 
>>>> 
>>>> Preferably through a small online meet? 
>>>> 
>>>> Regards
>>>> Arunima
>>>> 
>>>> On Sat, 1 Jul, 2023, 12:03 am Jeremy McMillan, 
>>>> mailto:jeremy.mcmil...@gridgain.com>> wrote:
>>>>> Python doesn't at this time go anywhere near Ignite CacheStore. You would 
>>>>> need to implement the CacheStore in Java or some other language which 
>>>>> compiles to JVM runtime/jar. There's a talk from the most recent summit 
>>>>> on using Groovy, if you want a higher level language than Java, but 
>>>>> theoretically you could use Jython (if you are willing to experiment and 
>>>>> can find a compatible JVM that runs both Ignite and Jython).
>>>>> 
>>>>> Ignite can operate like a federated query proxy if different caches are 
>>>>> implemented with different external persistence for each cache. 
>>>>> CacheStore is the interface Ignite would use to send a cache miss to a 
>>>>> backend database. In your original question you intended to use Parquet 
>>>>> files as a backend database, but Ignite does not (yet) provide one for 
>>>>> Parquet. If someone were to donate a supportable Java implementation, I 
>>>>> suspect the community would adopt and support it. Since Parquet is 
>>>>> columnar, I also suspect it would need to target Ignite 3 to adopt 
>>>>> conventions around columnar data, and then might be backported to Ignite 
>>>>> 2.
>>>>> 
>>>>> 
>>>>> On Fri, Jun 30, 2023 at 12:13 PM Arunima Barik >>>> <mailto:arunimabari...@gmail.com>> wrote:
>>>>>> Which do you think would be a better option? 
>>>>>> 
>>>>>> Federated queries or CacheStore
>>>>>> 
>>>>>> And is CacheStore supported in Python? 
>>>>>> 
>>>>>> On Fri, 30 Jun, 2023, 1:50 pm Stephen Darlington, 
>>>>>> >>>>> <mailto:stephen.darling...@gridgain.com>> wrote:
>>>>>>> You’d need to implement your own Cache Store. 
>>>>>>> https://ignite.apache.org/docs/latest/persistence/custom-cache-store
>>>>>>> 
>>>>>>>> On 30 Jun 2023, at 06:46, Arunima Barik >>>>>>> <mailto:arunimabari...@gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -- Forwarded message -
>>>>>>>> From: Arunima Barik >>>>>>> <mailto:arunimabari...@gmail.com>>
>>>>>>>> Date: Fri, 30 Jun, 2023, 10:52 am
>>>>>>>> Subject: Ignite for Parquet files
>>>>>>>> To: mailto:user@ignite.apache.org>>
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Hello Team
>>>>>>>> 
>>>>>>>> I have my data stored as parquet files. I want a caching layer on top 
>>>>>>>> of this existing file system. I am going to use Ignite for that but I 
>>>>>>>> do not need native persistence for that. 
>>>>>>>> 
>>>>>>>> I want that any changes to database should be reflected in both cache 
>>>>>>>> and file. 
>>>>>>>> And same for read queries. It should automatically read from disk if 
>>>>>>>> data is not present in cache. 
>>>>>>>> 
>>>>>>>> I want to do all this is python. Please let me know how the same can 
>>>>>>>> be done. 
>>>>>>>> Resources if any as well. 
>>>>>>>> 
>>>>>>>> Thank you and looking forward to hearing from you. 
>>>>>>>> 
>>>>>>>> Regard, 
>>>>>>>> Arunima Barik
>>>>>>> 
>>> 

Re: Ignite Cache - Eviction policy

[Stephen Darlington]

https://ignite.apache.org/docs/2.11.1/memory-configuration/eviction-policies

> On 3 Jul 2023, at 13:38, Arunima Barik  wrote:
> 
> I am reading a parquet file using spark into ignite
> 
> 1. For every sql query, suppose I write a part of the data to the ignite cache
> In this manner, the cache fills up
> 
> Now when I put new data into the cache, how will the old data be removed ( 
> LRU, FIFO etc.) 
> Or do I manually need to disable the same? 
> 
> 2. If such cache eviction policies work, then how will I come to know whether 
> required data is still present in cache or not... 
> 
> Regards
> Arunima

Re: Kafka > Ignite via Kafka Connect

[Stephen Darlington]

Can you include the stack trace rather than a screenshot? We can’t see which 
class appears to be missing.

> On 2 Jul 2023, at 17:04, Tama MA  wrote:
> 
> Hi Ignite community,
> 
> Per instructed by Ignite documentation (Streaming Data via Kafka Connect)
> https://ignite.apache.org/docs/latest/extensions-and-integrations/streaming/kafka-streamer
> 
> 0) My versions are:
> - Apache Ignite 2.15.0
> - Apache Kafka 3.4.1
> 
> 1) I downloaded the JAR - org.apache.ignite:ignite-kafka-ext:1.0.0.  
> (compiled against Ignite 2.9.x)
> 2) I added this to kafka-connect properties file:
> 
> plugin.path=libs/connect-file-3.4.1.jar,/home/tamama/.m2/repository/org/apache/ignite/ignite-kafka-ext/ignite-kafka-ext-1.0.0.jar
> 
> 
> 3) As usual, I apply Kafka Connect
> 
> 
> PUT /connectors/gnite-sink-toto-1/config
> {
>   "name": "ignite-sink-toto-1",
>   "connector.class": 
> "org.apache.ignite.stream.kafka.connect.IgniteSinkConnector",
>   "tasks.max": 1,
>   "topics": "nginx__access__private_tamama_io",
>   "cacheName": "toto-tamama-1",
>   "cacheAllowOverwrite": true,
>   "igniteCfg": 
> "/home/tamama/.tamama/etc/kafka/connect/ignite-sink/ignite-rsyslog-ignite-47500.xml"
> }
> 
> 
> 4) This crashes:
> 
> 
> 
> 
> Questions?
> 
> Q1) It seems to me that Ignite is discontinuing on Kafka integration efforts. 
> May I ask if this is generally true?
>   - Maybe in this case, we could remove the extension in the 
> documentation, as this would confuse the users?
> 
> Q2) If this were to be made to work, I believe that we need to A) compile the 
> source code (ignite-kafka-ext) against latest  ignite-core:2.15, B) compile 
> into a fat-jar. (Uber-jar).   Otherwise, I would need to use CLASSPATH which 
> would be a bit in a mess…. ?
> 
> However, if the general consensus is to stay away from Ignite-Kafka, I would 
> be glad to accept this too. :)
> 
> Kind regards,
> Tama MA

Re: Apache Ignite Cache layer

[Stephen Darlington]

A quick search came up with this: 
https://www.arm64.ca/post/reading-parquet-files-java/

Data is generally bulk loaded in the loadCache implementation. Which data is 
loaded would depend on your implementation.

> On 1 Jul 2023, at 13:11, Arunima Barik  wrote:
> 
> Hello Team
> 
> I wish to create a cache layer over an existing parquet database. Some doubts 
> regarding the same -
> 
> 1) How to read the parquet file into Ignite - Spark or something else
> 
> 2) While implementing the CacheStore interface for this, how to load a part 
> of data to the cache.
> Will it be done automatically or it has to be coded explicitly
> 
> Regards
> Arunima

Re: Ignite for Parquet files

[Stephen Darlington]

Commercial options are available, but otherwise help would generally be limited 
to email lists and Stack Overflow.

> On 1 Jul 2023, at 06:59, Arunima Barik  wrote:
> 
> Are there any provisions wherein I can discuss about my project 
> implementation with someone from the Ignite team to clarify some doubts? 
> 
> Preferably through a small online meet? 
> 
> Regards
> Arunima
> 
> On Sat, 1 Jul, 2023, 12:03 am Jeremy McMillan,  <mailto:jeremy.mcmil...@gridgain.com>> wrote:
>> Python doesn't at this time go anywhere near Ignite CacheStore. You would 
>> need to implement the CacheStore in Java or some other language which 
>> compiles to JVM runtime/jar. There's a talk from the most recent summit on 
>> using Groovy, if you want a higher level language than Java, but 
>> theoretically you could use Jython (if you are willing to experiment and can 
>> find a compatible JVM that runs both Ignite and Jython).
>> 
>> Ignite can operate like a federated query proxy if different caches are 
>> implemented with different external persistence for each cache. CacheStore 
>> is the interface Ignite would use to send a cache miss to a backend 
>> database. In your original question you intended to use Parquet files as a 
>> backend database, but Ignite does not (yet) provide one for Parquet. If 
>> someone were to donate a supportable Java implementation, I suspect the 
>> community would adopt and support it. Since Parquet is columnar, I also 
>> suspect it would need to target Ignite 3 to adopt conventions around 
>> columnar data, and then might be backported to Ignite 2.
>> 
>> 
>> On Fri, Jun 30, 2023 at 12:13 PM Arunima Barik > <mailto:arunimabari...@gmail.com>> wrote:
>>> Which do you think would be a better option? 
>>> 
>>> Federated queries or CacheStore
>>> 
>>> And is CacheStore supported in Python? 
>>> 
>>> On Fri, 30 Jun, 2023, 1:50 pm Stephen Darlington, 
>>> mailto:stephen.darling...@gridgain.com>> 
>>> wrote:
>>>> You’d need to implement your own Cache Store. 
>>>> https://ignite.apache.org/docs/latest/persistence/custom-cache-store
>>>> 
>>>>> On 30 Jun 2023, at 06:46, Arunima Barik >>>> <mailto:arunimabari...@gmail.com>> wrote:
>>>>> 
>>>>> 
>>>>> -- Forwarded message -
>>>>> From: Arunima Barik >>>> <mailto:arunimabari...@gmail.com>>
>>>>> Date: Fri, 30 Jun, 2023, 10:52 am
>>>>> Subject: Ignite for Parquet files
>>>>> To: mailto:user@ignite.apache.org>>
>>>>> 
>>>>> 
>>>>> Hello Team
>>>>> 
>>>>> I have my data stored as parquet files. I want a caching layer on top of 
>>>>> this existing file system. I am going to use Ignite for that but I do not 
>>>>> need native persistence for that. 
>>>>> 
>>>>> I want that any changes to database should be reflected in both cache and 
>>>>> file. 
>>>>> And same for read queries. It should automatically read from disk if data 
>>>>> is not present in cache. 
>>>>> 
>>>>> I want to do all this is python. Please let me know how the same can be 
>>>>> done. 
>>>>> Resources if any as well. 
>>>>> 
>>>>> Thank you and looking forward to hearing from you. 
>>>>> 
>>>>> Regard, 
>>>>> Arunima Barik
>>>> 

Re: SetLoacl is not work for Calcite

[Stephen Darlington]

I’m curious: why did you switch to Calcite if your deployment is in production? 
I would generally be cautious about putting beta software into production. Was 
there some critical feature that you needed? 

> On 30 Jun 2023, at 09:34, y  wrote:
> 
> Thanks for your suggestion. We are considering the feasibility of your 
> proposed solution. For complex business production environments, it is 
> difficult to distinguish whether the query requires setLocal or not. Anyway, 
> thank you for your help. 
> 
> 
> 
> 
> At 2023-06-30 15:18:07, "Stephen Darlington" 
>  wrote:
> 
> If this is an important feature for you, the obvious solution would be to use 
> the H2 SQL engine (which is still the default, since the Calcite engine is 
> still considered beta).
> 
> As noted in the documentation, you can even keep Calcite as the default 
> engine in your cluster and only route these queries to H2. 
> https://ignite.apache.org/docs/latest/SQL/sql-calcite#query_engine-hint
> 
>> On 30 Jun 2023, at 03:50, y  wrote:
>> 
>> Hello.
>>I'm sorry for it took so long time to reply to the message duing to I 
>> missed some messages. For example, I have multiple nodes performing the same 
>> computational tasks. The cache mode is  partition and the data is cached by 
>> affinity_key. So the different nodes have different data and node only 
>> query/calculate data from itself. If there is no setLocal, the node will 
>> query data from other nodes, which is inefficient.  That's why i need 
>> setLocal. What should I do if without setLocal?
>> 
>> 
>> 
>> Yours,
>> Hu Tiany
>> 2023/6/30
>> 
>> At 2023-06-05 19:21:13, "Alex Plehanov"  wrote:
>> >Hello,
>> >
>> >The Calcite-based SQL engine currently doesn't analyze any properties
>> >of SqlFieldsQuery except "Sql", "Schema", "Args" and
>> >"QueryInitiatorId". Some of the rest properties are useless for the
>> >Calcite-based engine at all (for example, "DistributedJoins", since
>> >all joins in the Calcite-based engine are distributed by default if
>> >needed). But, perhaps, others can be useful. If you are really sure
>> >that the "Local" property is necessary for the new SQL engine, feel
>> >free to create a ticket and describe the reason why we need it.
>> >
>> >пн, 5 июн. 2023 г. в 12:05, y :
>> >>
>> >> Hello igniters,
>> >>  Just like the title, setLocal seems invalid for Calcite 2.15. When I set 
>> >> ‘setLocal = true’ and query data from one node, the result sets is 
>> >> returned from all data nodes.  This problem is not present in version 
>> >> 2.13 ，which not use Calcite. I'd like to know is this an error? If yes it 
>> >> is, When will it be fixed?
>> >>
>> >> SqlFieldsQuery fieldsQuery = new SqlFieldsQuery(query);
>> >> fieldsQuery.setLocal(true);   // uneffective for this line
>> >> List> rs = 
>> >> ignite.cache("bfaccounttitle2020").query(fieldsQuery).getAll();
>> >>
>> >>
> 

Re: Ignite for Parquet files

[Stephen Darlington]

You’d need to implement your own Cache Store. 
https://ignite.apache.org/docs/latest/persistence/custom-cache-store

> On 30 Jun 2023, at 06:46, Arunima Barik  wrote:
> 
> 
> -- Forwarded message -
> From: Arunima Barik  >
> Date: Fri, 30 Jun, 2023, 10:52 am
> Subject: Ignite for Parquet files
> To: mailto:user@ignite.apache.org>>
> 
> 
> Hello Team
> 
> I have my data stored as parquet files. I want a caching layer on top of this 
> existing file system. I am going to use Ignite for that but I do not need 
> native persistence for that. 
> 
> I want that any changes to database should be reflected in both cache and 
> file. 
> And same for read queries. It should automatically read from disk if data is 
> not present in cache. 
> 
> I want to do all this is python. Please let me know how the same can be done. 
> Resources if any as well. 
> 
> Thank you and looking forward to hearing from you. 
> 
> Regard, 
> Arunima Barik

Re: SetLoacl is not work for Calcite

[Stephen Darlington]

If this is an important feature for you, the obvious solution would be to use 
the H2 SQL engine (which is still the default, since the Calcite engine is 
still considered beta).

As noted in the documentation, you can even keep Calcite as the default engine 
in your cluster and only route these queries to H2. 
https://ignite.apache.org/docs/latest/SQL/sql-calcite#query_engine-hint

> On 30 Jun 2023, at 03:50, y  wrote:
> 
> Hello.
>I'm sorry for it took so long time to reply to the message duing to I 
> missed some messages. For example, I have multiple nodes performing the same 
> computational tasks. The cache mode is  partition and the data is cached by 
> affinity_key. So the different nodes have different data and node only 
> query/calculate data from itself. If there is no setLocal, the node will 
> query data from other nodes, which is inefficient.  That's why i need 
> setLocal. What should I do if without setLocal?
> 
> 
> 
> Yours,
> Hu Tiany
> 2023/6/30
> 
> At 2023-06-05 19:21:13, "Alex Plehanov"  wrote:
> >Hello,
> >
> >The Calcite-based SQL engine currently doesn't analyze any properties
> >of SqlFieldsQuery except "Sql", "Schema", "Args" and
> >"QueryInitiatorId". Some of the rest properties are useless for the
> >Calcite-based engine at all (for example, "DistributedJoins", since
> >all joins in the Calcite-based engine are distributed by default if
> >needed). But, perhaps, others can be useful. If you are really sure
> >that the "Local" property is necessary for the new SQL engine, feel
> >free to create a ticket and describe the reason why we need it.
> >
> >пн, 5 июн. 2023 г. в 12:05, y :
> >>
> >> Hello igniters,
> >>  Just like the title, setLocal seems invalid for Calcite 2.15. When I set 
> >> ‘setLocal = true’ and query data from one node, the result sets is 
> >> returned from all data nodes.  This problem is not present in version 2.13 
> >> ，which not use Calcite. I'd like to know is this an error? If yes it is, 
> >> When will it be fixed?
> >>
> >> SqlFieldsQuery fieldsQuery = new SqlFieldsQuery(query);
> >> fieldsQuery.setLocal(true);   // uneffective for this line
> >> List> rs = 
> >> ignite.cache("bfaccounttitle2020").query(fieldsQuery).getAll();
> >>
> >>

Re: failureDetectionTimeout Timeout Issues

[Stephen Darlington]

Increasing timeouts is not a good solution for GC pauses. Better to avoid the 
pauses. There are a lot of recommendations in the documentation: 
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning

> On 19 Jun 2023, at 23:36, Alan Rose  wrote:
> 
> We believe GC
> 
> On Mon, 19 Jun 2023 at 21:23, Stephen Darlington 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> Well, is it a garbage collection pause or is it a network glitch? The 
>> solutions for each are different.
>> 
>> > On 19 Jun 2023, at 09:27, Alan Rose > > <mailto:alanjrose...@gmail.com>> wrote:
>> > 
>> > We have been experiencing timeout lately possibly due to GC (or network) 
>> > on our Lynx pods. Our timeouts are at the standard default values 
>> > clientFailureDetectionTimeout=3 and failureDetectionTimeout=1
>> > Has anyone else had similar issues and can recommend what we should set 
>> > these settings to. Thanks in advance
>> 

Re: failureDetectionTimeout Timeout Issues

[Stephen Darlington]

Well, is it a garbage collection pause or is it a network glitch? The solutions 
for each are different.

> On 19 Jun 2023, at 09:27, Alan Rose  wrote:
> 
> We have been experiencing timeout lately possibly due to GC (or network) on 
> our Lynx pods. Our timeouts are at the standard default values 
> clientFailureDetectionTimeout=3 and failureDetectionTimeout=1
> Has anyone else had similar issues and can recommend what we should set these 
> settings to. Thanks in advance

Re: How communication happens when using Multicast + Static IP finder

[Stephen Darlington]

Multicast is only used for node discovery. If you update a cache, run a SQL 
query or execute a compute task, that uses the “communications SPI” which is a 
direct TCP connection between nodes.

> On 18 Jun 2023, at 15:24, Vikas Vishwakarma  wrote:
> 
> Hi All,
> 
> I was wondering when using Multicast + Static IP finder, how communication 
> about cache update happens, is it unicast or multicast and what all 
> communication happen over multicast group and if there's any unicast 
> communication then what all communication using unicast.
> 
> Thank you

Re: Ignite compression not working on windows

[Stephen Darlington]

I would believe the error message. It’s pretty clear and explicit. Maybe you 
can leave some feedback on the documentation (there’s a button on the bottom 
right of each page).

> On 19 Jun 2023, at 09:32, Rohan Sharma via user  
> wrote:
> 
> I am trying to user apache ignite disk compression on windows for a cache 
> with disk persistence ON but it fails with below error -
> 
> Caused by: class org.apache.ignite.IgniteCheckedException: Currently page 
> compression is supported only for Linux. at 
> org.apache.ignite.internal.processors.compress.CompressionProcessorImpl.checkPageCompressionSupported(CompressionProcessorImpl.java:76)
> 
> I am following steps mentioned on the page - 
> https://ignite.apache.org/docs/latest/persistence/disk-compression#:~:text=Disk%20compression%20refers%20to%20the,compressed%20using%20the%20configured%20algorithm
>  
> .
> 
> No where in the ignite documentation says that it is NOT supported on Windows.
> 
> Is it supported on windows?
> 
> I want to reduce the disk storage for a particular cache that will be holding 
> large amount of data, any other way possible if compression doesn't work?
> 
> 
> Thanks 
> Rohan Sharma

Re: .NET Ignite server nodes not joining cluster using TcpDiscoveryStaticIpFinder

[Stephen Darlington]

Just a reminder that this is a community forum. People are very generous with 
their time, but it’s not fair to expect immediate responses to your questions.

> On 9 May 2023, at 06:18, satyajit.mandal.barclays.com via user 
>  wrote:
> 
> Hi  Team,
>  
> Issue  is  fixed.  There was  issue  with  my TcpDiscoveryStaticIpFinder  
> setup.
>  
> Regards
> Satyajit
>  
> From: satyajit.mandal.barclays.com  via 
> user mailto:user@ignite.apache.org>> 
> Sent: Tuesday, May 9, 2023 10:05 AM
> To: user@ignite.apache.org 
> Subject: RE: .NET Ignite server nodes not joining cluster using 
> TcpDiscoveryStaticIpFinder
>  
> CAUTION: This email originated from outside our organisation - 
> user@ignite.apache.org  Do not click on links, 
> open attachments, or respond unless you recognize the sender and can validate 
> the content is safe.
> 
> Hi Team,
>  
> Any  idea  why  this  TCP connection  error  happening.  We  haven’t  seen  
> these errors  while running  Ignite from  Java binaries.  This  is first  
> time we are running  from  binaries  generated  from  .NET nuget package and  
> hosting  Ignite as  webApi  service  ( .NET server  node).
> The  second  node  when  we  start  it  starts  giving  TCP  errors .  
> However  looking at  the  logs  it  seems  cluster  is getting  formed but  
> this  error  keeps coming  back.
>  
> Have seen  some similar  post where second  node  using  static  ip  is  not  
> able  to join  the cluster  and  throwing  errors.
>  
> https://stackoverflow.com/questions/46065368/apache-ignite-net-server-node-hangs-on-start
>  
> 
>  
>  
> Regards
> Satyajit
>  
>  
> From: Mandal, Satyajit: IT (PUN) 
> Sent: Monday, May 8, 2023 8:41 PM
> To: 'user@ignite.apache.org'  >; 'ptupit...@apache.org' 
> mailto:ptupit...@apache.org>>
> Subject: RE: .NET Ignite server nodes not joining cluster using 
> TcpDiscoveryStaticIpFinder
>  
> Hi  Pavel,
>  
> We are seeing  lot  of  interim TCP communication  errors  and  node leaving  
> and  joining  the  cluster when  we  hosted  Ignite  as  WebApi  service. Its 
>  rejoining immediately.
>  
> Can  we  conclude  that  this  could  be  because  Ignite  is embedded with 
> .NET  host ?
>  
> [15:44:18,930][SEVERE][exchange-worker-#46%ignite-instance-0612556c-26f7-4f30-b224-cc85a4e80e3f%][diagnostic]
>  Failed to send diagnostic message: class o.a.i.IgniteCheckedException: 
> Failed to send message (node may have left the grid or TCP connection cannot 
> be established due to firewall issues) [node=TcpDiscoveryNode 
> [id=aba2e264-40e4-4281-9c20-b4b2c86b9a72, consistentId=10.115.179.174:47500, 
> addrs=ArrayList [10.115.179.174], sockAddrs=HashSet 
> [GBRPSM030001102.INTRANET.BARCAPINT.com/10.115.179.174:47500], 
> discPort=47500, order=2, intOrder=2, lastExchangeTime=1683555768564, 
> loc=false, ver=2.14.0#20220929-sha1:951e8deb, isClient=false], 
> topic=TOPIC_INTERNAL_DIAGNOSTIC, msg=IgniteDiagnosticMessage [flags=1, 
> futId=7], policy=2]
> [15:44:18,931][INFO][grid-nio-worker-tcp-comm-3-#26%TcpCommunicationSpi%][diagnostic]
>  Exchange future on coordinator waiting for server response 
> [node=aba2e264-40e4-4281-9c20-b4b2c86b9a72, topVer=AffinityTopologyVersion 
> [topVer=2, minorTopVer=0]]
>  
> Regards
> Satyajit
>  
>  
>  
>  
>  
>  
> From: Mandal, Satyajit: IT (PUN) 
> Sent: Sunday, May 7, 2023 5:19 PM
> To: user@ignite.apache.org ; Mandal, Satyajit: 
> IT (PUN)  >;ptupit...@apache.org 
> 
> Subject: .NET Ignite server nodes not joining cluster using 
> TcpDiscoveryStaticIpFinder
>  
> Hi  Pavel/Team,
>  
> Issue  is  resolved  and  cluster  is  getting  formed.  I corrected  the  
> TCPDiscoverySpi  code  and  it  worked.In  LocalAddresses provided  local 
> node IP  and  under  TcpDiscoveryStaticIpFinder  added  remote  node IP  and  
> current  IP.
>  
> Regards
> Satyajit
>  
>  
>  
> From: satyajit.mandal.barclays.com via user  > 
> Sent: Saturday, May 6, 2023 8:42 PM
> To: user@ignite.apache.org ; 
> ptupit...@apache.org 
> Subject: RE: .NET Ignite server nodes not joining cluster using 
> TcpDiscoveryStaticIpFinder
>  
> CAUTION: This email originated from outside our organisation - 
> user@ignite.apache.org  Do not click on links, 
> open attachments, or respond unless you recognize the sender and can validate 
> the content is safe.
> 
> Hi  Pavel/Team,
>  
> I  tried  to  remove  the Spring.xml  and  wrote everything  using  Ignite 
> .NET Api. Looks  like  TcpDiscoveryStaticIpFinder  is 

Re: Failed to parse query SQL table not found issue

[Stephen Darlington]

You need to find out what the problem is before anyone can make a 
recommendation. Why are your nodes restarting?

> On 26 Apr 2023, at 12:34, Abhishek Ubhe  wrote:
> 
> Ok,
> I will remove the backup configuration setting of cache. But about you said,
> 
> In the case of in-memory cluster, simultaneous restart of all nodes
> could be a reason. Also, you could look for the log messages about
> changing of cluster topology and errors.
> 
> For the above case, what do you suggest I should do?
> 
> On Wed, Apr 26, 2023 at 4:23 PM Ilya Shishkov  <mailto:shishkovi...@gmail.com>> wrote:
>> > Is this maybe the case? This policy of K8s cause the loss of cache sql 
>> > tables?
>> 
>> In the case of in-memory cluster, simultaneous restart of all nodes
>> could be a reason. Also, you could look for the log messages about
>> changing of cluster topology and errors.
>> 
>> As I see from the attached picture, you start Ignite embedded into the
>> code, but it is unclear how you get the 'null' value for the ignite
>> variable. Also, for replicated cache you should not set backups
>> number, because all partitions of replicated cache are stored in each
>> node of the cluster.
>> 
>> 
>> ср, 26 апр. 2023 г. в 12:55, Abhishek Ubhe > <mailto:abhishekubhe0...@gmail.com>>:
>> >
>> > Hello,
>> >
>> > What is Ignite shell? Sqlline?  - > Yes sqlline.
>> >
>> > It looks like all cluster nodes have failed or restarted. - > May be 
>> > because K8s pods are getting restarted as per container restart policy.
>> >
>> > Is this maybe the case? This policy of K8s cause the loss of cache sql 
>> > tables?
>> >
>> >
>> > How do you get "instance of Ignite"? ->
>> >
>> >
>> >
>> >
>> > On Wed, Apr 26, 2023 at 2:40 PM Ilya Shishkov > > <mailto:shishkovi...@gmail.com>> wrote:
>> >>
>> >> Hi,
>> >>
>> >>
>> >>> After some days, I was unable to see the created cache on the Ignite 
>> >>> shell which I have created and was able to see at first when node 
>> >>> started properly.
>> >>
>> >>
>> >> What is Ignite shell? Sqlline?
>> >>
>> >>
>> >>> Now I am getting a table not found exception from API request for 
>> >>> fetching using ignite sql query.
>> >>
>> >>
>> >> It looks like all cluster nodes have failed or restarted.
>> >>
>> >>
>> >>> I am getting a null instance of ignite. I assume that I am unable to 
>> >>> connect to the live instance running on that node.
>> >>
>> >>
>> >> How do you get "instance of Ignite"?
>> >>
>> >> Have you deployed the nodes as described in these instructions [1-3]?
>> >>
>> >> https://ignite.apache.org/docs/latest/installation/kubernetes/amazon-eks-deployment.html
>> >> https://ignite.apache.org/docs/latest/installation/kubernetes/azure-deployment.html
>> >> https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html
>> >>
>> >>
>> >>
>> >> ср, 26 апр. 2023 г. в 09:42, Abhishek Ubhe > >> <mailto:abhishekubhe0...@gmail.com>>:
>> >>>
>> >>> Hello Stephen,
>> >>>
>> >>> I did try changes you suggested above and I did get output. Thanks for 
>> >>> that.
>> >>>
>> >>> But I am facing a different issue in meantime on my microservice which 
>> >>> have following setup :
>> >>>
>> >>> I have set up a kubernetes pod cluster where I have started 3 ignite 
>> >>> nodes and deployed k8s pods using -java commands.
>> >>> In that routine after node started, I created the above CacheTable on 
>> >>> the node and loaded data from hbase into the cache.table.
>> >>> After some days, I was unable to see the created cache on the Ignite 
>> >>> shell which I have created and was able to see at first when node 
>> >>> started properly.
>> >>> Now I am getting a table not found exception from API request for 
>> >>> fetching using ignite sql query.
>> >>> And also I tried to  recreate the same cache using a regular java API 
>> >>> script and run on that K8s pod where ignite is running
>> >>>

Re: Failed to parse query SQL table not found issue

[Stephen Darlington]

In sqlline, you can type “!tables” (no quotes) to list all the tables. In 
general, the schema is the cache name and the table is the value type name, so 
you would need to write "select * from CACHE_NAME.HbaseTableType".

> On 20 Apr 2023, at 06:38, Abhishek Ubhe  wrote:
> 
> Hello,
> 
> I am facing the issue as below : 
> I have created an ignite cache SQL table through java API.
> Data loaded from HBase in the table after creating it.(loading means just 
> fetched and inserted in ignite).
> Now when I was trying to fetch data from the sql table I created I am getting 
> Failed to parse query and table not found exception.
> For more confirmation I connected to the ignite shell and checked the list of 
> tables. I get the above created table in the list. I can see it exactly 
> created there by the same name.
> But when I fire my query on the table I get Error of failing to parse the 
> query and Table not found.
> I did not understand the above scenario. Please help me with this issue. 
> Please check out the attached screenshot for reference.
> 
> 
> -- 
> Regards,
> Abhishek Ubhe
> 
> 

Re: JVM pause on Ignite kernal

[Stephen Darlington]

It means that no Ignite code is being executed for that time. It’s not possible 
to say exactly why this was the case, but the most common cause is incorrect 
Java garbage collection configuration. See the documentation for more details: 
https://ignite.apache.org/docs/latest/perf-and-troubleshooting/memory-tuning

Regards,
Stephen

> On 17 Apr 2023, at 06:32, Abhishek Ubhe  wrote:
> 
> Hello,
> 
> Getting below log often times on a ignite node which runs as a microservice 
> deployed on Kubernetes pod.
> 
> org.apache.ignite.internal.IgniteKernal - Possible too long JVM pause: 803 
> milliseconds.
> I need to know when this log was printed and why?
> What should I do to avoid it?
> How monitor these nodes/ services to prevent JVM pause for future?
> 
> 
> 
> -- 
> Regards,
> Abhishek Ubhe
> 

Re: Ignite: Failed to process failed message: java.lang.NullPointerException

[Stephen Darlington]

If you have a problem with GridGain, you should ask them for support. Please 
let us know if you can reproduce in a recent version of Ignite.

> On 4 Apr 2023, at 03:10, 周倩  wrote:
> 
> Hi,
> I have a question while using gridgain 8.8.9.
> Problem scenario: The Ignite server of a node. Start a standard client, 
> create a Table, and continuously insert data into the Table using the Insert 
> statement. At the same time as inserting data, another standard client 
> started and deleted the table. 
> Problem phenomenon: The program executing the Insert statement operation is 
> stuck and there are no error returns.  
> Error content: This error may not necessarily occur, but there are two 
> possible scenarios: 
> 1.The first scenario: Most of the time, programs executing Insert statements 
> will report the following error: 
> Exception in thread "main" javax.cache.CacheException: Failed to execute DML 
> statement [stmt=INSERT INTO PRODUCT (ID, NAME, PRODUCTCODE, DISTRICT, NUMBER) 
> VALUES (?, ?, ?, ?, ?);, params=[52043, product52043, p52043, a product, 
> 100]] at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:829)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:762)
>  at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:385)
>  at com.example.batchkazhu2.example.Example01.main(Example01.java:32) Caused 
> by: class org.apache.ignite.internal.processors.query.IgniteSQLException: 
> Failed to execute DML statement [stmt=INSERT INTO PRODUCT (ID, NAME, 
> PRODUCTCODE, DISTRICT, NUMBER) VALUES (?, ?, ?, ?, ?);, params=[52043, 
> product52043, p52043, a product, 100]] at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1356)
>  at 
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1231)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2877)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2873)
>  at 
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:35)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3425)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:2893)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:2931)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2867)
>  at 
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2794)
>  at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:814)
>  ... 3 more Caused by: class 
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
>  Failed to update keys (retry update if possible).: [52043] at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:420)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:257)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3168)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:151)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:305)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:300)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1150)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1725)
>  at 
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager

Re: Key1 equals Key2 but not found in cache

[Stephen Darlington]

You can make any column visible in SQL.

> On 22 Mar 2023, at 15:34, Humphrey Lopez  wrote:
> 
> Can we query the keys as well? Adding QuerySqlField? I think this only 
> applies to the values right?
> 
> Op wo 22 mrt 2023 om 16:08 schreef Stephen Darlington 
> mailto:stephen.darling...@gridgain.com>>:
>> You don’t want to look through all the keys. That’s why Ignite has SQL.
>> 
>>> On 22 Mar 2023, at 14:44, Humphrey Lopez >> <mailto:hmmlo...@gmail.com>> wrote:
>>> 
>>> We have FAT keys that contain information about the Values we store. 
>>> KEY
>>> - Object A
>>> - Object B
>>> 
>>> VALUE
>>> - Object Y
>>> 
>>> The KEY we are using contains several (small) objects as fields. We have 
>>> added to Object A a new field A.TYPE so when searching through the cache we 
>>> could filter on that type.
>>> I guess we will need to first get all the keys that match that A.TYPE and 
>>> then get the objects with those objects, I think looping through the keys 
>>> will be quicker than looping through all the values. 
>>> Maybe we can query/filter the keys in BinaryMode, and then get all 
>>> corresponding values? Just thinking out loud. We don't want to be 
>>> deserializing unnecessarily values (Object.Y). Maybe with QuerySqlFields on 
>>> the key?
>>> 
>>> Humphrey
>>> 
>>> Op wo 22 mrt 2023 om 15:18 schreef Rick Lee >> <mailto:eerick...@gmail.com>>:
>>>> 
>>>> Why don’t u put the type to value and leave the id as the key?
>>>> 「Humphrey Lopez mailto:hmmlo...@gmail.com>>」在 
>>>> 2023年3月22日 週三，下午10:16 寫道：
>>>>> Okay transient is also not the way to go, cause we want to be able to 
>>>>> filter sometimes on that field, so it should be there in the cache. But 
>>>>> thanks for clarifying that the Equals and HashCode is not being used on 
>>>>> BinaryObjects.
>>>>> 
>>>>> Op wo 22 mrt 2023 om 14:51 schreef Humphrey Lopez >>>> <mailto:hmmlo...@gmail.com>>:
>>>>>> I see marking the field as Transient Ignite won't serialize it to 
>>>>>> BinaryObject, is that the way to go?
>>>>>> 
>>>>>> Humphrey
>>>>>> 
>>>>>> Op wo 22 mrt 2023 om 14:37 schreef Humphrey Lopez >>>>> <mailto:hmmlo...@gmail.com>>:
>>>>>>> Thanks for clarifying that. Is there a way to mark a property/field to 
>>>>>>> be excluded when storing?
>>>>>>> 
>>>>>>> Humphrey
>>>>>>> 
>>>>>>> Op wo 22 mrt 2023 om 14:20 schreef Stephen Darlington 
>>>>>>> >>>>>> <mailto:stephen.darling...@gridgain.com>>:
>>>>>>>> Ignite doesn’t use your equals or hashCode implementation. Data is 
>>>>>>>> stored as a BinaryObject, and it’s that that is compared for equality.
>>>>>>>> 
>>>>>>>>> On 22 Mar 2023, at 12:14, Humphrey Lopez >>>>>>>> <mailto:hmmlo...@gmail.com>> wrote:
>>>>>>>>> 
>>>>>>>>> They are in the example only checking the first field when overriding 
>>>>>>>>> the equals. And hashCode always returns 1.
>>>>>>>>> 
>>>>>>>>> Op wo 22 mrt 2023 om 13:06 schreef Prigoreanu, Alexandru 
>>>>>>>>> >>>>>>>> <mailto:prigoreanu.alexan...@anteash.com>>:
>>>>>>>>>> hashCode and equals should depend on the same fields.
>>>>>>>>>> 
>>>>>>>>>> On Wed, Mar 22, 2023 at 8:02 AM Humphrey Lopez >>>>>>>>> <mailto:hmmlo...@gmail.com>> wrote:
>>>>>>>>>>> Hello, when having a key which equals another key, when trying to 
>>>>>>>>>>> retrieve from cache it does not return the expected value. Is this 
>>>>>>>>>>> a bug?
>>>>>>>>>>> 
>>>>>>>>>>> I have a reproducible below in kotlin but in java we get the same 
>>>>>>>>>>> result (test with Ignite 2.10 and  2.14) and java 11 and 19.
>>>>>>>>>>> 
>>>>>>>>>>> import org.apa

Re: Key1 equals Key2 but not found in cache

[Stephen Darlington]

You don’t want to look through all the keys. That’s why Ignite has SQL.

> On 22 Mar 2023, at 14:44, Humphrey Lopez  wrote:
> 
> We have FAT keys that contain information about the Values we store. 
> KEY
> - Object A
> - Object B
> 
> VALUE
> - Object Y
> 
> The KEY we are using contains several (small) objects as fields. We have 
> added to Object A a new field A.TYPE so when searching through the cache we 
> could filter on that type.
> I guess we will need to first get all the keys that match that A.TYPE and 
> then get the objects with those objects, I think looping through the keys 
> will be quicker than looping through all the values. 
> Maybe we can query/filter the keys in BinaryMode, and then get all 
> corresponding values? Just thinking out loud. We don't want to be 
> deserializing unnecessarily values (Object.Y). Maybe with QuerySqlFields on 
> the key?
> 
> Humphrey
> 
> Op wo 22 mrt 2023 om 15:18 schreef Rick Lee  <mailto:eerick...@gmail.com>>:
>> 
>> Why don’t u put the type to value and leave the id as the key?
>> 「Humphrey Lopez mailto:hmmlo...@gmail.com>>」在 
>> 2023年3月22日 週三，下午10:16 寫道：
>>> Okay transient is also not the way to go, cause we want to be able to 
>>> filter sometimes on that field, so it should be there in the cache. But 
>>> thanks for clarifying that the Equals and HashCode is not being used on 
>>> BinaryObjects.
>>> 
>>> Op wo 22 mrt 2023 om 14:51 schreef Humphrey Lopez >> <mailto:hmmlo...@gmail.com>>:
>>>> I see marking the field as Transient Ignite won't serialize it to 
>>>> BinaryObject, is that the way to go?
>>>> 
>>>> Humphrey
>>>> 
>>>> Op wo 22 mrt 2023 om 14:37 schreef Humphrey Lopez >>> <mailto:hmmlo...@gmail.com>>:
>>>>> Thanks for clarifying that. Is there a way to mark a property/field to be 
>>>>> excluded when storing?
>>>>> 
>>>>> Humphrey
>>>>> 
>>>>> Op wo 22 mrt 2023 om 14:20 schreef Stephen Darlington 
>>>>> >>>> <mailto:stephen.darling...@gridgain.com>>:
>>>>>> Ignite doesn’t use your equals or hashCode implementation. Data is 
>>>>>> stored as a BinaryObject, and it’s that that is compared for equality.
>>>>>> 
>>>>>>> On 22 Mar 2023, at 12:14, Humphrey Lopez >>>>>> <mailto:hmmlo...@gmail.com>> wrote:
>>>>>>> 
>>>>>>> They are in the example only checking the first field when overriding 
>>>>>>> the equals. And hashCode always returns 1.
>>>>>>> 
>>>>>>> Op wo 22 mrt 2023 om 13:06 schreef Prigoreanu, Alexandru 
>>>>>>> >>>>>> <mailto:prigoreanu.alexan...@anteash.com>>:
>>>>>>>> hashCode and equals should depend on the same fields.
>>>>>>>> 
>>>>>>>> On Wed, Mar 22, 2023 at 8:02 AM Humphrey Lopez >>>>>>> <mailto:hmmlo...@gmail.com>> wrote:
>>>>>>>>> Hello, when having a key which equals another key, when trying to 
>>>>>>>>> retrieve from cache it does not return the expected value. Is this a 
>>>>>>>>> bug?
>>>>>>>>> 
>>>>>>>>> I have a reproducible below in kotlin but in java we get the same 
>>>>>>>>> result (test with Ignite 2.10 and  2.14) and java 11 and 19.
>>>>>>>>> 
>>>>>>>>> import org.apache.ignite.Ignition
>>>>>>>>> import org.apache.ignite.configuration.CacheConfiguration
>>>>>>>>> import org.assertj.core.api.SoftAssertions
>>>>>>>>> import org.junit.jupiter.api.Test
>>>>>>>>> 
>>>>>>>>> class MyTest {
>>>>>>>>> 
>>>>>>>>> private val key1 = MyKey("ABC", "DEF")
>>>>>>>>> private val key2 = MyKey("ABC", "xxx")
>>>>>>>>> 
>>>>>>>>> @Test
>>>>>>>>> fun testEquals() {
>>>>>>>>> SoftAssertions.assertSoftly {
>>>>>>>>> it.assertThat(key1).isEqualTo(key2)
>>>>>>>>> it.assertThat(key1 == key2).isTrue
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> @Test
>>>>>>>>> fun testWithMap() {
>>>>>>>>> val map = mapOf(Pair(key1, "key1"))
>>>>>>>>> 
>>>>>>>>> SoftAssertions.assertSoftly {
>>>>>>>>> it.assertThat(map.containsKey(key1)).isTrue
>>>>>>>>> it.assertThat(map.containsKey(key2)).isTrue
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> @Test
>>>>>>>>> fun testWithIgnite() {
>>>>>>>>> val ignite = Ignition.start();
>>>>>>>>> val cache = ignite.createCache(CacheConfiguration>>>>>>>> String>("mycache"))
>>>>>>>>> 
>>>>>>>>> cache.put(key1, "key1")
>>>>>>>>> SoftAssertions.assertSoftly {
>>>>>>>>> it.assertThat(cache.containsKey(key1)).isTrue
>>>>>>>>> it.assertThat(cache.containsKey(key2)).isTrue
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> private data class MyKey(val id: String, val type: String) {
>>>>>>>>> override fun equals(other: Any?): Boolean {
>>>>>>>>> if (other is MyKey)
>>>>>>>>> return id == other.id
>>>>>>>>> return false
>>>>>>>>> }
>>>>>>>>> 
>>>>>>>>> override fun hashCode(): Int {
>>>>>>>>> return 1
>>>>>>>>> }
>>>>>>>>> }
>>>>>>>>> }
>>>>>> 

Re: Key1 equals Key2 but not found in cache

[Stephen Darlington]

Ignite doesn’t use your equals or hashCode implementation. Data is stored as a 
BinaryObject, and it’s that that is compared for equality.

> On 22 Mar 2023, at 12:14, Humphrey Lopez  wrote:
> 
> They are in the example only checking the first field when overriding the 
> equals. And hashCode always returns 1.
> 
> Op wo 22 mrt 2023 om 13:06 schreef Prigoreanu, Alexandru 
> mailto:prigoreanu.alexan...@anteash.com>>:
>> hashCode and equals should depend on the same fields.
>> 
>> On Wed, Mar 22, 2023 at 8:02 AM Humphrey Lopez > > wrote:
>>> Hello, when having a key which equals another key, when trying to retrieve 
>>> from cache it does not return the expected value. Is this a bug?
>>> 
>>> I have a reproducible below in kotlin but in java we get the same result 
>>> (test with Ignite 2.10 and  2.14) and java 11 and 19.
>>> 
>>> import org.apache.ignite.Ignition
>>> import org.apache.ignite.configuration.CacheConfiguration
>>> import org.assertj.core.api.SoftAssertions
>>> import org.junit.jupiter.api.Test
>>> 
>>> class MyTest {
>>> 
>>> private val key1 = MyKey("ABC", "DEF")
>>> private val key2 = MyKey("ABC", "xxx")
>>> 
>>> @Test
>>> fun testEquals() {
>>> SoftAssertions.assertSoftly {
>>> it.assertThat(key1).isEqualTo(key2)
>>> it.assertThat(key1 == key2).isTrue
>>> }
>>> }
>>> 
>>> @Test
>>> fun testWithMap() {
>>> val map = mapOf(Pair(key1, "key1"))
>>> 
>>> SoftAssertions.assertSoftly {
>>> it.assertThat(map.containsKey(key1)).isTrue
>>> it.assertThat(map.containsKey(key2)).isTrue
>>> }
>>> 
>>> }
>>> 
>>> @Test
>>> fun testWithIgnite() {
>>> val ignite = Ignition.start();
>>> val cache = ignite.createCache(CacheConfiguration>> String>("mycache"))
>>> 
>>> cache.put(key1, "key1")
>>> SoftAssertions.assertSoftly {
>>> it.assertThat(cache.containsKey(key1)).isTrue
>>> it.assertThat(cache.containsKey(key2)).isTrue
>>> }
>>> }
>>> 
>>> private data class MyKey(val id: String, val type: String) {
>>> override fun equals(other: Any?): Boolean {
>>> if (other is MyKey)
>>> return id == other.id
>>> return false
>>> }
>>> 
>>> override fun hashCode(): Int {
>>> return 1
>>> }
>>> }
>>> }

Re: Regarding error : TcpCommunicationSpi - Failed to send message to remote node

[Stephen Darlington]

A communication problem happens between nodes, so it’s difficult to say what 
the problem is when we only see one side of the story.

Having said that, you either have a networking issue or one of your nodes is 
seeing long JVM pauses. A long JVM pause means that Ignite code isn’t running, 
resulting in the node appearing to be dead. It’s usually (but not always) 
because of Java garbage collection.

> On 21 Mar 2023, at 06:11, Abhishek Ubhe  wrote:
> 
> Hello,
> Getting below errors continuously on Ignite node. Please help me with 
> explaining the below exception when it occurs and why?
> 
> 
> ERROR org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi - Failed to 
> send message to remote node [node=TcpDiscoveryNode 
> [id=6cc31b37-7870-413a-b75a-95b4371fc542, 
> consistentId=mtnclzcom_1679291151812, addrs=ArrayList [10.233.102.12, 
> 127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500 , 
> /10.233.102.12:47500 , 
> mtn-kafka-stream-6b74bc74f-6d8jw/13.93.181.185:47500 
> ], discPort=47500, order=2, intOrder=2, 
> lastExchangeTime=1679291157038, loc=false, ver=2.10.0#20210310-sha1:bc24f6ba, 
> isClient=false], msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, 
> ordered=false, timeout=0, skipOnTimeout=false, msg=GridNearTxPrepareRequest 
> [futId=528e59df681-cef0f6c9-0046-4006-a7c4-9c6514ce6210, miniId=1, 
> topVer=AffinityTopologyVersion [topVer=2, minorTopVer=1], 
> subjId=6eaca65c-cf03-42d9-8819-31e0825fa86a, taskNameHash=0, txLbl=null, 
> flags=[implicitSingle], super=GridDistributedTxPrepareRequest [threadId=275, 
> concurrency=OPTIMISTIC, isolation=READ_COMMITTED, writeVer=GridCacheVersion 
> [topVer=290770946, order=1679291313990, nodeOrder=1], timeout=0, reads=null, 
> writes=PredicateCollectionView [IgniteTxEntry [txKey=IgniteTxKey 
> [key=KeyCacheObjectImpl [part=190, 
> val=IGNITE_CRUD_ROW_KEY_1234_5678_91011_DLR_CLZ_COM, hasValBytes=true], 
> cacheId=628281256], val=TxEntryValueHolder [val=com.google.gson.JsonObject 
> [idHash=85330180, hash=1866240837, members=LinkedHashMap 
> {ACTIVE_STATUS=com.google.gson.JsonPrimitive [idHash=1159180188, 
> hash=31429505, value=1], CML_ACCEPTED=com.google.gson.JsonPrimitive 
> [idHash=1673278339, hash=31429505, value=1], 
> CML_DATE=com.google.gson.JsonPrimitive [idHash=1909260391, hash=-1099433161, 
> value=2023-03-20T05:43:23.423]}], op=CREATE], prevVal=TxEntryValueHolder 
> [val=null, op=NOOP], oldVal=TxEntryValueHolder [val=null, op=NOOP], 
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
> explicitVer=null, dhtVer=null, filters=CacheEntryPredicate[] [], 
> filtersPassed=false, filtersSet=true, entry=GridDhtDetachedCacheEntry 
> [super=GridDistributedCacheEntry [super=GridCacheMapEntry 
> [key=KeyCacheObjectImpl [part=190, 
> val=IGNITE_CRUD_ROW_KEY_1234_5678_91011_DLR_CLZ_COM, hasValBytes=true], 
> val=null, ver=GridCacheVersion [topVer=0, order=0, nodeOrder=0], 
> hash=-661118938, extras=null, flags=0]]], prepared=0, locked=false, 
> nodeId=6cc31b37-7870-413a-b75a-95b4371fc542, locMapped=false, expiryPlc=null, 
> transferExpiryPlc=false, flags=2, partUpdateCntr=0, serReadVer=null, 
> xidVer=GridCacheVersion [topVer=290770946, order=1679291313990, 
> nodeOrder=1]]], dhtVers=null, txSize=0, plc=2, txState=null, flags=last, 
> super=GridDistributedBaseMessage [ver=GridCacheVersion [topVer=290770946, 
> order=1679291313990, nodeOrder=1], committedVers=null, rolledbackVers=null, 
> cnt=0, super=GridCacheIdMessage [cacheId=0, super=GridCacheMessage 
> [msgId=120793, depInfo=null, lastAffChangedTopVer=AffinityTopologyVersion 
> [topVer=2, minorTopVer=1], err=null, skipPrepare=false]]]
> org.apache.ignite.IgniteCheckedException: Failed to connect to node due to 
> unrecoverable exception (is node still alive?). Make sure that each 
> ComputeTask and cache Transaction has a timeout set in order to prevent 
> parties from waiting forever in case of network issues 
> [nodeId=6cc31b37-7870-413a-b75a-95b4371fc542, addrs=[/10.233.102.12:47100 
> , 
> mtn-kafka-stream-6b74bc74f-6d8jw/13.93.181.185:47100 
> , /127.0.0.1:47100 ], 
> err= class org.apache.ignite.IgniteCheckedException: Remote node does not 
> observe current node in topology : 6cc31b37-7870-413a-b75a-95b4371fc542]
> at 
> org.apache.ignite.spi.communication.tcp.internal.GridNioServerWrapper.createNioSession(GridNioServerWrapper.java:627)
>  ~[ignite-core-2.10.0.jar:2.10.0]
> at 
> org.apache.ignite.spi.communication.tcp.internal.GridNioServerWrapper.createTcpClient(GridNioServerWrapper.java:691)
>  ~[ignite-core-2.10.0.jar:2.10.0]
> at 
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.createTcpClient(TcpCommunicationSpi.java:1255)
>  ~[ignite-core-2.10.0.jar:2.10.0]
> at 
> org.apache.ignite.spi.communication.tcp.internal.GridNioServerWrapper.createTcpClient(GridNioServerWrapper.java

Re: pyignite - performance issue

[Stephen Darlington]

Macs don’t have epoll, so it doesn’t compile currently.

> On 14 Mar 2023, at 16:02, Igor Sapego  wrote:
> 
> Unfortunately, we do not have Mac agents, so we can not detect when 
> compilation on Mac OS is broken, so yeah...
> 
> Best Regards,
> Igor
> 
> 
> On Tue, Mar 14, 2023 at 2:48 PM Ivan Daschinsky  > wrote:
>> An ignite odbc driver works well on linux and windows OSes, but it seems 
>> that it is impossible to compile it on Mac OS.
>> 
>> вт, 14 мар. 2023 г. в 14:47, Ivan Daschinsky > >:
>>> Hi, Dren!
>>> 
>>> Unfortunatelly, pyignite doesn't have an efficient native serialization 
>>> library, whereas psycopg2 has (it is a thin wrapper around libpq). 
>>> 
>>> I would suggest two options:
>>> 1. Reduce a default batch size like this : `client.sql("SELECT * FROM 
>>> TABLE", page_size=10)`. Default 1024 seems too big and parsing of such a 
>>> big response seems to be really slow.
>>> 2. Use ignite odbc driver and pyodbc over it. Both of them work pretty well.
>>> 
>>> вт, 14 мар. 2023 г. в 14:10, Dren Butković >> >:
 
 Ignite and py client versions:
 
 - Apache Ignite 2.13.0
 - pyignite 0.5.2
 
 On Tue, Mar 14, 2023 at 11:46 AM Zhenya Stanilovsky via user 
 mailto:user@ignite.apache.org>> wrote:
> Hi, plz append ignite and py client versions.
>  
> 
> Hi,
> 
> I made a speed comparison of retrieving data from Apache Ignite using 
> several methods. All records are in one table, I did not use any WHERE 
> condition, only a SELECT * FROM TABLE XYZ LIMIT 2.
> 
> Test results are:
> 
> Apache Ignite
> Apache Ignite REST API - 0.52 seconds
> JDBC - 4 seconds
> Python pyignite - 40 seconds !!!
> pseudocode in Python using pyignite:
> 
> client = Client(username="ignite", password="pass", use_ssl=False)
> client.connect('localhost', 10800)
> 
> cursor=client.sql('SELECT * FROM TABLE_XYZ LIMIT 2')
> for row in cursor:
> pass
> After that I made a speed comparison of retrieving data from PostgreSQL 
> using JDBC and psycopg2 Python package. SQL select is same, SELECT * FROM 
> TABLE XYZ LIMIT 2
> 
> PostgreSQL
> JDBC - 3 seconds
> Python psycopg2 using fetchall - 3 seconds
> Python psycopg2 using fetchone - 4 seconds
> pseudocode in Python using psycopg2:
> 
> import psycopg2
> 
> conn = psycopg2.connect(database=DB_NAME,
> user=DB_USER,
> password=DB_PASS,
> host=DB_HOST,
> port=DB_PORT)
> 
> cur = conn.cursor()
> cur.execute("SELECT * FROM TABLE_XYZ LIMIT 2")
> rows = cur.fetchall()
> for data in rows:
> pass
> I can conclude that the pyignite implementation has much worse 
> performance compared to psycopg2 tests. The performance difference on 
> PostgreSQL between Java JDBC and Python psycopg2 is negligible. 
> 
> The performance difference on Apache Ignite between Java JDBC and Python 
> pyignite is very big.
> 
> Please if someone can comment on the tests, did I do something wrong or 
> are these results expected? How can such large differences in execution 
> times be explained? Do you have any suggestions to get better results 
> using pyignite?
> 
> Thank you
>  
>  
>  
>  
>>> 
>>> 
>>> -- 
>>> Sincerely yours, Ivan Daschinskiy
>> 
>> 
>> -- 
>> Sincerely yours, Ivan Daschinskiy

Re: Ignite Cluster issues with larger latency between nodes

[Stephen Darlington]

Firstly, Ignite isn’t a product in the same way that Coherence is. It’s a 
community driven project. If you’d like commercial support there are options 
available.

Deploying Ignite across availability zones is pretty common, and single digit 
round-trip latency between zones is on the high side of reasonable. (Though the 
definition of “region” and “zone” does vary between providers.) So I don’t 
think there’s anything fundamentally wrong with what you’re doing. The question 
is how is your installation different from others?

You’ve not shared any logs or configurations so all we can really do is guess. 
The queues building up suggest you have a throughput problem. Could it be a 
network bandwidth or reliability issue?

> On 11 Mar 2023, at 00:01, Vicky  wrote:
> 
> Thanks, Jeremy I will take a look at this.
> 
> I am sure there must be such benchmarks, just like every product publishes 
> its CPU and memory requirements. If a product entirely depends on the 
> underlying n/w, especially a clustering-based one should definitely publish 
> its n/w requirements. I believe long back Coherence (a distributed Cache) by 
> Tangosol (now owned by Oracle) did provide some of those details.
> 
> Right now, as I explained in the thread, we have a cluster setup across 3 
> zones within a region, and we are seeing issues when one of the nodes is set 
> up in an AZ whose latency is > 0.8 ms from the other 2 AZ's. So before we 
> look around and research any further tuning options than what we have already 
> tried it would help if some of these n/w requirements were already published, 
> that way we know that tuning further would help.
> 
> On Thu, Mar 9, 2023 at 4:47 PM Jeremy McMillan  > wrote:
>> Has this kind of benchmark ever been published for any p2p cluster 
>> technology?
>> 
>> What questions would it answer if there were such benchmarks for Ignite?
>> 
>> Maybe this will help:
>> 
>> There is an established algorithm for estimating the amount of buffer space 
>> necessary to keep a pipeline from stuttering during congestion. A generation 
>> ago this was a big deal because most Linux distros shipped with TCP buffer 
>> configuration that was insufficient for the rapidly improving network 
>> performance of Ethernet and broadband Internet service. The same idea 
>> generalizes for any streaming network communication, not only TCP.
>> 
>> https://en.m.wikipedia.org/wiki/Bandwidth-delay_product
>> 
>> Your infrastructure provider should be able to provide you with optimistic 
>> bandwidth numbers. Decide how much latency you need to tolerate. For best 
>> results, collect ping statistics over a long time to get realistic latency 
>> expectations. Plug that into the formula.
>> 
>> To prevent buffer underruns and overruns, allocate buffer space for double 
>> the BDP, as a rule of thumb. For best results, instrument the buffers and 
>> collect statistics under various load scenarios and adjust as necessary.
>> 
>> This will only solve sporadic latency hiccups. Some of this traffic will 
>> affect lock contention, so dealing with poor network performance isn't just 
>> a buffering issue. Expect to find, investigate, and solve new issues after 
>> you get rid of the buffering exceptions.
>> 
>> Good luck, and please let us know how things work for you.
>> 
>> On Thu, Mar 9, 2023, 17:08 Vicky > > wrote:
>>> Thanks, Sumit. I've gone through these, but I don't see any mention of 
>>> latency between two boxes within a cluster. Has any cloud-based 
>>> benchmarking been done? More specifically when a single cluster is spread 
>>> across multiple AZ's within the same region.
>>> 
>>> On Wed, Mar 8, 2023 at 10:33 PM Sumit Deshinge >> > wrote:
 Please check if these benchmark documents can help you :
 1. Apache Ignite and Apache Cassandra benchmarks 
 
 2. Gridgain benchmark results 
 
 
 You can also go through performance tips available on the official site at:
 https://ignite.apache.org/docs/latest/perf-and-troubleshooting/general-perf-tips
 
 On Wed, Mar 8, 2023 at 3:51 AM Vicky >>> > wrote:
> Hi,
> Is there any benchmarking about what is an acceptable latency between 
> nodes for an Ignite cluster to function stably?
> 
> We are currently having a single cluster across AZ's (same region). The 
> AZ latency published by the cloud provider is ~0.4-1ms.
> 
> What we have observed is for boxes where the AZ latency is larger i.e. > 
> 0.8, we start seeing server engine memory growing exponentially. We 
> controlled that by setting the msg queue and slow client limits to 1024 & 
> 1023 respectively. This helped get the memory

Re: Does peer class loading have to be enabled on both server and client node?

[Stephen Darlington]

You could consider using URI deployment? 
https://ignite.apache.org/docs/latest/code-deployment/deploying-user-code

> On 1 Mar 2023, at 18:59, John Smith  wrote:
> 
> So I'm stuck with a catch 22 here... I can't enable the flag on the server 
> nodes without shutting down all the client nodes and vise versa
> 
> Unless I did something wrong, but the server shuts off when i set the value 
> to true and it doesn't match with the another node... So I would have to 
> shutdown my entire infrastructure to enable it?
> 
> Like even if I shut down all the thick client connected I would have to even 
> to turn off all the server nodes make sure everything is off and then restart 
> one by one.
> 
> Does code deployment present the same problem, where I enable a shared folder 
> to periodically load classes?
> 
> On Mon., Feb. 27, 2023, 11:11 a.m. John Smith,  <mailto:java.dev@gmail.com>> wrote:
>> Sorry to be clear the applications are thick clients but client = true flag 
>> is enabled.
>> 
>> On Mon, Feb 27, 2023 at 11:09 AM John Smith > <mailto:java.dev@gmail.com>> wrote:
>>> Oh god! Forget that then! lol Really? So If I have 10 applications they all 
>>> need to be recompiled/reconfigured and redeployed?
>>> 
>>> On Mon, Feb 27, 2023 at 11:07 AM Stephen Darlington 
>>> mailto:stephen.darling...@gridgain.com>> 
>>> wrote:
>>>> It’s a cluster wide setting and needs to be set to the same value on all 
>>>> nodes, both server and thick-client.
>>>> 
>>>> > On 27 Feb 2023, at 15:58, John Smith >>> > <mailto:java.dev@gmail.com>> wrote:
>>>> > 
>>>> > I have 3 node clusters and I'm trying to enable peer class loading on 
>>>> > the cluster, but it keeps shutting off after restart because it says the 
>>>> > remote node doesn't have it enabled.
>>>> > 
>>>> > So is peer class loading required to be enabled on the server nodes or 
>>>> > can it just be enabled per client that needs it?
>>>> 

Re: Performance of data stream on 3 cluster node.

[Stephen Darlington]

This is a great blog that explains how data is distributed in an Ignite cluster:

https://www.gridgain.com/resources/blog/data-distribution-in-apache-ignite
Data Distribution in Apache Ignite
gridgain.com


> On 1 Mar 2023, at 18:40, John Smith  wrote:
> 
> My key is  phone_number and they are all unique... I'll check with the 
> command...
> 
> On Wed., Mar. 1, 2023, 11:20 a.m. Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> The streamer doesn’t determine where the data goes. It just efficiently 
>> sends it to the correct place. 
>> 
>> If your data is skewed in some way so that there is more data in some 
>> partitions than others, then you could find one machine with more work to do 
>> than others. All else being equal, you’ll also get better distribution with 
>> more than three nodes.
>> 
>>> On 1 Mar 2023, at 15:45, John Smith >> <mailto:java.dev@gmail.com>> wrote:
>>> 
>>> Ok thanks. I just thought the streamer would be more uniform.
>>> 
>>> On Wed, Mar 1, 2023 at 4:41 AM Stephen Darlington 
>>> mailto:stephen.darling...@gridgain.com>> 
>>> wrote:
>>>> You might want to check the data distribution. You can use control.sh 
>>>> —cache distribution to do that.
>>>> 
>>>>> On 28 Feb 2023, at 20:32, John Smith >>>> <mailto:java.dev@gmail.com>> wrote:
>>>>> 
>>>>> The last thing I can add to clarify is, the 3 node cluster is a 
>>>>> centralized cluster and the CSV loader is a thick client running on its 
>>>>> own machine.
>>>>> 
>>>>> On Tue, Feb 28, 2023 at 2:52 PM John Smith >>>> <mailto:java.dev@gmail.com>> wrote:
>>>>>> Btw when I run a query like SELECT COLUMN_2, COUNT(COLUMN_1) FROM 
>>>>>> MY_TABLE GROUP BY COLUMN_2; The query runs full tilt 100% on all 3 nodes 
>>>>>> and returns in a respectable manager.
>>>>>> 
>>>>>> So not sure whats going on but with the data streamer I guess most of 
>>>>>> the writes are pushed to THE ONE node mostly and the others are busy 
>>>>>> making the backups or the network to push/back up can't keep up?
>>>>>> The same behaviour happens with replicated table when using the data, 
>>>>>> one node seems to be running almost 100% while the others hover at 40-50%
>>>>>> The fastest I could get the streamer to work is to turn off backups, but 
>>>>>> same thing, one node runs full tilt while the others are "slowish"
>>>>>> 
>>>>>> Queries are ok, all nodes are fully utilized.
>>>>>> 
>>>>>> On Tue, Feb 28, 2023 at 12:54 PM John Smith >>>>> <mailto:java.dev@gmail.com>> wrote:
>>>>>>> Hi so I'm using it in a pretty straight forward kind of way at least I 
>>>>>>> think...
>>>>>>> 
>>>>>>> I'm loading 35 million lines from CSV to an SQL table. Decided to use 
>>>>>>> streamer as I figured it would still be allot faster than batching SQL 
>>>>>>> INSERTS.
>>>>>>> I tried with backup=0 and backup=1 (Prefer to have backup on)
>>>>>>> 1- With 0 backups: 6 minutes to load
>>>>>>> 2- With 1 backups: 15 minutes to load.
>>>>>>> 
>>>>>>> In both cases I still see the same behaviour, the 1 machine seems to be 
>>>>>>> taking the brunt of the work...
>>>>>>> 
>>>>>>> I'm reading a CSV file line by line and doing streamer.add()
>>>>>>> 
>>>>>>> The table definition is as follows...
>>>>>>> CREATE TABLE PUBLIC.MY_TABLE (
>>>>>>> COLUMN_1 VARCHAR(32) NOT NULL,
>>>>>>> COLUMN_2 VARCHAR(64) NOT NULL,
>>>>>>> CONSTRAINT PHONE_CARRIER_IDS_PK PRIMARY KEY (COLUMN_1)
>>>>>>> ) with "template=parallelTpl, backups=0, key_type=String, 
>>>>>>> value_type=MyObject";
>>>>>>> CREATE INDEX MY_TABLE_COLUMN_2_IDX ON PUBLIC.MY_TABLE (COLUMN_2);
>>>>>>> 
>>>>>>> String fileName = "my_file";
>>>>>>> 
>>>>>>> final String cacheNameDest = "MY_TABLE";
>>>>>>

Re: Storage Exception using Ignite

[Stephen Darlington]

This is a community forum. If you need support with SLAs there are commercial 
options available.

I think you’ll need to share more of your stack trace for someone to determine 
what the issue is.

> On 2 Mar 2023, at 08:47, satyajit.mandal.barclays.com via user 
>  wrote:
> 
> Hi  team,
>  
> Any  update  on  this  what might  be  causing  this  issue  while  storing  
> data in  Ignite  with  persistence  enabled?
>  
> class o.a.i.i.processors.cache.persistence.StorageException: Failed to 
> initialize partition file
>  
> Thanks
> Satyajit
>  
>  
>  
> From: Mandal, Satyajit: IT (PUN) 
> Sent: Thursday, March 2, 2023 7:00 AM
> To: 'user@ignite.apache.org' 
> Subject: Storage Exception using Ignite
>  
> Hi  Team,
>  
> Am  getting below  storage  exception while  loading  a  heavy  table  into  
> cache. Am running  Ignite  on  windows .
>  
> 17:29:29,731][SEVERE][exchange-worker-#62][] JVM will be halted immediately 
> due to the failure: [failureCtx=FailureContext [type=CRITICAL_ERROR, 
> err=class o.a.i.i.processors.cache.persistence.StorageException: Failed to 
> initialize partition file: 
> D:\Data\apache-ignite\work\db\node00-382c3dd6-8cca-4469-b041-bd2f24c31ab3\cache-unittest.RuleGroup\index.bin]]
>  
> Could  you  please  suggest  if  any  settings  is  missing ?
>  
> Thanks
> Satyajit
> 
> 

Re: Performance of data stream on 3 cluster node.

[Stephen Darlington]

The streamer doesn’t determine where the data goes. It just efficiently sends 
it to the correct place. 

If your data is skewed in some way so that there is more data in some 
partitions than others, then you could find one machine with more work to do 
than others. All else being equal, you’ll also get better distribution with 
more than three nodes.

> On 1 Mar 2023, at 15:45, John Smith  wrote:
> 
> Ok thanks. I just thought the streamer would be more uniform.
> 
> On Wed, Mar 1, 2023 at 4:41 AM Stephen Darlington 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> You might want to check the data distribution. You can use control.sh —cache 
>> distribution to do that.
>> 
>>> On 28 Feb 2023, at 20:32, John Smith >> <mailto:java.dev@gmail.com>> wrote:
>>> 
>>> The last thing I can add to clarify is, the 3 node cluster is a centralized 
>>> cluster and the CSV loader is a thick client running on its own machine.
>>> 
>>> On Tue, Feb 28, 2023 at 2:52 PM John Smith >> <mailto:java.dev@gmail.com>> wrote:
>>>> Btw when I run a query like SELECT COLUMN_2, COUNT(COLUMN_1) FROM MY_TABLE 
>>>> GROUP BY COLUMN_2; The query runs full tilt 100% on all 3 nodes and 
>>>> returns in a respectable manager.
>>>> 
>>>> So not sure whats going on but with the data streamer I guess most of the 
>>>> writes are pushed to THE ONE node mostly and the others are busy making 
>>>> the backups or the network to push/back up can't keep up?
>>>> The same behaviour happens with replicated table when using the data, one 
>>>> node seems to be running almost 100% while the others hover at 40-50%
>>>> The fastest I could get the streamer to work is to turn off backups, but 
>>>> same thing, one node runs full tilt while the others are "slowish"
>>>> 
>>>> Queries are ok, all nodes are fully utilized.
>>>> 
>>>> On Tue, Feb 28, 2023 at 12:54 PM John Smith >>> <mailto:java.dev@gmail.com>> wrote:
>>>>> Hi so I'm using it in a pretty straight forward kind of way at least I 
>>>>> think...
>>>>> 
>>>>> I'm loading 35 million lines from CSV to an SQL table. Decided to use 
>>>>> streamer as I figured it would still be allot faster than batching SQL 
>>>>> INSERTS.
>>>>> I tried with backup=0 and backup=1 (Prefer to have backup on)
>>>>> 1- With 0 backups: 6 minutes to load
>>>>> 2- With 1 backups: 15 minutes to load.
>>>>> 
>>>>> In both cases I still see the same behaviour, the 1 machine seems to be 
>>>>> taking the brunt of the work...
>>>>> 
>>>>> I'm reading a CSV file line by line and doing streamer.add()
>>>>> 
>>>>> The table definition is as follows...
>>>>> CREATE TABLE PUBLIC.MY_TABLE (
>>>>> COLUMN_1 VARCHAR(32) NOT NULL,
>>>>> COLUMN_2 VARCHAR(64) NOT NULL,
>>>>> CONSTRAINT PHONE_CARRIER_IDS_PK PRIMARY KEY (COLUMN_1)
>>>>> ) with "template=parallelTpl, backups=0, key_type=String, 
>>>>> value_type=MyObject";
>>>>> CREATE INDEX MY_TABLE_COLUMN_2_IDX ON PUBLIC.MY_TABLE (COLUMN_2);
>>>>> 
>>>>> String fileName = "my_file";
>>>>> 
>>>>> final String cacheNameDest = "MY_TABLE";
>>>>> 
>>>>> try(
>>>>> Ignite igniteDest = 
>>>>> configIgnite(Arrays.asList("...:47500..47509", "...:47500..47509", 
>>>>> "...:47500..47509"), "ignite-dest");
>>>>> IgniteCache cacheDest = 
>>>>> igniteDest.getOrCreateCache(cacheNameDest).withKeepBinary();
>>>>> IgniteDataStreamer streamer = 
>>>>> igniteDest.dataStreamer(cacheNameDest);
>>>>> ) {
>>>>> System.out.println("Ignite started.");
>>>>> long start = System.currentTimeMillis();
>>>>> 
>>>>> System.out.println("Cache size: " + 
>>>>> cacheDest.size(CachePeekMode.PRIMARY));
>>>>> System.out.println("Default");
>>>>> System.out.println("1d");
>>>>> 
>>>>>  

Re: Performance of data stream on 3 cluster node.

[Stephen Darlington]

You might want to check the data distribution. You can use control.sh —cache 
distribution to do that.

> On 28 Feb 2023, at 20:32, John Smith  wrote:
> 
> The last thing I can add to clarify is, the 3 node cluster is a centralized 
> cluster and the CSV loader is a thick client running on its own machine.
> 
> On Tue, Feb 28, 2023 at 2:52 PM John Smith  > wrote:
>> Btw when I run a query like SELECT COLUMN_2, COUNT(COLUMN_1) FROM MY_TABLE 
>> GROUP BY COLUMN_2; The query runs full tilt 100% on all 3 nodes and returns 
>> in a respectable manager.
>> 
>> So not sure whats going on but with the data streamer I guess most of the 
>> writes are pushed to THE ONE node mostly and the others are busy making the 
>> backups or the network to push/back up can't keep up?
>> The same behaviour happens with replicated table when using the data, one 
>> node seems to be running almost 100% while the others hover at 40-50%
>> The fastest I could get the streamer to work is to turn off backups, but 
>> same thing, one node runs full tilt while the others are "slowish"
>> 
>> Queries are ok, all nodes are fully utilized.
>> 
>> On Tue, Feb 28, 2023 at 12:54 PM John Smith > > wrote:
>>> Hi so I'm using it in a pretty straight forward kind of way at least I 
>>> think...
>>> 
>>> I'm loading 35 million lines from CSV to an SQL table. Decided to use 
>>> streamer as I figured it would still be allot faster than batching SQL 
>>> INSERTS.
>>> I tried with backup=0 and backup=1 (Prefer to have backup on)
>>> 1- With 0 backups: 6 minutes to load
>>> 2- With 1 backups: 15 minutes to load.
>>> 
>>> In both cases I still see the same behaviour, the 1 machine seems to be 
>>> taking the brunt of the work...
>>> 
>>> I'm reading a CSV file line by line and doing streamer.add()
>>> 
>>> The table definition is as follows...
>>> CREATE TABLE PUBLIC.MY_TABLE (
>>> COLUMN_1 VARCHAR(32) NOT NULL,
>>> COLUMN_2 VARCHAR(64) NOT NULL,
>>> CONSTRAINT PHONE_CARRIER_IDS_PK PRIMARY KEY (COLUMN_1)
>>> ) with "template=parallelTpl, backups=0, key_type=String, 
>>> value_type=MyObject";
>>> CREATE INDEX MY_TABLE_COLUMN_2_IDX ON PUBLIC.MY_TABLE (COLUMN_2);
>>> 
>>> String fileName = "my_file";
>>> 
>>> final String cacheNameDest = "MY_TABLE";
>>> 
>>> try(
>>> Ignite igniteDest = 
>>> configIgnite(Arrays.asList("...:47500..47509", "...:47500..47509", 
>>> "...:47500..47509"), "ignite-dest");
>>> IgniteCache cacheDest = 
>>> igniteDest.getOrCreateCache(cacheNameDest).withKeepBinary();
>>> IgniteDataStreamer streamer = 
>>> igniteDest.dataStreamer(cacheNameDest);
>>> ) {
>>> System.out.println("Ignite started.");
>>> long start = System.currentTimeMillis();
>>> 
>>> System.out.println("Cache size: " + 
>>> cacheDest.size(CachePeekMode.PRIMARY));
>>> System.out.println("Default");
>>> System.out.println("1d");
>>> 
>>> IgniteBinary binaryDest = igniteDest.binary();
>>> 
>>> try (BufferedReader br = new BufferedReader(new 
>>> FileReader(fileName))) {
>>> int count = 0;
>>> 
>>> String line;
>>> while ((line = br.readLine()) != null) {
>>> 
>>> String[] parts = line.split("\\|");
>>> 
>>> BinaryObjectBuilder keyBuilder = 
>>> binaryDest.builder("String");
>>> keyBuilder.setField("COLUMN_1", parts[1], String.class);
>>> BinaryObjectBuilder valueBuilder = 
>>> binaryDest.builder("PhoneCarrier");
>>> valueBuilder.setField("COLUMN_2", parts[3], 
>>> String.class);
>>> 
>>> streamer.addData(keyBuilder.build(), 
>>> valueBuilder.build());
>>> 
>>> count++;
>>> 
>>> if ((count % 1) == 0) {
>>> System.out.println(count);
>>> }
>>> }
>>> streamer.flush();
>>> long end = System.currentTimeMillis();
>>> System.out.println("Ms: " + (end - start));
>>> } catch (IOException e) {
>>> e.printStackTrace();
>>> }
>>> }
>>> 
>>> On Tue, Feb 28, 2023 at 11:00 AM Jeremy McMillan 
>>> mailto:jeremy.mcmil...@gridgain.com>> wrote:
 Have you tried tracing the workload on the 100% and 40% nodes for 
 comparison? There just isn't enough detail in your question to help 
 predict what should be happening with the cluster workload. For a starting 
 point, please identify your design goals. It's easy to get confused by 
 advice that seeks to help you do something you don't want to do.
 
 Some things to think about include how the stream workload is composed. 
 How should/would this work if there were only one node? How should

Re: Does peer class loading have to be enabled on both server and client node?

[Stephen Darlington]

It’s a cluster wide setting and needs to be set to the same value on all nodes, 
both server and thick-client.

> On 27 Feb 2023, at 15:58, John Smith  wrote:
> 
> I have 3 node clusters and I'm trying to enable peer class loading on the 
> cluster, but it keeps shutting off after restart because it says the remote 
> node doesn't have it enabled.
> 
> So is peer class loading required to be enabled on the server nodes or can it 
> just be enabled per client that needs it?

Re: How to avoid "all partition owners have left the grid" or handle automatically.

[Stephen Darlington]

I think there is an argument that when you have persistence enabled and a 
sensible partition loss policy, then you shouldn’t have to reset lost 
partitions. As you note, the data is still consistent. You’ve just temporarily 
lost some availability.

However, that’s not how it currently works. If you shut down more nodes than 
you have backups, then you have to reset lost partitions.

> On 20 Feb 2023, at 18:14, John Smith  wrote:
> 
> My cache config for distributed cache is as follows... The maintenance of a 
> machine can be about 10-20 mins depending on what the maintenance is. I don't 
> lose data. I just get "all partition owners have left" message and then I 
> just use control script to reset the  flag for that specific cache.
> 
>class="org.apache.ignite.configuration.CacheConfiguration">
> 
> 
>     
> 
> 
>   
> 
> On Mon., Feb. 20, 2023, 7:03 a.m. Stephen Darlington, 
> mailto:stephen.darling...@gridgain.com>> 
> wrote:
>> How are your caches configured? If they have at least one backup, you should 
>> be able to restart one node at a time without data loss.
>> 
>> There is no automated way to reset lost partitions. Nor should there be 
>> (IMHO). If you have lost partitions, you have probably lost data. That 
>> should require manual intervention.
>> 
>>> On 14 Feb 2023, at 17:58, John Smith >> <mailto:java.dev@gmail.com>> wrote:
>>> 
>>> Hello, does anyone have insights on this?
>>> 
>>> On Thu., Feb. 9, 2023, 4:28 p.m. John Smith, >> <mailto:java.dev@gmail.com>> wrote:
>>>> Any thoughts on this?
>>>> 
>>>> On Mon., Feb. 6, 2023, 8:38 p.m. John Smith, >>> <mailto:java.dev@gmail.com>> wrote:
>>>>> That Jira doesn't look like the issue at all. That issue seems to suggest 
>>>>> that there is a "data loss" exception. In our case the grid sets the 
>>>>> cache in a "safe" mode... "all partition owners have left the grid" which 
>>>>> requires us to then manually reset the flag.
>>>>> 
>>>>> On Mon, Feb 6, 2023 at 7:46 PM 18624049226 <18624049...@163.com 
>>>>> <mailto:18624049...@163.com>> wrote:
>>>>>> https://issues.apache.org/jira/browse/IGNITE-17657
>>>>>> 
>>>>>> 在 2023/2/7 05:41, John Smith 写道:
>>>>>>> Hi, sometimes when we perform maintenance and reboot nodes we get "All 
>>>>>>> partition owners have left the grid" and then we go and run 
>>>>>>> ./control.sh --host ignite-xx --cache reset_lost_partitions 
>>>>>>> some-cache and everything is fine again...
>>>>>>> 
>>>>>>> This seems to happen with partitioned caches and we are running as 
>>>>>>> READ_WRITE_SAFE.
>>>>>>> 
>>>>>>> We have a few caches and instead of relying on a human to manually go 
>>>>>>> run the command is there a way for this to happen automatically?
>>>>>>> 
>>>>>>> And if there is an automatic way how do we enable it and what are the 
>>>>>>> consequences?
>> 

Re: How to avoid "all partition owners have left the grid" or handle automatically.

[Stephen Darlington]

How are your caches configured? If they have at least one backup, you should be 
able to restart one node at a time without data loss.

There is no automated way to reset lost partitions. Nor should there be (IMHO). 
If you have lost partitions, you have probably lost data. That should require 
manual intervention.

> On 14 Feb 2023, at 17:58, John Smith  wrote:
> 
> Hello, does anyone have insights on this?
> 
> On Thu., Feb. 9, 2023, 4:28 p.m. John Smith,  > wrote:
>> Any thoughts on this?
>> 
>> On Mon., Feb. 6, 2023, 8:38 p.m. John Smith, > > wrote:
>>> That Jira doesn't look like the issue at all. That issue seems to suggest 
>>> that there is a "data loss" exception. In our case the grid sets the cache 
>>> in a "safe" mode... "all partition owners have left the grid" which 
>>> requires us to then manually reset the flag.
>>> 
>>> On Mon, Feb 6, 2023 at 7:46 PM 18624049226 <18624049...@163.com 
>>> > wrote:
 https://issues.apache.org/jira/browse/IGNITE-17657
 
 在 2023/2/7 05:41, John Smith 写道:
> Hi, sometimes when we perform maintenance and reboot nodes we get "All 
> partition owners have left the grid" and then we go and run ./control.sh 
> --host ignite-xx --cache reset_lost_partitions some-cache and 
> everything is fine again...
> 
> This seems to happen with partitioned caches and we are running as 
> READ_WRITE_SAFE.
> 
> We have a few caches and instead of relying on a human to manually go run 
> the command is there a way for this to happen automatically?
> 
> And if there is an automatic way how do we enable it and what are the 
> consequences?

Re: Get TotalServerNodes using controlscript/Rest Api

[Stephen Darlington]

Cool. You learn something new every day!

> On 1 Feb 2023, at 10:55, Николай Ижиков  wrote:
> 
> Hello.
> 
> You can query any metric value or system view content via control script [1], 
> [2]
> 
> > control.sh --system-view nodes
> 
> or [3]
> 
> > control.sh —metric cluster.TotalBaselineNodes
> > control.sh —metric cluster.TotalServerNodes
> > control.sh —metric cluster.TotalClientNodes
> 
> [1] https://ignite.apache.org/docs/latest/tools/control-script#metric-command
> [2] 
> https://ignite.apache.org/docs/latest/tools/control-script#system-view-command
> [3] 
> https://ignite.apache.org/docs/2.11.1/monitoring-metrics/new-metrics#cluster
> 
> 
>> 1 февр. 2023 г., в 13:28, Stephen Darlington 
>>  написал(а):
>> 
>> I’m not aware of any single command to do it, but there are a few options. 
>> I’ll list a few as they’re all imperfect.
>> 
>> There are some command-line JMX reader commands you could use to extract the 
>> information from Ignite’s metrics.
>> 
>> You could extract the information from the REST API. I needed to use the jq 
>> command to parse it into just a count:
>> 
>> http 'http://localhost:8080/ignite?cmd=top' | jq '[ .response[] ] | length' 
>> 
>> You could search the logs for “Topology snapshot” lines.
>> 
>> There’s also ignitevisorcmd that you can script.
>> 
>> Regards,
>> Stephen
>> 
>>> On 1 Feb 2023, at 09:32, Surinder Mehra  wrote:
>>> 
>>> Thanks, I am aware of it. But I needed this in a script. So either curl or 
>>> control options would be good.
>>> 
>>> On Wed, 1 Feb 2023, 14:51 Aleksandr Pakhomov, >> <mailto:apk...@gmail.com>> wrote:
>>>> Hi, 
>>>> 
>>>> Do you have a chance to use a java client? 
>>>> 
>>>> https://ignite.apache.org/docs/latest/thin-clients/java-thin-client
>>>> 
>>>> It seems this could help 
>>>> igniteClient.cluster().forServers().nodes().count(); 
>>>> 
>>>> Best regards, 
>>>> Aleksandr
>>>> 
>>>>> On 1 Feb 2023, at 10:21, Surinder Mehra >>>> <mailto:redni...@gmail.com>> wrote:
>>>>> 
>>>>> Hi,
>>>>> I am trying to find a way to fetch the count of server nodes in ignite 
>>>>> cluster but don't see any control script option or in Rest api. Could you 
>>>>> please suggest if it is possible. Below link shows this is exposed as a 
>>>>> cluster metric but not accessible through above two options.
>>>>> 
>>>>> https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics#cluster
>>>>>  
>>>>> Related stackoverflow post:  
>>>>> https://stackoverflow.com/questions/75301565/ignite-cluster-size-using-control-script/
>>>>> 
>>>>> Regards,
>>>>> Surinder
>>>> 
>> 
> 

Re: Get TotalServerNodes using controlscript/Rest Api

[Stephen Darlington]

I’m not aware of any single command to do it, but there are a few options. I’ll 
list a few as they’re all imperfect.

There are some command-line JMX reader commands you could use to extract the 
information from Ignite’s metrics.

You could extract the information from the REST API. I needed to use the jq 
command to parse it into just a count:

http 'http://localhost:8080/ignite?cmd=top' | jq '[ .response[] ] | length' 

You could search the logs for “Topology snapshot” lines.

There’s also ignitevisorcmd that you can script.

Regards,
Stephen

> On 1 Feb 2023, at 09:32, Surinder Mehra  wrote:
> 
> Thanks, I am aware of it. But I needed this in a script. So either curl or 
> control options would be good.
> 
> On Wed, 1 Feb 2023, 14:51 Aleksandr Pakhomov,  > wrote:
>> Hi, 
>> 
>> Do you have a chance to use a java client? 
>> 
>> https://ignite.apache.org/docs/latest/thin-clients/java-thin-client
>> 
>> It seems this could help 
>> igniteClient.cluster().forServers().nodes().count(); 
>> 
>> Best regards, 
>> Aleksandr
>> 
>>> On 1 Feb 2023, at 10:21, Surinder Mehra >> > wrote:
>>> 
>>> Hi,
>>> I am trying to find a way to fetch the count of server nodes in ignite 
>>> cluster but don't see any control script option or in Rest api. Could you 
>>> please suggest if it is possible. Below link shows this is exposed as a 
>>> cluster metric but not accessible through above two options.
>>> 
>>> https://ignite.apache.org/docs/latest/monitoring-metrics/new-metrics#cluster
>>>  
>>> Related stackoverflow post:  
>>> https://stackoverflow.com/questions/75301565/ignite-cluster-size-using-control-script/
>>> 
>>> Regards,
>>> Surinder
>> 

Re: Safe settings for ignite cache with external store

[Stephen Darlington]

Glad to hear that you got it working.

> On 30 Jan 2023, at 23:05, Łukasz Dywicki  wrote:
> 
> Hello Stephen,
> I've started tests with few angles, with larger and smaller memory setups, 
> looked at Ignite unit tests and began looking for page eviction triggers. 
> Once I found interesting code areas I realized that my test setup was not 
> having proper page eviction set up. This lead me to further debugging which 
> lead me piece of old code which was overriding persistence configuration, 
> *effectively* reverting page eviction to default (no eviction).
> After clean up I successfully tested eviction with small caches (512MB max + 
> direct buffer at 756MB). These worked stable under constant load, which 
> proved the point that it is possible to have stable operation on fairly 
> limited resources.
> 
> Guilt goes to spring configuration pre/post-processing which went under radar 
> till today. It was really specific to test application itself, not Ignite. I 
> thank you for feedback, pointers and assistance!
> 
> Kind regards,
> Łukasz
> 
> On 30.01.2023 12:51, Stephen Darlington wrote:
>> I’m not saying you should test with 50Gb, but I am saying that 512Mb is too 
>> small. Maybe try a few gigs.
>> When you define eviction at a cache level, that is for the on-heap cache. 
>> Most people don’t need an on-heap cache.
>> You you define eviction at a data region level, that works on the off-heap 
>> data. As you observe, it works at a /page/ rather than a record level. (This 
>> is why a tiny region can be problematic. There are far few pages that can be 
>> chosen to evict.)
>>> On 30 Jan 2023, at 11:37, Łukasz Dywicki  wrote:
>>> 
>>> Dear Jeremy and Stephen,
>>> Thank you for answers. I this issues I face is not bound exclusively to 
>>> assigned memory but behavior of eviction policies. After all, without 
>>> proper eviction or expiry policy, each amount of memory will eventually be 
>>> exceeded. Small size of memory makes it simply easier to test. To be honest 
>>> I do not see a point in testing eviction with 50GB of memory, if it cant be 
>>> configured for 512MB. Expiry policy proved to work, but it will not 
>>> preventing node from crash, as there always might be high write ratio 
>>> causing memory to fill.
>>> 
>>> Both LRU and FIFO eviction policies in default configuration do not take 
>>> into account overall memory allocation, they work only with on heap caches. 
>>> Unless memory size is explicitly specified they will rely on 
>>> over-provisioned memory, or assume that memory assignment is right. This is 
>>> possible only if cache entry have a predictable.
>>> Another point is that above eviction policies are dedicated to on-heap 
>>> caches and are told to have no affect to off-heap region, why is so? By 
>>> looking at sources I see CacheOffheapEvictionManager and 
>>> GridCacheEvictionManager, but I can't grasp what enables eviction of 
>>> entries from off heap memory managed by Ignite.
>>> Given that my use case is continuous operation with variety of entries 
>>> having various sizes I can't assume on-heap cache with LRU nor FIFO, 
>>> especially that they do not impact off heap memory. I also can't risk 
>>> filling in memory managed by Ignite due to lack of clear eviction policy 
>>> during peak load.
>>> As far I can understand from DataRegionConfiguration, its eviction 
>>> mechanism works for whole pages, but I haven't seen this happening. Could 
>>> it be due to fact that single cache entry in my test exceeds maximum page 
>>> size (16MB)?
>>> 
>>> Best regards,
>>> Łukasz
>>> 
>>> On 30.01.2023 10:32, Stephen Darlington wrote:
>>>> Ignite is designed to work as a cluster with a lot of memory. A single 
>>>> node with 512Mb of memory just isn’t what most people are testing with. 
>>>> I’ve seen similar issues when people use tiny nodes. I don’t see anything 
>>>> immediately wrong with your configuration, but if it works with more 
>>>> memory, that’s your problem.
>>>>> On 28 Jan 2023, at 00:35, Łukasz Dywicki  wrote:
>>>>> 
>>>>> Hello again,
>>>>> I've spent another day on this issue looking at configuration and with 
>>>>> cluster larger than configured backup count ignite did the work.
>>>>> After that I reverted to testing of single node with minimal 
>>>>> configuration and come to the point that the only way to keep Ignite 
>>>>&

Re: Safe settings for ignite cache with external store

[Stephen Darlington]

I’m not saying you should test with 50Gb, but I am saying that 512Mb is too 
small. Maybe try a few gigs. 

When you define eviction at a cache level, that is for the on-heap cache. Most 
people don’t need an on-heap cache.

You you define eviction at a data region level, that works on the off-heap 
data. As you observe, it works at a page rather than a record level. (This is 
why a tiny region can be problematic. There are far few pages that can be 
chosen to evict.)

> On 30 Jan 2023, at 11:37, Łukasz Dywicki  wrote:
> 
> Dear Jeremy and Stephen,
> Thank you for answers. I this issues I face is not bound exclusively to 
> assigned memory but behavior of eviction policies. After all, without proper 
> eviction or expiry policy, each amount of memory will eventually be exceeded. 
> Small size of memory makes it simply easier to test. To be honest I do not 
> see a point in testing eviction with 50GB of memory, if it cant be configured 
> for 512MB. Expiry policy proved to work, but it will not preventing node from 
> crash, as there always might be high write ratio causing memory to fill.
> 
> Both LRU and FIFO eviction policies in default configuration do not take into 
> account overall memory allocation, they work only with on heap caches. Unless 
> memory size is explicitly specified they will rely on over-provisioned 
> memory, or assume that memory assignment is right. This is possible only if 
> cache entry have a predictable.
> Another point is that above eviction policies are dedicated to on-heap caches 
> and are told to have no affect to off-heap region, why is so? By looking at 
> sources I see CacheOffheapEvictionManager and GridCacheEvictionManager, but I 
> can't grasp what enables eviction of entries from off heap memory managed by 
> Ignite.
> Given that my use case is continuous operation with variety of entries having 
> various sizes I can't assume on-heap cache with LRU nor FIFO, especially that 
> they do not impact off heap memory. I also can't risk filling in memory 
> managed by Ignite due to lack of clear eviction policy during peak load.
> As far I can understand from DataRegionConfiguration, its eviction mechanism 
> works for whole pages, but I haven't seen this happening. Could it be due to 
> fact that single cache entry in my test exceeds maximum page size (16MB)?
> 
> Best regards,
> Łukasz
> 
> On 30.01.2023 10:32, Stephen Darlington wrote:
>> Ignite is designed to work as a cluster with a lot of memory. A single node 
>> with 512Mb of memory just isn’t what most people are testing with. I’ve seen 
>> similar issues when people use tiny nodes. I don’t see anything immediately 
>> wrong with your configuration, but if it works with more memory, that’s your 
>> problem.
>>> On 28 Jan 2023, at 00:35, Łukasz Dywicki  wrote:
>>> 
>>> Hello again,
>>> I've spent another day on this issue looking at configuration and with 
>>> cluster larger than configured backup count ignite did the work.
>>> After that I reverted to testing of single node with minimal configuration 
>>> and come to the point that the only way to keep Ignite survive load was 
>>> setting ExpiryPolicy to very low value (10s).
>>> 
>>> To me it seems that Ignite behavior is to preserve all entries in memory at 
>>> any cost, even if there is a risk of running into OOM. Is that true?
>>> I would like to change this behavior and make sure that entries do not 
>>> expire because of time as long as there is memory available to store them. 
>>> They should be evicted by appropriate EvictionPolicy only if memory fills 
>>> up.
>>> To me it looks like DataStoreSettings do not make any impact in this 
>>> regard. At least setting page eviction to LRU do not change it.
>>> 
>>> Please let me know if I am doing something wrong as I can not prove Ignite 
>>> to be working stable. Even with such basic objectives I outlined in earlier 
>>> mail.
>>> 
>>> Kind regards,
>>> Łukasz
>>> 
>>> On 27.01.2023 00:58, Łukasz Dywicki wrote:
>>>> Dear all,
>>>> I come across use of Apache Ignite to cache results of expensive 
>>>> computation operation.
>>>> Objectives are basic:
>>>> - Keep most of "hot" data in memory
>>>> - Offload cold part to cache store
>>>> - Keep memory utilization under control (evict entries as needed)
>>>> While it sounds basic, it doesn't seem to fit Ignite defaults.
>>>> What I am testing now is behavior with large objects which can grow up to 
>>>> 10 mb (serialized) or 25 mb (json representa

Re: Safe settings for ignite cache with external store

[Stephen Darlington]

Ignite is designed to work as a cluster with a lot of memory. A single node 
with 512Mb of memory just isn’t what most people are testing with. I’ve seen 
similar issues when people use tiny nodes. I don’t see anything immediately 
wrong with your configuration, but if it works with more memory, that’s your 
problem. 

> On 28 Jan 2023, at 00:35, Łukasz Dywicki  wrote:
> 
> Hello again,
> I've spent another day on this issue looking at configuration and with 
> cluster larger than configured backup count ignite did the work.
> After that I reverted to testing of single node with minimal configuration 
> and come to the point that the only way to keep Ignite survive load was 
> setting ExpiryPolicy to very low value (10s).
> 
> To me it seems that Ignite behavior is to preserve all entries in memory at 
> any cost, even if there is a risk of running into OOM. Is that true?
> I would like to change this behavior and make sure that entries do not expire 
> because of time as long as there is memory available to store them. They 
> should be evicted by appropriate EvictionPolicy only if memory fills up.
> To me it looks like DataStoreSettings do not make any impact in this regard. 
> At least setting page eviction to LRU do not change it.
> 
> Please let me know if I am doing something wrong as I can not prove Ignite to 
> be working stable. Even with such basic objectives I outlined in earlier mail.
> 
> Kind regards,
> Łukasz
> 
> On 27.01.2023 00:58, Łukasz Dywicki wrote:
>> Dear all,
>> I come across use of Apache Ignite to cache results of expensive computation 
>> operation.
>> Objectives are basic:
>> - Keep most of "hot" data in memory
>> - Offload cold part to cache store
>> - Keep memory utilization under control (evict entries as needed)
>> While it sounds basic, it doesn't seem to fit Ignite defaults.
>> What I am testing now is behavior with large objects which can grow up to 10 
>> mb (serialized) or 25 mb (json representation). Usually objects will stay 
>> far below that threshold, but we can't make assumption on that.
>> I began testing various configurations of Ignite in order to facilitate 
>> offloading of memory contents to database. So far I am stuck for two days at 
>> Ignite/application itself running out of memory after processing several of 
>> such large objects. While I know that storing 10 mb blob in database is not 
>> the best idea, I have to test that behavior too.
>> By observing database contents I see that number of entries there grows, but 
>> cache do not seem to be evicted. When I try to switch eviction, it does 
>> require onheap to be switched on, and it still fails with LRU eviction 
>> policy.
>> So far I ended up with a named cache and default region configured as below:
>> ```
>> IgniteConfiguration igniteConfiguration = new IgniteConfiguration();
>> igniteConfiguration.setDataStorageConfiguration(new 
>> DataStorageConfiguration()
>> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
>> .setPersistenceEnabled(false)
>> .setInitialSize(256L * 1024 * 1024)
>> .setMaxSize(512L * 1024 * 1024)
>> .setPageEvictionMode(DataPageEvictionMode.RANDOM_LRU)
>> .setSwapPath(null)
>> .setEvictionThreshold(0.75)
>> )
>> .setPageSize(DataStorageConfiguration.MAX_PAGE_SIZE)
>> );
>> CacheConfiguration expensiveCache = new 
>> CacheConfiguration<>()
>> .setName(CACHE_NAME)
>> .setBackups(2)
>> .setAtomicityMode(CacheAtomicityMode.ATOMIC)
>> .setCacheStoreFactory(cacheJdbcBlobStoreFactory)
>> .setWriteThrough(true)
>> .setOnheapCacheEnabled(true)
>> .setEvictionPolicyFactory(new LruEvictionPolicyFactory<>(1024))
>> .setReadThrough(true);
>> igniteConfiguration.setCacheConfiguration(
>> expensiveCache
>> );
>> ```
>> What I observe is following - the cache keeps writing data into database, 
>> but it does not remove old entries fast enough to prevent crash.
>> JVM parameters I use are fairly basic:
>> -Xms1g -Xmx1g -XX:+AlwaysPreTouch -XX:+UseG1GC -XX:+ScavengeBeforeFullGC 
>> -XX:+DisableExplicitGC
>> The store mechanism is jdbc blob store. Exceptions I get happen to occur in 
>> Ignite itself, processing (application code writing cache) or communication 
>> thread used to feed cache. I collected one case here:
>> https://gist.github.com/splatch/b5ec9134cd9df19bc62f007dd17a19a1
>> The error message in linked gist advice to enable persistence (which I did 
>> via cache store!), increase memory limit (which I don't want to do), or 
>> enable eviction/expiry policy (which somehow miss behave).
>> To me it looks like self defense mechanisms Ignite has are being tricked   
>> leading whole application to crash.
>> Can you please advise me which settings to tune and how in order to get 
>> Ignite more stable under such load?
>> Kind regards,
>> Łukasz

Re: Kafka & Ignite AffinityFunction

[Stephen Darlington]

You don’t need to override the RendezvousAffinityFunction to do what you’re 
asking. Instead, if you define an affinity key to your table, it will guarantee 
that related records will be kept together. However, make sure your groups are 
not too coarse or you’ll get poor distribution across your cluster.

> On 26 Jan 2023, at 11:37, Colin Cassidy via user  
> wrote:
> 
> I would like to override the Ignite AffinityFunction to delegate to Kafka's 
> partitioning algorithm. Possibly also the node assignment - but definitely 
> the partitioning
> 
> This will allow me to ensure that events are processed local to where the 
> data is stored.
> 
> I think this is possible in Ignite 2.x but there appear to be significant 
> changes in Ignite 3.x. Could I confirm - if I follow this path, will it be 
> possible to override the cache partitioning still in 3.x?
> 
> Thanks in advance,
> Colin.

Re: C# Ignite thin client - how to connect specific grid

[Stephen Darlington]

Those ports are for thick-clients and servers. Thin clients connect to 10800. 
The second server to start will be on 10801, etc.

You can configure the thin-client port with ClientConnectorConfiguration: 
getting-started-with-thin-clients 


> On 12 Jan 2023, at 11:56, Charlin S  wrote:
> 
> Hi Pavel,
> Thanks for your reply.
> I am having two grids in one server and grid configuration as below. Which 
> port should I use for connecting grid1 and grid2?
> 
> 
> 
> As per my understanding, I should be able to connect thin clients like this. 
> Please correct me if I am wrong.
> //for Grid 1
> var clientCfgGrid1 = new IgniteClientConfiguration
> {
> Endpoints = new[] { "10.201.30.116: 
> 48500","10.201.30.117: 
> 48500" }
> };
> // for Grid 2
> var clientCfgGrid2 = new IgniteClientConfiguration
> {
> Endpoints = new[] { "10.201.30.116: 
> 55800","10.201.30.117: 
> 55800" }
> };
> 
> Regards,
> Charlin
> 
> 
> 
> 
>  
> 
> 
> 
> 
> On Thu, 12 Jan 2023 at 15:37, Pavel Tupitsyn  > wrote:
> 
> C# thin client can connect to any port, specify it in the endpoint string 
> like this:
> 
> var clientCfg = new IgniteClientConfiguration("127.0.0.1:10901 
> ");
> var client = Ignition.StartClient(clientCfg);
> 
> or
> 
> var clientCfg2 = new IgniteClientConfiguration
> {
> Endpoints = new[] { "127.0.0.1:10901 " }
> };
> 
> On Thu, Jan 12, 2023 at 11:41 AM Charlin S  > wrote:
> Hi All,
> My requirement is to connect a specific grid(server has multiple grids) from 
> c# thin client, since its support only 10800 ports.
> 
> Regards,
> Charlin
> 
> 
> 

Re: How to use Hash Join in SQL API?

[Stephen Darlington]

Are you saying that you have no indexes other than the primary key? What is the 
primary key for RetailProductFeatures?

> On 22 Dec 2022, at 13:00, Айсина Роза Мунеровна  
> wrote:
> 
> Hi Stephen!
> 
> I use this DDLl to create table (all tables are created this way): 
> 
> CREATE TABLE IF NOT EXISTS PUBLIC.ProductFeatures
> (
> product_sku INT PRIMARY KEY,
> total_cnt_orders_with_sku INT
> )
> WITH "CACHE_NAME=PUBLIC_ProductFeatures, KEY_TYPE=io.sbmt.ProductFeaturesKey, 
> VALUE_TYPE=io.sbmt.ProductFeaturesValue, AFFINITY_KEY=product_sku, 
> TEMPLATE=PARTITIONED, BACKUPS=1
> 
> So I have affinity index and primary key index and what I see in indexes 
> system table: 
> ++
> |INDEX_NAME  |
> ++
> |_key_PK_hash|
> |__SCAN_ |
> |_key_PK |
> |AFFINITY_KEY|
> ++
> 
> 
>> On 22 Dec 2022, at 1:21 PM, Stephen Darlington 
>>  wrote:
>> 
>> What indexes have you created on RetailerProductFeatures? In general, 
>> there’s no need to specify the index to use in your query.
>> 
>>> On 22 Dec 2022, at 09:53, Айсина Роза Мунеровна >> <mailto:roza.ays...@sbermarket.ru>> wrote:
>>> 
>>> Hi!
>>> 
>>> Thank you for your replies!
>>> 
>>> I tried to specify any index except primary key index and explained showed, 
>>> that SCAN is used which, I guess, is full table scan: 
>>> 
>>> explain
>>> SELECT ProductFeatures.product_sku,
>>>ProductFeatures.total_cnt_orders_with_sku,
>>>RetailerProductFeatures.mean_daily_sku_retailer_popularity
>>> FROM ProductFeatures
>>>  LEFT JOIN RetailerProductFeatures USE INDEX(PUBLIC."_key_PK_hash")
>>>ON ProductFeatures.product_sku = 
>>> RetailerProductFeatures.product_sku
>>>AND RetailerProductFeatures.retailer_id = 142
>>> WHERE ProductFeatures.product_sku IN (52864, 1582957, 110319, 1477711, 
>>> 272024)
>>> ;
>>> 
>>> SELECT
>>> __Z0.PRODUCT_SKU AS __C0_0,
>>> __Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1,
>>> __Z1.MEAN_DAILY_SKU_RETAILER_POPULARITY AS __C0_2
>>> FROM PUBLIC.PRODUCTFEATURES __Z0
>>> /* PUBLIC."_key_PK": PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 
>>> 272024) */
>>> /* WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
>>> */
>>> LEFT OUTER JOIN PUBLIC.RETAILERPRODUCTFEATURES __Z1 USE INDEX 
>>> ("_key_PK_hash")
>>> /* PUBLIC.RETAILERPRODUCTFEATURES.__SCAN_ */
>>> ON (__Z1.RETAILER_ID = 142)
>>> AND (__Z0.PRODUCT_SKU = __Z1.PRODUCT_SKU)
>>> WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
>>> 
>>> So I guess there is no way to specify more “fast” index because the main 
>>> goal is to speed up our JOIN queries. 
>>> 
>>> Thanks!
>>> 
>>>> On 21 Dec 2022, at 9:06 PM, Николай Ижиков >>> <mailto:nizhi...@apache.org>> wrote:
>>>> 
>>>> Hello.
>>>> 
>>>> It seems, you should replace `HASH_JOIN_IDX` with your actual index name.
>>>> You can find all indexes with `SELECT * FROM SYS.INDEXES`
>>>> 
>>>>> 21 дек. 2022 г., в 20:43, Stephen Darlington 
>>>>> >>>> <mailto:stephen.darling...@gridgain.com>> написал(а):
>>>>> 
>>>>> I don’t think it’s ever been in Ignite.
>>>>> 
>>>>>> On 21 Dec 2022, at 16:49, Айсина Роза Мунеровна 
>>>>>> mailto:roza.ays...@sbermarket.ru>> wrote:
>>>>>> 
>>>>>> Hi Stephen!
>>>>>> 
>>>>>> Sorry, I forgot to attach link on doc: 
>>>>>> https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins 
>>>>>> <https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins>
>>>>>> 
>>>>>> We use 2.13.0 Ignite version.
>>>>>> So this feature was deleted from releases after 2.11? :(
>>>>>> 
>>>>>>> On 21 Dec 2022, at 7:43 PM, Stephen Darlington 
>>>>>>> >>>>>> <mailto:stephen.darling...@gridgain.com>> wrote:
>>>>>>> 
>>>>>>> Внимание: Внешний отправитель!
>>>>>>> Если вы не знаете отправителя - не открывайте вложения, не переходите 
>>>>>>&

Re: How to use Hash Join in SQL API?

[Stephen Darlington]

What indexes have you created on RetailerProductFeatures? In general, there’s 
no need to specify the index to use in your query.

> On 22 Dec 2022, at 09:53, Айсина Роза Мунеровна  
> wrote:
> 
> Hi!
> 
> Thank you for your replies!
> 
> I tried to specify any index except primary key index and explained showed, 
> that SCAN is used which, I guess, is full table scan: 
> 
> explain
> SELECT ProductFeatures.product_sku,
>ProductFeatures.total_cnt_orders_with_sku,
>RetailerProductFeatures.mean_daily_sku_retailer_popularity
> FROM ProductFeatures
>  LEFT JOIN RetailerProductFeatures USE INDEX(PUBLIC."_key_PK_hash")
>ON ProductFeatures.product_sku = 
> RetailerProductFeatures.product_sku
>AND RetailerProductFeatures.retailer_id = 142
> WHERE ProductFeatures.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
> ;
> 
> SELECT
> __Z0.PRODUCT_SKU AS __C0_0,
> __Z0.TOTAL_CNT_ORDERS_WITH_SKU AS __C0_1,
> __Z1.MEAN_DAILY_SKU_RETAILER_POPULARITY AS __C0_2
> FROM PUBLIC.PRODUCTFEATURES __Z0
> /* PUBLIC."_key_PK": PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 
> 272024) */
> /* WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
> */
> LEFT OUTER JOIN PUBLIC.RETAILERPRODUCTFEATURES __Z1 USE INDEX ("_key_PK_hash")
> /* PUBLIC.RETAILERPRODUCTFEATURES.__SCAN_ */
> ON (__Z1.RETAILER_ID = 142)
> AND (__Z0.PRODUCT_SKU = __Z1.PRODUCT_SKU)
> WHERE __Z0.PRODUCT_SKU IN(52864, 1582957, 110319, 1477711, 272024)
> 
> So I guess there is no way to specify more “fast” index because the main goal 
> is to speed up our JOIN queries. 
> 
> Thanks!
> 
>> On 21 Dec 2022, at 9:06 PM, Николай Ижиков  wrote:
>> 
>> Hello.
>> 
>> It seems, you should replace `HASH_JOIN_IDX` with your actual index name.
>> You can find all indexes with `SELECT * FROM SYS.INDEXES`
>> 
>>> 21 дек. 2022 г., в 20:43, Stephen Darlington 
>>>  написал(а):
>>> 
>>> I don’t think it’s ever been in Ignite.
>>> 
>>>> On 21 Dec 2022, at 16:49, Айсина Роза Мунеровна >>> <mailto:roza.ays...@sbermarket.ru>> wrote:
>>>> 
>>>> Hi Stephen!
>>>> 
>>>> Sorry, I forgot to attach link on doc: 
>>>> https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins 
>>>> <https://ignite.apache.org/docs/2.11.1/SQL/distributed-joins#hash-joins>
>>>> 
>>>> We use 2.13.0 Ignite version.
>>>> So this feature was deleted from releases after 2.11? :(
>>>> 
>>>>> On 21 Dec 2022, at 7:43 PM, Stephen Darlington 
>>>>> >>>> <mailto:stephen.darling...@gridgain.com>> wrote:
>>>>> 
>>>>> Внимание: Внешний отправитель!
>>>>> Если вы не знаете отправителя - не открывайте вложения, не переходите по 
>>>>> ссылкам, не пересылайте письмо!
>>>>> 
>>>>> Where did you get that syntax from? I don’t think Ignite supports hash 
>>>>> joins, though there are other distributions of Ignite that do.
>>>>> 
>>>>>> On 21 Dec 2022, at 16:22, Айсина Роза Мунеровна 
>>>>>> mailto:roza.ays...@sbermarket.ru>> wrote:
>>>>>> 
>>>>>> Hola again!
>>>>>> 
>>>>>> I have a problem when trying to use Hah Join in SQL API.
>>>>>> I am using this doc: 
>>>>>> 
>>>>>> What I am doing: 
>>>>>> 
>>>>>> query = """
>>>>>> SELECT pf.product_sku,
>>>>>>pf.total_cnt_orders_with_sku,
>>>>>>rpf.mean_daily_sku_retailer_popularity
>>>>>> FROM ProductFeatures AS pf
>>>>>>  LEFT JOIN RetailerProductFeatures AS rpf 
>>>>>> USE INDEX(HASH_JOIN_IDX)
>>>>>>ON pf.product_sku = rpf.product_sku
>>>>>>AND rpf.retailer_id = 142
>>>>>> WHERE pf.product_sku IN (52864, 1582957, 110319, 1477711, 272024)
>>>>>> """
>>>>>> 
>>>>>> data = next(
>>>>>> ignite_client.sql(
>>>>>> query,
>>>>>> distributed_joins=False,
>>>>>> enforce_join_order=True,
>>>>>> collocated=True,
&