Re: concurrency issues in entry processor

[Kamil Misuth]

Hi Semyon,

I have tracked the issue down in our code base and in the end it wasn't 
Ignite's fault.


Sorry for the false alarm.

Kamil

On 5/19/21 9:43 AM, Kamil Misuth wrote:

Hi,

yes. I am preparing a reproducer but this is happening in a production 
grade app deployed in our testing environment. I will send you the 
reproducer once its' ready. Hopefully it won't take long.


Kamil

On 5/19/21 7:48 AM, Данилов Семён wrote:

Hello!

Ignite indeed has such optimizations but I don't see them enabled in 
your configuration so perhaps it's a bug.
I still have trouble reproducing your issue, so could you please send 
a minimal reproducer?


Kind regards, Semyon.

19.05.2021, 06:12, "Kamil Misuth" :

Hi Semyon,

we are using Ignite 2.8.1. That being said, could Ignite really be 
using
some behind the scenes optimization which allows for a value 
instance to

be re-used between multiple EntryProcessor runs?

Kamil

On 5/17/21 11:45 AM, Данилов Семён wrote:
  I tried reproducing your issue but with no avail. What version of 
Apache Ignite do you use?


  Kind regards, Semyon.

  17.05.2021, 11:03, "kimec.ethome.sk" :

  Hi Semyon,

  the cache configuration is:

  CacheConfiguration> cc = new
  CacheConfiguration<>();
  cc.setName("fancyCache");
  cc.setAtomicityMode(CacheAtomicityMode.ATOMIC);
  cc.setCacheMode(CacheMode.PARTITIONED);
  cc.setBackups(1);
  cc.setRebalanceMode(CacheRebalanceMode.SYNC);
  cc.setPartitionLossPolicy(PartitionLossPolicy.READ_WRITE_SAFE);
  cc.setReadFromBackup(false);

  Kamil

  On 2021-05-17 09:06, Данилов Семён wrote:

Hello, Kamil!

Could you please provide your cache configuration?

Kind regards, Semyon.

17.05.2021, 09:10, "kimec.ethome.sk" :

Greetings,

we have recently run into a concurrency issue in an entry 
processor.


Suppose we have a cache that is IgniteCacheHashMap
String>>.
Entries in this cache are added and modified solely via
EntryProcessors.

Now suppose that the cache contains a value for key 1L - a 
map with

several key value pairs.
Next suppose, we execute the same entry processor for the 
key 1L TWICE

at the very same time on the same value.

Up until now my understanding was that since the HashMap is 
stored
offheap, each entry processor would get it's own 
deserialized copy of
the HashMap for modification and Ignite would then 
orchestrate the
update of the value (serializing/deserializing the value to 
offheap

reagion).

However, what we see in our test case is that both entry 
processor

"executions" receive the same deserialized HashMap and thus the
modification of the HashMap in both processors at the same 
time causes

java.util.ConcurrentModificationException.

I would expect this kind of behaviour in case the HashMap 
was stored

on
regular Java heap but if the value is deserialized from offheap
region?
Is my logic correct? I am trying to wrap my head around this 
but does
this mean that any complex datastractures stored in must 
require

separate locking?

Thanks!

Kamil

Re: Scan query ClassNotFoundException

[ict.management.trexon]

Incredible.

By treating the cache with withKeepBinary (), obviously the
IgniteBiPredicate  also, now WORKS! However, such a
solution is not normal.

Below the classes and the search method:

public class SimplePojo implements Serializable{
private static final long serialVersionUID = 1L;
private Integer id;
private String str1;
public SimplePojo() {}
public Integer getId() {return id;}
public String getStr1() {return str1;}
public void setId(Integer id) {this.id = id;}
public void setStr1(String str1) {this.str1 = str1;}
}

public class SmplePojoFilter implements IgniteBiPredicate {
private static final long serialVersionUID = 1L;
private Integer idToFind;
private String srtToFind;
public SmplePojoFilter() {}
public SmplePojoFilter(Integer idToFind, String srtToFind) {
super();
this.idToFind = idToFind;
this.srtToFind = srtToFind;
}
@Override
public boolean apply(Integer e1, BinaryObject e2) {
SimplePojo sp =
e2.deserialize(SimplePojo.class.getClassLoader());
return sp.getId().equals(idToFind);
}
}

IgniteCache cache = ignite.getOrCreateCache(c_cfg);
SmplePojoFilter spf = new SmplePojoFilter(1, null);
Collection res = new ArrayList<>();
try(QueryCursor> cursor =
cache.withKeepBinary().query(new ScanQuery<>(spf))){
cursor.forEach(entry->res.add(entry.getValue().deserialize()));
}



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

RE: 2.8.1 : CacheEntryProcessor for insert/update within Transaction supported ?

[VeenaMithare]

Hi Anton, 

Thanks for the reply . 

As per the definition of entry processor - it is used to execute updates on
entries on
the nodes that store it - currently this is not the case. It runs on the
client side as well. 



Will this issue not be resolved if the entry processor ran only on the
server nodes.

regards,
Veena.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Bug in GridCacheWriteBehindStore

[Ilya Korol]

I've created a Jira for this issue 
https://issues.apache.org/jira/browse/IGNITE-14898


10.06.2021 18:56, Ilya Kasnacheev пишет:

Hello!

I guess so. I think you should file a ticket against Ignite JIRA.

Regards,
--
Ilya Kasnacheev


ср, 9 июн. 2021 г. в 20:26, gigabot >:


There's a bug in GridCacheWriteBehindStore in the flusher method.


https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/store/GridCacheWriteBehindStore.java#L674



The logic states there that if flush thread count is not a power
of 2,  then
perform some math that is not guaranteed to return a positive
number. For
example, if you pass this string as a key it returns a negative
number:
 accb2e8ea33e4a89b4189463cacc3c4e

and then throws an array out of bounds exception when looking up
the thread.

I'm surprised this bug has been there so long, I guess people are not
setting their thread counts to non-powers-of-2.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: SQL EXPLAIN ANALYZE

[Devakumar J]

Hi,

In general. I can see in server logs if any query executes longer, log shows
Long running query with information about scan count and index usage.

But if i execute from sql client EXPLAIN ANALYZE   which returns two
rows as per below link:

https://apacheignite-sql.readme.io/docs/performance-and-debugging#using-explain-statement

But i dont scan count returned in this. Is there any to enable it from
ignite config?

Thanks & Regards,
Devakumar J



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Split brain in 2.9.0?

[Ilya Kasnacheev]

Hello!

It looks like your nodes has re-joined with different consistent IDs/data
dirs and thus some of your data was not accessible.

Please make sure that your nodes preserve their consistent IDs/data dirs
over restart.

It also looks like your one failing node has formed this topology as
opposed to two surviving ones, which seem to have restarted and rejoined to
it. What's the specific ordering of events?

Regards,
-- 
Ilya Kasnacheev


пт, 11 июн. 2021 г. в 04:30, Devin Bost :

> We encountered a situation after a node unexpectedly went down and came
> back up.
> After it came back, none of our transactions were going through (due to
> rollbacks), and we started getting a lot of exceptions in the logs. (I've
> added the exceptions at the bottom of this message.)
> We were getting "Failed to execute the cache operation (all partition
> owners have left the grid, partition data has been lost)", so we tried to
> reset the partitions (since these are persistent caches), and the commands
> succeeded, but we kept seeing errors.
>
> We checked the cluster state, and it looks like we have two nodes that
> came up with different IDs.
>
> Cluster state: active
> Current topology version: 1170
> Baseline auto adjustment disabled: softTimeout=30
> Current topology version: 1170 (Coordinator:
> ConsistentId=1455b414-5389-454a-9609-8dd1d15a2430, Order=1)
> Baseline nodes:
> ConsistentId=1a0aa611-58b7-479a-b1e6-735e31f87ed9, State=ONLINE,
> Order=1169
> ConsistentId=92bc8407-30f1-433d-9c32-5eeb759c73be, State=OFFLINE
> ConsistentId=b5875ab9-7923-46c9-b3f3-1550455a24e5, State=OFFLINE
>
> 
> Number of baseline nodes: 3
> Other nodes:
> ConsistentId=1455b414-5389-454a-9609-8dd1d15a2430, Order=1
> ConsistentId=5e8f3b03-aa20-45aa-892a-37e988e3741f, Order=2
>
>
> Could this be a split-brain scenario?
>
> Here's the more complete logs:
>
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute the cache operation (all partition owners have left the
> grid, partition data has been lost) [cacheName=propensity-customer,
> partition=430, key=com.company.PropensityKey [idHash=362342248,
> hash=42458921, customerId=142045188, variant=MODEL_A]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2083)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:1110)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:676)
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCacheGetRequest.process(ClientCacheGetRequest.java:41)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:99)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:202)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:56)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute the cache operation (all partition owners have left the
> grid, partition data has been lost) [cacheName=propensity-customer,
> partition=430, key=com.company.PropensityKey [idHash=362342248,
> hash=42458921, customerId=142045188, variant=MODEL_A]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateKey(GridDhtTopologyFutureAdapter.java:209)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:128)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.validate(GridPartitionedSingleGetFuture.java:859)
>

Re: SQL EXPLAIN ANALYZE

[Ilya Kasnacheev]

Hello!

I can remember seeing scan count in regular EXPLAINs.

Regards,
-- 
Ilya Kasnacheev


пт, 11 июн. 2021 г. в 08:22, Devakumar J :

> Hi,
>
> I see the ANALYZE syntax doesn't show the scan count.
>
> Is this not supported in ignite?
>
> Thanks & Regards,
> Devakumar J
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Scan query ClassNotFoundException

[ict.management.trexon]

I've also prepared a test with the simplest POJO possible, ad the
ClassNotFoundException persist with scanquery:

public class SimplePojo implements Serializable{
private static final long serialVersionUID = 1L;
private Integer id;
private String str1;
public SimplePojo() {}
public Integer getId() {return id;}
public String getStr1() {return str1;}
public void setId(Integer id) {this.id = id;}
public void setStr1(String str1) {this.str1 = str1;}
}

public class SmplePojoFilter implements IgniteBiPredicate {
private static final long serialVersionUID = 1L;
private Integer idToFind;
private String srtToFind;
public SmplePojoFilter() {}
public SmplePojoFilter(Integer idToFind, String srtToFind) {
super();
this.idToFind = idToFind;
this.srtToFind = srtToFind;
}
@Override
public boolean apply(Integer e1, SimplePojo e2) {
return e2.getId().equals(idToFind);
}
}

IgniteCache cache = ignite.getOrCreateCache(c_cfg);
SmplePojoFilter spf = new SmplePojoFilter(1, null);
Collection res = new ArrayList<>();
try(QueryCursor> cursor =
cache.query(new ScanQuery<>(spf))){
cursor.forEach(entry->res.add(entry.getValue()));
}





--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Scan query ClassNotFoundException

[ict.management.trexon]

Hi, why the scanquery return me this error?
I've a cache , the POJO is a simple entity from jar dependency,
it extend an abstract class who implement an interface that extends
serializable.
I've follow the example on page
https://ignite.apache.org/docs/latest/key-value-api/using-scan-queries
The IgniteBiPredicate is a concrete class, not a lambda.
If i do an IgniteRunnable with the POJO class, no error returned, all work
well. Why scan query fails?
tank!



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: AtomicReference issue with different userVersions

[tanshuai]

I don't think we should treat it as a bug. But it does introduce tricky
exceptions under certain circumstances.



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/