In which scenario the ignite nodes will shutdown by itself

[aa...@tophold.com]

Hi All, 

we notice more than one time the ignite node and cache just stop itself quietly 
. this is weird, no specific ERROR log print. 

we allocated enough memory for those cache.  From the GC log we can not find 
any obvious abnormal as the main process still running . 
























we have enough memory for this cache:








the server have 64G memory totally 

But if we keep run for more than 5 hours then we keep getting:

javax.cache.CacheException: class 
org.apache.ignite.internal.NodeStoppingException: Operation has been cancelled 
(node is stopping).
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1312)
 ~[ignite-core-2.1.0.jar!/:2.1.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:2630)
 ~[ignite-core-2.1.0.jar!/:2.1.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1509)
 ~[ignite-core-2.1.0.jar!/:2.1.0]
at 
com.tophold.trade.booker.TransactionCommandGateWay.handle(TransactionCommandGateWay.java:343)
 ~[classes!/:?]
at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source) ~[?:?]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:1.8.0_131]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_131]

Eventually:

java.lang.IllegalStateException: class 
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to 
perform cache operation (cache is stopped): TransactionEntry
at 
org.apache.ignite.internal.processors.cache.GridCacheGateway.checkState(GridCacheGateway.java:88)
 ~[ignite-core-2.1.0.jar!/:2.1.0]
at 
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:179)
 ~[ignite-core-2.1.0.jar!/:2.1.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.onEnter(IgniteCacheProxy.java:2722)
 ~[ignite-core-2.1.0.jar!/:2.1.0]
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:1172)
 ~[ignite-core-2.1.0.jar!/:2.1.0]

our JVM arguments:

-Xms10g
-Xmx10g
-server
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=D:\data\memory
-XX:NewRatio=3
-XX:SurvivorRatio=8
-XX:+UseTLAB
-XX:GCTimeRatio=4
-XX:+ScavengeBeforeFullGC
-XX:G1HeapRegionSize=8M
-XX:ConcGCThreads=8
-XX:G1HeapWastePercent=10
-XX:+AggressiveOpts
-XX:MaxMetaspaceSize=256m
-XX:+UseG1GC
-XX:MaxGCPauseMillis=1000
-XX:InitiatingHeapOccupancyPercent=35
-XX:+DisableExplicitGC
-Djava.awt.headless=true


Need we detect the Node stopping itself events?  then re-bring up the Ignite 
instance and cache?  very appreciate your time!



Regards



aa...@tophold.com

RE: Activation: slow and: Ignite node crashed in the middle of checkpoint.

[Roger Fischer (CW)]

Hi Alex,

there were no other relevant logs than what I already listed in the first email.

http://www.springframework.org/schema/beans;
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation="
   http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd;>







10.24.51.190
10.24.51.187
10.24.51.150




   










































dateTime
portId







portId
dateTime







switchId
dateTime















All 3 servers (and the client) are on VMs on the same host. No network hop 
latency. But all 3 VMs use the same physical disk (on the host).

Servers have 16 GB of RAM. Data on disk (work/db) was about 35 GB per mode. 
About 36M objects.

Please also note 
http://apache-ignite-users.70518.x6.nabble.com/Strange-problems-with-Ignite-native-Persistence-when-Data-exceeds-Memory-td16187.html.
There were some odd problems at time that may have affected the activation.

Roger


From: afedotov [mailto:alexander.fedot...@gmail.com]
Sent: Monday, August 14, 2017 11:05 AM
To: user@ignite.apache.org
Subject: Re: Activation: slow and: Ignite node crashed in the middle of 
checkpoint.

Hi,

Could you please share the logs and configuration?
Actually, the activation time depends on the amount of data, network 
connectivity and other variables.

Kind regards,
Alex.

On Sat, Aug 12, 2017 at 12:39 AM, Roger Fischer (CW) [via Apache Ignite Users] 
<[hidden email]> wrote:
Hello,

I am wondering if the following behavior is typical, or if it represents a 
concern.

I have a 3 node cluster with native persistence. Each node as 4 CPU and 16 GB 
of RAM.
Each node has ~45 GB used in work/db. Total across the 3 nodes is about 36.5 M 
objects.
I am using SQL queries, and there are 3 indexes.

The servers start up normally and join the cluster, as expected.

When I start the client, which calls active(), all 3 servers report the 
following:

[12:41:28] Topology snapshot [ver=5, servers=3, clients=1, CPUs=16, heap=4.8GB]
[12:41:29] Default checkpoint page buffer size is too small, setting to an 
adjusted value: 2.0 GiB
[12:41:29] Ignite node crashed in the middle of checkpoint. Will 

Re: Streaming test

[vkulichenko]

What is this class used for? I'm a bit confused - service is usually invoked
on the server, so it will obviously need all classes it works with. Am I
missing something?

Can you show the whole trace?

-Val



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

Re: Streaming test

[waterg]

Hello Val,

I now put the stream visitor code in a different model and packaged it in a
different jar with dependencies. 

Interestingly, when I ran the program again, the server node has weird error
messages. 
The FileConnector is a class in the client jar. Why would the service needs
the caller's signature?
Btw, I turned enablePeerClassLoader on, but I still have the same error.

Jessie 

Caused by: java.lang.ClassNotFoundException: com.sample.client.FileConnector
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
~[?:1.8.0_
91]
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
~[?:1.8.0_91]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
~[?:1.8
.0_91]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
~[?:1.8.0_91]
at java.lang.Class.forName0(Native Method) ~[?:1.8.0_91]
at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_91]
at
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:
8478) ~[sample-client-0.1-SNAPSHOT-jar-with-dependencies.jar:?]
at
org.apache.ignite.internal.MarshallerContextImpl.getClass(MarshallerC
ontextImpl.java:340) ~[sample-client-0.1-SNAPSHOT-jar-with-dependencies.jar:
?]
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUt
ils.classDescriptor(OptimizedMarshallerUtils.java:268) ~[sample-client:?]



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

Strange problems with Ignite native Persistence when Data exceeds Memory

[Roger Fischer (CW)]

Hello,

I am running into strange problems with Ignite Native Persistence when the data 
exceeds the size of the cache (memory).

I have 3 nodes with 8 GB each, one cache, using 1 backup. I am using SQL 
queries, and the cache has 3 indexes.

I am loading 9.6M objects, using IgniteDataStreamer in a client. The work/db 
directory is about 13 GB on each node. Everything is fine.

Then I am trying to load another 4.8M objects. Here is where the problems start:
1) Loading becomes slow, less than 1000 objects per second.
2) Object are missed (not inserted). There is no indication, neither any logs 
nor any feedback to the client that does the loading.
3) The client that does the loading eventually hangs, waiting on a future. It 
never returns to my code.
4) Another client doing SQL queries eventually hangs also.
5) Restarting clients does not help, they will hang again. Thus deactivating 
the cluster to allow a server restart is not possible.

There are no logs to indicate any problems. No errors or warnings. Only 
periodic metrics logs.

The first time I ran into the problem, each server had 16 GB of RAM, and the 
problem happened when the work/db directory was about 35 GB.

This leads me to believe that the problem is related to the number of objects 
becoming bigger than what the cache can hold.

I am using simple native persistence, no special configuration.





ver. 2.1.0#20170720-sha1:a6ca5c8a

OS: Linux 3.10.0-514.el7.x86_64 amd64

VirtualBox VMs (all on same host), with dynamic disk (one drive on the host)

Roger

Re: Failure to deserialize simple model object

[Valentin Kulichenko]

Cross-posting to dev

Folks,

I'm confused by the issue discussed in this thread.

Here is the scenario:
- Start server node with a cache with POJO store configured. There is one
type declared, read-through enabled.
- Start client node and execute get() for a key that exists in underlying
DB.
- During deserialization on the client, 'Requesting mapping from grid
failed for' exception is thrown.

Specifying the type explicitly in BinaryConfiguration solves the issue, and
I think I understand technical reasons for this. But is this really
expected? Is it possible to fix the issue without requiring to provide this
configuration?

I thought we do not require to provide types in configuration as long as
there is only one platform involved, am I wrong? If yes, we need to
identify scenarios when this documentation is required and document them.

-Val

On Mon, Aug 14, 2017 at 4:23 AM, franck102  wrote:

> My bad, here is the whole project.
>
> Franck ignite-binary-sample.zip
>  n16158/ignite-binary-sample.zip>
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Failure-to-deserialize-simple-model-
> object-tp15440p16158.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

Re: EntryProcessor and Locks

[rajivgandhi]

What will happen for the reads when there is a concurrent write by some other
process?

Will we see OptimisticTransactionException or will be get stale reads
(preferred in out use case).

thanks!




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16185.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Running Spark SQL on Spark Thrift Server with Ignite

[vkulichenko]

Ravi,

You can take a look at these pages:

https://apacheignite-fs.readme.io/docs/ignitecontext-igniterdd
https://apacheignite-fs.readme.io/docs/testing-integration-with-spark-shell

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Running-Spark-SQL-on-Spark-Thrift-Server-with-Ignite-tp16087p16184.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Query about running SQL with durable memory

[vkulichenko]

Dmitry,

When you execute a SQL query, there is no deserialization at all. Ignite
stores data in binary format that allows to lookup fields without full
deserialization. So only required fields are fetched from the objects.

https://apacheignite.readme.io/docs/binary-marshaller

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Query-about-running-SQL-with-durable-memory-tp16015p16183.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Use SLF4J in Ignite

[Jessie Lin]

Yes, the ignite-slf4j folder is copied over

[image: Inline image 1]

On Mon, Aug 14, 2017 at 1:10 PM, ignite_user2016 
wrote:

> It looks like ignite version of slf4j is not in the classpath.
>
> Did you copy the ignite slf4j jars into server lib directory ?
>
> On Mon, Aug 14, 2017 at 1:55 PM, waterg [via Apache Ignite Users] <[hidden
> email] > wrote:
>
>> Hello there,
>>
>> I'm having following error when starting Ignite server node
>>
>> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
>> SLF4J: Defaulting to no-operation (NOP) logger implementation
>> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
>> further detail
>> s.
>>
>> In maven pom file, I added
>> 
>> org.apache.ignite
>> ignite-slf4j
>> ${ignite.version}
>> 
>> In XML config, I added:
>> 
>> 
>> 
>> I've also moved 'optional/ignite-slf4j' folder to
>> 'libs' folder before running 'ignite.{sh|bat}' script, according to
>> README here https://github.com/apache/ignite/tree/master/modules/slf4j
>>
>> What should I do differently?
>>
>> Thank you.
>> Jessie
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://apache-ignite-users.70518.x6.nabble.com/Use-SLF4J-in-
>> Ignite-tp16179.html
>> To start a new topic under Apache Ignite Users, email [hidden email]
>> 
>> To unsubscribe from Apache Ignite Users, click here.
>> NAML
>> 
>>
>
>
>
> --
> Rishi Yagnik
>
> --
> View this message in context: Re: Use SLF4J in Ignite
> 
>
> Sent from the Apache Ignite Users mailing list archive
>  at Nabble.com.
>

Re: Use SLF4J in Ignite

[ignite_user2016]

It looks like ignite version of slf4j is not in the classpath.

Did you copy the ignite slf4j jars into server lib directory ?

On Mon, Aug 14, 2017 at 1:55 PM, waterg [via Apache Ignite Users] <
ml+s70518n1617...@n6.nabble.com> wrote:

> Hello there,
>
> I'm having following error when starting Ignite server node
>
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
> detail
> s.
>
> In maven pom file, I added
> 
> org.apache.ignite
> ignite-slf4j
> ${ignite.version}
> 
> In XML config, I added:
> 
> 
> 
> I've also moved 'optional/ignite-slf4j' folder to
> 'libs' folder before running 'ignite.{sh|bat}' script, according to README
> here https://github.com/apache/ignite/tree/master/modules/slf4j
>
> What should I do differently?
>
> Thank you.
> Jessie
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Use-SLF4J-
> in-Ignite-tp16179.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>



-- 
Rishi Yagnik




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

Re: Query about running SQL with durable memory

[Dmitri Bronnikov]

If memory cache is empty and all 10 entries are on disk, will Ignite
de-serialize all of them? Can de-serialization be avoided if the query has a
filter, e.g. SELECT COUNT(*) FROM EMP WHERE SALARY > ?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Query-about-running-SQL-with-durable-memory-tp16015p16180.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Use SLF4J in Ignite

[waterg]

Hello there,

I'm having following error when starting Ignite server node

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
detail
s.

In maven pom file, I added

org.apache.ignite
ignite-slf4j
${ignite.version}

In XML config, I added:



I've also moved 'optional/ignite-slf4j' folder to
'libs' folder before running 'ignite.{sh|bat}' script, according to README
here https://github.com/apache/ignite/tree/master/modules/slf4j

What should I do differently?

Thank you.
Jessie



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

Re: TcpDiscoveryVmIpFinder handle IP change

[Nikolai Tikhonov]

Hi David,

JVM can cache a name service. Could you try to set
*networkaddress.cache.ttl* to zero?

1.
http://www.myhowto.org/java/42-understanding-host-name-resolution-and-dns-behavior-in-java
2. http://docs.oracle.com/javase/1.5.0/docs/guide/net/properties.html

On Mon, Aug 14, 2017 at 10:18 AM, David Li  wrote:

> Hi all,
>
> Currently I am connecting to an ignite server node
> with TcpDiscoveryVmIpFinder, from a client node, using a domain as
> hostname, eg. ignite.dev, normally when there is any network issue or
> server issue, the client node will reconnect automatically when the network
> restore or ignite server node up again. But it cannot reconnect if the IP
> address of the server node has changed.
>
> I had a look the TcpDiscoveryVmIpFinder class, when setting the address,
> it resolve the ip string (or hostname) as  InetSocketAddress , I guess
> when ignite try to reconnect, it directly use the  InetSocketAddress ,
> will not try to resolve the ip address by the original hostname, so I am
> thinking maybe I can extend the TcpDiscoveryVmIpFinder, and make it work
> for my scenario, but I am not very sure about the place to change.
>
> Overall, my ignite server node may change its IP address if it up from a
> failure, and I want my client node can automatically reconnect itself to
> the server node. Any help are appreciated. Thank you.
>
>
> David
> 14 Aug
>
>

Re: PeerClassLoading example using cacheLoaders

[afedotov]

Hi,

You are right, *load* method is called when there is a miss in a cache.
putIfAbsent is supported by IgniteCache out of the box. I'm afraid that
there is no simple way to achieve what
a CacheStore offers. With any other approach, you would have to sacrifice
read/write-through behavior.


Kind regards,
Alex.

On Sat, Aug 12, 2017 at 8:39 AM, daniels [via Apache Ignite Users] <
ml+s70518n16149...@n6.nabble.com> wrote:

> Thank you,very much.
>
> And one more question, The  load method  of cacheLoader is called when I
> do get from cache with the key which does not exists. Isn't it?
>
>  Isnt it solution without passing chacheLoader   -I do get and if the key
> is  absent ,do put that key in the cache,in other words do  putIfAbsent but
>  in my code ?
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/PeerClassLoading-example-
> using-cacheLoaders-tp16136p16149.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/PeerClassLoading-example-using-cacheLoaders-tp16136p16177.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Activation: slow and: Ignite node crashed in the middle of checkpoint.

[afedotov]

Hi,

Could you please share the logs and configuration?
Actually, the activation time depends on the amount of data, network
connectivity and other variables.


Kind regards,
Alex.

On Sat, Aug 12, 2017 at 12:39 AM, Roger Fischer (CW) [via Apache Ignite
Users]  wrote:

> Hello,
>
>
>
> I am wondering if the following behavior is typical, or if it represents a
> concern.
>
>
>
> I have a 3 node cluster with native persistence. Each node as 4 CPU and 16
> GB of RAM.
>
> Each node has ~45 GB used in work/db. Total across the 3 nodes is about
> 36.5 M objects.
>
> I am using SQL queries, and there are 3 indexes.
>
>
>
> The servers start up normally and join the cluster, as expected.
>
>
>
> When I start the client, which calls active(), all 3 servers report the
> following:
>
>
>
> [12:41:28] Topology snapshot [ver=5, servers=3, clients=1, CPUs=16,
> heap=4.8GB]
>
> [12:41:29] Default checkpoint page buffer size is too small, setting to an
> adjusted value: 2.0 GiB
>
> [12:41:29] Ignite node crashed in the middle of checkpoint. Will restore
> memory state and enforce checkpoint on node start.
>
>
>
> 1) Should I worry about the “crashed” log?
>
>
>
> The activation takes more than 30 minutes (until active() returns).
>
>
>
> 2) Is that normal for activate to take that long?
>
>
>
> ver. 2.1.0#20170720-sha1:a6ca5c8a
>
> OS: Linux 3.10.0-514.el7.x86_64 amd64
>
>
>
> Thanks…
>
>
>
> Roger
>
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Activation-slow-and-Ignite-
> node-crashed-in-the-middle-of-checkpoint-tp16144.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Activation-slow-and-Ignite-node-crashed-in-the-middle-of-checkpoint-tp16144p16176.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: EntryProcessor and Locks

[afedotov]

HI,

Yes, I meant starting a transaction via
igniteInstance.transactions().txStart(OPTIMISTIC, isolationLevel)
and calling cache.invoke(key, entryProcessor) within its scope.

Kind regards,
Alex.

On Mon, Aug 14, 2017 at 7:59 PM, rajivgandhi [via Apache Ignite Users] <
ml+s70518n16172...@n6.nabble.com> wrote:

> By the way, I requested subscribe several times.
>
> The one thing with subscription is that it floods my email box with
> messages from other threads as well.
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-
> tp16150p16172.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16175.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite starting by itself when using javax.cache.Caching

[matt]

Hi, thanks for your help. I understand the problem now... exactly what you
said it was.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-starting-by-itself-when-using-javax-cache-Caching-tp15997p16174.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Unsubscribe

[Πασχαλης Γεωργοπουλος]

Re: EntryProcessor and Locks

[rajivgandhi]

By the way, I requested subscribe several times.

The one thing with subscription is that it floods my email box with messages
from other threads as well.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16172.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: EntryProcessor and Locks

[rajivgandhi]

Thanks. 

How do you use optimistic tx with Entry processor? The ConcurrencyMode and
isolationMode can only be set when you start a tx. Are you saying we should
call the entry processor within a tx with concurencymode Optimistic?

thanks !



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16171.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Apache Ignite 2.0.0 Events Issue

[Igor Sapego]

Hi,

There is 2 issues in your code:

1) You only put 1 value in cache and you cannot be sure whether your
node is primary for this particular key or not. As you use "LocalListen"
you will only receive notifications for those events which are local for
your node. Try putting 100 key-value pairs - you will receive notifications
for roughly half of them, as the second half will be stored on remote node.

2) Your second node starts without cacheEvents-config file so events
won't be enabled for it.

Also, note, that your second node is not client node. This is the server
node just as the first one. If you want to start client node you need to
explicitly configure it to be a client. See [1] for details. But also keep
in
mind that if you make your second node client it will not receive any
CacheObjectPut or CacheObjectRemoved etc local events, as it will not
store cache data locally and thus those events won't be "local" for it.

[1] -
https://apacheignite.readme.io/docs/clients-vs-servers#section-configuring-clients-and-servers

Best Regards,
Igor

On Sat, Aug 12, 2017 at 6:59 PM, Ramón Dominguez Rivas 
wrote:

> Hey guys I posted a few days ago a message in the gitter chat where I was
> mentioning issues with remote events using .NET API, so here I am attaching
> the files and the way to reproduce my issue as you were asking me for do it.
>
> 1) Take the cacheEvents-config file as config for a SERVER standalone
> node, I did use the Apache.Ignite.exe wrapper as utility for run this node.
>
> 2)Take the ApacheIgniteEventsTest solution zipped and run it in the same
> machine you are running the server node, this project creates a node on
> client mode and the subscribed events there are never reached by the
> subscribed listener. I just followed what the documentation says but looks
> like there are no way to listen remote events using the IEvents interface
> in the .net interface.
>
> Thank you in advance guys.
>

Re: EntryProcessor and Locks

[afedotov]

Hi,

Looks like you are not subscribed to the mailing list. Please make sure you
are   subscribed

 
.

Answering to your questions,
with the PESSIMISTIC or implicit transactions EntryProcessor will cause a
lock on a key, thus
making one of the threads waiting on another.

Probably, you should consider the  OPTIMISTIC

  
mode.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/EntryProcessor-and-Locks-tp16150p16169.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[franck102]

Thanks Alex!



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159p16168.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[afedotov]

Hi,

Yes, GetOrCreateCache should do the thing in this case.

Kind regards,
Alex.

On Mon, Aug 14, 2017 at 3:53 PM, franck102 [via Apache Ignite Users] <
ml+s70518n16165...@n6.nabble.com> wrote:

> Hi Alex,
>
> Regarding this statement:
> "When you destroy or create a cache from a client node, there generally no
> need to have/propagate the configuration manually to remote nodes.
> *On join/restart*, a node will find out the caches configured in the
> cluster and all the required routines will take place."
>
> I assume that after destroying the cache, simply calling GetOrCreateCache
> locally on the client node will be enough for remote server nodes to pick
> up the new cache and its configuration - without having to restart them?
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-
> management-tp16159p16165.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159p16167.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Client requires DataSource bean configuration copy

[franck102]

In case someone else hits this, the issue is easily resolved by embedding
cachestore and datasource facotyr beans in the cache bean, instead of using
spring references:



Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-requires-DataSource-bean-configuration-copy-tp15491p16166.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[franck102]

Hi Alex,

Regarding this statement:
"When you destroy or create a cache from a client node, there generally no
need to have/propagate the configuration manually to remote nodes.
*On join/restart*, a node will find out the caches configured in the cluster
and all the required routines will take place."

I assume that after destroying the cache, simply calling GetOrCreateCache
locally on the client node will be enough for remote server nodes to pick up
the new cache and its configuration - without having to restart them?



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159p16165.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Calling service methods from servlets

[afedotov]

Hi,

The first approach is preferable because the second one implies an
additional network round trip.



Kind regards,
Alex.

On Mon, Aug 14, 2017 at 2:44 PM, luqmanahmad [via Apache Ignite Users] <
ml+s70518n16160...@n6.nabble.com> wrote:

> Hi there,
>
> Let say we have a node singleton service with a method called
> doSomething()
>
> Now if we want to call the service from a servlet we can either inject the
> service in the servlet directly like:
>
> MyService service = ignite.services().serviceProxy("myService",
> "MyService.class", false);
> service.doSomething();
>
> or
>
> create a IgniteCallable and send it to server for execution. For example
>
> private class MyServiceCallable implements IgniteCallable {
> @ServiceResource(serviceName = "myService")
> private MyService myService;
>
> @Override
> public Object call() throws Exception {
> return myService.doSomething();
> }
> }
>
> getGrid().compute().call(new MyServiceCallable());
>
> Now the second call I know will be sent to the server for execution and
> the results will be sent back. Question is what is the difference between
> two and is there any performance cost using the first technique? Just
> looking for the best approach.
>
> Thanks,
> Luqman
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Calling-
> service-methods-from-servlets-tp16160.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Calling-service-methods-from-servlets-tp16160p16164.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[afedotov]

Hi,

There is no option to update the configuration of an existing cache. As
well, you cannot create two caches with the same name but different
configurations.
So, as you've correctly suggested, to achieve this, you need first to
destroy a cache and then start a new one with the updated configuration.
When you destroy or create a cache from a client node, there generally no
need to have/propagate the configuration manually to remote nodes.
On join/restart, a node will find out the caches configured in the cluster
and all the required routines will take place.

Kind regards,
Alex.

On Mon, Aug 14, 2017 at 2:53 PM, franck102 [via Apache Ignite Users] <
ml+s70518n16161...@n6.nabble.com> wrote:

> I need to be a bit more specific I guess.
> I need the ability to create new caches, or to update the configuration of
> existing caches.
> When updating the configuration of a cache other caches should not be
> affected - so a node restart is not a great option.
>
> Would this plan work:
> - The controller contains a client node; and also serves XML configuration
> for all cluster nodes through a REST endpoint
> - When an existing cache configuration is updated, the controller
>   1. updates the persistent configuration that it returns through the REST
> endpoint
>   2. destroys the cache
>   3. Recreates it use GetOrCreateCache
>
> I assume that 2. and 3. above will propagate the changes to the entire
> cluster? And 1. should take care of any late joiners or future restarts?
>
> Franck
>
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-
> management-tp16159p16161.html
> To start a new topic under Apache Ignite Users, email
> ml+s70518n1...@n6.nabble.com
> To unsubscribe from Apache Ignite Users, click here
> 
> .
> NAML
> 
>




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159p16163.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Apache Ignite JDBC Support for SAP BOXI or Other BI tools

[slava.koptilin]

Hi Ravi,

>  1) Do SAP BO or any other BI tool support Ignite as SQL Engine?. 
Yes, Apache Ignite provides integration with Tableau [1] and Pentaho [2].

As Jörn Franke mentioned above, you can use ODBC [3] or JDBC driver [4] in
order to processing data using standard SQL statements.

[1] https://apacheignite-tools.readme.io/docs/tableau
[2] https://apacheignite-tools.readme.io/docs/pentaho
[3] https://apacheignite.readme.io/docs/odbc-driver
[4] https://apacheignite.readme.io/docs/jdbc-driver

Best regards,
Slava.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Apache-Ignite-JDBC-Support-for-SAP-BOXI-or-Other-BI-tools-tp16154p16162.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Centralized configuration management

[franck102]

I need to be a bit more specific I guess.
I need the ability to create new caches, or to update the configuration of
existing caches.
When updating the configuration of a cache other caches should not be
affected - so a node restart is not a great option.

Would this plan work:
- The controller contains a client node; and also serves XML configuration
for all cluster nodes through a REST endpoint
- When an existing cache configuration is updated, the controller
  1. updates the persistent configuration that it returns through the REST
endpoint
  2. destroys the cache
  3. Recreates it use GetOrCreateCache

I assume that 2. and 3. above will propagate the changes to the entire
cluster? And 1. should take care of any late joiners or future restarts?

Franck





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159p16161.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Calling service methods from servlets

[luqmanahmad]

Hi there,

Let say we have a node singleton service with a method called doSomething()

Now if we want to call the service from a servlet we can either inject the
service in the servlet directly like:

MyService service = ignite.services().serviceProxy("myService",
"MyService.class", false);
service.doSomething();

or 

create a IgniteCallable and send it to server for execution. For example 

private class MyServiceCallable implements IgniteCallable {
@ServiceResource(serviceName = "myService")
private MyService myService;

@Override
public Object call() throws Exception {
return myService.doSomething();
}
}

getGrid().compute().call(new MyServiceCallable());

Now the second call I know will be sent to the server for execution and the
results will be sent back. Question is what is the difference between two
and is there any performance cost using the first technique? Just looking
for the best approach. 

Thanks,
Luqman



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Calling-service-methods-from-servlets-tp16160.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Centralized configuration management

[franck102]

Hi all,

I am trying to design a controller that will be responsible for managing the
cache configuration of all nodes in a cluster. Having read this in the docs:

"All caches defined in Ignite Spring XML configuration on any cluster member
will also be automatically created and deployed on all the cluster servers
(no need to specify the same configuration on each cluster member)."...

I am thinking of having that controller start a client node and join the
cluster. This raises a few questions though:

- If I update the configuration on the controller, can I manually trigger a
re-deployment to all nodes?
- on configuration changes I can re-create the client node and have it
re-join the cluster: will that trigger a re-deployment of the controller's
cache configuration? Or will that trigger an error because two different
cnofigurations exist for the same cache?
- If that is what it takes, is there any node-2-node or REST API I can use
to restart each node in the cluster?

Any other suggestion to design a configuration manager that can control the
cache configuration for an entire cluster is welcome... thanks!

Franck



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Centralized-configuration-management-tp16159.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Failure to deserialize simple model object

[franck102]

My bad, here is the whole project.

Franck ignite-binary-sample.zip

  



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Failure-to-deserialize-simple-model-object-tp15440p16158.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Async messaging

[Humphrey]

Hello, I bumped into the same error. Was not clear to me that you shouldn't
call the future after doing the send:

IgniteMessaging message = ignite.message().withAsync();
message.send("destination", "hello world");
IgniteFuture future = message.future();
log.info("Keeps on throwing exception")

Was giving me the exception:
Exception in thread "pub-#67%null%" java.lang.IllegalStateException:
Asynchronous operation not started.
at
org.apache.ignite.internal.AsyncSupportAdapter.future(AsyncSupportAdapter.java:91)
at
org.apache.ignite.internal.AsyncSupportAdapter.future(AsyncSupportAdapter.java:73)

The correct way to use it is without calling the message.future()

IgniteMessaging message = ignite.message().withAsync();
message.send("destination", "hello world");
log.info("Doing async!")

Hope this helps someone else.



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

TcpDiscoveryVmIpFinder handle IP change

[David Li]

Hi all,

Currently I am connecting to an ignite server node
with TcpDiscoveryVmIpFinder, from a client node, using a domain as
hostname, eg. ignite.dev, normally when there is any network issue or
server issue, the client node will reconnect automatically when the network
restore or ignite server node up again. But it cannot reconnect if the IP
address of the server node has changed.

I had a look the TcpDiscoveryVmIpFinder class, when setting the address, it
resolve the ip string (or hostname) as  InetSocketAddress , I guess when
ignite try to reconnect, it directly use the  InetSocketAddress , will not
try to resolve the ip address by the original hostname, so I am thinking
maybe I can extend the TcpDiscoveryVmIpFinder, and make it work for my
scenario, but I am not very sure about the place to change.

Overall, my ignite server node may change its IP address if it up from a
failure, and I want my client node can automatically reconnect itself to
the server node. Any help are appreciated. Thank you.


David
14 Aug