Re: Continuous Queries

[vkulichenko]

Hi,

Local listener is executed on the node which started the query. Essentially,
it's never transferred across network.

-Val



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

Re: jar file update issue in ignite server side

[Alexey Kuznetsov]

Hi, Kevin!

In case of XML you do not need any custom CacheJdbcPojoStoreExampleFactory.
You should use CacheJdbcPojoStoreFactory and configure Datasource bean in
XML
And set dataSourceBean property.

Take a look on sample bellow:





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

http://www.springframework.org/schema/beans/spring-beans.xsd
   http://www.springframework.org/schema/util

http://www.springframework.org/schema/util/spring-util.xsd;>




















127.0.0.1:47500..47510





















































































-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

re: jar file update issue in ignite server side

[Zhengqingzheng]

Hi Alexey,
Thank you for your help.
One more question, How to set store factory class in all node class path?

I have java configurations like this:

  jdbcType = initMetaDatabaseJdbcTypeMapping(jdbcType,
metaCacheMap.get(cacheType));

storeFactory.setTypes(jdbcType);

cfg.setCacheStoreFactory(storeFactory);

// Set atomicity as transaction, since we are showing transactions in 
the example.
cfg.setAtomicityMode(CacheAtomicityMode.ATOMIC);
cfg.setIndexedTypes(metaCacheKeyTypeMap.get(cacheType),
metaCacheMap.get(cacheType));

cfg.setReadThrough(true);
cfg.setWriteThrough(true);

cfg.setCacheMode(CacheMode.PARTITIONED);

I see there is an example in 
http://apacheignite.gridgain.org/v1.1/docs/persistent-store
Do I need  the use xml configurations inside the server side?

Best regards,
Kevin

发件人: Alexey Kuznetsov [mailto:akuznet...@gridgain.com]
发送时间: 2016年4月22日 10:55
收件人: user@ignite.apache.org
主题: Re: jar file update issue in ignite server side

Hi!

I see in trace:
Caused by: java.lang.ClassNotFoundException: 
com.huawei.soa.ignite.util.CacheJdbcPojoStoreExampleFactory

Store factory class should be available in all nodes classpath.

On Fri, Apr 22, 2016 at 9:48 AM, Zhengqingzheng 
> wrote:
Hi Val,
Here is the exception trace:

[10:46:28,118][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi] Failed 
to unmarshal discovery custom message.
class org.apache.ignite.IgniteCheckedException: Failed to find class with given 
class loader for unmarshalling (make sure same versions of all classes are 
available on all nodes or enable peer-class-loading): 
sun.misc.Launcher$AppClassLoader@15136019
at 
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)
at 
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:78)
at 
org.apache.ignite.spi.discovery.tcp.messages.TcpDiscoveryCustomEventMessage.message(TcpDiscoveryCustomEventMessage.java:78)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:4731)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:4592)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2276)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5784)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2161)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException: 
com.huawei.soa.ignite.util.CacheJdbcPojoStoreExampleFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:278)
at 
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8172)
at 
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at java.util.ArrayList.readObject(ArrayList.java:771)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Continuous Queries

[ght230]

Local listener is executed on local client ignite node or on the remote
ignite server node?

If it is executed on local client node and I start several client node, can
it do loadbalance and enhance listener processing capabilities?



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

Re: jar file update issue in ignite server side

[Alexey Kuznetsov]

Hi!

I see in trace:
Caused by: java.lang.ClassNotFoundException: com.huawei.soa.ignite.util.
CacheJdbcPojoStoreExampleFactory

Store factory class should be available in all nodes classpath.

On Fri, Apr 22, 2016 at 9:48 AM, Zhengqingzheng 
wrote:

> Hi Val,
> Here is the exception trace:
>
> [10:46:28,118][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi]
> Failed to unmarshal discovery custom message.
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all
> classes are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@15136019
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:78)
> at
> org.apache.ignite.spi.discovery.tcp.messages.TcpDiscoveryCustomEventMessage.message(TcpDiscoveryCustomEventMessage.java:78)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:4731)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:4592)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2276)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5784)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2161)
> at
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> com.huawei.soa.ignite.util.CacheJdbcPojoStoreExampleFactory
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8172)
> at
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
> at java.util.ArrayList.readObject(ArrayList.java:771)
> at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1897)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
> at

re: jar file update issue in ignite server side

[Zhengqingzheng]

Hi Val,
Here is the exception trace:

[10:46:28,118][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi] Failed 
to unmarshal discovery custom message.
class org.apache.ignite.IgniteCheckedException: Failed to find class with given 
class loader for unmarshalling (make sure same versions of all classes are 
available on all nodes or enable peer-class-loading): 
sun.misc.Launcher$AppClassLoader@15136019
at 
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)
at 
org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:78)
at 
org.apache.ignite.spi.discovery.tcp.messages.TcpDiscoveryCustomEventMessage.message(TcpDiscoveryCustomEventMessage.java:78)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:4731)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:4592)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2276)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5784)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2161)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
Caused by: java.lang.ClassNotFoundException: 
com.huawei.soa.ignite.util.CacheJdbcPojoStoreExampleFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:278)
at 
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8172)
at 
org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.resolveClass(JdkMarshallerObjectInputStream.java:54)
at 
java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1612)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1517)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1771)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at java.util.ArrayList.readObject(ArrayList.java:771)
at sun.reflect.GeneratedMethodAccessor12.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1897)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at 
java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1997)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1921)
at 
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1798)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1350)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370)
at 
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:102)
... 8 more
[10:46:28,132][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi] Failed 
to unmarshal discovery custom message.
class org.apache.ignite.IgniteCheckedException: Failed to find 

Re: Client fails to connect - joinTimeout vs networkTimeout

[vkulichenko]

1. Failure detection timeout doesn't affect the join process, so this is
correct behavior.
2. I see your point, but setting joinTimeout looks like a good solution.
Does it work for you?
3. Yes, that's OK, and in most cases servers and clients should have the
same discovery configuration. TcpCommunicationSpi is used, but implicitly,
with all defaults.

As for the instability over time, I would check if you don't have any memory
issues. If the memory consumption grows, you will have longer GC pauses that
can cause issues.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-fails-to-connect-joinTimeout-vs-networkTimeout-tp4419p4437.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: jar file update issue in ignite server side

[vkulichenko]

Can you show the whole trace?

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/jar-file-update-issue-in-ignite-server-side-tp4401p4436.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: jar file update issue in ignite server side

[kevin.zheng]

Hi Val,
When I delete the jar class file from ./libs folder, and set
peerclassLoadingEnabled  to true inside the configuration file. I get the
following exception message:
[09:57:06,516][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi]
Failed to unmarshal discovery custom message.
class org.apache.ignite.IgniteCheckedException: Failed to find class with
given class loader for unmarshalling (make sure same versions of all classes
are available on all nodes or enable peer-class-loading):
sun.misc.Launcher$AppClassLoader@764c12b6
at
org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:108)

and It seems someone else experience the same problem, and I find the
discussion page :
https://issues.apache.org/jira/browse/IGNITE-1255
  
It seems that I still need to distribute jar files across all the ignite
servers.

Or do I missed anything?

kind regards,
Kevin
-
Hi Kevin,

This is right, JARs in libs folder are added to node classpath on startup
and replacing them in runtime doesn't have any effect.

However, you don't need to deploy your POJOs on server nodes. Ignite stores
all its data in binary format (see [1] for details) and never serializes it
on the server side unless you explicitly ask for this.

CacheJdbcPojoStore automatically detects if there is a class available and
uses BinaryObjectBuilder if it's not. You can then provide DB query that
will be used to load the data in loadCache() method parameters, so you can
define the list of fields to load. Take a look preload() method in [2] to
see how this can be done.

Let me know if you have more questions.

[1] https://apacheignite.readme.io/docs/binary-marshaller
[2]
https://github.com/apache/ignite/blob/master/examples/schema-import/src/main/java/org/apache/ignite/schema/Demo.java

-Val





--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/jar-file-update-issue-in-ignite-server-side-tp4401p4435.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: jar file update issue in ignite server side

[kevin.zheng]

Hi Val, 
Thank you for your suggestion. I have two more question regards to the table
loading problem.
1. Currently I have a table with 20 Millions records, it takes almost 2hours
to load all into the cache. is it normal this so long time? (I have set
offheap size to 30g, and begins with 2 nodes (each node has an independent
vm server).
2. I have another table with 50Million records, and I don't want to wait so
long time, So I decide to split this table into 10 small tables, each table
has a different name (say table_1, table_2 ), the column properties are
the same. So the OR Mapping become one Object Mapping with 10 smaller
tables. After the loading process, If I delete the 10 small tables, and I
want to update records into the original big one. Will Ignite write to the
original big one?

best wishes,
Kevin 



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/jar-file-update-issue-in-ignite-server-side-tp4401p4434.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Performance Issue - Threads blocking

[ccanning]

We seem to be having some serious performance issues after adding Apache
Ignite Local cache to our APIs'. Looking at a heap dump, we seem to have a
bunch of threads blocked by this lock:

"ajp-0.0.0.0-8009-70" - Thread t@641
   java.lang.Thread.State: RUNNABLE
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:166)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1486)
at
org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:1830)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadMap(BinaryUtils.java:1813)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1597)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1646)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:643)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:714)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:537)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:117)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinary(CacheObjectContext.java:280)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:145)
at
org.apache.ignite.internal.processors.cache.GridCacheEventManager.addEvent(GridCacheEventManager.java:276)
at
org.apache.ignite.internal.processors.cache.GridCacheEventManager.addEvent(GridCacheEventManager.java:159)
at
org.apache.ignite.internal.processors.cache.GridCacheEventManager.addEvent(GridCacheEventManager.java:92)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet0(GridCacheMapEntry.java:862)
- locked <70d32489> (a
org.apache.ignite.internal.processors.cache.local.GridLocalCacheEntry)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerGet(GridCacheMapEntry.java:669)
at
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.getAllInternal(GridLocalAtomicCache.java:587)
at
org.apache.ignite.internal.processors.cache.local.atomic.GridLocalAtomicCache.get(GridLocalAtomicCache.java:483)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.get(GridCacheAdapter.java:1378)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.get(IgniteCacheProxy.java:864)
at org.apache.ignite.cache.spring.SpringCache.get(SpringCache.java:52)

 - locked <70d32489> (a
org.apache.ignite.internal.processors.cache.local.GridLocalCacheEntry)

Should this be causing blocking in a high-throughput API? Do you have any
pointers in how we could solve this issue?

Thanks.



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Performance-Issue-Threads-blocking-tp4433.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Client fails to connect - joinTimeout vs networkTimeout

[bintisepaha]

Val, thanks for the quick response

1. I tried removing all the legacySettings and just using failureDetection
of 5 seconds and the client still hangs forever if the cluster is down.
2. Our clients are existing java apps that save orders to the database and
now to the grid too. If the grid is down, we don't want clients to stop
working, we want it to report an error and proceed further. without
specifying joinTimeout, this is not possible.
3. Is it ok if both server and client use the same TcpDsicoverySpi? I am not
using TcpCommunicationSpi anywhere.

Also, the clients were originally able to connect to grid fine, slowly over
time we are unable to establish new random connections. So it looks like the
grid becomes unstable over time.

Thanks,
Binti



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-fails-to-connect-joinTimeout-vs-networkTimeout-tp4419p4432.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Client fails to connect - joinTimeout vs networkTimeout

[vkulichenko]

Hi Binti,

1. networkTimeout , ackTimeout and maxAckTimeout are legacy settings and I
would recommend to use failure detection timeout instead [1]. This is a
global setting that defines the period of time during which a node can be
unaccessible before being considered failed. joinTimeout on the other side
defines how long node waits for discovery during startup. If discovery
doesn't happen, there can be different reasons. I would check server logs
and network load first.
2. What do you expect from the client in this case? Client can't actually
work without servers, even if it start, it will throw an exception on any
operation.
3. TcpDiscoverySpi and TcpCommunicationSpi are different components and are
used by any node (client or server) in parallel for different purposes. The
failure detection timeout is properly applied to both of them.

[1]
https://apacheignite.readme.io/docs/cluster-config#failure-detection-timeout

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-fails-to-connect-joinTimeout-vs-networkTimeout-tp4419p4431.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Best Practices for Deploying Ignite

[Jörn Franke]

In Addition to that you should make sure that you run JDK8, it has a lot of 
optimizations

> On 21 Apr 2016, at 21:06, vkulichenko  wrote:
> 
> In most cases it's OK to have one node per machine, but you should not
> allocate more than 10-12G of heap memory, because otherwise you will likely
> have long GC pauses. For storing the data you can use off-heap memory [1].
> 
> The only case when having several nodes per machine can be useful is when
> SQL queries are heavily used. If each node has less data, the SQL query
> execution can scale better and give better performance. Essentially, you
> will just better use CPU resources, so it's a good practice to start as many
> nodes as many cores you have.
> 
> [1] https://apacheignite.readme.io/docs/off-heap-memory
> 
> -Val
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/Best-Practices-for-Deploying-Ignite-tp4417p4426.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: ignite logging not captured in log file (log4j)

[vkulichenko]

To use Log4J, you need to enable optional ignite-log4j module (if you're
using Maven, add ignite-log4j dependency). The Log4J logging will be enabled
automatically without any configuration changes and will use the Log4J
settings used in your application. How to properly configure Log4J, please
refer to its documentation.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/ignite-logging-not-captured-in-log-file-log4j-tp4334p4429.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: jar file update issue in ignite server side

[vkulichenko]

Hi Kevin,

This is right, JARs in libs folder are added to node classpath on startup
and replacing them in runtime doesn't have any effect.

However, you don't need to deploy your POJOs on server nodes. Ignite stores
all its data in binary format (see [1] for details) and never serializes it
on the server side unless you explicitly ask for this.

CacheJdbcPojoStore automatically detects if there is a class available and
uses BinaryObjectBuilder if it's not. You can then provide DB query that
will be used to load the data in loadCache() method parameters, so you can
define the list of fields to load. Take a look preload() method in [2] to
see how this can be done.

Let me know if you have more questions.

[1] https://apacheignite.readme.io/docs/binary-marshaller
[2]
https://github.com/apache/ignite/blob/master/examples/schema-import/src/main/java/org/apache/ignite/schema/Demo.java

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/jar-file-update-issue-in-ignite-server-side-tp4401p4428.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Ignite support machine learning librarys?

[vkulichenko]

You don't have to implement algorithms from scratch, but you can use Compute
Grid to parallelize existing algorithms using existing libraries. Compute
Grid API is fairly simple, so if the algorithm itself allows to run it in
parallel, this should not be hard to implement.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-support-machine-learning-librarys-tp4305p4427.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

RE: Data lost when using write-behind

[vkulichenko]

Shaomin,

Session is ended when the cache update is done or when transaction is
committed/rolled back. In case of write behind the actual DB update can
happen after the cache store session ends.

There is no synchronization between this process and discovery event.
Actually, discovery event is fired on all nodes and the session is
node-local, so I'm not sure what you meant by your question. Please clarify
if anything is still unclear for you.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Data-lost-when-using-write-behind-tp4265p4425.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Automatic persistence ?

[vkulichenko]

You can do this in any IDE. Do you have any particular issues?

-Val



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

Re: ignite logging not captured in log file (log4j)

[bintisepaha]

I do not have ignite-log4j enabled. I tried doing what Kamal suggested, but
it expects a datatype of type IgniteLogger.

cfg.setGridLogger(new Log4JLogger());

Should I try this
cfg.setGridLogger(new JavaLogger());

How can I set it up in the XML configuration? Which log4j xml file should I
use? Sorry I am not very familiar with log4j settings.

Thanks,
Binti



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/ignite-logging-not-captured-in-log-file-log4j-tp4334p4423.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: No servlet container

[vkulichenko]

Hi Philippe,

Can you please properly subscribe to the mailing list so that the community
can receive email notifications? Here is the instruction:
http://apache-ignite-users.70518.x6.nabble.com/mailing_list/MailingListOptions.jtp?forum=1


ppet wrote
> I'm a Scala user and not using a servlet container for my deployments
> (Netty).
> I'm wondering if it's possible to use Ignite outside such a container, so
> without a web.xml file ?
> I can configure services through code, but is there issues like security
> or Ids handled by the container that should avoid the possibility tu use
> Ignite outside the container ?

There are no any requirements for having a Web container when using Ignite.
Please refer to examples [1] to see how Ignite should be embedded into an
application and used to access the cluster.

[1] https://github.com/apache/ignite/tree/master/examples

-Val



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

RE: BinaryObject performance issue

[vkulichenko]

Hi,

BinaryObject is designed to represent POJOs in binary format, in this case
schema change is generally a very rare event, so there is no performance
concern about metadata update. You use case is more specific and thus
requires specific solution.

And btw, I'm not sure I understand the difference between
BinaryObject.hasField and Map.containsKey in your scenario. Can you clarify?

-Val



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

Client fails to connect - joinTimeout vs networkTimeout

[bintisepaha]

We are running into production issues with some clients unable to connect to
the grid (16 server nodes running on linux). The error is 

Caused by: class org.apache.ignite.spi.IgniteSpiException: Join process
timed out, did not receive response for join request (consider increasing
'joinTimeout' configuration property) [joinTimeout=5000, sock=null]
   at
org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1334)
   at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)


DiscoverySpi has these settings





At the time, the clients got this error we tried increasing the timeout to
30 seconds and even 50 seconds, new client connections from some windows
machine just won't happen. We read
http://apache-ignite-users.70518.x6.nabble.com/Help-with-tuning-for-larger-clusters-td1692.html
 
[1]

  
and got rid of joinTimeout and started using networkTimeout. It seems to be
working this way so far (have not yet pushed to production).

When we specify joinTimeout along with networkTimeout, we still cannot
connect.

Question 1) What is the difference between these 2 settings - join and
network timeout. 
Question 2) Without a joinTimeout in test environment, if the cluster is
down the client hangs forever (because joinTimeout is infinite), how do we
make sure that the client still proceeds even if it could not connect to the
cluster. We need clients to proceed in testing environment even if the grid
is down.
Question 3) both clients and servers are using TcpDiscoverySPI - is that
right? Should we be using TcpCommunicationSPI instead? 

Thanks,
Binti




--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Client-fails-to-connect-joinTimeout-vs-networkTimeout-tp4419.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Automatic persistence ?

[Ravi kumar Puri]

Yea i tried it.. but i want to use in eclipse n run d demo ..
On 21-Apr-2016 20:26, "Alexey Kuznetsov"  wrote:

> Hi, Ravi!
>
> Did you try example for POJO store that shipped with Ignite?
>
> See Readme.txt for this example.
>
> https://github.com/apache/ignite/blob/master/examples/schema-import/README.txt
>
> and docs: https://apacheignite.readme.io/docs/automatic-persistence
>
> Hope this help.
>
> On Thu, Apr 21, 2016 at 8:58 PM, Ravi Puri 
> wrote:
>
>> i generated all the related pojo and xml classess. please let me knw how
>> to
>> test that thing?
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-ignite-users.70518.x6.nabble.com/Automatic-persistence-tp4413.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

RE: Data lost when using write-behind

[Shaomin Zhang]

Val

In the case of the primary failure, it send out a EVT_NODE_FAILED event, is the 
CacheStoreSessionListener.onSessionEnd() method still be called? Which one goes 
first, the event or the onSessionEnd() method?

Thanks again

Shaomin

-Original Message-
From: vkulichenko [mailto:valentin.kuliche...@gmail.com]
Sent: 19 April 2016 21:56
To: user@ignite.apache.org
Subject: RE: Data lost when using write-behind

Shaomin,

The EVT_NODE_FAILED is fired when any node fails and leaves topology, but you 
still don't know which entries are lost because you lost the write-behind queue 
that was on that node.

Currently the only way to fully guarantee consistency between cache and DB is 
using write-through. After [1] is fixed, this will be also possible with 
write-behind in ATOMIC caches. But in TRANSACTIONAL caches write-behind store 
makes all DB updates separately, losing the transactional semantics on DB 
level, so inconsistencies will still be possible.

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

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Data-lost-when-using-write-behind-tp4265p4342.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
_

This email, its contents, and any attachments transmitted with it are intended 
only for the addressee(s) and may be confidential and legally privileged. We do 
not waive any confidentiality by misdelivery. If you have received this email 
in error, please notify the sender immediately and delete it. You should not 
copy it, forward it or otherwise use the contents, attachments or information 
in any way. Any liability for viruses is excluded to the fullest extent 
permitted by law.

Tudor Capital Europe LLP (TCE) is authorised and regulated by The Financial 
Conduct Authority (the FCA). TCE is registered as a limited liability 
partnership in England and Wales No: OC340673 with its registered office at 10 
New Burlington Street, London, W1S 3BE, United Kingdom

Write-behind and foreign keys in DB

[vetko]

Hi All,

I am experiencing an issue while trying to use write-behind on caches
connected to tables which have foreign key constraints between them.
Seemingly the write-behind mechanism is not executing the updates/inserts in
a deterministic order, but rather is trying to push all the collected
changes per each cache consecutively in some unknown order. But as we have
foreign keys in the tables, the order of the operation matters, so parent
objects should be inserted/updated first, and children only after that
(otherwise foreign key violations are thrown from the DB).

It seems that the current implementation is trying to workaround this
problem on a trial-and-error basis
(org.apache.ignite.cache.store.jdbc.CacheAbstractJdbcStore:888), which means
that it will periodically retry to flush the changes again and again for the
caches in case of which a constraint violation occured. So the "child" cache
will periodically retry to flush, until the "parent" cache gets flushed
first. This ultimately will result in getting the data into the DB, but it
also means a lot of unsuccessful tries in case of complex hierarchical
tables, until the correct order is "found". This results in poor performance
and unnecessary shelling of the DB.

Do you have any suggestions how could I circumvent this issue?

(Initially I were trying with write-through, but it resulted in VERY poor
performance, because the CacheAbstractJdbcStore is seemingly opening a new
prepared statement for each insert/update operation.)

(Using Ignite 1.4)



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Write-behind-and-foreign-keys-in-DB-tp4415.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Automatic persistence ?

[Alexey Kuznetsov]

Hi, Ravi!

Did you try example for POJO store that shipped with Ignite?

See Readme.txt for this example.
https://github.com/apache/ignite/blob/master/examples/schema-import/README.txt

and docs: https://apacheignite.readme.io/docs/automatic-persistence

Hope this help.

On Thu, Apr 21, 2016 at 8:58 PM, Ravi Puri 
wrote:

> i generated all the related pojo and xml classess. please let me knw how to
> test that thing?
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/Automatic-persistence-tp4413.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>



-- 
Alexey Kuznetsov
GridGain Systems
www.gridgain.com

Automatic persistence ?

[Ravi Puri]

i generated all the related pojo and xml classess. please let me knw how to
test that thing?



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

Re: Affinity Collocation - Using CacheKeyConfiguration - Multiple fields

[arthi]

Thanks Val!



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/Affinity-Collocation-Using-CacheKeyConfiguration-Multiple-fields-tp3812p4409.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: ignite logging not captured in log file (log4j)

[Kamal C]

Binti,

Have you enabled log4j logger in Ignite Configuration ?

IgniteConfiguration cfg = new IgniteConfiguration();
cfg.setGridLogger(new Log4JLogger());

--Kamal

On Thu, Apr 21, 2016 at 12:38 AM, vkulichenko  wrote:

> Binti,
>
> This doesn't depend on whether it's a client or server. Do you have
> ignite-log4j module enabled?
>
> -Val
>
>
>
> --
> View this message in context:
> http://apache-ignite-users.70518.x6.nabble.com/ignite-logging-not-captured-in-log-file-log4j-tp4334p4388.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>

RE: BinaryObject performance issue

[dmreshet]

I need BinaryObject to process ScanQueries on data with dynamic categories
list. There are 30 different categories at current case.
My Task is to calculate amount of persons in each category, so *map* is not
working for me. 

try (QueryCursor cursor = cache.query(new ScanQuery((k,
p) -> p.hasField(category {
for (Object o : cursor)
counter += 1;
}

I see that it is possible to use another data structure: <(Long)CategoryId,
List<(Long)PersonId>>. In this case my task will be calculated very fast.
But this solution is very spesific for this task and I will not be able to
reuse this data structure. So I want to undestand if I can use  to solve this task, because it looks like more general
solution.

As you said that each update may be cause of metadata update I have do sort
of categories before puch them to cache. It looks that it partialy helps,
now it takes* 44 seconds *to put 5 000 elements in cache.

Is there any way to improve performance?



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

Re: I have problems with balancing cache partitioning among nodes

[vkulichenko]

If you increase the number of companies, you should get much better
distribution. I would try this out and see how it changes the results.

If you have a very specific use case where the number of companies is very
limited, but you still want to use partitioned cache, you can implement the
affinity function. Let me know if you have additional questions about this.

-Val



--
View this message in context: 
http://apache-ignite-users.70518.x6.nabble.com/I-have-problems-with-balancing-cache-partitioning-among-nodes-tp4387p4405.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.