Re: How to configure ignite-jcl and Ignite-slf4j logger

[Nikolay Tikhonov]

Hi Denis,

JCL it's wrapper for logging system (similar sl4j) which can be used
together with log4j. I guess that JavaDoc correct.

On Fri, Sep 1, 2017 at 5:40 PM, Denis Magda  wrote:

> Nikolai,
>
> Looking at JCL documentation I see the usage of Log4j together with JCL:
>
> * 
> *  ...
> *  property name="gridLogger"
> *  bean class="org.apache.ignite.logger.jcl.JclLogger"
> *  constructor-arg type="org.apache.commons.
> logging.Log"
> *  bean class="org.apache.commons.
> logging.impl.Log4JLogger"
> *  constructor-arg type="java.lang.String"
> value="config/ignite-log4j.xml"/
> *  /bean
> *  /constructor-arg
> *  /bean
> *  /property
> *  ...
> * 
>
>
> or
>
> * And the same configuration if you'd like to configure Ignite in your
> code:
> * 
> *  IgniteConfiguration cfg = new IgniteConfiguration();
> *  ...
> *  IgniteLogger log = new JclLogger(new Log4JLogger("config/ignite-
> log4j.xml"));
> *  ...
> *  cfg.setGridLogger(log);
> * 
>
>
> Is it wrong? Could you fix the Java Doc in a proper way?
>
>
> > On Sep 1, 2017, at 3:12 AM, Nikolai Tikhonov 
> wrote:
> >
> > Hello Prachi!
> >
> > You need to set gridLogger property in IgniteConfiguration and remove
> ignite-log4j dependency from POM file.
> >
> > For example for Sl4j logger:
> >
> > igniteConfiguration.setGridLogger(new Slf4jLogger());
> >
> > and for Jc logger:
> >
> > igniteConfiguration.setGridLogger(new JclLogger());
> >
> > On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg > wrote:
> > Engineers,
> >
> > In the attempt to document loggers supported by Ignite, I am having a
> hard
> > time configuring ignite-jcl and ignite-slf4j (I could configure log4j and
> > log4j2). I don't see the log message on my console when I use ignite-jcl
> or
> > ignite-slf4j.
> >
> >  Below is the configuration and sample code I am using:
> >
> > *ignite-log4j.xml*
> >
> > 
> >  > xmlns:log4j='http://jakarta.apache.org/log4j/ <
> http://jakarta.apache.org/log4j/>'>
> >
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > 
> > 
> >
> > 
> >
> >
> > *Maven dependency -*
> >
> > 
> > org.apache.ignite
> > ignite-log4j
> > 2.1.0
> > 
> >
> > 
> > org.apache.ignite
> > ignite-jcl
> > 2.1.0
> > 
> >
> >
> > *Configuration for JCL ( as specified in javadoc)- *
> >
> > 
> > 
> > 
> > 
> >  > value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> > 
> > 
> > 
> > 
> >
> >
> > *Sample code I am using- *
> >
> > public class LoggerExample {
> > public static void main(String[] args) throws IgniteException {
> > try (Ignite ignite =
> > Ignition.start("/Users/prachig/myexamples/config/cluster-config.xml"))
> > {
> > ignite.log().info("Info Message 1 Logged !!!");
> > ignite.log().info("Info Message 2 Logged !!!");
> >
> > System.out.println(ignite.log().getClass());
> > }
> > }
> > }
> >
> > *Output*
> >
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java
> > -Didea.launcher.port=7535
> > "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA
> > CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> > "/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/
> 

[jira] [Created] (IGNITE-5848) Ignite should support Hibernate 5.2.X

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5848:


 Summary: Ignite should support Hibernate 5.2.X
 Key: IGNITE-5848
 URL: https://issues.apache.org/jira/browse/IGNITE-5848
 Project: Ignite
  Issue Type: Sub-task
  Components: cache
Affects Versions: 2.0, 2.1
Reporter: Nikolay Tikhonov


Currently Ignite supports Hibernate 5.1.X
With Hibernate version of 5.2.X got the following exception:

{code:java}
Handler dispatch failed; nested exception is java.lang.AbstractMethodError: 
org.apache.ignite.cache.hibernate.HibernateEntityRegion$AccessStrategy.putFromLoad(Lorg/hibernate/engine/spi/SharedSessionContractImplementor;Ljava/lang/Object;Ljava/lang/Object;JLjava/lang/Object;Z)Z
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5489) Possible connection leaks when loadPreviousValue set to true

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5489:


 Summary: Possible connection leaks when loadPreviousValue set to 
true
 Key: IGNITE-5489
 URL: https://issues.apache.org/jira/browse/IGNITE-5489
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Nikolay Tikhonov


When {{CacheConfiguration#setLoadPreviousValue}} set to true on owning node 
does not call {{CacheStore#sessionEnd}} method. It can to lead to leak of 
connections to DB.
See attached test.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5290) Events might be missed during concurrent CQ registration and cache operations

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5290:


 Summary: Events might be missed during concurrent CQ registration 
and cache operations
 Key: IGNITE-5290
 URL: https://issues.apache.org/jira/browse/IGNITE-5290
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Nikolay Tikhonov


Events might be missed during concurrent CQ registration and cache operations. 
See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-5214) ConcurrentModificationException with enable DEBUG log level

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-5214:


 Summary: ConcurrentModificationException with enable DEBUG log 
level
 Key: IGNITE-5214
 URL: https://issues.apache.org/jira/browse/IGNITE-5214
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
Reporter: Nikolay Tikhonov
Assignee: Nikolay Tikhonov


ConcurrentModificationException with 
org.apache.ignite.continuous.query=DEBUG
{{noformat}}
Unexpected exception during cache update 
java.util.ConcurrentModificationException: null
at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1211)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1247)
at java.util.TreeMap$EntryIterator.next(TreeMap.java:1242)
at java.util.AbstractMap.toString(AbstractMap.java:554)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$PartitionRecovery.collectEntries(CacheContinuousQueryHandler.java:1132)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:739)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.onEntryUpdate(CacheContinuousQueryHandler.java:792)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.access$800(CacheContinuousQueryHandler.java:91)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler$1.onEntryUpdated(CacheContinuousQueryHandler.java:419)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onEntryUpdated(CacheContinuousQueryManager.java:347)
at 
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2669)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2390)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1792)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1632)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.mapSingle(GridNearAtomicAbstractUpdateFuture.java:263)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:494)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:436)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:208)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1152)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$23.apply(GridDhtAtomicCache.java:1150)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:847)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1150)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:619)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2574)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsentAsync(GridDhtAtomicCache.java:664)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putIfAbsent(GridDhtAtomicCache.java:657)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.putIfAbsent(IgniteCacheProxy.java:1451)
at 
com.workday.fabric.ignite.management.IgniteManagementService.doExecute(IgniteManagementService.java:174)
at 
com.workday.fabric.ignite.service.AbstractIgniteService.execute(AbstractIgniteService.java:94)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$3.run(GridServiceProcessor.java:1157)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor

[jira] [Created] (IGNITE-4939) Receive event before cache initialized

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4939:


 Summary: Receive event before cache initialized
 Key: IGNITE-4939
 URL: https://issues.apache.org/jira/browse/IGNITE-4939
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.9
Reporter: Nikolay Tikhonov


Receive event before cache initialized that leads to the following:

Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException: 
Cache is not configured: ignite-sys-cache
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
at 
org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
at 
org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4901) Decrease logging level for DataStremer retry

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4901:


 Summary: Decrease logging level for DataStremer retry 
 Key: IGNITE-4901
 URL: https://issues.apache.org/jira/browse/IGNITE-4901
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.9
Reporter: Nikolay Tikhonov


When topology are changed DataStreame log the following error message which 
confused users. Need to decrease logging level for this case.
{noformat}
ERROR  Failed to execute compound future reducer: GridCompoundFuture [...] 
class org.apache.ignite.IgniteCheckedException: DataStreamer request failed 
[node=9d405934-eb78-4452-a3a8-fc44c3c61e76] 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$Buffer.onResponse(DataStreamerImpl.java:1777)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamerImpl$3.onMessage(DataStreamerImpl.java:335)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1080)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:708)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:101)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:671)
 
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745) 
Caused by: class org.apache.ignite.IgniteCheckedException: DataStreamer will 
retry data transfer at stable topology [...] 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.localUpdate(DataStreamProcessor.java:337)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:297)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:56)
 
at 
org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:86)
 
... 7 more 
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (IGNITE-4590) Lock/unlock operations are hanging when topology changed

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4590:


 Summary: Lock/unlock operations are hanging when topology changed
 Key: IGNITE-4590
 URL: https://issues.apache.org/jira/browse/IGNITE-4590
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8
Reporter: Nikolay Tikhonov


Lock/unlock operations are hanging when topology changed. See attached test.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4589) Possible starvation during rebalancing for marshaller cache

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4589:


 Summary: Possible starvation during rebalancing for marshaller 
cache
 Key: IGNITE-4589
 URL: https://issues.apache.org/jira/browse/IGNITE-4589
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.8
Reporter: Nikolay Tikhonov


When Ignite processing supply messages (rebalancing) in marshaller threads and 
calling marshaller cache from them, but responses also should be proccessed in 
marshaller threadpool. It leads to starvation.

{noformat}
marshaller-cache-#26%test-node%" #117 prio=5 os_prio=0 tid=0x7f89e40c6000 
nid=0x1dc waiting on condition [0x7f8a3fffc000]
   java.lang.Thread.State: WAITING (parking)
 at sun.misc.Unsafe.park(Native Method)
 - parking to wait for <0xc206d318> (a 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedGetFuture)
 at java.util.concurrent.locks.LockSupport.park(Unknown Source)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown
 Source)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(Unknown
 Source)
 at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(Unknown
 Source)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:159)
 at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
 at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.getTopologySafe(GridCacheAdapter.java:1340)
 at 
org.apache.ignite.internal.MarshallerContextImpl.className(MarshallerContextImpl.java:195)
 at 
org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:174)
 at 
org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:266)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:318)
 at java.io.ObjectInputStream.readObject(Unknown Source)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
 at 
org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
 at java.io.ObjectInputStream.readObject(Unknown Source)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readFields(OptimizedObjectInputStream.java:491)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readSerializable(OptimizedObjectInputStream.java:579)
 at 
org.apache.ignite.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:927)
 at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:324)
 at java.io.ObjectInputStream.readObject(Unknown Source)
 at 
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:218)
 at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
 at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1614)
 at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1680)
 at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
 at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:298)
 at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
 at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
 at org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9722)
 at org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9751)
 at 
org.apache.ignite.internal.processors.cacheobject.IgniteCacheObjectProcessorImpl.unmarshal(IgniteCacheObjectProcessorImpl.java:111)
 at 
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.unmarshal(CacheObjectBinaryProcessorImpl.java:811)
 at 
org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:109)
 at 
org.apache.ignite.internal.processors.cache.GridCacheEntryInfo.unmarshal(GridCacheEntryInfo.java:416)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplyMessageV2.finishUnmarshal(GridDhtPartitionSupplyMessageV2.java:245)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManage

[jira] [Created] (IGNITE-4344) Client node allocates off heap memories for caches

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4344:


 Summary: Client node allocates off heap memories for caches
 Key: IGNITE-4344
 URL: https://issues.apache.org/jira/browse/IGNITE-4344
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7, 1.6
Reporter: Nikolay Tikhonov
 Fix For: 1.9


Client node should not allocate memories. Test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4052) Add ability to set up users for MESOS

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4052:


 Summary: Add ability to set up users for MESOS
 Key: IGNITE-4052
 URL: https://issues.apache.org/jira/browse/IGNITE-4052
 Project: Ignite
  Issue Type: Improvement
  Components: general
Affects Versions: 1.7
Reporter: Nikolay Tikhonov
Priority: Trivial


In current implementation Ignite Mesos Framework connects to MESOS cluster via 
current user. Need to add ability to configure this parameters via system env 
properties. See org/apache/ignite/mesos/IgniteFramework.java:53





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4047) CQ skips events if autoUnsubscribe flag was set to false

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4047:


 Summary: CQ skips events if autoUnsubscribe flag was set to false
 Key: IGNITE-4047
 URL: https://issues.apache.org/jira/browse/IGNITE-4047
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Nikolay Tikhonov


CQ skips events after topology change, if {{autoUnsubscribe}} flag was set to 
{{false}}. Test attached.

See 
http://apache-ignite-users.70518.x6.nabble.com/CacheContinuousQuery-did-not-work-after-the-second-server-node-joinned-into-the-topology-td8011.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-4014) Transaction hangs if entry processor failed during serialization

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-4014:


 Summary: Transaction hangs if entry processor failed during 
serialization
 Key: IGNITE-4014
 URL: https://issues.apache.org/jira/browse/IGNITE-4014
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Nikolay Tikhonov
Assignee: Nikolay Tikhonov


If entry processor implements Externalizable interface and inside of methods 
writeTo() or readTo() throws exceptions then transaction hangs.

Hanged thread dump:
{code}
Thread 
[name="test-runner-#217%continuous.CacheEntryProcessorExternalizableFailedTest%",
 id=275, state=WAITING, blockCnt=0, waitCnt=6]
Lock 
[object=o.a.i.i.processors.cache.distributed.near.GridNearTxFinishFuture@2575e80b,
 ownerName=null, ownerId=-1]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:964)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1282)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
at 
o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocalAdapter.rollback(GridDhtTxLocalAdapter.java:859)
at 
o.a.i.i.processors.cache.transactions.IgniteTxAdapter.close(IgniteTxAdapter.java:903)
at 
o.a.i.i.processors.cache.distributed.near.GridNearTxLocal.close(GridNearTxLocal.java:1306)
at 
o.a.i.i.processors.cache.GridCacheSharedContext.endTx(GridCacheSharedContext.java:720)
at 
o.a.i.i.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:276)
at 
o.a.i.i.processors.cache.query.continuous.CacheEntryProcessorExternalizableFailedTest.doTestInvokeTest(CacheEntryProcessorExternalizableFailedTest.java:327)
at 
o.a.i.i.processors.cache.query.continuous.CacheEntryProcessorExternalizableFailedTest.testOptimisticOnePhaseCommitFullSync(CacheEntryProcessorExternalizableFailedTest.java:233)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
o.a.i.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1760)
at 
o.a.i.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
o.a.i.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1698)
at java.lang.Thread.run(Thread.java:745)
{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3878) Add isPrimary() and isBackup() methods on CacheQUeryEntryEvent

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3878:


 Summary: Add isPrimary() and isBackup() methods on 
CacheQUeryEntryEvent
 Key: IGNITE-3878
 URL: https://issues.apache.org/jira/browse/IGNITE-3878
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.7
Reporter: Nikolay Tikhonov
Priority: Minor


In some cases useful know where (on primary or backup nodes) was invoked  a 
continuous query filter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3867) ScanQuery ignore pageSize propertry

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3867:


 Summary: ScanQuery ignore pageSize propertry
 Key: IGNITE-3867
 URL: https://issues.apache.org/jira/browse/IGNITE-3867
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.7
Reporter: Nikolay Tikhonov


See 
{{org.apache.ignite.internal.processors.cache.IgniteCacheProxy#query(ScanQuery, 
IgniteClosure<T,R>, ClusterGroup)}} method. In this place we loose page size 
which set by user and use default value
{{qry = ctx.queries().createScanQuery(p, transformer, scanQry.getPartition(), 
isKeepBinary)}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3850) Need to add support WIN for YARN integration

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3850:


 Summary: Need to add support WIN for YARN integration
 Key: IGNITE-3850
 URL: https://issues.apache.org/jira/browse/IGNITE-3850
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.7
 Environment: Windows
Reporter: Nikolay Tikhonov


Current YARN integration does not support WIN OS. Need to implement it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3433) Uninformative error message for affinity function

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3433:


 Summary: Uninformative error message for affinity function
 Key: IGNITE-3433
 URL: https://issues.apache.org/jira/browse/IGNITE-3433
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 1.6
Reporter: Nikolay Tikhonov
Priority: Minor
 Fix For: 1.7


Ignite public API allows to get an affinity function for not existing cache. 
Any method calls lead to NPE and user getting the following error message:
{noformat}
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor$AffinityInfo.access$1800(GridAffinityProcessor.java:538)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor$CacheAffinityProxy.allPartitions(GridAffinityProcessor.java:766)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityApiSelfTest.testAllPartitionsException(GridCacheAffinityApiSelfTest.java:241)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1724)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1662)
at java.lang.Thread.run(Thread.java:745)
{noformat}

Need to change the message and make it more clear..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Docker image for Ignite 1.6.0 release pull request

[Nikolay Tikhonov]

Hi Aliaksandr!

I've reviewed and merge your changes to master.

Thank you for your contribution!

On Tue, Jun 7, 2016 at 5:31 PM, Denis Magda  wrote:

> Nikolay,
>
> As a maintainer of this component please do the review.
>
> —
> Denis
>
> > On Jun 5, 2016, at 3:18 PM, zshamrock 
> wrote:
> >
> > Hi, guys, what about the following
> https://github.com/apache/ignite/pull/757?
> >
> > Is already someone from DataGrid/Ignite working on official docker image
> for
> > 1.6.0 release, or you can take a look into the pull request above I've
> > submitted.
> >
> >
> >
> >
> > --
> > View this message in context:
> http://apache-ignite-developers.2346864.n4.nabble.com/Docker-image-for-Ignite-1-6-0-release-pull-request-tp9276.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
>
>

[jira] [Created] (IGNITE-3272) Memory consumption in ContinuousQueryHandler

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3272:


 Summary: Memory consumption in ContinuousQueryHandler
 Key: IGNITE-3272
 URL: https://issues.apache.org/jira/browse/IGNITE-3272
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
Reporter: Nikolay Tikhonov


On backup nodes events put in queue with value and key. For filtered events 
need to store only update counter and partition. In attached test which should 
pass with -Xmx2g -Xms2g



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3268) Integration with YARN in net without internet

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3268:


 Summary: Integration with YARN in net without internet
 Key: IGNITE-3268
 URL: https://issues.apache.org/jira/browse/IGNITE-3268
 Project: Ignite
  Issue Type: Bug
  Components: hadoop
Affects Versions: 1.6
Reporter: Nikolay Tikhonov


When deploying Ignite on YARN in a network without outbound internet access, 
got unclear exception on startup. Need to improve error message which will 
propose to use {{IGNITE_PATH}} property.

http://apache-ignite-users.70518.x6.nabble.com/Using-Ignite-within-within-networks-without-internet-egress-td5349.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3214) YARN allocates containers at random

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3214:


 Summary: YARN allocates containers at random
 Key: IGNITE-3214
 URL: https://issues.apache.org/jira/browse/IGNITE-3214
 Project: Ignite
  Issue Type: Improvement
Reporter: Nikolay Tikhonov


YARN allocates containers at random it's pretty onerous to figure out which 
hostnames have Ignite nodes running on them and specifying those in the URL. 
Also need to add the property which allows to limit number of nodes per host.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3188) Binary marshaller doesn't unmarshal a void type

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3188:


 Summary: Binary marshaller doesn't unmarshal a void type
 Key: IGNITE-3188
 URL: https://issues.apache.org/jira/browse/IGNITE-3188
 Project: Ignite
  Issue Type: Bug
  Components: cache, important
Affects Versions: 1.6
Reporter: Nikolay Tikhonov


The following code snippet failed with binary marshaller:
{{
BinaryMarshaller marsh = 
(BinaryMarshaller)ignite.configuration().getMarshaller();
Map<Object, Object> map = new HashMap<>();
map.put(Void.class, Void.TYPE);
byte[] marshal = marsh.marshal(map);
marsh.unmarshal(marshal, null);
}}

Got expcetion:

{{
class org.apache.ignite.binary.BinaryObjectException: Failed to unmarshal 
object with optimized marshaller
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1555)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1631)
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1568)
at 
org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:1915)
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadMap(BinaryUtils.java:1899)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1596)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:298)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal(BinaryMarshaller.java:112)
at 
org.apache.ignite.internal.processors.cache.BinarySerializationQuerySelfTest.testPlain(BinarySerializationQuerySelfTest.java:181)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:1723)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:118)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$4.run(GridAbstractTest.java:1661)
at java.lang.Thread.run(Thread.java:745)
Caused by: 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@36d98810
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal(OptimizedMarshaller.java:225)
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1552)
... 17 more
Caused by: java.lang.ClassNotFoundException: void
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:274)
at 
org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8213)
at 
org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:185)
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:270)
at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readClass(OptimizedObjectInputStream.java:353)
at 
org.apache.ignite.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:305)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:364)
at 
org.apache.ignite.marshaller.optimized.OptimizedMarshaller.unmarshal(OptimizedMarshaller.java:219)
... 18 more
}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3183) ScanQuery and localEntries are ignored keepBinary flag in OFFHEAP_TIERED mode

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3183:


 Summary: ScanQuery and localEntries are ignored keepBinary flag in 
OFFHEAP_TIERED mode
 Key: IGNITE-3183
 URL: https://issues.apache.org/jira/browse/IGNITE-3183
 Project: Ignite
  Issue Type: Bug
  Components: cache, important
Affects Versions: 1.6
Reporter: Nikolay Tikhonov


{{ScanQuery}} and {{localEntries}} method returns iterator which contains 
deserialized entries but they have been called with withKeepBinary flag. 
Reproducible test attached.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [VOTE] Apache Ignite 1.6.0 RC1

[Nikolay Tikhonov]

+1 (binding)

On Fri, May 20, 2016 at 10:38 AM, Anton Vinogradov  wrote:

> +1 (binding)
>
> On Fri, May 20, 2016 at 12:16 AM, Vladimir Ozerov 
> wrote:
>
> > Looks good to me.
> >
> > +1 (binding)
> >
> > On Thu, May 19, 2016 at 10:11 PM, Denis Magda 
> wrote:
> >
> > > +1
> > >
> > > > On Wed, May 18, 2016 at 5:24 PM, Anton Vinogradov 
> > wrote:
> > > >
> > > >> Dear Sirs!
> > > >>
> > > >> We have uploaded release candidate to
> > > >> https://dist.apache.org/repos/dist/dev/ignite/1.6.0-rc1/
> > > >>
> > > >> This is very important release containing huge amount of fixes and
> > > >> improvements.
> > > >> Over 600 issues were closed since previous release.
> > > >> 8 new modules were added to the project.
> > > >>
> > > >> Tag name is
> > > >> 1.6.0-rc1
> > > >>
> > > >> 1.6.0 changes:
> > > >> Ignite .NET:
> > > >> * Added ability to use Java-based remote filters in continuous
> > queries.
> > > >> * Added AtomicSequence and AtomicReference data structures
> > > >> * Added automatic Java detection: no need for JAVA_HOME
> > > >> * Added java-based continuous query filters
> > > >> * Added LINQ Provider for cache SQL queries
> > > >> * Added native configuration mechanism (C#, app.config, web.config -
> > > >> instead of Spring XML)
> > > >> * Added NuGet distribution
> > > >> * Binaries are now AnyCPU (instead of separate x64/x86)
> > > >> * Java-based services can be called the same way as .NET service are
> > > called
> > > >>
> > > >> Ignite C++:
> > > >> * Added Transactions API for C++ client.
> > > >> * Added Date and Timestamp types implementation for C++ client.
> > > >> * Simplified Autotools build process for C++ client.
> > > >>
> > > >> Ignite:
> > > >> * Added ability to get partition 'updateCntr' with continuous query
> > > public
> > > >> API.
> > > >> * Added asynchronous execution of ContinuousQuery's remote filter
> and
> > > local
> > > >> listener.
> > > >> * Added backup partitions storing to local store default behavior.
> > > >> * Added cache deadlock detection.
> > > >> * Added Cache Store implementation backed by Cassandra DB.
> > > >> * Added method to get versioned cache entry.
> > > >> * Added ODBC driver for Ignite.
> > > >> * Added support for join timeout while registering local addresses
> > with
> > > IP
> > > >> finder in TcpDiscoverySpi.
> > > >> * Added support for JTA transactions via synchronization callback.
> > > >> * Added Web Console for Ignite.
> > > >> * Fixed a bug causing object deserialization when local store is
> > > configured
> > > >> for cache.
> > > >> * Fixed a problem with incorrect classloader picked in OSGI
> > environment.
> > > >> * Fixed a race condition when evicted offheap data was not delivered
> > to
> > > >> query engine leading to query timeout.
> > > >> * Fixed an issue in ContinuousQueries that caused missing of
> > > notifications.
> > > >> * Fixed background cache partition map exchange not to flood
> network.
> > > >> * Fixed BinaryContext to honor custom loader set through
> > > >> IgniteConfiguration.
> > > >> * Fixed BinaryObjectOffHeapImpl leak to public code.
> > > >> * Fixed cluster stability with 500+ clients.
> > > >> * Fixed continuous queries to send filter factory instead of filter.
> > > >> * Fixed continuous query deployment in case originating node has
> left.
> > > >> * Fixed issues with continuous query.
> > > >> * Fixed deadlock in services deployment when Spring is used.
> > > >> * Fixed discovery and node start procedure issues that may cause
> > > slowdowns
> > > >> during larger topologies start (>100 nodes).
> > > >> * Fixed eviction policy notification if swap or off heap is enabled
> > and
> > > an
> > > >> entry is not loaded during preloading.
> > > >> * Fixed excessive thread stack usage in case of high contention on
> > cache
> > > >> entries.
> > > >> * Fixed execution of Splunk MapReduce jobs on top of Ignite MR.
> > > >> * Fixed GridClosureProcessor internal closures to be deserialized by
> > > >> BinaryMarshaller.
> > > >> * Fixed issue with AWS dependencies.
> > > >> * Fixed java proxies deserialization with optimized marshaller.
> > > >> * Fixed local store behavior at cross cache transactions.
> > > >> * Fixed marshalling of Java collection and maps for
> BinaryMarshaller.
> > > >> * Fixed memory leak in IgniteH2Indexing.
> > > >> * Fixed NPE during rebalancing.
> > > >> * Fixed NPE in GridMergeIndex.
> > > >> * Fixed OOME when OFFHEAP_TIERED mode is used.
> > > >> * Fixed potential thread starvation during cache rebalancing.
> > > >> * Fixed race condition on load cache on changing topology.
> > > >> * Fixed race in marshalling logic that could arise when several
> nodes
> > > are
> > > >> running on the same host.
> > > >> * Fixed redeployment issues happened with ScanQueries filters.
> > > >> * Fixed service proxy not to make remote call for methods declared
> in
> > > >> java.lang.Object.
> > > >> * Fixed 

[jira] [Created] (IGNITE-3168) Ignite mesos framework should provide ability to configure timeouts.

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3168:


 Summary: Ignite mesos framework should provide ability to 
configure timeouts.
 Key: IGNITE-3168
 URL: https://issues.apache.org/jira/browse/IGNITE-3168
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.5.0.final
Reporter: Nikolay Tikhonov
 Fix For: 1.7


Need to add in ClusterProperties class properties which allow to configure 
jetty timeouts.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3083) Shmem loader failed with OverlappingFileLockException

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-3083:


 Summary: Shmem loader failed with OverlappingFileLockException
 Key: IGNITE-3083
 URL: https://issues.apache.org/jira/browse/IGNITE-3083
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5.0.final
Reporter: Nikolay Tikhonov
Priority: Minor


IpcSharedMemoryNativeLoader can try to get lock on a file twice in the same JVM 
in case when nodes are starting in parallel in one JVM and they loaded by 
different classloaders. 
{{java.nio.channels.OverlappingFileLockException
at sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
at sun.nio.ch.SharedFileLockTable.add(FileLockTable.java:152)
at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:1012)
at java.nio.channels.FileChannel.lock(FileChannel.java:1052)
at 
org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryNativeLoader.doLoad(IpcSharedMemoryNativeLoader.java:141)
at 
org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryNativeLoader.load(IpcSharedMemoryNativeLoader.java:111)
at 
org.apache.ignite.internal.util.ipc.shmem.IpcSharedMemoryServerEndpoint.start(IpcSharedMemoryServerEndpoint.java:167)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.resetShmemServer(TcpCommunicationSpi.java:1737)
at 
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getNodeAttributes(TcpCommunicationSpi.java:1422)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:219)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.start(GridIoManager.java:236)
at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1505)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:861)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1688)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1547)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1003)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:534)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:515)
at org.apache.ignite.Ignition.start(Ignition.java:322)}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: API for asynchronous execution.

[Nikolay Tikhonov]

Dima,
We have also JCache API which allow register/deregister continuous query
javax.cache.Cache#registerCacheEntryListener(CacheEntryListenerConfiguration)
and we can't change it.
I think that annotation looks better for consistency both API.

On Mon, Apr 18, 2016 at 7:26 AM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> Instead of the Async annotation, why not just have a setter
> “setAsyncFilter(true)”?
>
> D.
>
> On Fri, Apr 15, 2016 at 4:33 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
> wrote:
>
> > Yakov is right. Benchmarks show performance drop 3-8% when using
> > asynchronous callbacks.
> >
> > On Fri, Apr 15, 2016 at 11:34 AM, Yakov Zhdanov <yzhda...@apache.org>
> > wrote:
> >
> > > I am pretty sure that making all filter notifications asynchronous will
> > > terribly affect performance. I would leave it only for cases when some
> > > complex processing needs to be done involving, for example, cache
> > > operations. If filter is simple then I would leave it sync (by
> default).
> > >
> > > --Yakov
> > >
> > > 2016-04-15 0:52 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> > >
> > > > Nick,
> > > >
> > > > Can you explain why we would ever want to have a synchronous
> callback?
> > > > Aren’t all filter notifications supposed to be asynchronous,
> especially
> > > if
> > > > there is no performance degradation?
> > > >
> > > > D.
> > > >
> > > > On Thu, Apr 14, 2016 at 11:17 AM, Nikolay Tikhonov <
> > > ntikho...@gridgain.com
> > > > >
> > > > wrote:
> > > >
> > > > > The following code snippet show how make asynchronous filter in
> > > > continuous
> > > > > query. Difference in configuration between sync and async  filters
> > just
> > > > in
> > > > > annotation on class.
> > > > >
> > > > > IgniteCache cache = ...;
> > > > >
> > > > > ContinuousQuery qry = new ContinuousQuery();
> > > > >
> > > > > qry.setRemoteFilterFactory(FactoryBuiler.factoryOf(Filter.class));
> > > > >
> > > > > cache.query(qry);
> > > > >
> > > > > *@IgniteAsyncCallback*
> > > > > class Filter implements CacheEntryEventFilter<Key, Value> {
> > > > > @IgniteInstanceResource
> > > > > private Ignite ignite;
> > > > >
> > > > > @Override public boolean evaluate(CacheEntryEvent Key,
> > ?
> > > > > extends Value> evt) {
> > > > > IgniteCache<Key, Value> cache = ignite.cache(...);
> > > > >
> > > > > // This filter has @IgniteAsyncCallback annotation then in
> > this
> > > > > place cache
> > > > > // operations are allowed and safe otherwise can get
> > deadlock.
> > > > > Value val = cache.get(...);
> > > > > ...
> > > > > }
> > > > > }
> > > > >
> > > > > Size for thread pool which using for executing callbacks can be
> > > > configured
> > > > > by IgniteConfiguration.setAsyncCallbackPoolSize(...) method.
> > > > >
> > > > > On Thu, Apr 14, 2016 at 8:10 PM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Do we have a coding example for this functionality somewhere? It
> > > would
> > > > be
> > > > > > nice to review the changes from usability standpoint.
> > > > > >
> > > > > > On Thu, Apr 14, 2016 at 3:58 AM, Nikolay Tikhonov <
> > > > > ntikho...@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > We are close to completing IGNITE-2004 ticket.
> > > > > > > As part this ticket was made the following changes on public
> API
> > > > > > > - if callback has @IgniteAsyncCallback annotation then callback
> > > > should
> > > > > be
> > > > > > > run asynchronously
> > > > > > > - these callbacks are executed in special pool (callback thread
> > > pool)
> > > > > > which
> > > > > > > is configured by
> IgniteConfiguration.asyncCallbac

Re: Small how to for Mesos + Ignite + Java

[Nikolay Tikhonov]

Dima,
Sure, when I finish updating doc I'll post the link here.

On Fri, Apr 15, 2016 at 8:15 PM, Dmitriy Setrakyan <dsetrak...@gridgain.com>
wrote:

> Thanks Nick! Can you please send the link to the updated documentation
> here? Also, please don’t forget to update both, 1.5 and 1.6 versions.
>
> D.
>
> On Fri, Apr 15, 2016 at 6:36 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
> wrote:
>
> > Hi,
> > Thank you for efforts and feedback!
> >
> > Vova,
> > I'll change our documentation that points will be more clear.
> >
> > On Fri, Apr 15, 2016 at 4:25 PM, Vladimir Ozerov <voze...@gridgain.com>
> > wrote:
> >
> > > Hi,
> > > Thank you for such deep and thorough analysis. I think we definitely
> > > reflect your findings in our documentation.
> > >
> > > Nick,
> > > Provided that you worked on Mesos integration, could you please see,
> how
> > we
> > > can integrate this into our docs?
> > >
> > > Vladimir.
> > >
> > > On Fri, Apr 15, 2016 at 1:42 AM, lpalbou <laurent.al...@genognose.org>
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I have been testing recently Mesos and Apache Ignite. Some problems
> > were
> > > > not
> > > > documented and I sometimes had to look at some java sources.
> > > >
> > > > So this is a very small guide to help you launch Ignite nodes from
> > Mesos
> > > > and
> > > > access these nodes with Java.
> > > >
> > > > A) First, to install Mesos, I would advise to consult this tutorial
> > which
> > > > is
> > > > easy to follow:
> > > >
> > > >
> > >
> >
> https://www.digitalocean.com/community/tutorials/how-to-configure-a-production-ready-mesosphere-cluster-on-ubuntu-14-04
> > > >
> > > > B) Then, to create a Mesos framework/application to launch your
> Ignite
> > > > nodes, you can refer to this tutorial:
> > > > http://apacheignite.gridgain.org/docs/mesos-deployment
> > > >
> > > > For those having a "Got unexpected response code 404" exception in
> > > /stderr/
> > > > of a Mesos node sandbox after launching the application through
> > > > curl/marathon (step 3 of tutorial B) ), it basically says it can't
> > > download
> > > > the ignite-mesos.jar. I had this problem and edited the marathon.json
> > (or
> > > > whatever the name you choose) to change the IGNITE_VERSION parameter
> > > > previously set to 1.0.5. I first changed it to "latest" and
> everything
> > > was
> > > > ok until I triedto access these nodes with Java (see after). For now,
> > set
> > > > IGNITE_VERSION to "1.5.9".
> > > >
> > > > By now, your Ignite nodes should now launch correctly on Mesos and
> you
> > > > should see something similar to tutorial B) steps 5-7.
> > > >
> > > > Now let's try to access those Ignite nodes launched by Mesos with a
> > small
> > > > Java application. At first, it did not work at all. If you try
> > something
> > > > like bin/ignite.sh, it will create a new cluster independant of the
> one
> > > > created by Mesos. So you have to setup the proper configuration. And
> > > there,
> > > > I did not find any tutorial or information on Google. So here is
> what I
> > > > did:
> > > >
> > > > 1) ssh to a Mesos node running ignite
> > > > 2) ps -aux | grep ignite (to see the parameters used for launching
> > these
> > > > ignite nodes)
> > > > 3) the spring configuration file by default was
> > > "ignite-default-config.xml"
> > > > 4) reproduce this configuration inside the java application with the
> > > > IgniteConfiguration class (see below)
> > > > 5) it was not working. Looking at the Java exception, I discovered my
> > > java
> > > > app was using a different version of Ignite than Mesos (?!). Indeed,
> > > > although the latest stable version of Ignite is 1.5.0 on the download
> > > page
> > > > (https://ignite.apache.org/download.cgi#binaries), when using
> "latest"
> > > for
> > > > the field IGNITE_VERSION in the marathon.json file, it actually
> > > downloaded
> > > > and launched the version 1.5.9 (FWY, set IGNITE_VERSION t

Re: Small how to for Mesos + Ignite + Java

[Nikolay Tikhonov]

Hi,
Thank you for efforts and feedback!

Vova,
I'll change our documentation that points will be more clear.

On Fri, Apr 15, 2016 at 4:25 PM, Vladimir Ozerov 
wrote:

> Hi,
> Thank you for such deep and thorough analysis. I think we definitely
> reflect your findings in our documentation.
>
> Nick,
> Provided that you worked on Mesos integration, could you please see, how we
> can integrate this into our docs?
>
> Vladimir.
>
> On Fri, Apr 15, 2016 at 1:42 AM, lpalbou 
> wrote:
>
> > Hi everyone,
> >
> > I have been testing recently Mesos and Apache Ignite. Some problems were
> > not
> > documented and I sometimes had to look at some java sources.
> >
> > So this is a very small guide to help you launch Ignite nodes from Mesos
> > and
> > access these nodes with Java.
> >
> > A) First, to install Mesos, I would advise to consult this tutorial which
> > is
> > easy to follow:
> >
> >
> https://www.digitalocean.com/community/tutorials/how-to-configure-a-production-ready-mesosphere-cluster-on-ubuntu-14-04
> >
> > B) Then, to create a Mesos framework/application to launch your Ignite
> > nodes, you can refer to this tutorial:
> > http://apacheignite.gridgain.org/docs/mesos-deployment
> >
> > For those having a "Got unexpected response code 404" exception in
> /stderr/
> > of a Mesos node sandbox after launching the application through
> > curl/marathon (step 3 of tutorial B) ), it basically says it can't
> download
> > the ignite-mesos.jar. I had this problem and edited the marathon.json (or
> > whatever the name you choose) to change the IGNITE_VERSION parameter
> > previously set to 1.0.5. I first changed it to "latest" and everything
> was
> > ok until I triedto access these nodes with Java (see after). For now, set
> > IGNITE_VERSION to "1.5.9".
> >
> > By now, your Ignite nodes should now launch correctly on Mesos and you
> > should see something similar to tutorial B) steps 5-7.
> >
> > Now let's try to access those Ignite nodes launched by Mesos with a small
> > Java application. At first, it did not work at all. If you try something
> > like bin/ignite.sh, it will create a new cluster independant of the one
> > created by Mesos. So you have to setup the proper configuration. And
> there,
> > I did not find any tutorial or information on Google. So here is what I
> > did:
> >
> > 1) ssh to a Mesos node running ignite
> > 2) ps -aux | grep ignite (to see the parameters used for launching these
> > ignite nodes)
> > 3) the spring configuration file by default was
> "ignite-default-config.xml"
> > 4) reproduce this configuration inside the java application with the
> > IgniteConfiguration class (see below)
> > 5) it was not working. Looking at the Java exception, I discovered my
> java
> > app was using a different version of Ignite than Mesos (?!). Indeed,
> > although the latest stable version of Ignite is 1.5.0 on the download
> page
> > (https://ignite.apache.org/download.cgi#binaries), when using "latest"
> for
> > the field IGNITE_VERSION in the marathon.json file, it actually
> downloaded
> > and launched the version 1.5.9 (FWY, set IGNITE_VERSION to "1.5.9" to
> avoid
> > such mistake). I retrieve those jar from the Mesos slave nodes (look in
> > /tmp/mesos/slaves/.../latest/) and use them as libraries in my Java app
> > 5) but it was still not working !? "Failed to connect to any address from
> > IP
> > finder (will retry to join topology every 2 secs)". To make a long story
> > short, you have to provide to your IpFinder some IP addresses of your
> Mesos
> > slave nodes... and it worked !
> >
> >
> > *Here is a very small Java code to help you connect to your Mesos Ignite
> > nodes:*
> >
> > Collection addr = new ArrayList();
> > addr.add("X.X.X.X"); // replace this by IP addresses of ignite nodes
> > addr.add("X.X.X.X"); // replace this by IP addresses of ignite nodes
> >
> > TcpDiscoveryVmIpFinder tcpvm = new TcpDiscoveryVmIpFinder();
> > tcpvm.setAddresses(addr);
> >
> > TcpDiscoverySpi dspi = new TcpDiscoverySpi();
> > dspi.setIpFinder(tcpvm);
> > dspi.setJoinTimeout(6);
> >
> > IgniteConfiguration cfg = new IgniteConfiguration();
> > cfg.setDiscoverySpi(dspi);
> > cfg.setClientMode(true);
> >
> > Ignite ignite = Ignition.start(cfg);
> >
> >
> > I hope this will be of some use to some of you.
> > Bests,
> > LPA
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Small-how-to-for-Mesos-Ignite-Java-tp8467.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
> >
>

Re: API for asynchronous execution.

[Nikolay Tikhonov]

Yakov is right. Benchmarks show performance drop 3-8% when using
asynchronous callbacks.

On Fri, Apr 15, 2016 at 11:34 AM, Yakov Zhdanov <yzhda...@apache.org> wrote:

> I am pretty sure that making all filter notifications asynchronous will
> terribly affect performance. I would leave it only for cases when some
> complex processing needs to be done involving, for example, cache
> operations. If filter is simple then I would leave it sync (by default).
>
> --Yakov
>
> 2016-04-15 0:52 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
>
> > Nick,
> >
> > Can you explain why we would ever want to have a synchronous callback?
> > Aren’t all filter notifications supposed to be asynchronous, especially
> if
> > there is no performance degradation?
> >
> > D.
> >
> > On Thu, Apr 14, 2016 at 11:17 AM, Nikolay Tikhonov <
> ntikho...@gridgain.com
> > >
> > wrote:
> >
> > > The following code snippet show how make asynchronous filter in
> > continuous
> > > query. Difference in configuration between sync and async  filters just
> > in
> > > annotation on class.
> > >
> > > IgniteCache cache = ...;
> > >
> > > ContinuousQuery qry = new ContinuousQuery();
> > >
> > > qry.setRemoteFilterFactory(FactoryBuiler.factoryOf(Filter.class));
> > >
> > > cache.query(qry);
> > >
> > > *@IgniteAsyncCallback*
> > > class Filter implements CacheEntryEventFilter<Key, Value> {
> > > @IgniteInstanceResource
> > > private Ignite ignite;
> > >
> > > @Override public boolean evaluate(CacheEntryEvent > > extends Value> evt) {
> > > IgniteCache<Key, Value> cache = ignite.cache(...);
> > >
> > > // This filter has @IgniteAsyncCallback annotation then in this
> > > place cache
> > > // operations are allowed and safe otherwise can get deadlock.
> > > Value val = cache.get(...);
> > > ...
> > > }
> > > }
> > >
> > > Size for thread pool which using for executing callbacks can be
> > configured
> > > by IgniteConfiguration.setAsyncCallbackPoolSize(...) method.
> > >
> > > On Thu, Apr 14, 2016 at 8:10 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > Do we have a coding example for this functionality somewhere? It
> would
> > be
> > > > nice to review the changes from usability standpoint.
> > > >
> > > > On Thu, Apr 14, 2016 at 3:58 AM, Nikolay Tikhonov <
> > > ntikho...@gridgain.com>
> > > > wrote:
> > > >
> > > > > We are close to completing IGNITE-2004 ticket.
> > > > > As part this ticket was made the following changes on public API
> > > > > - if callback has @IgniteAsyncCallback annotation then callback
> > should
> > > be
> > > > > run asynchronously
> > > > > - these callbacks are executed in special pool (callback thread
> pool)
> > > > which
> > > > > is configured by IgniteConfiguration.asyncCallbackThreadPoolSize
> > > > >
> > > > > Any comments on this?
> > > > >
> > > > > On Wed, Mar 30, 2016 at 12:45 PM, Yakov Zhdanov <
> > yzhda...@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > I think this approach works unless user does not initiate number
> of
> > > > > > concurrent cache operations greater than MSG_QUEUE_SIZE.  Where
> msg
> > > > queue
> > > > > > size default is 1024, but still configurable.
> > > > > >
> > > > > > Thanks!
> > > > > > --
> > > > > > Yakov Zhdanov, Director R
> > > > > > *GridGain Systems*
> > > > > > www.gridgain.com
> > > > > >
> > > > > > 2016-03-30 11:44 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com
> >:
> > > > > >
> > > > > > > Does it mean that if cache update rate is greater than filter
> > > > execution
> > > > > > > rate, then at some point we will stop reading messages from
> > socket?
> > > > If
> > > > > > yes,
> > > > > > > then it seems we still cannot execute cache operations:
> > > > > > > 1) Filter starts cache operati

Re: API for asynchronous execution.

[Nikolay Tikhonov]

The following code snippet show how make asynchronous filter in continuous
query. Difference in configuration between sync and async  filters just in
annotation on class.

IgniteCache cache = ...;

ContinuousQuery qry = new ContinuousQuery();

qry.setRemoteFilterFactory(FactoryBuiler.factoryOf(Filter.class));

cache.query(qry);

*@IgniteAsyncCallback*
class Filter implements CacheEntryEventFilter<Key, Value> {
@IgniteInstanceResource
private Ignite ignite;

@Override public boolean evaluate(CacheEntryEvent evt) {
IgniteCache<Key, Value> cache = ignite.cache(...);

// This filter has @IgniteAsyncCallback annotation then in this
place cache
// operations are allowed and safe otherwise can get deadlock.
Value val = cache.get(...);
...
}
}

Size for thread pool which using for executing callbacks can be configured
by IgniteConfiguration.setAsyncCallbackPoolSize(...) method.

On Thu, Apr 14, 2016 at 8:10 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> Do we have a coding example for this functionality somewhere? It would be
> nice to review the changes from usability standpoint.
>
> On Thu, Apr 14, 2016 at 3:58 AM, Nikolay Tikhonov <ntikho...@gridgain.com>
> wrote:
>
> > We are close to completing IGNITE-2004 ticket.
> > As part this ticket was made the following changes on public API
> > - if callback has @IgniteAsyncCallback annotation then callback should be
> > run asynchronously
> > - these callbacks are executed in special pool (callback thread pool)
> which
> > is configured by IgniteConfiguration.asyncCallbackThreadPoolSize
> >
> > Any comments on this?
> >
> > On Wed, Mar 30, 2016 at 12:45 PM, Yakov Zhdanov <yzhda...@gridgain.com>
> > wrote:
> >
> > > I think this approach works unless user does not initiate number of
> > > concurrent cache operations greater than MSG_QUEUE_SIZE.  Where msg
> queue
> > > size default is 1024, but still configurable.
> > >
> > > Thanks!
> > > --
> > > Yakov Zhdanov, Director R
> > > *GridGain Systems*
> > > www.gridgain.com
> > >
> > > 2016-03-30 11:44 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>:
> > >
> > > > Does it mean that if cache update rate is greater than filter
> execution
> > > > rate, then at some point we will stop reading messages from socket?
> If
> > > yes,
> > > > then it seems we still cannot execute cache operations:
> > > > 1) Filter starts cache operation for a key. Current node is backup
> for
> > > this
> > > > key.
> > > > 2) Cache message is sent to primary node
> > > > 3) Primary sends message back to current node.
> > > > 4) Message is never read because of backpressure. Cache operation and
> > > > filter never complete.
> > > >
> > > > Am I missing something?
> > > >
> > > > On Wed, Mar 30, 2016 at 11:23 AM, Yakov Zhdanov <yzhda...@apache.org
> >
> > > > wrote:
> > > >
> > > > > Vladimir,
> > > > >
> > > > > Communication should stop reading from connection is there are too
> > many
> > > > > unprocessed messages. Sender will be blocked on putting message to
> > > queue.
> > > > >
> > > > > --Yakov
> > > > >
> > > > > 2016-03-30 11:11 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>:
> > > > >
> > > > > > Guys,
> > > > > >
> > > > > > Can you explain how backpressure control is implemented? What if
> > > event
> > > > > > arrival speed is greater than filter processing speed?
> > > > > >
> > > > > > On Wed, Mar 30, 2016 at 10:37 AM, Semyon Boikov <
> > > sboi...@gridgain.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Andrey,
> > > > > > >
> > > > > > > I agree that current situation with threading in Ignite is very
> > > > > > > inconvenient when user callbacks execute some non-trivial code.
> > But
> > > > > > > changing this to async dispatch is huge refactoring, even
> > changing
> > > > this
> > > > > > > just for continuous queries callback is not so easy task.
> > > > > > >
> > > > > > > We can start with
> > > https://issues.apache.org/jira/browse/IGNITE-2004,
> > > > > and

[jira] [Created] (IGNITE-2630) Make 'updateCntr' available through CacheInterceptor API

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-2630:


 Summary: Make 'updateCntr' available through CacheInterceptor API
 Key: IGNITE-2630
 URL: https://issues.apache.org/jira/browse/IGNITE-2630
 Project: Ignite
  Issue Type: New Feature
  Components: cache
Affects Versions: 1.5.0.final
Reporter: Nikolay Tikhonov
Priority: Minor


Make {{updateCntr}} available through {{CacheInterceptor}} API. On 
{{onAfterPut}} and {{onAfterRemove}} methods partition update counter can be 
got by Cache.Entry.unwrap(Long.class). When invoking other methods on 
{{CacheIntercetor}} API ({{onBeforePut}}, {{onBeforeRemove}}) the counter is 
not available.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Docker image

[Nikolay Tikhonov]

Val,

Our docker repo contains not only the latest version or 1.0.0-incubating,
there all versions.  List of versions here [1]. I've updated "Dockerfile"
tab, now it shows dockerfile from "1.5.0.final" tag.

[1] https://hub.docker.com/r/apacheignite/ignite/tags

On Fri, Jan 29, 2016 at 9:34 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Nikolay,
>
> As far as I know you were creating Docker images for Ignite.
>
> I just opened it [1] and noticed that the version is 1.0.0 there. Is there
> a reason for this? Can we switch it to the latest?
>
> [1] https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
>
> -Val
>

[jira] [Created] (IGNITE-2435) Mesos doesn't work with limited access to internet

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-2435:


 Summary: Mesos doesn't work with limited access to internet
 Key: IGNITE-2435
 URL: https://issues.apache.org/jira/browse/IGNITE-2435
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Nikolay Tikhonov


Ignite Mesos integration doesn't work behind a firewall. Need to make all 
external resources will customizable and avoid unnecessary accesses to web.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Intoduction

[Nikolay Tikhonov]

Hi Edouard!

I think it useful future and don't see any reason why you can't implement
this task. Feel free to ask if you have questions.


On Wed, Jan 20, 2016 at 6:08 PM, Edouard Chevalier <
edouard.cheval...@techmydata.net> wrote:

> Hi all,
>
> I'm Edouard Chevalier and I would like to contribute to the Apache Ignite
> project.
> I have read some of the guides on "how to contribute". If you agree I can
> start with a proposal on the JIRA I have just created (
> https://issues.apache.org/jira/browse/IGNITE-2419) and then go on any
> newbie task.
> Thanks,
> Edouard Chevalier.
>

Re: Ignite docker image

[Nikolay Tikhonov]

Dima,

Docker hub repository has six images. Each image is labeled with tag
(1.0.0-incubating, 1.1.0-incubating, 1.2.0-incubating and etc) [1] and
stores specific ignite distributive i.e. image with tag 1.0.0-incubating
stores Ignite 1.0.0-incubating distributive, 1.1.0-incubating stores Ignite
1.1.0-incubating and etc. For downloading docker image with specific
version need to perform docker pull and specify the tag. For example:
docker pull apacheignite/ignite:1.4.0 (1.4.0 is tag) download image with
Ignite 1.4.0 distributive. Whenever tag is not specific (docker pull
apacheignite/ignite is the same docker pull apacheignite/ignite:latest)
will download image with latest tag, right now latest tag contains Apache
Ignite 1.5 distributive.

https://hub.docker.com/r/apacheignite/ignite/tags/

On Mon, Jan 11, 2016 at 9:55 PM, Dmitriy Setrakyan <dsetrak...@apache.org>
wrote:

> Nick,
>
> I am still a bit confused. Can you please describe what happens right now
> with the image we have stored on the docker hub? I am interested in what
> Ignite version is stored there and what Ignite version is downloaded
> whenever no specific version is passed.
>
> D.
>
> On Mon, Jan 11, 2016 at 10:26 AM, Nikolay Tikhonov <ntikho...@gridgain.com
> >
> wrote:
>
> > >
> > > In that case, why does the docker image contain any version of Ignite
> at
> > > all?
> > >
> > We download docker image which was built from Dockerfile (which contains
> > specific version of Ignite) and the image contains Ignite distributive.
> > Apache Ignite distributive is downloaded only once in during the build of
> > the docker image.
> >
>

Re: Ignite docker image

[Nikolay Tikhonov]

Dima,
Docker hub shows Dockerfile for `1.0.0-incubating` tag [1]. For this tag it
is correct. [2]
I would prefer see Dockerfile for the latest version, but I can't find
functionality to change it. I'll ask DockerHub community how fix it.

1. https://hub.docker.com/r/apacheignite/ignite/~/dockerfile/
2.
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=tree;f=modules/docker;h=7406e8b30a8ec6c2cdf9974c4a4e41c3df838bbf;hb=HEAD

On Mon, Jan 4, 2016 at 9:17 PM, Dmitriy Setrakyan 
wrote:

> Gents,
>
> I just looked at the Ignite docker image [1] and it has the following
> directive in it:
>
> *ENV IGNITE_HOME /opt/ignite/ignite-fabric-1.0.0-incubating*
>
> Looked like it needs some freshening up.
>
> Nick, given that you have been managing this docker account, can you please
> update it?
>
> D.
>

Re: Ignite docker image

[Nikolay Tikhonov]

On Mon, Jan 11, 2016 at 8:39 PM, Dmitriy Setrakyan 
wrote:
>
>
> I am not sure I understand. Are you suggesting we have different docker
> files for different versions?


Yes, for each Ignite version need to create Dockerfile with version and tag
on DockerHub.

I would prefer that unless a version is explicitly specified, the docker
> file should download the latest version.
>

Docker image contains a specific version of Ignite. Apache Ignite docker
repo contains the following tags [1] that essentially means exist six
docker images and each contains own version Ignite. For example if user
perform *docker pull apacheignite/ignite:1.4.0 *command then will be
downloaded image with Ignite version 1.4.0. If user doesn't set version
explicitly (*docker pull apacheignite/ignite*) then will be downloaded
image with the latest ignite version.

1. https://hub.docker.com/r/apacheignite/ignite/tags/

Re: Ignite docker image

[Nikolay Tikhonov]

>
> In that case, why does the docker image contain any version of Ignite at
> all?
>
We download docker image which was built from Dockerfile (which contains
specific version of Ignite) and the image contains Ignite distributive.
Apache Ignite distributive is downloaded only once in during the build of
the docker image.

Re: [VOTE] Apache Ignite 1.5.0.final RC3

[Nikolay Tikhonov]

+1 (binding)

On Tue, Dec 29, 2015 at 4:23 PM, Anton Vinogradov 
wrote:

> +1 (binding)
>
> On Tue, Dec 29, 2015 at 4:17 PM, 姜 为  wrote:
>
> > +1 nice job!
> >
> > > 在 2015年12月29日，下午6:54，Anton Vinogradov  写道：
> > >
> > > Dear Sirs!
> > >
> > > We have uploaded release candidate to
> > > https://dist.apache.org/repos/dist/dev/ignite/1.5.0.final-rc3/
> > >
> > > This is very important release containing initial versions of
> Ignite.NET
> > > and Ignite C++ and many other important features.
> > >
> > > Tag name is
> > > 1.5.0.final-rc3
> > >
> > > 1.5.0 changes:
> > > * Ignite.NET: Initial Release.
> > > * Ignite C++: Initial Release.
> > > * Massive performance improvements for cache operations and SQL.
> > > * Added new binary cache object marshalling implementation.
> > > * Added IgniteSemaphore data structure.
> > > * Added MQTT Streamer.
> > > * Added Twitter Streamer.
> > > * Added Ignite Sink (integration with Apache Flume).
> > > * Fixed optimistic serializable transactions: implemented
> "deadlock-free"
> > > locking algorithm.
> > > * Fixed failover for continuous queries.
> > > * Fixed compilation and runtime errors under OpenJDK and IBM JDK.
> > > * Fixed Integer.size limitation for cache.
> > > * Fixed and improved cache types configuration.
> > > * Fixed cache rebalancing.
> > > * Many stability and fault-tolerance fixes.
> > > * Added example to demonstrate the usage of EntryProcessor.
> > >
> > > Complete list of closed issues:
> > >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.5%20AND%20status%20%3D%20closed
> > >
> > > DEVNOTES
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/1.5.0.final-rc3
> > >
> > > RELEASENOTES
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.5.0.final-rc3
> > >
> > > Please start voting.
> > >
> > > +1 - to accept Apache Ignite 1.5.0.final-rc3
> > > 0 - don't care either way
> > > -1 - DO NOT accept Apache Ignite 1.5.0.final-rc3 (explain why)
> > >
> > > This vote will go for 72 hours.
> >
> >
>

Re: [VOTE] Apache Ignite 1.5.0-b1

[Nikolay Tikhonov]

+1

On Wed, Dec 2, 2015 at 3:21 PM, Anton Vinogradov 
wrote:

> +1
>
> On Wed, Dec 2, 2015 at 3:16 PM, Yakov Zhdanov  wrote:
>
> > Dear Sirs!
> >
> > We have uploaded release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/1.5.0-b1-rc1/
> >
> > This is very important release containing initial versions of Ignite.NET
> > and Ignite C++ and many other important features.
> > We want community to test this Early Access version in order to gather
> > feedback and move on to releasing final version.
> >
> > Tag name is
> > ignite-1.5.0-b1-rc1
> >
> > 1.5.0 changes:
> > * Ignite.NET: Initial Release.
> > * Ignite C++: Initial Release.
> > * Massive performance improvements for cache operations and SQL.
> > * Added new binary cache object marshalling implementation.
> > * Added IgniteSemaphore data structure.
> > * Added MQTT Streamer.
> > * Added Twitter Streamer.
> > * Added Ignite Sink (integration with Apache Flume).
> > * Fixed failover for continuous queries.
> > * Fixed compilation and runtime errors under OpenJDK and IBM JDK.
> > * Fixed Integer.size limitation for cache.
> > * Fixed and improved cache types configuration.
> > * Fixed cache rebalancing.
> > * Many stability and fault-tolerance fixes.
> >
> > Complete list of closed issues:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.5%20AND%20status%20%3D%20closed
> >
> > DEVNOTES
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/ignite-1.5.0-b1-rc1
> >
> > RELEASENOTES
> >
> >
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/ignite-1.5.0-b1-rc1
> >
> > Please start voting.
> >
> > +1 - to accept Apache Ignite 1.5.0-b1
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 1.5.0-b1 (explain why)
> >
> > This vote will go for 72 hours.
> >
> > --Yakov
> >
>

Re: Ignite-1.5 Release

[Nikolay Tikhonov]

I'm fully agree with Yakov. We plain to release massive changes and I think
that it's good chance for community to play with new features and we can
get more feedback.

On Mon, Nov 30, 2015 at 7:32 PM, Alexey Kuznetsov 
wrote:

> +1 for EA
>
> On Mon, Nov 30, 2015 at 11:30 PM, Yakov Zhdanov 
> wrote:
>
> > Guys,
> >
> > Our plan was to release over the weekend, but unfortunately that didn’t
> > happen due to a few bugs. And even though we have fixed all the
> discovered
> > issues I am still not comfortable with releasing the final version.
> Having
> > the great number of functionality introduced in 1.5 including (but not
> > limited to) - .net and cpp platforms, marshalling changes to support
> > platforms and massive optimizations - I would ask community whether we
> can
> > release 1.5.0-EA and have folks to play with it for a week or so and then
> > release the final version.
> >
> > Please let me know your opinion. If community agrees I will submit
> 1.5.0-EA
> > for vote in a few hours.
> >
> > --Yakov
> >
> > 2015-11-28 13:57 GMT+03:00 Yakov Zhdanov :
> >
> > > Guys,
> > >
> > > Small update. We are very close to submit Ignite-1.5-RC1. We currently
> > > fixing TeamCity in ignite-1.5 branch.
> > >
> > > --Yakov
> > >
> > > 2015-11-25 3:39 GMT+03:00 Dmitriy Setrakyan :
> > >
> > >> On Wed, Nov 25, 2015 at 3:09 AM, Raul Kripalani 
> > wrote:
> > >>
> > >> > It's integrated, i.e. it deploys on an OSGi container. And the
> Ignite
> > >> part
> > >> > works. But at soon as it delegates to Spring to parse the context
> XML,
> > >> the
> > >> > latter complains about namespace handlers not being found.
> > >> >
> > >> > Spring DM looks into bundles to find NS handlers. So without Spring
> DM
> > >> such
> > >> > problems are expected.
> > >> >
> > >> > Maybe it does work after all if we refrain from using certain
> > namespace
> > >> > like util. I'll have to check that tomorrow.
> > >> >
> > >>
> > >> Thanks! Dropping support for Spring XML configuration in OSGI would
> be a
> > >> huge loss. Would be great if you could investigate it and see what it
> > >> would
> > >> take.
> > >>
> > >
> > >
> >
>
>
>
> --
> Alexey Kuznetsov
> GridGain Systems
> www.gridgain.com
>

Re: Ignite-1.5 Release

[Nikolay Tikhonov]

I've merged changes related to IGNITE-426 (Make sure continuous queries
notifications are not missed in case primary node fails
) task.

On Thu, Nov 19, 2015 at 5:53 PM, Anton Vinogradov 
wrote:

> Twitter intergration
> *https://issues.apache.org/jira/browse/IGNITE-530
> *
>
> is done too
>
> On Thu, Nov 19, 2015 at 5:32 PM, Semyon Boikov 
> wrote:
>
> > Just merged single get optimizations (improvements in the last benchmarks
> > run: ~10% for atomic-put-get, ~5% for tx-put-get).
> >
>

[jira] [Created] (IGNITE-1922) Add auth support to YARN module

[Nikolay Tikhonov (JIRA)]

Nikolay Tikhonov created IGNITE-1922:


 Summary: Add auth support to YARN module
 Key: IGNITE-1922
 URL: https://issues.apache.org/jira/browse/IGNITE-1922
 Project: Ignite
  Issue Type: Improvement
Affects Versions: ignite-1.4
Reporter: Nikolay Tikhonov
 Fix For: 1.6


User list discussion:
http://apache-ignite-users.70518.x6.nabble.com/Exception-in-Kerberos-Yarn-cluster-td1950.html#a1965



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Ignite-1.5 Release

[Nikolay Tikhonov]

I implemented changes related to IGNITE-426 task. Currently investigating
performance degradation for atomic caches. I expect the ticket to be merged
in 2 days.

On Tue, Nov 3, 2015 at 6:47 PM, Alexey Goncharuk  wrote:

> IGNITE-950 is taking more time to be merged than I originally estimated. We
> had a couple of silly bugs, such as loosing cache operation context on
> async cache operations, which led to hard-to debug failures in the platform
> integration code.
> I also added some sanity checks to indexing and found that I ran benchmarks
> for new binary format on a model with externalizable classes, so the result
> I've got were invalid, need more time to fix the model and re-run
> benchmarks.
>
> I am currently waiting for another CI run, will give an update in several
> hours.
>
> 2015-11-03 17:51 GMT+03:00 Vladimir Ozerov :
>
> > Here are my current status for all interop-related stuff (you can view
> > these tickets using query "project = IGNITE AND status in (Open, "In
> > Progress", Reopened, Resolved, "Patch Available") AND component = interop
> > AND fixVersion = 1.5"):
> >
> > *IGNITE-1819 - Remove metadataEnabled flag in Java*
> > Trivial. Waiting for IGNITE-950 merge.
> >
> > *IGNITE-1845, IGNITE-1846 - portable API renamings in CPP and .Net*
> > Trivial. Waiting for IGNITE-950 merge.
> >
> > *IGNITE-1803 - Optimized field lookup for queries*
> > Ready. Waiting for IGNITE-950 to merge.
> >
> > *IGNITE-1847 - Add "field" method to portable metadata.*
> > Not started yet. Waiting for IGNITE-950 to merge.
> >
> > *IGNITE-1816 - Optionally do not write field IDs to portable object
> > footer.*
> > Not started yet.
> >
> > + Several minor tickets.
> >
> > All in all, I expect all these tickets to be ready in 2 days.
> >
> >
> >
> > On Tue, Nov 3, 2015 at 1:43 AM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com
> > > wrote:
> >
> > > I'm sorry, I meant to write "changes related to IGNITE-1486 *ticket*".
> > The
> > > changes are in ignite-950-new branch because it is a result of work on
> > > multiple sub-tickets and it is currently used as an integration branch.
> > >
> > > 2015-11-03 1:39 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Alexey,
> > > >
> > > > I am confused. Why do you have 2 branches?
> > > >
> > > > D.
> > > >
> > > > On Mon, Nov 2, 2015 at 2:32 PM, Alexey Goncharuk <
> > > > alexey.goncha...@gmail.com
> > > > > wrote:
> > > >
> > > > > I am finalizing changes related to IGNITE-1486 branch. Currently
> the
> > > API
> > > > > changes are finished and now I am mostly fixing the CI tests. In
> > fact,
> > > I
> > > > > just submitted the latest fix related to the new .NET platform
> > > > > functionality and hope CI tests will pass, in this case it will be
> > > ready
> > > > to
> > > > > be merged tomorrow morning.
> > > > > It would be nice if other community members reviewed my changes in
> > > > > ignite-950-new branch before it gets to master.
> > > > >
> > > > > 2015-11-02 22:27 GMT+03:00 Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > Thanks Vladislav!
> > > > > >
> > > > > > Would also be nice to get an update from other committers
> involved
> > in
> > > > the
> > > > > > outlined tickets. Specifically whether the ticket has been merged
> > to
> > > > > master
> > > > > > or not, and if not, what should be the expectation.
> > > > > >
> > > > > > Thanks,
> > > > > > D.
> > > > > >
> > > > > > On Mon, Nov 2, 2015 at 11:23 AM, Vladisav Jelisavcic <
> > > > > vladis...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > >10. I would also like to include distributed Semaphore.
> > Vladislav,
> > > > any
> > > > > > > >chance you can finish with it this week?
> > > > > > > >https://issues.apache.org/jira/browse/IGNITE-
> > > > > > > >638
> > > > > > >
> > > > > > > I will have it done by thursday.
> > > > > > >
> > > > > > > Best regards,
> > > > > > > Vladisav
> > > > > > >
> > > > > > > On Mon, Nov 2, 2015 at 6:40 PM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Mon, Nov 2, 2015 at 6:58 AM, M G 
> > wrote:
> > > > > > > >
> > > > > > > > > Can/will this include
> > > > > > > https://issues.apache.org/jira/browse/IGNITE-1681
> > > > > > > > ?
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don’t see why not. Would be nice if one of the committers
> > could
> > > > > pick
> > > > > > up
> > > > > > > > the review for this patch.
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Nov 2, 2015 at 1:51 PM, Anton Vinogradov <
> > > > > > > > avinogra...@gridgain.com
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Branch ignite-1.5 created.
> > > > > > > > > >
> > > > > > > > > > On Mon, Nov 2, 2015 at 4:39 PM, Anton Vinogradov <
> > > > > > > > > avinogra...@gridgain.com
> >