Re: Ignite 2.16 - Failed to commit transaction, transaction is concurrently rolled back on timeout

Can you share more logs of your application and cluster nodes, please? пт, 8 нояб. 2024 г. в 11:51, Charlin S : > > Hi Ilya, > Thanks for your reply. > My code as below. Please suggest me either this error due to Ignite > upgradation or with code > using (var transact = > ICache.Ignite.GetTrans

Re: Using large number of unique locks over time - design adivce

Thank you Pavel! On Mon, Nov 11, 2024 at 12:25 AM Pavel Tupitsyn wrote: > - IgniteLock is cheap. It is just an entry in a special cache, you can > have thousands of them. > - IgniteLock is removed without a trace on close(), you can create a new > one with the same name later. > > > Would you ex

Re: Using large number of unique locks over time - design adivce

- IgniteLock is cheap. It is just an entry in a special cache, you can have thousands of them. - IgniteLock is removed without a trace on close(), you can create a new one with the same name later. > Would you expect ignite 3 the same behavior as ignite 2 in this respect or it may be different We

Re: Using large number of unique locks over time - design adivce

Hello Jeremy, Sorry for the confusion and verbose message - it has nothing to do with Ignite files or file locking in general - I was just trying to provide some background on what the application is doing and how ignite locks will be used. The only thing (about ignite) I really need to know is ho

Re: Using large number of unique locks over time - design adivce

I don't understand what Ignite does with processing filesystem directories. This sounds like a question for whoever is supporting your OS. It is generally a very bad idea to write to files which belong to Ignite. I suspect you're struggling with OS file locking semantics and concurrent file access.

Re: Ignite 3 roadmap and changes

Alex, I'm not sure about data structures availability yet. On Fri, Nov 8, 2024 at 3:27 PM Alex Roytman wrote: > Thank you Pavel! > Having raft and split brain protection in 3.0 is attractive so we will > likely migrate to 3.0 once distributed data structures are available. > Do you think they'll

Re: Ignite 3 roadmap and changes

Thank you Pavel! Having raft and split brain protection in 3.0 is attractive so we will likely migrate to 3.0 once distributed data structures are available. Do you think they'll be available within 6-9mo after general 3.0 release? On Fri, Nov 8, 2024 at 5:27 AM Pavel Tupitsyn wrote: > > 1. Is i

Re: Ignite 3 roadmap and changes

> 1. Is it really coming this year? Yes, late this year / early next year. > 2. When distributed data structures (locks, semaphores, queues etc) are planned? Later, not in the upcoming 3.0 > 3. What is your take on embedding? Are you moving away from embedding Embedding is implemented, it will

Re: Ignite 2.16 - Failed to commit transaction, transaction is concurrently rolled back on timeout

Hi Ilya, Thanks for your reply. My code as below. Please suggest me either this error due to Ignite upgradation or with code using (var transact = ICache.Ignite.GetTransactions().TxStart(TransactionConcurrency.Pessimistic, TransactionIsolation.RepeatableRead, TimeSpan.FromMilliseconds(7000), 0)) {

Re: Ignite 2.16 - Failed to commit transaction, transaction is concurrently rolled back on timeout

Hi Charlin, As far as I know, transactions have no timeout by default. Did you set any transaction timeout in server configuration or in your code? Regards, Ilya чт, 7 нояб. 2024 г. в 13:05, Charlin S : > > Hi All, > > I have planned to upgrade the Ignite version from 2.10 to 2.16 and saw this

Re: Ignite 2.10 - Caused by: class org.apache.ignite.IgniteException: Failed to execute native callback because grid is stopping

- App pool recycle caused the node to stop - Cache operation failed because the node was in process of stopping On Thu, Nov 7, 2024 at 12:20 PM Charlin S wrote: > Hi All, > > My Ignite client node failed to connect after application pool recycle but > other client nodes are connected to the same

Re: Ignite 3 API changes

No schedule yet but I would expect it early next year/late this year On Wed, Nov 6, 2024 at 12:11 PM JP Moresmau wrote: > Thank you. Our main issue with Ignite 2 is that running on Java 17 > requires lots of flags. I see a 2.x version built on Java 11 is planned, is > there any schedule for that

Re: Ignite 3 API changes

Thank you. Our main issue with Ignite 2 is that running on Java 17 requires lots of flags. I see a 2.x version built on Java 11 is planned, is there any schedule for that release? JP Moresmau On Wed, Nov 6, 2024 at 10:52 AM Pavel Tupitsyn wrote: > Hello, > > - IgniteCache is now KeyValueView,

Re: Ignite 3 API changes

Hello, - IgniteCache is now KeyValueView, most operations are the same as in Ignite 2 - Other data structures will come later - Embedded mode is available - Compute API is available - We don't yet have a document with all the big changes, it will come with the release Also, Ignite 2.x is still su

Re: Ignite 2.16 - Apache Ignite.NET LINQ Provider - Slow

1. Check the generated SQL // Cast to ICacheQueryable var cacheQueryable = (ICacheQueryable) query; // Get resulting fields query SqlFieldsQuery fieldsQuery = cacheQueryable.GetFieldsQuery(); // Examine generated SQL Console.WriteLine(fieldsQuery.Sql); 2. Try EXPLAIN and other suggestions from

Re: Ignite 2.16 - Apache Ignite.NET LINQ Provider - Slow

Hi Pavel, Thanks for your email. it reduces to 9 seconds after removing AsParallel. Please let me know if there are any more options to get good performance. Regards, Charlin On Tue, 5 Nov 2024 at 13:31, Pavel Tupitsyn wrote: > Hi, "AsParallel" is the problem, it causes the entire data set to

Re: Ignite 2.16 - Computer task

Sorry, I don't understand the question. Is there a problem with examples? Are you able to run them? On Tue, Nov 5, 2024 at 10:30 AM Vladimir Tchernyi wrote: > Hi, > > Take a look at the article i wrote, there is complete compilable project > > > https://www.gridgain.com/resources/blog/how-fast-l

Re: Ignite 2.16 - Apache Ignite.NET LINQ Provider - Slow

Hi, "AsParallel" is the problem, it causes the entire data set to be loaded locally before filtering. Remove it so that the LINQ expression can be translated into Ignite SQL and executed more efficiently. https://ignite.apache.org/docs/latest/net-specific/net-linq On Tue, Nov 5, 2024 at 8:58 AM

Re: Ignite 2.16 - Computer task

Hi, Take a look at the article i wrote, there is complete compilable project https://www.gridgain.com/resources/blog/how-fast-load-large-datasets-apache-ignite-using-key-value-api вт, 5 нояб. 2024 г., 11:03 Pavel Tupitsyn : > Java: > https://github.com/apache/ignite/tree/master/examples/src/mai

Re: Ignite 2.16 - Computer task

Java: https://github.com/apache/ignite/tree/master/examples/src/main/java/org/apache/ignite/examples/computegrid .NET: https://github.com/apache/ignite/tree/master/modules/platforms/dotnet/examples/Thick/Compute On Tue, Nov 5, 2024 at 8:41 AM Charlin S wrote: > Hi All, > I am planning to impleme

Re: Updating ignite.

GridGain Enterprise and Ultimate editions provide Ignite compatible implementations with limited support for nodes with two concurrent versions to coexist temporarily in a cluster topology. This feature is called "Rolling Upgrade" and is only available in commercial GridGain versions. Please read t

Re: with nested entry processors, child completes but parent IgniteFuture does not

I see. It sounds like this would be a rough sequence of events for a happy path successful case: 1. OuterEntryProcessor, running on sys-stripe-5 on server2, invokes InnerEntryProcessor 2. sys-stripe-5 on server2 waits for the above future 3. InnerEntryProcessor runs on sys-stripe-1 on server1 4. s

Re: with nested entry processors, child completes but parent IgniteFuture does not

> both invocations use sys-stripe-6 Ignite needs sys-stripe-6 to complete the future for the invocation, but the thread is blocked waiting on that future. On Thu, Oct 31, 2024 at 3:05 PM Raymond Liu wrote: > Each node has 32 sys-stripe threads. With 3 servers and 1 client, there > are a total o

Re: with nested entry processors, child completes but parent IgniteFuture does not

Have you tried to get a thread dump to understand which code is blocking the sys-stripe thread? On Thu, Oct 31, 2024 at 5:56 AM Raymond Liu wrote: > Hm, the scenario you described doesn't sound accurate here. I guess it's > my fault for not including logs. I will paste them below. The logs show

Re: with nested entry processors, child completes but parent IgniteFuture does not

Hm, the scenario you described doesn't sound accurate here. I guess it's my fault for not including logs. I will paste them below. The logs show all four *inner* entry processors complete without being blocked - we see four "Entered InnerEntryProcessor" and four "Exiting InnerEntryProcessor" lines.

Re: with nested entry processors, child completes but parent IgniteFuture does not

Looks like a deadlock to me. Processor 1 invokes processor 2 and blocks on a future, stripe thread T is blocked Processor 2 invokes processor 3, which needs stripe thread T and waits forever General advice - do not block striped pool threads. Avoid IO, waiting for futures, etc. An entry processor

Re: rejecting communication connection & Failed to processselector key

Yes TLS is enabled.  But that's a must for our prod env.  Will try renew certificates and see how it goes.  Thanks ! ---Original--- From: "Stephen Darlington"

Re: Updating ignite.

There is no "enterprise" in Apache Ignite. Some vendors provide products based on Ignite with added features. On Tue, Oct 29, 2024 at 4:01 PM John Smith wrote: > And this is specifically an open source vs "enterprise" feature? > > On Tue, Oct 29, 2024 at 2:33 AM Pavel Tupitsyn > wrote: > >> Ye

Re: Updating ignite.

And this is specifically an open source vs "enterprise" feature? On Tue, Oct 29, 2024 at 2:33 AM Pavel Tupitsyn wrote: > Yes, thick clients will fail to connect on version mismatch (thin clients > will work across versions). > > On Mon, Oct 28, 2024 at 3:51 PM John Smith wrote: > >> Are we limi

Re: Ignite through Redis interface - Restarted node unable to join

What do you mean "through the Redis interface"? I don't see anything obvious in your configuration or logs. The most suspicious thing is that you have a tiny amount of Java heap space and a large number of tables. On Mon, 28 Oct 2024 at 19:27, Ashu Pachauri wrote: > Hi folks, > > We have been f

Re: Updating ignite.

Yes, thick clients will fail to connect on version mismatch (thin clients will work across versions). On Mon, Oct 28, 2024 at 3:51 PM John Smith wrote: > Are we limited by version when updating ignite? I have a 3 node "central" > cluster and a bunch of THICK clients connecting. Can we update the

Re: Persistence and workDirectory vs. storagePath

storagePath defaults to "{workDirectory}/db". It is enough to set workDirectory to a persistent volume. On Tue, Oct 29, 2024 at 4:05 AM Darius Cooper wrote: > Installing Ignite to AWS EKS. > > The Ignite docs say "workDirectory" should be on a volume that is > retained across pod-restarts. That

Re: Update roadmap

Excellent, that's great info. On Fri, Oct 25, 2024, 12:02 PM Pavel Tupitsyn wrote: > Hello, I would expect a new release late this year / early next year. > > The work goes on, but 2.16 is stable and we are not in a rush to release > something. > > On Fri, Oct 25, 2024 at 4:42 PM Jupiter Tangles

Re: rejecting communication connection & Failed to processselector key

> > 24-10-08 18:34:27.642 [INFO ] data-streamer-stripe-3-#12%app_primary% > o.a.i.s.c.t.TcpCommunicationSpi:117 - TCP client created [client=null, node > addrs=[/10.254.28.57:47100, /127.0.0.1:47100], duration=211ms] > > 24-10-08 18:34:28.728 [INFO ] > grid-nio-worker-tcp-comm-2-#25%TcpCommuni

Re: Update roadmap

Hello, I would expect a new release late this year / early next year. The work goes on, but 2.16 is stable and we are not in a rush to release something. On Fri, Oct 25, 2024 at 4:42 PM Jupiter Tangles wrote: > Hello, > > I do not see any published updates to ignite since December 2023: > > htt

Re: rejecting communication connection & Failed to processselector key

Added log details of another “Broken pipe” excpetion.  Per the log the two nodes appear connecting to each other for multiple times though I did not set “usePairedConnections” .  Any idea how below activities can be explained , or some special configs are needed for container environment ?  Tha

Re: Ignite 2.10 error - java.net.SocketException: Software caused connection abort: socket write error

Given the error, all we can really say is that it doesn't look like an Ignite issue -- the error is "can't write to socket" which is lower-level than even Java. On Wed, 9 Oct 2024 at 05:23, Charlin S wrote: > Hi Stephen, > Thank you for your email. > Why is it not happening? for other client nod

Re: Ignite 2.10 error - java.net.SocketException: Software caused connection abort: socket write error

Hi Stephen, Thank you for your email. Why is it not happening? for other client nodes which are there in the same network. Regards, On Tue, 8 Oct 2024 at 18:22, Stephen Darlington wrote: > It's likely something to do with your network configuration. Firewall, > routing, something like that. Ba

Re: Ignite 2.10 error - java.net.SocketException: Software caused connection abort: socket write error

It's likely something to do with your network configuration. Firewall, routing, something like that. Basically, Ignite tried to write to a port and the OS wouldn't allow it. On Mon, 7 Oct 2024 at 12:55, Charlin S wrote: > Hi All, > I am having a requirement to start/add a new Ignite client node

Re: rejecting communication connection & Failed to process selector key

Yes - kubernetes discovery spi.   No client nodes are out of the cluster. and below setting for communication spi. config of communicationSpi

Re: rejecting communication connection & Failed to process selector key

Are you using the kubernetes discovery SPI?Humphrey On 16 Sep 2024, at 02:58, MJ <6733...@qq.com> wrote:Hi Igniters,   I am experiencing the “Failed to process selector key” error once every one or two days. Every time it appears received and rejected multiple communication connections and then th

Re: How to use ClusterNodeAttributeAffinityBackupFilter to have atleast one replica in second zone

Hello Alex, Thanks for the suggestion. I will try with both options. Most likely I will use the custom AffinityBackupFilter implementation you provided and will try to enhance zone skewness configurable. Regards, Amit On Thu, Sep 19, 2024 at 3:16 PM Alex Plehanov wrote: > Hello Amit, > > You

Re: How to use ClusterNodeAttributeAffinityBackupFilter to have atleast one replica in second zone

Hello Amit, You can use ClusterNodeAttributeAffinityBackupFilter and introduce some virtual zones. For example, if you have 5 nodes in zone 1 and 5 nodes in zone 2, you can assign 'zone1' attribute value to 3 nodes from zone 1, assign 'zone2' attribute value to 3 nodes from zone 2, and assign 'zon

Re: How to use ClusterNodeAttributeAffinityBackupFilter to have atleast one replica in second zone

Hi Pavel, Well based upon documentation of ClusterNodeAttributeAffinityBackupFilter.java class. It says "This implementation will discard backups rather than place multiple on the same set of nodes. This avoids trying to cram more data onto remaining nodes when some have failed." and i have verif

Re: How to use ClusterNodeAttributeAffinityBackupFilter to have atleast one replica in second zone

Hi Amit, > if the backup count is let's say 2, Ignite won't create a second backup as there are not enough zones Not correct - Ignite will create backups anyway. - A backup is a copy of a partition on another node - With 2 backups every partition will have 3 copies (1 primary, 2 backup), all on d

Re: rejecting communication connection & Failed to process selector key

I suspect your openshift networking is doing something wrong: NAT is particularly suspicious. Share your discovery configuration and openshift network layout. On Mon, Sep 16, 2024 at 4:38 AM MJ <6733...@qq.com> wrote: > Donot think so. As below the remote ip 10.254.13.83 >

Re: Failed to execute query because cache partition has been lost

does Ignites offers any mechanism to prevent this or should I implement it? > > > > > > *From:* Pavel Tupitsyn > *Sent:* miércoles, 18 de septiembre de 2024 11:30 > *To:* user@ignite.apache.org > *Subject:* Re: Failed to execute query because cache partition has been >

Re: Failed to execute query because cache partition has been lost

will be allowed for keys in valid > partitions), and when the node rejoins to the cluster, reset the lost > partitions. > > > > What event do I have to listen? Maybe EVT_NODE_JOINED? > > > > *From:* jrov...@identy.io > *Sent:* miércoles, 18 de septiembre de 2024 11:54

RE: Failed to execute query because cache partition has been lost

: miércoles, 18 de septiembre de 2024 11:54 To: user@ignite.apache.org Subject: RE: Failed to execute query because cache partition has been lost Ok, thanks, I understand. But in this case, if someone tries to modify the DB while a node is down, does Ignites offers any mechanism to prevent this or

RE: Failed to execute query because cache partition has been lost

Ok, thanks, I understand. But in this case, if someone tries to modify the DB while a node is down, does Ignites offers any mechanism to prevent this or should I implement it? From: Pavel Tupitsyn Sent: miércoles, 18 de septiembre de 2024 11:30 To: user@ignite.apache.org Subject: Re

Re: Failed to execute query because cache partition has been lost

> 2 servers and 1 client, and no backups > shut down one node There are no backups => any node shutdown leads to partition loss. If you want to ignore data loss, set partitionLossPolicy = IGNORE [1] [1] https://ignite.apache.org/docs/latest/configuring-caches/partition-loss-policy On Wed, Sep 18

Re: rejecting communication connection & Failed to process selector key

Donot think so.  As below the remote ip 10.254.13.83 is the another server node.  --- log Accepted incoming communication connection [locAddr=/10.254.32.162:47100, rmtAddr=/10.254.13.83:35160]  super=GridNioSessionImpl [locAddr=/10.254.32.162:52542, rmtAddr=/10.254.13.83:47100 ---  so the

RE: Self manageemnt script ( Control Scripts) + Ignite .NET Clusters

Sent: Monday, September 16, 2024 12:36 PM To: Mandal, Satyajit: IT (PUN) Cc: user@ignite.apache.org Subject: Re: Self manageemnt script ( Control Scripts) + Ignite .NET Clusters CAUTION: This email originated from outside our organization - ptupit...@apac

Re: Self manageemnt script ( Control Scripts) + Ignite .NET Clusters

Hi, control script [1] uses REST API You can disable it or set up secret keys, SSL, etc, as described in the docs [2] To do that from .NET, use IgniteConfiguration.SpringConfigUrl property [3] [1] https://ignite.apache.org/docs/latest/tools/control-script [2] https://ignite.apache.org/docs/latest

Re: rejecting communication connection & Failed to process selector key

Looks like some non-Ignite application connects to the Ignite server, then sends unexpected data or disconnects quickly. Could it be some kind of a security tool, port scanner, or a misconfigured service somewhere on the network? On Mon, Sep 16, 2024 at 3:59 AM MJ <6733...@qq.com> wrote: > Hi Ig

Re: Rolling Update

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 topol

Re: Rolling Update

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 ch

Re: Rolling Update

Thanks, I’ll incorporate that check of joining the cluster as well.I didn’t know about that race condition.HumphreyOn 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 finis

Re: Rolling Update

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

Re: Rolling Update

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 mi

Re: Rolling Update

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 whic

Re: Rolling Update

I assume you have created your caches/tables with backups>=1. You should restart one node at a time, and wait until the restarted node has rejoined the cluster, then wait for rebalancing to begin, then wait for rebalancing to finish before restarting the next node. Kubernetes readiness probes aren

Re: Rolling Update

Thanks, I meant Rolling Update of the same version of Ignite (2.16). Not upgrade to a new version. We have our ignite embedded in Spring Boot application, and when changing code we need to deploy new version of the jar.HumphreyOn 3 Sep 2024, at 19:24, Gianluca Bonetti wrote:HelloIf you want to up

Re: Rolling Update

Hello If you want to upgrade Apache Ignite version, this is not supported by Apache Ignite "Ignite cluster cannot have nodes that run on different Ignite versions. You need to stop the cluster and start it again on the new Ignite version." https://ignite.apache.org/docs/latest/installation/upgrad

Re: Does the JDBC thin driver support partition aware execution of INSERT statements?

A) From what I can see - no, it resolves a hostname to a single address B) Not sure about this On Thu, Aug 29, 2024 at 5:32 PM Jeremy McMillan wrote: > Thanks Pavel! > > That is really cool, but looks like it only works in very carefully > managed situations. > > Do you happen to know off the to

Re: Does the JDBC thin driver support partition aware execution of INSERT statements?

Thanks Pavel! That is really cool, but looks like it only works in very carefully managed situations. Do you happen to know off the top of your head A) the JDBC thin driver client needs to have a complete list of node addresses. Q: will it collect IPs from DNS hostnames that return multiple A

Re: Does the JDBC thin driver support partition aware execution of INSERT statements?

JDBC driver does support partition awareness [1] And it works for INSERT statements too, as I understand [2] > When a query is executed for the first time, the driver receives the partition distribution for the table > that is being queried and saves it for future use locally. > When you query thi

Re: Does the JDBC thin driver support partition aware execution of INSERT statements?

Probably not in the way you might expect from the question. From the documentation: "The driver connects to one of the cluster nodes and forwards all the queries to it for final execution. The node handles the query distribution and the result’s aggregations. Then the result is sent back to the cli

Re: Ignite Thick Client running Node Filters???

Service has a User Attribute that indicates which service to run. >>> Each ServerNode sets two User Attributes - indicating it should run two >>> services. >>> >>> When the Cluster starts up from nothing, it sets the BLT and starts all >>> services a

Re: Ignite Thick Client running Node Filters???

services. >> >> When the Cluster starts up from nothing, it sets the BLT and starts all >> services as expected. >> >> After the BLT is set, the cluster ports are opened (via firewalld) to >> allow the clients to connect to the cluster and start utilizing the >

Re: Ignite Thick Client running Node Filters???

d (via firewalld) to > allow the clients to connect to the cluster and start utilizing the > services offered. > > If, after this point, a BLT cluster node restarts and drops out of the > cluster and then re-joins, the Node Filter's apply() method is invoked on > all ServerNod

Re: Query regarding Apache ignite open source

It isn't clear exactly what you're asking in any of these questions. If you want a guided introduction to Apache Ignite, maybe you should try to attend a free training workshop. This should prepare you to navigate the documentation and enable you to answer your own questions as they arise. https:/

Re: Query regarding Apache ignite open source

Apache Ignite is fully open-source, this is how Apache Software Foundation works. All features, everything you see on the website, in the docs, blogs etc is open-source. The development happens in the open as well, JIRA, discussions, pull requests are open to the public. On Tue, Aug 20, 2024 at 1

Re: Query regarding Apache ignite open source

Thanks for the response. I am looking into Apache ignite for our caching needs and specifically few features like 1. backup servers configurable to be sync or async. 2. Write behind updates in the cluster 3. Entry processor Are the above features part of open source? Is there a way to know whi

Re: Query regarding Apache ignite open source

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 rel

Re: Ignite H2 to Calcite issues

Hi Alex, Also looks like the query does work with this error/warning. But not sure what's the implication on the result or overall performance. Thanks, Amit Jolly On Fri, Aug 16, 2024 at 10:03 AM Amit Jolly wrote: > Hi Alex, > > Find below the details you requested. > > CacheConfiguration cac

Re: Ignite H2 to Calcite issues

Hi Alex, Find below the details you requested. CacheConfiguration cacheConfiguration = new CacheConfiguration<>(); cacheConfiguration.setCacheMode(CacheMode.PARTITIONED); cacheConfiguration.setBackups(2); cacheConfiguration.setExpiryPolicyFactory(CreatedExpiryPolicy.factoryOf(new Duration(MINUTES

Re: Ignite H2 to Calcite issues

Amit, Can you please show the output of "EXPLAIN PLAN FOR "? I've found the bug in index scan on binary object field (ticket [1]), but I can't reproduce it with select without "order by", or without forcing index scan. [1]: https://issues.apache.org/jira/browse/IGNITE-23004 ср, 14 авг. 2024 г. в

Re: Ignite H2 to Calcite issues

HI, Jeremy & Alex, First of all thanks for the quick response. Sorry for the confusion here, We are trying to switch from using H2 as a default query engine to Calcite due to above mentioned CVE's. I have read the ticket and understood that those CVE's do not have any impact on how Ignite uses H2

Re: Ignite H2 to Calcite issues

Amit: I'm concerned that you may be misreading the CVE details in the ticket you cited, since you indicated you are moving TO H2.. Also the stack trace is a Calcite stack trace. This is ambiguous whether this is the before (persistence config changes) depicted or after changing persistence depicte

Re: Ignite H2 to Calcite issues

Hello, Please provide the query you are using. Such a stack can't be caused by just "select * from table" (at least sorting is used). Perhaps you are using "ORDER BY" for fields which can't be compared in SQL (complex _key or _val for example). вт, 13 авг. 2024 г. в 17:17, Amit Jolly : > > Hi, >

Re: High speed writing(INSERT) can significantly reduce SQL query performance

- Try changing QueryThreadPoolSize [1] - Consider Data Streamer [2] for high-volume data insertion instead of SQL [1] https://ignite.apache.org/docs/latest/perf-and-troubleshooting/thread-pools-tuning#queries-pool [2] https://ignite.apache.org/docs/latest/data-streaming On Fri, Aug 9, 2024 at 3:1

Re: Requesting information about known CVEs related to Apache Ignite 2.16

Hi Jeremy Thanks for your response and appreciate the insights. Vishy Vishy Ramaswamy Modernization Architect | Workload Automation Mainframe Division | Broadcom mobile: +1.236.638.9672 CAN-British Columbia Remote Location vishy.ramasw...@broadcom.com | broadcom.com On Fri, Aug 2, 2024

Re: Requesting information about known CVEs related to Apache Ignite 2.16

There is an example of and gentle introduction to building Ignite out of Maven dependencies in the Ignite Essentials workshop. You could enroll in an upcoming free training session or access the same material on your own schedule for free on university.gridgain.com. The Ignite quick start documenta

Re: Requesting information about known CVEs related to Apache Ignite 2.16

Hi Jeremy thanks for your response. ill take a look at the scan reports. To be more specific we are running into the following issue We are using Ignite standalone, from https://ignite.apache.org/download.cgi, version 2.16.0. We are using thin client to connect to Ignite. When running Ignite itself

Re: Requesting information about known CVEs related to Apache Ignite 2.16

Apache Ignite release notes contain details about fixes including CVEs addressed. https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt Current known vulnerabilities are determined by vulnerability testing, which differs depending on who (test/scan tool vendor, stakeholder/user) does the

RE: Ignite cache with custom key : key not found

: mercredi 31 juillet 2024 13:13 À : user@ignite.apache.org Objet : Re: Ignite cache with custom key : key not found Well, the quick work around would be to add at least one named field to the object. Meanwhile, we'll try to figure out the right way to fix it without breaking backward compa

Re: Ignite cache with custom key : key not found

che. As we can see there are 2 keys in the cache, that deserialize to > the same object, but have different binary representation. > See the capture: > Hope you'll manage to run the example. > > Regards > Louis > -- > *De :* Pavel Tupitsyn >

Re: Ignite cache with custom key : key not found

nks, >> >> Louis C. >> -- >> *De :* Louis C >> *Envoyé :* lundi 22 juillet 2024 17:06 >> *À :* user@ignite.apache.org >> *Objet :* RE: Ignite cache with custom key : key not found >> >> Hello, >> >> Thanks

Re: Ignite cache with custom key : key not found

a ? > > Thanks, > > Louis C. > -- > *De :* Louis C > *Envoyé :* lundi 22 juillet 2024 17:06 > *À :* user@ignite.apache.org > *Objet :* RE: Ignite cache with custom key : key not found > > Hello, > > Thanks for your answers. > > As for

RE: Ignite cache with custom key : key not found

Sorry to up this subject, but I have not been able to find a solution/reason for this problem. Does anyone have an idea ? Thanks, Louis C. De : Louis C Envoyé : lundi 22 juillet 2024 17:06 À : user@ignite.apache.org Objet : RE: Ignite cache with custom key

RE: Ignite cache with custom key : key not found

__ De : Николай Ижиков de la part de Nikolay Izhikov Envoyé : lundi 22 juillet 2024 10:33 À : user@ignite.apache.org Objet : Re: Ignite cache with custom key : key not found Hello. It common issue with the thin client. Please, set same value of BinaryConfiguration#compa

Re: Ignite cache with custom key : key not found

Hello. It common issue with the thin client. Please, set same value of BinaryConfiguration#compactFooter explicitly to false both on the server side and client side. > On 22 Jul 2024, at 10:32, Pavel Tupitsyn wrote: > > Hello, could you please attach a reproducer? > > This might have to do wi

Re: Ignite cache with custom key : key not found

Hello, could you please attach a reproducer? This might have to do with type names / ids mismatch, but hard to tell without the code. On Fri, Jul 19, 2024 at 7:39 PM Louis C wrote: > Hello, > > I have a strange problem for which I can't find the reason. > > I made a cache (key/value cache) with

Re: Ignite 2.16 entry processors sometimes execute twice

for its retry. On Fri, Jul 12, 2024 at 5:54 AM Pavel Tupitsyn wrote: > > how did you discover the answer to this > > By enabling "break on all exceptions" in my IDE. > This exception is not logged, Ignite considers this a normal situation, > registers the type automat

Re: Ignite 2.16 entry processors sometimes execute twice

> how did you discover the answer to this By enabling "break on all exceptions" in my IDE. This exception is not logged, Ignite considers this a normal situation, registers the type automatically and then re-runs the processor. As Slava said, you should not rely on the fact that

Re: Ignite 2.16 entry processors sometimes execute twice

Hi Raymond, Besides the answer Pavel provided, please take into account that entry processor implementation should avoid generating random values for the entry being updated. For example, mutableEntry.setValue(rand.nextInt()) might lead to data inconsistency. * * An instance of entry processor m

Re: Ignite 2.16 entry processors sometimes execute twice

> > - Raymond > > On Thu, Jul 11, 2024 at 8:42 AM Pavel Tupitsyn > wrote: > >> - Duplicate invocation happens due to automatic retry >> for UnregisteredClassException caused by return value of type >> LightsaberColor. >> - Ignite handles the exception, regist

Re: Ignite 2.16 entry processors sometimes execute twice

sed by return value of type > LightsaberColor. > - Ignite handles the exception, registers the type automatically, and > re-runs the processor > - This only happens once, subsequent invocations are not duplicated > - To fix this, register the LightsaberColor explicitly in > Binary

Re: Ignite 2.16 entry processors sometimes execute twice

- Duplicate invocation happens due to automatic retry for UnregisteredClassException caused by return value of type LightsaberColor. - Ignite handles the exception, registers the type automatically, and re-runs the processor - This only happens once, subsequent invocations are not duplicated - To

  1   2   3   4   5   6   7   8   9   10   >