Re: Amazon AMI not available in a specific region

2020-06-24 Thread Petr Ivanov
AMI is not being update with release — it uses Docker inside that receive 
VERSION as parameters and pulls corresponding image from Docker Hub.

Concerning image itself, I will try to search which account owns it.


> On 24 Jun 2020, at 18:31, Denis Magda  wrote:
> 
> Ignite dev community,
> 
> Could you remind me if we still updating the AWS images for our releases? If 
> yes, how about expanding a list of supported regions?
> 
> -
> Denis
> 
> 
> On Wed, Jun 24, 2020 at 6:10 AM Gandhi, Karthik  > wrote:
> Hi - AWS Apache images are limited to 2 regions (US East 1 and US West 1). I 
> have a need to Install and configure ignite in US East 2 AWS region. 
> Appreciate if can copy to this region
> 
> -Karthik



Re: Setting Cache Size using Max Records

2020-06-24 Thread Victor
Hi Denis,

For our product we are using an in-house solution where we expose the size
in records. Now we are looking at replacing it with Ignite. So we wanted to
make the experience seamless and let the end user's continue to set the same
configuration they are familiar with, rather than adding a new learning
curve.

Does any of the expiry policies except record size?

Thanks,
Vic



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


Re: Setting Cache Size using Max Records

2020-06-24 Thread Denis Magda
Hi Vic,

That’s unsupported for the off-heap memory. You can only limit memory usage
based on the size in bytes.

Please share more details of why this type of records eviction is needed.
We might suggest an alternate solution.

Denis

On Wednesday, June 24, 2020, Victor  wrote:

> Hi,
>
> I am looking to set the cache size for off-heap via number of max records
> instead of max bytes. Similar to how LRU eviction policy for on-heap can
> set
> it.
>
> Haven't found anything around that. Is that doable, if yes, how do i go
> about it?
>
> Thanks,
> Vic
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>


-- 
-
Denis


Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread Evgenii Zhuravlev
No, it's not. It's not clear when it happened and what was with the cluster
and the client node itself at this moment.

Evgenii

ср, 24 июн. 2020 г. в 18:16, John Smith :

> Ok I'll try... The stack trace isn't enough?
>
> On Wed., Jun. 24, 2020, 4:30 p.m. Evgenii Zhuravlev, <
> e.zhuravlev...@gmail.com> wrote:
>
>> John, right, didn't notice them before. Can you share the full log for
>> the client node with an issue?
>>
>> Evgenii
>>
>> ср, 24 июн. 2020 г. в 12:29, John Smith :
>>
>>> I thought I did! The link doesn't have them?
>>>
>>> On Wed., Jun. 24, 2020, 2:43 p.m. Evgenii Zhuravlev, <
>>> e.zhuravlev...@gmail.com> wrote:
>>>
 Can you share full log files from server nodes?

 ср, 24 июн. 2020 г. в 10:47, John Smith :

> The logs for server are here:
> https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0
>
> The error from the client:
>
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute cache operation (all partition owners have left the 
> grid,
> partition data has been lost) [cacheName=cache1, part=580,
> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$d94e711a$1(IgniteCacheRepository.java:55)
> at
> org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
> at
> com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
> at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
> at
> io.vertx.core.impl.WorkerContext.lambda$wrapTask$0(WorkerContext.java:35)
> at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute cache operation (all partition owners have left the 
> grid,
> partition data has been lost) [cacheName=cache1, part=580,
> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:169)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1428)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:472)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:472)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:4749)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1477)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAsync(IgniteCacheProxyImpl.java:937)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAsync(GatewayProtectedCacheProxy.java:652)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$get$1(IgniteCacheRepository.java:28)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:51)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.

Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread John Smith
Ok I'll try... The stack trace isn't enough?

On Wed., Jun. 24, 2020, 4:30 p.m. Evgenii Zhuravlev, <
e.zhuravlev...@gmail.com> wrote:

> John, right, didn't notice them before. Can you share the full log for the
> client node with an issue?
>
> Evgenii
>
> ср, 24 июн. 2020 г. в 12:29, John Smith :
>
>> I thought I did! The link doesn't have them?
>>
>> On Wed., Jun. 24, 2020, 2:43 p.m. Evgenii Zhuravlev, <
>> e.zhuravlev...@gmail.com> wrote:
>>
>>> Can you share full log files from server nodes?
>>>
>>> ср, 24 июн. 2020 г. в 10:47, John Smith :
>>>
 The logs for server are here:
 https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0

 The error from the client:

 javax.cache.CacheException: class
 org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
 Failed to execute cache operation (all partition owners have left the grid,
 partition data has been lost) [cacheName=cache1, part=580,
 key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
 at
 org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
 at
 org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
 at
 org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
 at
 com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$d94e711a$1(IgniteCacheRepository.java:55)
 at
 org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
 at
 com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
 at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
 at
 io.vertx.core.impl.WorkerContext.lambda$wrapTask$0(WorkerContext.java:35)
 at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
 at
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at
 io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
 at java.lang.Thread.run(Thread.java:748)
 Caused by:
 org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
 Failed to execute cache operation (all partition owners have left the grid,
 partition data has been lost) [cacheName=cache1, part=580,
 key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:169)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1428)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:135)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:474)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:472)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
 at
 org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:472)
 at
 org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:4749)
 at
 org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1477)
 at
 org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAsync(IgniteCacheProxyImpl.java:937)
 at
 org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAsync(GatewayProtectedCacheProxy.java:652)
 at
 com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$get$1(IgniteCacheRepository.java:28)
 at
 com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:51)
 at
 com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.get(IgniteCacheRepository.java:28)
 at
 com.xx.impl.CarrierCodeServiceImpl.getCarrierIdOfPhone(CarrierCodeServiceImpl.java:65)
 at
 com.xx.impl.SmppGatewayServiceImpl.sendSms(SmppGatewayServiceImpl.java:39)
 at com.xx.impl.MtEventProcessor.process(

Setting Cache Size using Max Records

2020-06-24 Thread Victor
Hi,

I am looking to set the cache size for off-heap via number of max records
instead of max bytes. Similar to how LRU eviction policy for on-heap can set
it.

Haven't found anything around that. Is that doable, if yes, how do i go
about it?

Thanks,
Vic



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


Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread Evgenii Zhuravlev
John, right, didn't notice them before. Can you share the full log for the
client node with an issue?

Evgenii

ср, 24 июн. 2020 г. в 12:29, John Smith :

> I thought I did! The link doesn't have them?
>
> On Wed., Jun. 24, 2020, 2:43 p.m. Evgenii Zhuravlev, <
> e.zhuravlev...@gmail.com> wrote:
>
>> Can you share full log files from server nodes?
>>
>> ср, 24 июн. 2020 г. в 10:47, John Smith :
>>
>>> The logs for server are here:
>>> https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0
>>>
>>> The error from the client:
>>>
>>> javax.cache.CacheException: class
>>> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
>>> Failed to execute cache operation (all partition owners have left the grid,
>>> partition data has been lost) [cacheName=cache1, part=580,
>>> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
>>> at
>>> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
>>> at
>>> org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
>>> at
>>> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
>>> at
>>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$d94e711a$1(IgniteCacheRepository.java:55)
>>> at
>>> org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
>>> at
>>> com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
>>> at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
>>> at
>>> io.vertx.core.impl.WorkerContext.lambda$wrapTask$0(WorkerContext.java:35)
>>> at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>>> at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>> at
>>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>>> at java.lang.Thread.run(Thread.java:748)
>>> Caused by:
>>> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
>>> Failed to execute cache operation (all partition owners have left the grid,
>>> partition data has been lost) [cacheName=cache1, part=580,
>>> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:169)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1428)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:135)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:474)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:472)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
>>> at
>>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:472)
>>> at
>>> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:4749)
>>> at
>>> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1477)
>>> at
>>> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAsync(IgniteCacheProxyImpl.java:937)
>>> at
>>> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAsync(GatewayProtectedCacheProxy.java:652)
>>> at
>>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$get$1(IgniteCacheRepository.java:28)
>>> at
>>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:51)
>>> at
>>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.get(IgniteCacheRepository.java:28)
>>> at
>>> com.xx.impl.CarrierCodeServiceImpl.getCarrierIdOfPhone(CarrierCodeServiceImpl.java:65)
>>> at
>>> com.xx.impl.SmppGatewayServiceImpl.sendSms(SmppGatewayServiceImpl.java:39)
>>> at com.xx.impl.MtEventProcessor.process(MtEventProcessor.java:46)
>>> at
>>> com.xx.common.vertx.ext.kafka.impl.KafkaProcessorImpl.lambda$null$4(KafkaProcessorImpl.java:83)
>>> at
>>> io.reactivex.internal.operators.completable.CompletableCreate.subscribeActual(Comp

Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread John Smith
I thought I did! The link doesn't have them?

On Wed., Jun. 24, 2020, 2:43 p.m. Evgenii Zhuravlev, <
e.zhuravlev...@gmail.com> wrote:

> Can you share full log files from server nodes?
>
> ср, 24 июн. 2020 г. в 10:47, John Smith :
>
>> The logs for server are here:
>> https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0
>>
>> The error from the client:
>>
>> javax.cache.CacheException: class
>> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
>> Failed to execute cache operation (all partition owners have left the grid,
>> partition data has been lost) [cacheName=cache1, part=580,
>> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
>> at
>> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
>> at
>> org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
>> at
>> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
>> at
>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$d94e711a$1(IgniteCacheRepository.java:55)
>> at
>> org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
>> at
>> com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
>> at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
>> at
>> io.vertx.core.impl.WorkerContext.lambda$wrapTask$0(WorkerContext.java:35)
>> at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>> at
>> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>> at java.lang.Thread.run(Thread.java:748)
>> Caused by:
>> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
>> Failed to execute cache operation (all partition owners have left the grid,
>> partition data has been lost) [cacheName=cache1, part=580,
>> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:169)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1428)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:135)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:474)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:472)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
>> at
>> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:472)
>> at
>> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:4749)
>> at
>> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1477)
>> at
>> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAsync(IgniteCacheProxyImpl.java:937)
>> at
>> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAsync(GatewayProtectedCacheProxy.java:652)
>> at
>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$get$1(IgniteCacheRepository.java:28)
>> at
>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:51)
>> at
>> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.get(IgniteCacheRepository.java:28)
>> at
>> com.xx.impl.CarrierCodeServiceImpl.getCarrierIdOfPhone(CarrierCodeServiceImpl.java:65)
>> at
>> com.xx.impl.SmppGatewayServiceImpl.sendSms(SmppGatewayServiceImpl.java:39)
>> at com.xx.impl.MtEventProcessor.process(MtEventProcessor.java:46)
>> at
>> com.xx.common.vertx.ext.kafka.impl.KafkaProcessorImpl.lambda$null$4(KafkaProcessorImpl.java:83)
>> at
>> io.reactivex.internal.operators.completable.CompletableCreate.subscribeActual(CompletableCreate.java:39)
>> at io.reactivex.Completable.subscribe(Completable.java:2309)
>> at
>> io.reactivex.internal.operators.completable.CompletableTimeout.subscribeActual(CompletableTimeout.java:53)
>> at io.reactivex.Completable.subscribe(Co

Re: Ignite SSL security

2020-06-24 Thread akorensh
Hi,
  Internally, Ignite will use new File(keyStoreFilePath) ...
  This will interpret the keyStoreFilePath relative to the process working
directory.
  
  Use:
System.out.println("Working Directory = " +
System.getProperty("user.dir"));
to determine your working dir.

  Then use:
 File file = new File(keyStoreFilePath);
 System.out.println(file.getAbsolutePath()); 
 to see whether your file is in the correct place.

  see:
https://github.com/apache/ignite/blob/832cf801301f79b7e904b004e33855b105387982/modules/core/src/main/java/org/apache/ignite/ssl/SslContextFactory.java#L488
  for implementation.
Thanks, Alex 
  

   



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


Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread Evgenii Zhuravlev
Can you share full log files from server nodes?

ср, 24 июн. 2020 г. в 10:47, John Smith :

> The logs for server are here:
> https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0
>
> The error from the client:
>
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute cache operation (all partition owners have left the grid,
> partition data has been lost) [cacheName=cache1, part=580,
> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
> at
> org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$d94e711a$1(IgniteCacheRepository.java:55)
> at
> org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
> at
> com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
> at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
> at
> io.vertx.core.impl.WorkerContext.lambda$wrapTask$0(WorkerContext.java:35)
> at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.lang.Thread.run(Thread.java:748)
> Caused by:
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to execute cache operation (all partition owners have left the grid,
> partition data has been lost) [cacheName=cache1, part=580,
> key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:169)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1428)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:135)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:474)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:472)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:472)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:4749)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1477)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAsync(IgniteCacheProxyImpl.java:937)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAsync(GatewayProtectedCacheProxy.java:652)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$get$1(IgniteCacheRepository.java:28)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:51)
> at
> com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.get(IgniteCacheRepository.java:28)
> at
> com.xx.impl.CarrierCodeServiceImpl.getCarrierIdOfPhone(CarrierCodeServiceImpl.java:65)
> at
> com.xx.impl.SmppGatewayServiceImpl.sendSms(SmppGatewayServiceImpl.java:39)
> at com.xx.impl.MtEventProcessor.process(MtEventProcessor.java:46)
> at
> com.xx.common.vertx.ext.kafka.impl.KafkaProcessorImpl.lambda$null$4(KafkaProcessorImpl.java:83)
> at
> io.reactivex.internal.operators.completable.CompletableCreate.subscribeActual(CompletableCreate.java:39)
> at io.reactivex.Completable.subscribe(Completable.java:2309)
> at
> io.reactivex.internal.operators.completable.CompletableTimeout.subscribeActual(CompletableTimeout.java:53)
> at io.reactivex.Completable.subscribe(Completable.java:2309)
> at
> io.reactivex.internal.operators.completable.CompletablePeek.subscribeActual(CompletablePeek.java:51)
> at io.reactivex.Completable.subscribe(Completable.java:2309)
> at
> io.reactivex.internal.ope

Ignite SSL security

2020-06-24 Thread marble.zh...@coinflex.com
Hi Guru, 

I am try to implement the SSL security, 

default-config.xml like below, I have generated the server.jks and trust.jks
with command 'keytool -genkey -alias ignite -keystore server.jks -keyalg
RSA' and put the file server.jks to the $IGNITE_HOME folder, but when
restart ignite, met below exception:

Failed to start grid: Failed to initialize key store (key store file was not
found): [path=server.jks, msg=server.jks (No such file or directory)]

please advice where this file to put in?  or any suggestions for the ssl?



  
  
  
  
  


  

  




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


Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread John Smith
The logs for server are here:
https://www.dropbox.com/sh/ejcddp2gcml8qz2/AAD_VfUecE0hSNZX7wGbfDh3a?dl=0

The error from the client:

javax.cache.CacheException: class
org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
Failed to execute cache operation (all partition owners have left the grid,
partition data has been lost) [cacheName=cache1, part=580,
key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
at
org.apache.ignite.internal.processors.cache.IgniteCacheFutureImpl.convertException(IgniteCacheFutureImpl.java:62)
at
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
at
com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$executeAsync$d94e711a$1(IgniteCacheRepository.java:55)
at
org.apache.ignite.internal.util.future.AsyncFutureListener$1.run(AsyncFutureListener.java:53)
at
com.xx.common.vertx.ext.data.impl.VertxIgniteExecutorAdapter.lambda$execute$0(VertxIgniteExecutorAdapter.java:18)
at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
at io.vertx.core.impl.WorkerContext.lambda$wrapTask$0(WorkerContext.java:35)
at io.vertx.core.impl.TaskQueue.run(TaskQueue.java:76)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:748)
Caused by:
org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
Failed to execute cache operation (all partition owners have left the grid,
partition data has been lost) [cacheName=cache1, part=580,
key=UserKeyCacheObjectImpl [part=580, val=14385045508, hasValBytes=false]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validatePartitionOperation(GridDhtTopologyFutureAdapter.java:169)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTopologyFutureAdapter.validateCache(GridDhtTopologyFutureAdapter.java:116)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.init(GridPartitionedSingleGetFuture.java:208)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync0(GridDhtAtomicCache.java:1428)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1600(GridDhtAtomicCache.java:135)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:474)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$16.apply(GridDhtAtomicCache.java:472)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
at
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.getAsync(GridDhtAtomicCache.java:472)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:4749)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getAsync(GridCacheAdapter.java:1477)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.getAsync(IgniteCacheProxyImpl.java:937)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAsync(GatewayProtectedCacheProxy.java:652)
at
com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.lambda$get$1(IgniteCacheRepository.java:28)
at
com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.executeAsync(IgniteCacheRepository.java:51)
at
com.xx.common.vertx.ext.data.impl.IgniteCacheRepository.get(IgniteCacheRepository.java:28)
at
com.xx.impl.CarrierCodeServiceImpl.getCarrierIdOfPhone(CarrierCodeServiceImpl.java:65)
at
com.xx.impl.SmppGatewayServiceImpl.sendSms(SmppGatewayServiceImpl.java:39)
at com.xx.impl.MtEventProcessor.process(MtEventProcessor.java:46)
at
com.xx.common.vertx.ext.kafka.impl.KafkaProcessorImpl.lambda$null$4(KafkaProcessorImpl.java:83)
at
io.reactivex.internal.operators.completable.CompletableCreate.subscribeActual(CompletableCreate.java:39)
at io.reactivex.Completable.subscribe(Completable.java:2309)
at
io.reactivex.internal.operators.completable.CompletableTimeout.subscribeActual(CompletableTimeout.java:53)
at io.reactivex.Completable.subscribe(Completable.java:2309)
at
io.reactivex.internal.operators.completable.CompletablePeek.subscribeActual(CompletablePeek.java:51)
at io.reactivex.Completable.subscribe(Completable.java:2309)
at
io.reactivex.internal.operators.completable.CompletableResumeNext.subscribeActual(CompletableResumeNext.java:41)
at io.reactivex.Completable.subscribe(Completable.java:2309)
at
io.reactivex.internal.operators.completable.CompletableToFlowable.subscribeActual(CompletableToFlowable.java:32)
a

Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread John Smith
Not sure about the wrong configuration... All the apps work this seems to
happen every few weeks. We don't have any particular heavy load.

I just bounced the client application and the errors went away.

On Wed, 24 Jun 2020 at 12:57, Evgenii Zhuravlev 
wrote:

> Hi,
>
> It means that there are no nodes in the cluster that holds certain
> partitions. So, probably you have a wrong configuration or some of the
> nodes left the cluster and you don't have backups in the cluster for these
> partitions. I believe more can be found from logs.
>
> Evgenii
>
> ср, 24 июн. 2020 г. в 09:52, John Smith :
>
>> Also I'm assuming that the thin client wouldn't be susceptible to this
>> error?
>>
>> On Wed, 24 Jun 2020 at 12:38, John Smith  wrote:
>>
>>> The cluster is showing active when running control.sh
>>>
>>> But the client is showing "all partition owners have left the grid"
>>>
>>> The client node is marked as client=true so it's not a server node.
>>>
>>> Is this split brain as well?
>>>
>>


Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread Evgenii Zhuravlev
Hi,

It means that there are no nodes in the cluster that holds certain
partitions. So, probably you have a wrong configuration or some of the
nodes left the cluster and you don't have backups in the cluster for these
partitions. I believe more can be found from logs.

Evgenii

ср, 24 июн. 2020 г. в 09:52, John Smith :

> Also I'm assuming that the thin client wouldn't be susceptible to this
> error?
>
> On Wed, 24 Jun 2020 at 12:38, John Smith  wrote:
>
>> The cluster is showing active when running control.sh
>>
>> But the client is showing "all partition owners have left the grid"
>>
>> The client node is marked as client=true so it's not a server node.
>>
>> Is this split brain as well?
>>
>


Re: What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread John Smith
Also I'm assuming that the thin client wouldn't be susceptible to this
error?

On Wed, 24 Jun 2020 at 12:38, John Smith  wrote:

> The cluster is showing active when running control.sh
>
> But the client is showing "all partition owners have left the grid"
>
> The client node is marked as client=true so it's not a server node.
>
> Is this split brain as well?
>


What does all partition owners have left the grid on the client side mean?

2020-06-24 Thread John Smith
The cluster is showing active when running control.sh

But the client is showing "all partition owners have left the grid"

The client node is marked as client=true so it's not a server node.

Is this split brain as well?


Re: GridIoManager compile error(2.8.0)

2020-06-24 Thread Denis Magda
This should be a problem of your toolchain. If there were compilations
issues we would not release those versions. The first thing to check is
that you use JDK 8 to build the binary. The produced binary can work on
other versions of JDK 9+.


-
Denis


On Sun, Jun 21, 2020 at 6:21 PM 38797715 <38797...@qq.com> wrote:

> Hi team,
>
> I downloaded the source code of version 2.8.1, but found that it could
> not be compiled successfully, and there were compilation errors in the
> code.
>
> for example:
>
> org.apache.ignite.internal.managers.communication.GridIoManager
>
> line 395:
>
> The method register(String, BooleanSupplier, String) is ambiguous for
> the type MetricRegistry
>  - The type of getSentMessagesCount() from the type CommunicationSpi
> is int, this is incompatible with the descriptor's return type:
>   boolean
>
> But it can be compiled successfully by executing mvn compile.
>
> I use eclipse, I think this code is really problematic, I want to know
> why mvn compile can be compiled successfully? Why can this code be
> released?
>
>


Re: Amazon AMI not available in a specific region

2020-06-24 Thread Denis Magda
Ignite dev community,

Could you remind me if we still updating the AWS images for our releases?
If yes, how about expanding a list of supported regions?

-
Denis


On Wed, Jun 24, 2020 at 6:10 AM Gandhi, Karthik 
wrote:

> Hi - AWS Apache images are limited to 2 regions (US East 1 and US West
> 1). I have a need to Install and configure ignite in US East 2 AWS
> region. Appreciate if can copy to this region
>
> -Karthik
>


Re: Thread starvations

2020-06-24 Thread adipro
Sorry the above log file doesn't contain all info. Please check this file

Logs.zip
  



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


Re: Thread starvations

2020-06-24 Thread adipro
Thanks for the reply.

We've done query analysis and found that pretty much all queries are taking
around 1-5ms execution time for our operations which we consider it to be
fine.

But we have one query which is adding of rows in a table. We get maximum
5000 records at a time and we use IgniteDataStreamer API and JCache
QueryEntity way to insert rows in the table. We don't use JDBC. And for all
querying we either use SqlFieldsQuery or JCache getAll query. We are not
using job computes as well.

Now according to above statement, in real-time we get around 1500-2000 bulk
row insertions from each thread. All 300-400 threads insert at once without
any locking mechanism. This is actually giving us insert time of around
40-50 ms for one thread.

We are suspecting because of this many thread starvations are happening.

Weirdly, most of logs are printing read query delays but when seen from
Client application there are no delays that are printed too.

For the run-time of around two days, I'm sending you the entire logs of the
coordinator node. Please find the attached.

Logs.zip
  

Unfortunately I am not system adminstrator and couldn't get to run jstack on
that system. But I'll try and get one if possible.

Version - We are using gridgain's libraries of version 8.7.10.
Client heap size is 2GB and Server heap size is 4GB.
Config -> Peristence is ON. Checkpointing frequency is every 15 mins. Wal
archiving is off. Data region size off-heap is 20GB. Persistence used would
be around 25GB in real-time for our case. All Caches used are of replication
mode. Full-sync happens between two server nodes. WAL segment size used is
256MB. And all are atomic mode atomicity.

Topology -> two Clients connected to two Servers. Total 4 nodes. All the
connection pool threads size are default ones which is equal to number of
CPU cores. Client machines are of 40 core CPUs. Server machines are of 64
core CPUs.

The system is actually working but we want to know if we actually are
worried these may cause any issues in future like cluster wide data
corruption, etc. We want to know if we are doing something wrong and would
like to correct.

Would be grateful if you go through the entire log. Thank you.



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


Amazon AMI not available in a specific region

2020-06-24 Thread Gandhi, Karthik
Hi - AWS Apache images are limited to 2 regions (US East 1 and US West 1). I 
have a need to Install and configure ignite in US East 2 AWS region. Appreciate 
if can copy to this region

-Karthik