Re: Cache Preload from database using IgniteDatastreamer

[ravichandra]

Hi Om Thacker,

I am trying to implement / follow the same approach for my POC to understand
how that can be applied to a real time scenario's.
I googled but couldn't find a complete implementation in spring boot. 
Is it possible to share the source code location, it would help me a lot.

Thanks,
Ravichandra



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

Re: Authenticating communication between nodes using Ignite.Net

[alokyadav12]

We had tried suggested solution to enable SSL on node and thick client. 
used following setting at node and thick client to enable SSL using
certificate and copied to both application directory 


Node runs fine with message SSL on, when thick client run then it starts
thick client but throws exception when connecting node. Please let me know
if i am missing something or doing wrong configuration.


Few lines of messages at end when Node starts
Security status [authentication=off, tls/ssl=on]
[11:38:57] Started write-ahead log manager in NONE mode, persisted data may
be lost in a case of unexpected node failure. Make sure to deactivate the
cluster before shutdown.
[11:39:03] Started write-ahead log manager in NONE mode, persisted data may
be lost in a case of unexpected node failure. Make sure to deactivate the
cluster before shutdown.
[11:39:03] Performance suggestions for grid  (fix if possible)
[11:39:03] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
[11:39:03]   ^-- Switch to the most recent 1.8 JVM version
[11:39:03]   ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
JVM options)
[11:39:03]   ^-- Set max direct memory size if getting 'OOME: Direct buffer
memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
[11:39:03]   ^-- Disable processing of calls to System.gc() (add
'-XX:+DisableExplicitGC' to JVM options)
[11:39:03] Refer to this page for more performance suggestions:
https://apacheignite.readme.io/docs/jvm-and-system-tuning
[11:39:03] 
[11:39:03] To start Console Management & Monitoring run
ignitevisorcmd.{sh|bat}
[11:39:03] Data Regions Configured:
[11:39:03]   ^-- defaultRegion [initSize=128.0 MiB, maxSize=4.0 GiB,
persistence=false]
[11:39:03]   ^-- SecureRegion [initSize=32.0 MiB, maxSize=512.5 MiB,
persistence=true]
[11:39:03] 
[11:39:03] Ignite node started OK (id=061316a9)
[11:39:03] Topology snapshot [ver=1, locNode=061316a9, servers=1, clients=0,
state=INACTIVE, CPUs=8, offheap=4.5GB, heap=4.0GB]
[11:39:03]   ^-- Baseline [id=0, size=1, online=1, offline=0]
[11:39:03]   ^-- All baseline nodes are online, will start auto-activation


Following message when starting thick client 
[11:39:43] Security status [authentication=off, tls/ssl=on]
[11:39:44] REST protocols do not start on client node. To start the
protocols on client node set '-DIGNITE_REST_START_ON_CLIENT=true' system
property.
[11:39:48] Topology snapshot [ver=2, locNode=061316a9, servers=1, clients=1,
state=ACTIVE, CPUs=8, offheap=4.5GB, heap=7.9GB]
[11:39:48]   ^-- Baseline [id=0, size=1, online=1, offline=0]
[11:39:50,234][SEVERE][grid-nio-worker-tcp-comm-0-#24][TcpCommunicationSpi]
Failed to process selector key [ses=GridSelectorNioSessionImpl
[worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=0,
bytesRcvd=1516, bytesSent=0, bytesRcvd0=1516, bytesSent0=0, select=true,
super=GridWorker [name=grid-nio-worker-tcp-comm-0, igniteInstanceName=null,
finished=false, heartbeatTs=1570815589230, hashCode=298351978,
interrupted=false, runner=grid-nio-worker-tcp-comm-0-#24]]],
writeBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
inRecovery=null, outRecovery=null, super=GridNioSessionImpl
[locAddr=/0:0:0:0:0:0:0:1:47100, rmtAddr=/0:0:0:0:0:0:0:1:28223,
createTime=1570815589045, closeTime=0, bytesSent=1487, bytesRcvd=1516,
bytesSent0=1487, bytesRcvd0=1516, sndSchedTime=1570815589045,
lastSndTime=1570815589230, lastRcvTime=1570815589230, readsPaused=false,
filterChain=FilterChain[filters=[GridNioCodecFilter
[parser=o.a.i.i.util.nio.GridDirectParser@17956e51, directMode=true],
GridConnectionBytesVerifyFilter, SSL filter], accepted=true,
markedForClose=false]]]
java.io.IOException: An established connection was aborted by the software
in your host machine
at java.base/sun.nio.ch.SocketDispatcher.read0(Native Method)
at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43)
at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
at 
java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:358)
at
org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processRead(GridNioServer.java:1282)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2386)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2153)
at
org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1794)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:835)
[11:39:50,515][SEVERE][grid-nio-worker-tcp-comm-1-#25][TcpCommunicationSpi]
Failed to process selector 

Thick client is not recieving event when Cache is put on main node

[alokyadav12]

Hi,
 we are using Ignite.Net and testing eventing, We had a main node running
and our application connects to node using thin client. we run another node
as thick client and implement eventing on cache put as per documentation and
Ignite.Net examples.
But thick client is not able to get the events when there is new cache entry
is created, but when i add the eventing on main node its able to catch
events.
I had added event types in Cache config as per the document, but still thick
client is not getting event.
Added following in both thick client and node
 
  CacheObjectPut



Please suggest if i am missing anything




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

Re: Authenticating communication between nodes using Ignite.Net

[alokyadav12]

Thanks for the inputs will try suggested solution, we just want to stop
adding any node to main node.



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

Re: Cluster went down after "Unable to await partitions release latch within timeout" WARN

[ihalilaltun]

Hi Pavel,

Thank you for detailed explanation. We are discussing hotfix with
management, but i think decision will be negative :(

I think we'll have to wait 2.8 release, which seems to be released on
January 17, 2020. I hope we'll have this issue by then.

Regards.



-
İbrahim Halil Altun
Senior Software Engineer @ Segmentify
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Fault tolerance with IgniteCallable and IgniteRunnable on user errors

[Prasad Bhalerao]

Ignite error gives message to implement ComputeTask and override result
method to when the task is failed.
So I thought of implementing ComputTask to override this behaviour.
Ignite documentation describes the same thing but for the task implementing
ComputTask and executed with execute method.

Thanks,
Prasad

On Fri 11 Oct, 2019, 8:45 PM Denis Mekhanikov  Prasad,
>
> User errors are propagated to the calling site, so you can implement
> failover outside of the task’s logic.
>
> Denis
> On 11 Oct 2019, 17:33 +0300, Prasad Bhalerao ,
> wrote:
>
> Hi,
>
> How to define custom failover behavior when executing IgniteRunnable or
> IgniteCallable tasks executed with ignite.compute().affinityRun or
> ignite.compute().affinityCall ?
>
> I want to retry the task on few user errors.
>
> Implementing additional interface ComputeTask along with IgniteRunnable is
> not helping in this case.
>
> Thanks,
> Prasad
>
>

Re: Fault tolerance with IgniteCallable and IgniteRunnable on user errors

[Denis Mekhanikov]

Prasad,

User errors are propagated to the calling site, so you can implement failover 
outside of the task’s logic.

Denis
On 11 Oct 2019, 17:33 +0300, Prasad Bhalerao , 
wrote:
> Hi,
>
> How to define custom failover behavior when executing IgniteRunnable or 
> IgniteCallable tasks executed with ignite.compute().affinityRun or 
> ignite.compute().affinityCall ?
>
> I want to retry the task on few user errors.
>
> Implementing additional interface ComputeTask along with IgniteRunnable is 
> not helping in this case.
>
> Thanks,
> Prasad

Fault tolerance with IgniteCallable and IgniteRunnable on user errors

[Prasad Bhalerao]

Hi,

How to define custom failover behavior when executing IgniteRunnable or
IgniteCallable tasks executed with ignite.compute().affinityRun or
ignite.compute().affinityCall ?

I want to retry the task on few user errors.

Implementing additional interface ComputeTask along with IgniteRunnable is
not helping in this case.

Thanks,
Prasad

Re: Cluster went down after "Unable to await partitions release latch within timeout" WARN

[Pavel Kovalenko]

Ibrahim,

I've checked logs and found the following issue:
[2019-09-27T15:00:06,164][ERROR][sys-stripe-32-#33][atomic] Received
message without registered handler (will ignore)
[msg=GridDhtAtomicDeferredUpdateResponse [futIds=GridLongList [idx=1,
arr=[6389728]]], node=e39bd72e-acee-48a7-ad45-2019dfff9df4,
locTopVer=AffinityTopologyVersion [topVer=92, minorTopVer=1], ...

This response was needed to complete (finish) AtomicUpdateFuture:
[2019-09-27T15:00:36,287][WARN ][exchange-worker-#219][diagnostic] >>>
GridDhtAtomicSingleUpdateFuture [allUpdated=true,
super=GridDhtAtomicAbstractUpdateFuture [futId=6389728, resCnt=0,
addedReader=false, dhtRes={e39bd72e-acee-48a7-ad45-2019dfff9df4=[res=false,
size=1, nearSize=0]}]]

During exchange, all nodes wait for atomic updates and transaction
completion and then send an acknowledgment to the coordinator to continue
processing exchange.
Because atomic update on that node was not finished, the node didn't send
the acknowledgement to the coordinator and that's why you have seen
messages like:
[2019-09-27T15:00:17,727][WARN ][exchange-worker-#219][
GridDhtPartitionsExchangeFuture] Unable to await partitions release latch
within timeout: ServerLatch [permits=1, pendingAcks=[
*3561ac09-6752-4e2e-8279-d975c268d045*], super=CompletableLatch
[id=exchange, topVer=AffinityTopologyVersion [topVer=92, minorTopVer=2]]]

The handler to complete AtomicUpdateFuture was not found due to the
concurrency issue in 2.7.6 codebase. There is a map that contains handlers
for cache messages:
org/apache/ignite/internal/processors/cache/GridCacheIoManager.java:1575
In 2.7.6 it's just HashMap with volatile read/write publishing. However,
because of improper synchronization with adding and getting a handler in
rare cases, it can lead to false-positive missing a handler for a message
that you may see in logs.
This issue was fixed at https://issues.apache.org/jira/browse/IGNITE-8006 which
will be in 2.8 release.
However, if it's critical, you can make a hotfix by yourself:
Checkout ignite-2.7.6 branch from https://github.com/apache/ignite
Change HashMap declaration to ConcurrentHashMap here:
org/apache/ignite/internal/processors/cache/GridCacheIoManager.java:1575
Rebuild ignite-core module and deploy new ignite-core-jar on your server
nodes.
This hotfix will work for your case.

Another option is you can use the last version of GridGain Community
Edition instead of Apache Ignite which is fully compatible with Ignite.

Regarding message:
[sys-#337823][GridDhtPartitionsExchangeFuture] Partition states validation
has failed for group: acc_1306acd07be78000_userPriceDrop. Partitions
cachesizes are inconsistent for Part 129

I see that you create caches with ExpiryPolicy. If you use expiry policies
you can have different partition sizes on primary-backup nodes, because
expiring is not synchronized and performed independently on different nodes.
So it's OK to see such warnings. They are false-positive. Such warning
messages will not be printed if a cache has an expiry policy set. That was
fixed in https://issues.apache.org/jira/browse/IGNITE-12206


пт, 11 окт. 2019 г. в 14:40, ihalilaltun :

> Hi Pavel,
>
> Here is the logs from node with
> localId:3561ac09-6752-4e2e-8279-d975c268d045
> ignite-2019-10-06.gz
> <
> http://apache-ignite-users.70518.x6.nabble.com/file/t2515/ignite-2019-10-06.gz>
>
>
> cache creation is done with java code on our side, we use getOrCreateCache
> method, here is the piece of code how we configure and create caches;
>
> ...
> ignite.getOrCreateCache(getCommonCacheConfigurationForAccount(accountId,
> initCacheType));
>
> private  CacheConfiguration
> getCommonCacheConfigurationForAccount(String accountId, IgniteCacheType
> cacheType) {
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration<>();
>
>
> cacheConfiguration.setName(accountId.concat(cacheType.getCacheNameSuffix()));
> if (cacheType.isSqlTable()) {
> cacheConfiguration.setIndexedTypes(cacheType.getKeyClass(),
> cacheType.getValueClass());
> cacheConfiguration.setSqlSchema(accountId);
> cacheConfiguration.setSqlEscapeAll(true);
> }
> cacheConfiguration.setEventsDisabled(true);
> cacheConfiguration.setStoreKeepBinary(true);
> cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
> cacheConfiguration.setBackups(1);
> if (!cacheType.getCacheGroupName().isEmpty()) {
> cacheConfiguration.setGroupName(cacheType.getCacheGroupName());
> }
> if (cacheType.getExpiryDurationInDays().getDurationAmount() > 0) {
>
>
> cacheConfiguration.setExpiryPolicyFactory(TouchedExpiryPolicy.factoryOf(cacheType.getExpiryDurationInDays()));
> }
> return cacheConfiguration;
> }
>
>
>
> -
> İbrahim Halil Altun
> Senior Software Engineer @ Segmentify
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Get key or cache's updation time?

[Andrei Aleksandrov]

Hi,

I guess that you can use CacheEntry to check that new version of entry 
is different from previous. Example you can see here:


https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/CacheEntry.html

In case of you are going to check cache updates then try to use Events 
(but here you can get performance drop):


https://apacheignite.readme.io/docs/events

BR,
Andrei

10/11/2019 4:08 PM, SidP пишет:

Is there a way to know if key and/or cache is updation time?

I want to check if key or cache is updated in last 10 sec or not?




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

Re: Unresponsive cluster after "Checkpoint read lock acquisition has been timed out" Error

[ihalilaltun]

Hi Ilya,

Yes we have persistence enabled.










OS is not swapping out ignite memory, since we have more than enough
resources on the server. The disks used for persistence are ssd ones with
96MB/s read and write speed. Is there any easy way to check if we are
running out of data region?

Regards.



-
İbrahim Halil Altun
Senior Software Engineer @ Segmentify
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Get key or cache's updation time?

[SidP]

Is there a way to know if key and/or cache is updation time?

I want to check if key or cache is updated in last 10 sec or not?




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

Re: Cluster went down after "Unable to await partitions release latch within timeout" WARN

[ihalilaltun]

Hi Pavel,

Here is the logs from node with localId:3561ac09-6752-4e2e-8279-d975c268d045
ignite-2019-10-06.gz

  

cache creation is done with java code on our side, we use getOrCreateCache
method, here is the piece of code how we configure and create caches;

...
ignite.getOrCreateCache(getCommonCacheConfigurationForAccount(accountId,
initCacheType));

private  CacheConfiguration
getCommonCacheConfigurationForAccount(String accountId, IgniteCacheType
cacheType) {
CacheConfiguration cacheConfiguration = new
CacheConfiguration<>();
   
cacheConfiguration.setName(accountId.concat(cacheType.getCacheNameSuffix()));
if (cacheType.isSqlTable()) {
cacheConfiguration.setIndexedTypes(cacheType.getKeyClass(),
cacheType.getValueClass());
cacheConfiguration.setSqlSchema(accountId);
cacheConfiguration.setSqlEscapeAll(true);
}
cacheConfiguration.setEventsDisabled(true);
cacheConfiguration.setStoreKeepBinary(true);
cacheConfiguration.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cacheConfiguration.setBackups(1);
if (!cacheType.getCacheGroupName().isEmpty()) {
cacheConfiguration.setGroupName(cacheType.getCacheGroupName());
}
if (cacheType.getExpiryDurationInDays().getDurationAmount() > 0) {
   
cacheConfiguration.setExpiryPolicyFactory(TouchedExpiryPolicy.factoryOf(cacheType.getExpiryDurationInDays()));
}
return cacheConfiguration;
}



-
İbrahim Halil Altun
Senior Software Engineer @ Segmentify
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: Authenticating communication between nodes using Ignite.Net

[Ilya Kasnacheev]

Hello!

If you really need authentication of nodes, you can add SSL configuration
with certificate checking.

This means that any rogue node will not be able to join since it does not
have proper certificate.

This is also much more secure than passwords. Make sure to add SSL to all
ports, such as connectors, ODBC, etc.

Regards,
-- 
Ilya Kasnacheev


чт, 10 окт. 2019 г. в 02:07, alokyadav12 :

> We are new to Ignite.Net and trying to implement few security feature
> before
> deciding final implementation in product.
>
> We had implemented authentication on Ignite Server and when connecting Thin
> client it user user id and password and working as expected.
> We had noticed that if we spun off another Node then it connects
> automatically to running node and doesnt need username and password.
>
> Question 1 : Does thick client and node does not authenticate when
> connecting nodes?
>
> Question 2 : Found an article to create custome plugin and authenticate
> http://smartkey.co.uk/development/securing-an-apache-ignite-cluster/. This
> article focused on Java implementation, but we are using Ignite.Net and
> didnt find the  DiscoverySpiNodeAuthenticator,  GridSecurityProcessor
> Interfaces to create a plugin. Are these classes available to use in
> Ignite.Net? Is there any other alternate available.
>
> Is there any other way we can authenticate thick client and nodes when
> connecting, as we need to secure nodes so only authenticated nodes and
> Thick
> client can connect.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Unresponsive cluster after "Checkpoint read lock acquisition has been timed out" Error

[Ilya Kasnacheev]

Hello!

Unfortunately it's hard to say what happens here, because the oldest log
already starts with error messages and any root causes are clobbered.

Do you have persistence in this cluster? If the answer is yes, are you sure
that OS is not swapping out Ignite memory to disk, and that your disk is
not overwhelmed with updates. If no, please make sure you're not running
out of data region.

Regards,
-- 
Ilya Kasnacheev


ср, 9 окт. 2019 г. в 13:50, ihalilaltun :

> Hi There,
>
> We had a unresponsive cluster today after the following error;
>
>
> [2019-10-09T07:08:13,623][ERROR][sys-stripe-94-#95][GridCacheDatabaseSharedManager]
> Checkpoint read lock acquisition has been timed out.
>
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$CheckpointReadLockTimeoutException:
> Checkpoint read lock acquisition has been timed out.
> at
>
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.failCheckpointReadLock(GridCacheDatabaseSharedManager.java:1564)
> ~[ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1497)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1739)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1668)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3138)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:135)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:271)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
> [ignite-core-2.7.6.jar:2.7.6]
> at
>
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
> [ignite-core-2.7.6.jar:2.7.6]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> [ignite-core-2.7.6.jar:2.7.6]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201]
>
>
>
> After this log cluster went into infinite loop somehow and became
> unresponsive. Since log files are bigger than 5MB, I am sharing
> google-drive
> link for all log files.
>
> https://drive.google.com/drive/folders/1XHaw2YZq3_F4CMw8m_mJZkUz1K17njU9?usp=sharing
>
> any help appriciated
>
> thanks
>
>
>
>
> -
> İbrahim Halil Altun
> Senior Software Engineer @ Segmentify
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: GridCachePartitionExchangeManager Null pointer exception

[Ilya Kasnacheev]

Hello!

In Java, assertions is a run-time property. You can enable them by passing
-ea flag to JVM. Note that we don't recommend running Ignite with
assertions on.

Regards,
-- 
Ilya Kasnacheev


пт, 11 окт. 2019 г. в 11:52, maheshkr76private :

> Pavel, are ignite 2.7.6 binaries built with assertions disabled? THis could
> explain the null pointer exception seen here on the server-side. I am still
> not following if the null pointer exception, that I am reporting here is
> understood and if there is a defect filed for this
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Starvation in striped pool

[Ilya Kasnacheev]

Hello!

I don't think there is any problem with idleConnectionTimeout, but you *should
not* use nodes which are not mutually connectible to each other anyway.

I can't really comment on the feasibility of dropping client when it can't
be reached via Communication. You can start a discussion about it on
developers list.

Regards,
-- 
Ilya Kasnacheev


пт, 11 окт. 2019 г. в 11:31, maheshkr76private :

> >>I'm almost certain is that problem is that server node cannot open a
> connection to client node (and while it tries, it will reject connection
> attempts from client node)
>
> The default idleTimeout of TCP communication spi is 6 minutes. So I assume,
> after this timeout, the connection is closed and restarted probably later
> on
> a request from the client.
> So I can imagine, this issue happening, when the client and server are
> trying to re-establish the connection and your explanation makes sense.
>
> However, my concern still remains.  The server has plenty of timeouts in
> its
> communication SPI. Why wouldn't the server, not throw that client out of
> the
> cluster and let the client fail gracefully? This incessant pinging by
> client
> to the server is a problem in production environments.
>
> Currently, the only way out for me seems to be set
>  >>>communicationSpi.setIdleConnectionTimeout(Long.MAX_VALUE);
> testing is currently and seems to be holding up for 22 hours now.
>
> Do you see any issues with setting idleConnectionTimeout that high?
>
>
>
>
>
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Events and selective marshalling between nodes?

[Ilya Kasnacheev]

Hello!

I have looked up code, and it seems that if key or value can't be
deserialized, it will be passed into event in BinaryObject form.

Is it not working for you? Can you show which errors you are getting?

Otherwise, you can try using rmtFilter with same considerations.

Otherwise, there is no way to peer load key/value classes yet.

Regards,
-- 
Ilya Kasnacheev


пт, 11 окт. 2019 г. в 04:26, KJQ :

> Hello everyone,
>
> I am not even sure how to phrase this so I will try to describe the
> environment...
>
> We have numerous embedded Ignite instances (server mode) that deploy into a
> K8S cluster.  Between those instances we have Ignite events being raised
> for
> PUT and EXPIRED.  We have at least one instance, also a part of the Ignite
> cluster, which uses Drools and distributed compute (this works good so
> far).
>
> The problem we are having is when the distributed compute node raises the
> cache events to other nodes, they do not have those classes there.  For
> example, Drools caches some stuff specific to it and when that event gets
> raised to other nodes (who have no knowledge of Drools) an exception is of
> course thrown.
>
> So my questions are:
>
> - Can I selectively choose what to raise the event for based on the type?
> For example, check the event "value" and ignore if something I am not
> concerned with and not raise it.
>
> - Is the only way to share classes between nodes, whose Java applications
> may not have knowledge of each other, through peer-classloading or
> downloading a jar?  For example, projectB depends on projectA so it is
> aware
> of A's classes but projectA has no knowledge of projectB in the event B
> raises an event from its cached object to A.
>
> - How does all of this play into Spring?  If I do somehow get the classes
> into each node, do they have to be within the SpringContext (IoC
> configured)
> or is having the classes available good enough?  This applies to using the
> @SpringResource in something like a callable.
>
> Any help or guidance is greatly appreciated.
>
>
>
> -
> KJQ
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: GridCachePartitionExchangeManager Null pointer exception

[maheshkr76private]

Pavel, are ignite 2.7.6 binaries built with assertions disabled? THis could
explain the null pointer exception seen here on the server-side. I am still
not following if the null pointer exception, that I am reporting here is
understood and if there is a defect filed for this



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

Re: Starvation in striped pool

[maheshkr76private]

>>I'm almost certain is that problem is that server node cannot open a
connection to client node (and while it tries, it will reject connection
attempts from client node)

The default idleTimeout of TCP communication spi is 6 minutes. So I assume,
after this timeout, the connection is closed and restarted probably later on
a request from the client. 
So I can imagine, this issue happening, when the client and server are
trying to re-establish the connection and your explanation makes sense. 

However, my concern still remains.  The server has plenty of timeouts in its
communication SPI. Why wouldn't the server, not throw that client out of the
cluster and let the client fail gracefully? This incessant pinging by client
to the server is a problem in production environments. 

Currently, the only way out for me seems to be set 
 >>>communicationSpi.setIdleConnectionTimeout(Long.MAX_VALUE);
testing is currently and seems to be holding up for 22 hours now. 

Do you see any issues with setting idleConnectionTimeout that high?



  




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