Re: Ignite SQL Grid Load

[Raja]

Andrew,

Figured out the issue. We created a user defined spatial function and in it
we were using an object that's not thread safe. That created an issue.

Thank you very much

Raja



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-SQL-Grid-Load-tp11072p11086.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Is it safe to use NTP time synchronization system on different ignite nodes？

[bluehu]

I want to use NTP to synchronize system time on different ignite nodes, does
it have an impact on data consistency?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Is-it-safe-to-use-NTP-time-synchronization-system-on-different-ignite-nodes-tp11085.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

generic class support

[shawn.du]

Hi,see below configuration:                                                     java.lang.String                     com.example.MyClass                       MyClass is a generic class.  T can be Integer/Long/byte[]/String etc simple data type.public class MyClass{    @QuerySqlField     private T value;}Does ignite support? 






ThanksShawn

Re: Pessimistic TXN did not release lock on a key, all subsequent txns failed

[Andrey Gura]

Your logs should contain exception with stack trace that looks like
piece of log bellow. You can try find "TransactionDeadlockException"
or "Deadlock detected" patterns in log.

javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionTimeoutException: Failed to
acquire lock within provided timeout for transaction [timeout=800,
tx=org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$10@647b61d9]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1440)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2183)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putAll(IgniteCacheProxy.java:1430)
at 
org.apache.ignite.internal.processors.cache.transactions.TxPessimisticDeadlockDetectionTest$1.run(TxPessimisticDeadlockDetectionTest.java:322)
at 
org.apache.ignite.testframework.GridTestUtils$8.call(GridTestUtils.java:1092)
at 
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
Suppressed: class org.apache.ignite.IgniteException: Transaction
has been already completed.
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:924)
at 
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:279)
at 
org.apache.ignite.internal.processors.cache.transactions.TxPessimisticDeadlockDetectionTest$1.run(TxPessimisticDeadlockDetectionTest.java:325)
... 2 more
Caused by: class org.apache.ignite.IgniteCheckedException:
Transaction has been already completed.
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finishDhtLocal(IgniteTxHandler.java:786)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:728)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxFinishRequest(IgniteTxHandler.java:687)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:157)
at 
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$3.apply(IgniteTxHandler.java:155)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:827)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:369)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:293)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$000(GridCacheIoManager.java:95)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:238)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: class
org.apache.ignite.transactions.TransactionTimeoutException: Failed to
acquire lock within provided timeout for transaction [timeout=800,
tx=org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter$10@647b61d9]
at 
org.apache.ignite.internal.util.IgniteUtils$13.apply(IgniteUtils.java:831)
at 
org.apache.ignite.internal.util.IgniteUtils$13.apply(IgniteUtils.java:828)
... 6 more
Caused by: class org.apache.ignite.transactions.TransactionDeadlockException:
Deadlock detected:

K1: TX1 holds lock, TX2 waits lock.
K2: TX3 holds lock, TX1 waits lock.
K3: TX2 holds lock, TX3 waits lock.

Transactions:

TX1 [txId=GridCacheVersion [topVer=100472269, time=1488992349410,
order=1488992271778, nodeOrder=5],
nodeId=52c630e7-3b59-4d58-9291-dd8bd9e4, threadId=637]
TX2 [txId=GridCacheVersion [topVer=100472269, time=1488992349410,
order=1488992271778, nodeOrder=6],
nodeId=652f18b9-8948-4d66-a1a8-f45346c5, threadId=636]
TX3 [txId=GridCacheVersion [topVer=100472269, time=1488992349410,
order=1488992271806, nodeOrder=4],
nodeId=5810f06c-f9a5-40b2-91ec-e9ec97a3, threadId=635]

Keys:

K1 [key=3, cache=cache]
K2 [key=2, cache=cache]
K3 [key=1, cache=cache]

at 
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture$LockTimeoutObject$1.apply(GridDhtColocatedLockFuture.java:1355)
at 

Re: accurate offheap metrics

[Andrey Gura]

Hi,

JVM allocates more memory than pointed out by Xms and Xmx parameters.
For my case is 2-4 Gb more allocated for 4-8 Gb heaps. I think that it
is related with preloaded classes for faster start new JVM processes.

Ignite internal structures that provide offheap cache also allocates
memory in off heap but MBean doesn't take it into account. There are
two structures: offheap map implementation and offheap LRU eviction
policy implementation. Both structures of course are created for each
off heap cache. There is issue about this problem [1]

[1] https://issues.apache.org/jira/browse/IGNITE-4797

On Tue, Mar 7, 2017 at 6:59 PM, lawrencefinn  wrote:
> What's the best way to get accurate metrics of offheap memory used?  I've
> tried a bunch of different ways such as utilizing jmx, utilizing the API and
> iterating through each cache on each node to get offHeapAllocatedSize, using
> rest api, etc...  None of the values add up right.  I see my ignite process
> taking up 4GB, max heap is 2GB, and all the calculations are around 300MB.
> Are indexes not taken into account?
>
>
>
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/accurate-offheap-metrics-tp11057.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: CacheStore.loadCache loading data for 1024 partitions for a single node

[Andrey Mashenkov]

Hi Sumanta,

You can set AffinityFunction to cache configuration providing certain
partitions number to existed AF or implements your own AF.
For more information see
org.apache.ignite.cache.affinity.AffinityFunction.partitions().

On Tue, Mar 7, 2017 at 8:03 PM, Sumanta Ghosh 
wrote:

> It is not causing problems so to say; however I am concerned then we have
> 1024 queries executed per cache during startup; in case there is any
> configuration to set up the total number of partitions, that would give us
> more control I believe.
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/CacheStore-loadCache-loading-
> data-for-1024-partitions-for-a-single-node-tp11028p11059.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Ignite SQL Grid Load

[Andrey Mashenkov]

Hi Raja,

Would you please attach full ignite logs with failure?

On Wed, Mar 8, 2017 at 9:44 AM, Raja  wrote:

> Hi,
> I have a 12 node ignite cluster with node configuration of 8 core, 10g
> memory
> I am using the following JVM options as recommended by ignite docs
>
> IGNITE_JVM_OPTS=-server \
> -Xms8g \
> -Xmx8g \
> -XX:+UseParNewGC \
> -XX:+UseConcMarkSweepGC \
> -XX:+UseTLAB \
> -XX:NewSize=128m \
> -XX:MaxNewSize=128m \
> -XX:MaxTenuringThreshold=0 \
> -XX:SurvivorRatio=1024 \
> -XX:+UseCMSInitiatingOccupancyOnly \
> -XX:CMSInitiatingOccupancyFraction=40 \
> -XX:MaxGCPauseMillis=1000  \
> -XX:InitiatingHeapOccupancyPercent=50 \
> -XX:+UseCompressedOops \
> -XX:ParallelGCThreads=8 \
> -XX:ConcGCThreads=8 \
> -XX:+DisableExplicitGC
>
>
> When I tried to load test ONE REST client, it just cannot handle more than
> 1
> thread. If I hit it with 2 or more threads, some sql queries randomly
> fails.
> Even after increasing cluster to 40 nodes. No difference. Just if hit with
> more than 1 thread everything falls apart.
>
> Wondering if I'm missing something. We wanted to have cluster with a
> configuration where 50 or more concurrent users will be hitting Ignite.
>
> Is it possible with Ignite. BTW we are running geo-spatial sql queries on
> ignite.
>
> Appreciate any insights into this.
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-SQL-Grid-Load-tp11072.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: Upgrade to 1.8.0 problems

[Andrey Mashenkov]

Hi Isaeed,

It looks weird. Would you please share a whole log?

On Wed, Mar 8, 2017 at 9:26 AM, Isaeed Mohanna  wrote:

> Hi
> I have a 1.7.0 cluster with two nodes with several caches in it, i tried
> moving to Ignite 1.8.0 unfortunately i am facing two issues:
> 1. My query's stopped working against the cache. A simple SQL Query like
> this
> SqlQuery sql = new SqlQuery(Entity.class, "type
> = ?");
> type is part of the entity class its a simply enum, any idea why my query
> now returns zero results?
>
> 2. In my efforts to resolve problem 1, i thought to start using binary
> marshaller in my entities which implemented Externalizable interface, i
> removed the interface to use the binary marshaller which actually  helped
> and my query is working again however whenever i have two nodes in the
> cluster i receive the following exception several times when I join the
> second node to the cluster but it appears to go away afterwards. what is
> causing this exception? and how do i resolve the problem?
> Thanks
>
> [2017-03-08 05:58:19] [ERROR]
> [org.apache.ignite.internal.processors.task.GridTaskWorker:org.apache.
> ignite.logger.slf4j.Slf4jLogger.error(Slf4jLogger.java:112)]:
> Failed to obtain remote job result policy for result from
> ComputeTask.result(..) method (will fail the whole task): GridJobResultImpl
> [job=C2V2 [c=com.hhh.Task@100853d8], sib=GridJobSiblingImpl
> [sesId=a454e7caa51-9feeb429-75c5-4920-81a1-e95fdb12ebd5,
> jobId=b454e7caa51-9feeb429-75c5-4920-81a1-e95fdb12ebd5,
> nodeId=a02307c0-64d8-443f-83e5-2dbdca9ab259, isJobDone=false],
> jobCtx=GridJobContextImpl
> [jobId=b454e7caa51-9feeb429-75c5-4920-81a1-e95fdb12ebd5, timeoutObj=null,
> attrs={}], node=TcpDiscoveryNode [id=a02307c0-64d8-443f-83e5-2dbdca9ab259,
> addrs=[20.0.2.55], sockAddrs=[/20.0.2.55:47500], discPort=47500, order=2,
> intOrder=2, lastExchangeTime=1488952697596, loc=false,
> ver=1.8.0#20161205-sha1:9ca40dbe, isClient=false], ex=class
> o.a.i.IgniteException: null, hasRes=true, isCancelled=false,
> isOccupied=true]
> class org.apache.ignite.IgniteException: Remote job threw user exception
> (override or implement ComputeTask.result(..) method if you would like to
> have automatic failover for this exception).
> at
> org.apache.ignite.compute.ComputeTaskAdapter.result(
> ComputeTaskAdapter.java:101)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(
> GridTaskWorker.java:1030)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker$5.apply(
> GridTaskWorker.java:1023)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.
> java:6596)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.result(
> GridTaskWorker.java:1023)
> at
> org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(
> GridTaskWorker.java:841)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor.
> processJobExecuteResponse(GridTaskProcessor.java:996)
> at
> org.apache.ignite.internal.processors.task.GridTaskProcessor$
> JobMessageListener.onMessage(GridTaskProcessor.java:1221)
> at
> org.apache.ignite.internal.managers.communication.
> GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.
> processRegularMessage0(GridIoManager.java:710)
> at
> org.apache.ignite.internal.managers.communication.
> GridIoManager.access$1700(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(
> GridIoManager.java:673)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2V2.
> execute(GridClosureProcessor.java:2040)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$
> 2.call(GridJobWorker.java:556)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.
> java:6564)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.
> execute0(GridJobWorker.java:550)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.
> body(GridJobWorker.java:479)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.
> processJobExecuteRequest(GridJobProcessor.java:1180)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$
> JobExecutionListener.onMessage(GridJobProcessor.java:1894)
> ... 7 more
> Caused by: java.lang.NullPointerException
> at
> 

Re: hasOffHeapPointer

[Andrey Mashenkov]

Hi Peter,

I think the message is not relevant.
It means, Entry had been load from Offhead earlier was evicted to Offheap
back (as AccessedEvictionPolicy is configured) without changes. So, there
is no need to rewrite Offheap data.
You shouldn't bother about this.

On Sat, Mar 4, 2017 at 2:47 PM, Peter Schmitt 
wrote:

> Hi Andrey,
>
> see https://github.com/ps4os/ignite_offheap_test/blob/
> master/src/main/java/demo/RunIgniteTester.java#L83
>
> Kind regards,
> Peter
>
>
>
> 2017-03-03 13:35 GMT+01:00 Andrey Mashenkov :
>
>> Hi Peter,
>>
>> It looks like offheap entry was evicted from cache and it won't to be
>> swapped by some reason.
>> Would you please share cache configuration?
>>
>> On Fri, Mar 3, 2017 at 2:59 AM, Peter Schmitt <
>> peter.schmitt@gmail.com> wrote:
>>
>>> Hello Ignite-Community!
>>>
>>> All our Ignite caches are offheap.
>>> Now I've found the following entry in the logs:
>>> "Value did not change, skip write swap entry..."
>>>
>>> Checking the source-code I can see that it can just happen in
>>> case hasOffHeapPointer returns true. What does that mean? We just have
>>> "soft references" between caches. In our case cache-entries don't have
>>> references to entries in other caches via a reference-variable pointing to
>>> those entries. Instead we store the key (in most cases a string) of the
>>> other cache-entry and do a lookup (once needed).
>>>
>>> Any hint is appreciated,
>>> Peter
>>>
>>
>>
>>
>> --
>> Best regards,
>> Andrey V. Mashenkov
>>
>
>


-- 
Best regards,
Andrey V. Mashenkov

Re: Authentication

[Andrey Mashenkov]

Hi,

It looks like you need to implement *DiscoverySpiNodeAuthenticator*.
You can use *ClusterNode *attribute to authenticate node inside '
*DiscoverySpiNodeAuthenticator.authenticateNode()'* method.

You can find in source code how *IgniteNodeAttributes.ATTR_SECURITY_CREDENTIALS
*attribute passed to *DiscoverySpiNodeAuthenticator.authenticateNode()* as
*SecurityCredentials*.

On Mon, Mar 6, 2017 at 3:25 PM, conor  wrote:

> Hi, I'm trying to implement authentication for an ignite cluster.  I've
> read
> the blog post mentioned in other posts here but it's incomplete and also
> quite old so I was hoping for some guidance. (blog post:
> http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/)
>
> The authentication mechanism I'm intending to use is to check for a common
> password shared by nodes.  So when a node starts up by itself, it obtains
> the shared password from the local system using a library call.  So I need
> to do two things.
>  * when a node starts up it needs to fetch the local password and store it
> in it's own configuration
>  * when a node joins the cluster other nodes need to compare the provided
> password with the one they have locally
>
> So I tried setting the credentials locally as follows:
>
> TcpDiscoverySpi spi = new TcpDiscoverySpi();
> SecurityCredentials securityCredentials = new
> SecurityCredentials(getModuleName(), passwordService.getPassword());
> Map nodeAttributes = new HashMap<>();
> nodeAttributes.put("org.apache.ignite.security.cred",
> securityCredentials);
> IgniteProductVersion igniteProductVersion = new
> IgniteProductVersion();
> spi.setNodeAttributes(nodeAttributes, igniteProductVersion);
>
> However I run into an issue here because when setNodeAttributes is called
> on
> TcpDiscoverySpi I get a NullPointerException.  The exception is thrown in
> line 963 which is shown below.
>
> 959@Override public void setNodeAttributes(Map attrs,
> IgniteProductVersion ver) {
> 960assert locNodeAttrs == null;
> 961assert locNodeVer == null;
> 962
> 963if (log.isDebugEnabled()) {
> 964log.debug("Node attributes to set: " + attrs);
> 965log.debug("Node version to set: " + ver);
> 966}
> 967
> 968locNodeAttrs = attrs;
> 969locNodeVer = ver;
> 970}
>
> The instance of IgniteLogger named 'log' is null when this method is
> called.
> This seems like a bug to me but if it's not, am I doing something wrong?
> Is
> there another way I should be fetching and setting this property on my
> local
> node?
>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Authentication-tp11037.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Best regards,
Andrey V. Mashenkov

Re: IGNITE-4106

[Andrey Mashenkov]

Hi Anil,

SQL queries are run in system pool.

On Wed, Mar 8, 2017 at 3:04 PM, Anil  wrote:

> Hi,
>
> Does queryparallelism uses system pool or separate thread pool other than
> system and public thread pool ? please clarify.
>
> 1. https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-
> performance-and-usability-considerations
>
> Thanks.
>
>



-- 
Best regards,
Andrey V. Mashenkov

IGNITE-4106

[Anil]

Hi,

Does queryparallelism uses system pool or separate thread pool other than
system and public thread pool ? please clarify.

1.
https://apacheignite.readme.io/docs/sql-performance-and-debugging#sql-performance-and-usability-considerations

Thanks.