Re: Apache Ignite 2.8 ETA

Hi, 2.8 got postponed multiple times due to various fixes. This is discussed on the dev list: http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-8-RELEASE-Time-Scope-Manager-td43616.html There is no ETA right now I believe. We understand that 2.8 is long overdue, but it is a

Re: cache put/clear atomicity query

Hi Stephen, Yes, you are correct. I meant replace and remove. I tried to see what happens when we remove the key when replace is in progress and node resulted in SEVERE error and node is blocked. I stopped replace method in between after it determined that key exists at line 613,

High CPU usage on sun.nio.ch.EPollArrayWrapper.epollWait when Node Failover

Hi, I have problem in some Ignite (version 1.9) thread. Issue detail process 1. Ignite Running on Multi Server Machine - Linux and JDK 1.7.0_95 environment, Over 2 Ignite process run on the Machine 2. One Machine Shutdown 3. Ignite Failover and Rebalanced 4. Ignite seemingly normal behavior

Re: Data Load to Ignite cache is very slow from Oracle Table

Hi Ilya, Thank you so much. Issue is resolved after following the steps mentioned in the link you have shared. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Ignite 2.7.6 : Discovery Threads reporting OOPS

Hi, We have Ignite data nodes reporting out of memory after many days. What could be possible reasons? [16:45:04,018][SEVERE][tcp-disco-client-message-worker-#2404][TcpDiscoverySpi] Runtime error caught during grid runnable execution: GridWorker [name=tcp-disco-client-message-worker,

"Adding entry to partition that is concurrently evicted" error

Hello! I've got a 6 node Ignite 2.7.5 grid. I had this strange issue where multiple nodes hit the following exception - [ERROR] [sys-stripe-53-#54] GridCacheIoManager - Failed to process message [senderId=f4a736b6-cfff-4548-a8b4-358d54d19ac6, messageType=class

Apache Ignite 2.8 ETA

Hi, Not sure if we have developers around, but is there an ETA for the official 2.8? On the release notes it was planned for yesterday. -- Sent from: http://apache-ignite-users.70518.x6.nabble.com/

New Blog: Why my in-memory Ignite cluster underperforms? Network and co-located compute

Igniters, I've just published an article that describes one of the reasons for why an Ignite cluster can underperform. It's reviewed how a selection of proper Ignite APIs can put less pressure on the network and proliferate the performance:

Re: New blog post on Apache Ignite in AWS

Sergey, There is one point that I missed initially. It's explained that the address resolver is required to establish connections from the local client to EC2 servers but it's not underscored that the servers might need to open connections to the client at any given time. And if the client

Re: New blog post on Apache Ignite in AWS

Please try to fix the screenshot issue what I mentioned I think it’s a easy fix. On Tuesday, January 28, 2020, Sergey Chugunov wrote: > Thank you for the feedback! > > Than I'll focus my next post on connecting to AWS cluster with other > methods like JDBC, thin clients etc. > > On Sat, Jan 25,

Re: New blog post on Apache Ignite in AWS

Thank you for the feedback! Than I'll focus my next post on connecting to AWS cluster with other methods like JDBC, thin clients etc. On Sat, Jan 25, 2020 at 7:22 AM sri hari kali charan Tummala < kali.tumm...@gmail.com> wrote: > cant open second screenshot I mean cant expand , a simple example

Re: cache put/clear atomicity query

First, I assume you mean remove rather than clear? Clear removes all entries in the cache (and takes no parameters). With that, yes, your sequence of events could happen. There are (at least) two alternative ways of doing it. “Put” doesn’t “check that a value already exists.” It simply puts

cache put/clear atomicity query

Hello, Consider I have below cache on server node Cache --- key,value 1 | a >From client node1, I try to do put(1,a) and from client node2 I try to do clear(1). Are put and clear atomic, mean could this happen? 1. cliennode1 put operation identified that

Cache.replace-K-V-V- performing slow

Hi All, We are running Ignite cluster with 12 nodes running Ignite 2.7.0 on openjdk 1.8 RHEL platform. We saw some slowness with one of our process and when we tried to drill it further by profiling the JVM, the main culprit (taking ~78% of total time) seems to be coming from cache.repalce(K,V,V)

Re: JVM crashed with SIGSEGV with stack trace to OptimizedObjectOutputStream.writeObject

Thanks Ilya, Sorry I missed to update on your response. We are using Ignite 2.7.0 with openjdk 1.8 (RedHat distribution). Is there any existing Ignite bug with this version ? We are not yet eagerly looking to upgrade Java 11. Do you think Ignite or Java upgrade handle this ? Regarding different

Error Connecting to Web Console

Hi , We are doing a POC on using the Ignite in-memory capabilities for our application and as a part of this trying to connect to Ignite Web Console but we end up facing the error provided in the attachment after downloading the web agent and starting the agent by executing the