[jira] [Updated] (IGNITE-2105) DirectMessageWriter cannot write nested collections.
[ https://issues.apache.org/jira/browse/IGNITE-2105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2105: Component/s: (was: 1.4) general > DirectMessageWriter cannot write nested collections. > > > Key: IGNITE-2105 > URL: https://issues.apache.org/jira/browse/IGNITE-2105 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Valentin Kulichenko >Priority: Blocker > Fix For: 1.5 > > > Steps to reproduce: > 1) Run GridMessageCollectionTest in ignite-1.5 branch > 2) Observe class-cast exception. > The problem is caused by DirectByteBufferStreamImplV2 which is re-used across > all nested objects. > This class is stateful. When nested collection is written, instead of writing > collection element it writes element of another collection which is upper in > call stack. > Looks pretty critical for me. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2145) Async cache operations on primary node might block
[
https://issues.apache.org/jira/browse/IGNITE-2145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-2145.
-
Resolution: Won't Fix
{{EntryProcessor}} has to be invoked atomically, regardless of whether you're
executing it synchronously or asynchronously. This means that the entry will be
locked during the execution.
If you need to execute a long-running task collocated with the data, you can
use {{IgniteCompute.affinityRun()}} method instead, which sends a closure to
the node where the entry is stored without locking it.
> Async cache operations on primary node might block
> --
>
> Key: IGNITE-2145
> URL: https://issues.apache.org/jira/browse/IGNITE-2145
> Project: Ignite
> Issue Type: Bug
>Affects Versions: ignite-1.4
> Environment: Windows 8.1 64 bit
> java version "1.8.0_51"
> Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
> Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)
> Ignite 1.4.0
>Reporter: Avihai Berkovitz
>
> When executing async operations on caches the initial function call is
> supposed to return immediately, without regard to cache state, network
> traffic, etc. If we reference a cache key on a different node it works. But
> if the primary node for a cache key is the same node that initiate the
> operation everything is executed synchronously.
> This is probably an optimization, but can have side effects. For example, if
> a long running CacheProcessor is invoked on this key, every operation will
> block.
> Here is some code to illustrate the problem. Notice that there is a 4 seconds
> delay between "Before async op" and "After async op". If you reverse the
> isPrimary() condition it won't happen.
> {code}
> IgniteConfiguration igniteConfiguration = new IgniteConfiguration()
> .setFailoverSpi(new AlwaysFailoverSpi())
> .setGridLogger(new Slf4jLogger())
> .setPeerClassLoadingEnabled(false)
> .setDeploymentMode(DeploymentMode.CONTINUOUS);
> Ignite ignite1 = Ignition.start(igniteConfiguration);
> Ignite ignite2 = Ignition.start(igniteConfiguration.setGridName("2"));
> assert ignite1.cluster().nodes().size() == 2;
> assert ignite2.cluster().nodes().size() == 2;
> CacheConfiguration cacheConfiguration = new
> CacheConfiguration()
> .setName("test")
> .setCacheMode(CacheMode.PARTITIONED)
> .setAtomicityMode(CacheAtomicityMode.ATOMIC)
>
> .setWriteSynchronizationMode(CacheWriteSynchronizationMode.FULL_SYNC);
> IgniteCache cache1 =
> ignite1.getOrCreateCache(cacheConfiguration);
> IgniteCache cache2 =
> ignite2.getOrCreateCache(cacheConfiguration);
> // Find key mapped to the first node
> String key = IntStream.range(0, 100)
> .mapToObj(value -> "HI" + value)
> .filter(s ->
> ignite1.affinity(cacheConfiguration.getName()).isPrimary(ignite1.cluster().localNode(),
> s))
> .findFirst().get();
> // Run a blocked processor from node 2
> Thread thread = new Thread() {
> @Override
> public void run() {
> System.out.println("Invoking blocked processor");
> cache2.invoke(key, (entry, arguments) -> {
> System.out.println("IN INVOKE");
> try {
> Thread.sleep(5 * 1000);
> } catch (InterruptedException e) {
> e.printStackTrace();
> }
> return null;
> });
> System.out.println("Blocked invoke returned");
> }
> };
> thread.start();
> Thread.sleep(1000);
> IgniteCache async1 = cache1.withAsync();
> System.out.println("Before async op");
> //async1.put(key, 1);
> //async1.get(key);
> async1.containsKey(key);
> System.out.println("After async op");
> assert async1.future().isDone();
> thread.join();
> ignite2.close();
> ignite1.close();
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2087) Ignite CacheManager ignores provided class loader
[
https://issues.apache.org/jira/browse/IGNITE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15059425#comment-15059425
]
Valentin Kulichenko edited comment on IGNITE-2087 at 12/16/15 7:50 AM:
---
We should also set class loader for non-default URI.
This can be achieved by passing the loader to {{IgnitionEx}} and setting it to
{{IgniteConfiguration}} after it's loaded from the XML.
UPD: I think {{IgniteConfiguration.setClassLoader}} should not be called if the
class loader is already explicitly set.
was (Author: vkulichenko):
We should also set class loader for non-default URI.
This can be achieved by passing the loader to {{IgnitionEx}} and setting it to
{{IgniteConfiguration}} after it's loaded from the XML.
> Ignite CacheManager ignores provided class loader
> -
>
> Key: IGNITE-2087
> URL: https://issues.apache.org/jira/browse/IGNITE-2087
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.5
>
>
> {{CacheManager}} should delegate the provided class loader to
> {{IgniteConfiguration.setClassLoader()}}. Currently it's ignored.
> user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Help-with-integrating-Ignite-as-JCache-with-JBoss-EAP-6-4-td2134.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2332) Service proxy can't be created for package-private implementation
Valentin Kulichenko created IGNITE-2332:
---
Summary: Service proxy can't be created for package-private
implementation
Key: IGNITE-2332
URL: https://issues.apache.org/jira/browse/IGNITE-2332
Project: Ignite
Issue Type: Bug
Components: managed services
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Fix For: 1.6
{noformat}
Caused by: java.lang.IllegalAccessException: Class
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable
can not access a member of class
org.apache.ignite.examples.service.MyServiceImpl with modifiers "public"
at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:109)
at
java.lang.reflect.AccessibleObject.slowCheckMemberAccess(AccessibleObject.java:261)
at
java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:253)
at java.lang.reflect.Method.invoke(Method.java:599)
at
org.apache.ignite.internal.processors.service.GridServiceProxy$ServiceProxyCallable.call(GridServiceProxy.java:382)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1789)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:509)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6372)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:503)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:456)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1166)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1770)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:823)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:105)
at
org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:786)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2080) JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c
[
https://issues.apache.org/jira/browse/IGNITE-2080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15074116#comment-15074116
]
Valentin Kulichenko commented on IGNITE-2080:
-
Andrey,
{{DirectByteBufferStreamImplV1}} is an old version of the protocol which is
left for compatibility only. Are you sure it needs to be changed? Also, is
changing {{DirectByteBufferStreamImplV2}} is OK from compatibility standpoint?
Shouldn't we introduce new protocol version for these changes?
> JVM crashes on SunOS with SIGBUS (0xa) on frame [libjvm.so+0xc7c438]
> Unsafe_SetInt+0x14c
> -
>
> Key: IGNITE-2080
> URL: https://issues.apache.org/jira/browse/IGNITE-2080
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5, 1.4
> Environment: SunOS 5.11, JDK 7
>Reporter: Andrey Gura
>Assignee: Andrey Gura
> Fix For: 1.6
>
> Attachments: 054424_0_localhost.log, benchmark-offheap.properties,
> hs_err_pid10523.log
>
>
> JVM crashes on SunOS 5.11 with the following message:
> {noformat}
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0xa) at pc=0x76a7c438, pid=10523, tid=652
> #
> # JRE version: Java(TM) SE Runtime Environment (7.0_79-b15) (build
> 1.7.0_79-b15)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.79-b02 mixed mode
> solaris-sparc )
> # Problematic frame:
> # V [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c
> {noformat}
> Stack trace:
> {noformat}
> Stack: [0xfff0f6f0,0xfff0f700], sp=0xfff0f6ffd1f0, free
> space=1012k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V [libjvm.so+0xc7c438] Unsafe_SetInt+0x14c
> j sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+-1763873616
> j sun.misc.Unsafe.putInt(Ljava/lang/Object;JI)V+0
> j
> org.apache.ignite.internal.util.IgniteUtils.writeVersion([BJLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;)J+135
> j
> org.apache.ignite.internal.processors.cache.GridCacheSwapEntryImpl.marshal()[B+128
> j
> org.apache.ignite.internal.processors.cache.GridCacheSwapManager.write(Lorg/apache/ignite/internal/processors/cache/KeyCacheObject;Ljava/nio/ByteBuffer;BLorg/apache/
> ignite/internal/processors/cache/version/GridCacheVersion;JJLorg/apache/ignite/lang/IgniteUuid;Lorg/apache/ignite/lang/IgniteUuid;)V+86
> j org.apache.ignite.internal.processors.cache.GridCacheMapEntry.swap()V+333
> j
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.evictInternal(ZLorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignit
> e/internal/processors/cache/CacheEntryPredicate;)Z+122
> j
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.evict0(Lorg/apache/ignite/internal/processors/cache/GridCacheAdapter;Lorg/apache/ignite/internal
> /processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/processors/cache/version/GridCacheVersion;[Lorg/apache/ignite/internal/processors/cache/CacheEntryPredica
> te;Z)Z+117
> j
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager.touch(Lorg/apache/ignite/internal/processors/cache/GridCacheEntryEx;Lorg/apache/ignite/internal/
> processors/affinity/AffinityTopologyVersion;)V+123
> j
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.unlockEntries(Ljava/util/Collection;Lorg/apache/ignite/internal/processors/affi
> nity/AffinityTopologyVersion;)V+331
> j
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/
> cache/distributed/dht/atomic/GridNearAtomicUpdateRequest;Lorg/apache/ignite/internal/util/typedef/CI2;)V+1023
> j
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/c
> ache/distributed/dht/atomic/GridNearAtomicUpdateRequest;Lorg/apache/ignite/internal/util/typedef/CI2;)V+33
> j
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(Ljava/util/UUID;Lorg/apache/ignite/internal/processors/cache/
> distributed/dht/atomic/GridNearAtomicUpdateRequest;)V+28
> j
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1200(Lorg/apache/ignite/internal/processors/cache/distributed/dh
> t/atomic/GridNearAtomicUpdateFuture;Ljava/util/UUID;Lorg/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridNearAtomicUpdateRequest;)V+3
> j
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(Lorg/apache/ignite/internal/processors/affinity/Affinit
>
[jira] [Created] (IGNITE-2345) Implement JPA-based store session listener
Valentin Kulichenko created IGNITE-2345: --- Summary: Implement JPA-based store session listener Key: IGNITE-2345 URL: https://issues.apache.org/jira/browse/IGNITE-2345 Project: Ignite Issue Type: Improvement Components: cache Reporter: Valentin Kulichenko We already have JDBC, Spring and Hibernate-based listeners, but it would be useful to have JPA-based implementation as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2345) Implement JPA-based store session listener
[ https://issues.apache.org/jira/browse/IGNITE-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2345: Fix Version/s: 1.6 > Implement JPA-based store session listener > -- > > Key: IGNITE-2345 > URL: https://issues.apache.org/jira/browse/IGNITE-2345 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Valentin Kulichenko > Fix For: 1.6 > > > We already have JDBC, Spring and Hibernate-based listeners, but it would be > useful to have JPA-based implementation as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1575) NPE when cache is started concurrently with the node stop
[
https://issues.apache.org/jira/browse/IGNITE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1575:
Labels: (was: usability)
> NPE when cache is started concurrently with the node stop
> -
>
> Key: IGNITE-1575
> URL: https://issues.apache.org/jira/browse/IGNITE-1575
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Minor
> Fix For: 1.6
>
>
> It's not causing any harm, but it's possible to get the NPE below during the
> node stop.
> {noformat}
> 57724 [main] ERROR IgniteKernal%t1-1 - Got exception while starting (will
> rollback startup routine).
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onKernalStart0(CacheContinuousQueryManager.java:91)
> at
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStart(GridCacheManagerAdapter.java:97)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:833)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1549)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1416)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:916)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> .. application stack frames ...
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1575) NPE when cache is started concurrently with the node stop
[
https://issues.apache.org/jira/browse/IGNITE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1575:
Flags: Important
Priority: Major (was: Minor)
> NPE when cache is started concurrently with the node stop
> -
>
> Key: IGNITE-1575
> URL: https://issues.apache.org/jira/browse/IGNITE-1575
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
> Fix For: 1.6
>
>
> It's not causing any harm, but it's possible to get the NPE below during the
> node stop.
> {noformat}
> 57724 [main] ERROR IgniteKernal%t1-1 - Got exception while starting (will
> rollback startup routine).
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryManager.onKernalStart0(CacheContinuousQueryManager.java:91)
> at
> org.apache.ignite.internal.processors.cache.GridCacheManagerAdapter.onKernalStart(GridCacheManagerAdapter.java:97)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:833)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:829)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1549)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1416)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:916)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:477)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:458)
> at org.apache.ignite.Ignition.start(Ignition.java:321)
> .. application stack frames ...
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
> at
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2212) Transactional put triggers several deserializations on server of there are recordable events
[ https://issues.apache.org/jira/browse/IGNITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2212: Attachment: TxTest.java > Transactional put triggers several deserializations on server of there are > recordable events > > > Key: IGNITE-2212 > URL: https://issues.apache.org/jira/browse/IGNITE-2212 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko > Fix For: 1.6 > > Attachments: TxTest.java > > > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2212) Transactional put triggers several deserializations on server of there are recordable events
Valentin Kulichenko created IGNITE-2212: --- Summary: Transactional put triggers several deserializations on server of there are recordable events Key: IGNITE-2212 URL: https://issues.apache.org/jira/browse/IGNITE-2212 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: 1.6 Attachments: TxTest.java Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2249) Services are sometimes deserialized on client
Valentin Kulichenko created IGNITE-2249: --- Summary: Services are sometimes deserialized on client Key: IGNITE-2249 URL: https://issues.apache.org/jira/browse/IGNITE-2249 Project: Ignite Issue Type: Bug Components: managed services Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Priority: Critical Fix For: 1.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2202) Local server query result doesn't include versions in entries
[ https://issues.apache.org/jira/browse/IGNITE-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2202: Fix Version/s: 1.6 > Local server query result doesn't include versions in entries > - > > Key: IGNITE-2202 > URL: https://issues.apache.org/jira/browse/IGNITE-2202 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Labels: important > Fix For: 1.6 > > Attachments: QueryTest2.java > > > Cache entries returned as query results don't contain versions even if the > query is local. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2202) Local server query result doesn't include versions in entries
[ https://issues.apache.org/jira/browse/IGNITE-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15069219#comment-15069219 ] Valentin Kulichenko commented on IGNITE-2202: - This ticket is about local query on server (changed title to more informative). Moved back to 1.6 > Local server query result doesn't include versions in entries > - > > Key: IGNITE-2202 > URL: https://issues.apache.org/jira/browse/IGNITE-2202 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Labels: important > Fix For: 1.6 > > Attachments: QueryTest2.java > > > Cache entries returned as query results don't contain versions even if the > query is local. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-967:
---
Labels: important (was: )
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Artem Shutak
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2195) Accessing from IGFS to HDFS that is in kerberised environment
[
https://issues.apache.org/jira/browse/IGNITE-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2195:
Labels: important (was: )
> Accessing from IGFS to HDFS that is in kerberised environment
> -
>
> Key: IGNITE-2195
> URL: https://issues.apache.org/jira/browse/IGNITE-2195
> Project: Ignite
> Issue Type: Bug
> Components: hadoop, IGFS
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Ivan Veselovsky
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> There is some issue in the current IGFS implementation that doesn't take into
> account some Kerberos user related settings which leads to the exception
> below when there is an attempt to work with Kerberised cluster
> {noformat}
> Connecting to HDFS with the following settings [uri=null, cfg=all-site.xml,
> userName=null]
> log4j:WARN No appenders could be found for logger
> (org.apache.hadoop.metrics2.lib.MutableMetricsFactory).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info.
> org.apache.hadoop.security.AccessControlException: SIMPLE authentication is
> not enabled. Available:[TOKEN, KERBEROS]
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at
> org.apache.hadoop.ipc.RemoteException.instantiateException(RemoteException.java:106)
> at
> org.apache.hadoop.ipc.RemoteException.unwrapRemoteException(RemoteException.java:73)
> at org.apache.hadoop.hdfs.DFSClient.listPaths(DFSClient.java:2096)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$DirListingIterator.(DistributedFileSystem.java:944)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$DirListingIterator.(DistributedFileSystem.java:927)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:872)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem$19.doCall(DistributedFileSystem.java:868)
> at
> org.apache.hadoop.fs.FileSystemLinkResolver.resolve(FileSystemLinkResolver.java:81)
> at
> org.apache.hadoop.hdfs.DistributedFileSystem.listLocatedStatus(DistributedFileSystem.java:868)
> at org.apache.hadoop.fs.FileSystem.listLocatedStatus(FileSystem.java:1694)
> at org.apache.hadoop.fs.FileSystem$6.(FileSystem.java:1786)
> at org.apache.hadoop.fs.FileSystem.listFiles(FileSystem.java:1783)
> at com.ig.HadoopFsIssue.main(HadoopFsIssue.java:35)
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.security.AccessControlException):
> SIMPLE authentication is not enabled. Available:[TOKEN, KERBEROS]
> at org.apache.hadoop.ipc.Client.call(Client.java:1427)
> at org.apache.hadoop.ipc.Client.call(Client.java:1358)
> at
> org.apache.hadoop.ipc.ProtobufRpcEngine$Invoker.invoke(ProtobufRpcEngine.java:229)
> at com.sun.proxy.$Proxy7.getListing(Unknown Source)
> at
> org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolTranslatorPB.getListing(ClientNamenodeProtocolTranslatorPB.java:573)
> 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
> org.apache.hadoop.io.retry.RetryInvocationHandler.invokeMethod(RetryInvocationHandler.java:187)
> at
> org.apache.hadoop.io.retry.RetryInvocationHandler.invoke(RetryInvocationHandler.java:102)
> at com.sun.proxy.$Proxy8.getListing(Unknown Source)
> at org.apache.hadoop.hdfs.DFSClient.listPaths(DFSClient.java:2094)
> {noformat}
> The issue is fixed in the following way. Need to revisit the fix and check
> whether it can lead to some other consequences.
> {noformat}
> /**
> * @return {@link org.apache.hadoop.fs.FileSystem} instance for this
> secondary Fs.
> * @throws IOException
> */
> public FileSystem createFileSystem(String userName) throws IOException {
> userName = IgfsUtils.fixUserName(userName);
> UserGroupInformation.setConfiguration(cfg);
> UserGroupInformation ugi = UserGroupInformation.createProxyUser(userName,
> UserGroupInformation.getCurrentUser());
> try {
> return ugi.doAs(new PrivilegedExceptionAction() {
> @Override
> public FileSystem run() throws Exception {
> return FileSystem.get(uri, cfg);
> }
> });
> } catch (InterruptedException e)
[jira] [Updated] (IGNITE-2258) Hadoop: secondary file system is initialized on client even if there are no explicit PROXY paths.
[ https://issues.apache.org/jira/browse/IGNITE-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2258: Labels: important (was: ) > Hadoop: secondary file system is initialized on client even if there are no > explicit PROXY paths. > - > > Key: IGNITE-2258 > URL: https://issues.apache.org/jira/browse/IGNITE-2258 > Project: Ignite > Issue Type: Bug > Components: hadoop >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 1.6 > > > *Problem*: > In case at least one PROXY path exists, we intialize secondary file system on > the client (IgniteHadoopFileSystem). > We have 4 "default paths" which are always defined (see IgfsImpl) and one of > these paths is in PROXY mode. > As a result, whenever secondary file system is defined, it will always be > intiialized on the client whether it is needed or not. > *Proposed solutions*: > a) Remove these default paths as they are of little use in real apps. > b) Or make them optional through configuration parameter. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2083) EntryProcessor is called twice on primary node in transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2083:
Labels: important (was: )
> EntryProcessor is called twice on primary node in transactional cache
> -
>
> Key: IGNITE-2083
> URL: https://issues.apache.org/jira/browse/IGNITE-2083
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Labels: important
> Fix For: 1.5
>
>
> Issue is described in details here:
> http://apache-ignite-developers.2346864.n4.nabble.com/EntryProcessor-invoked-twice-td5494.html
> Looks like that this can be optimized, at least for {{REPEATABLE_READ}}
> transactions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2079) GridCacheIoManager eats exception trail if it falls into the directed case
[
https://issues.apache.org/jira/browse/IGNITE-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2079:
Labels: important (was: )
> GridCacheIoManager eats exception trail if it falls into the directed case
> --
>
> Key: IGNITE-2079
> URL: https://issues.apache.org/jira/browse/IGNITE-2079
> Project: Ignite
> Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
> Labels: important
> Fix For: 1.6
>
>
> During a recent test I have run into an issue where a storage disabled client
> of a Fabric that has services deployed for which the client does not have the
> fabric in the class path failed with the following exception:
> com.workday.fabric.HelloWorldTest STANDARD_ERROR
> Nov 08, 2015 6:15:20 PM org.apache.ignite.logger.java.JavaLogger error
> SEVERE: Failed to process message
> [senderId=30775397-457a-400f-a6c9-077c9e762d61, messageType=class
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> class org.apache.ignite.IgniteCheckedException: Failed to send response to
> node. Unsupported direct type [message=GridCacheQueryResponse [finished=true,
> reqId=5, err=null, fields=false, metadata=null]]
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:546)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:272)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:77)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1078)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2302)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:992)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:106)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:961)
> 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 unfortunately gives me 0 information to work on to resolve the issue, as
> the original unmarshalling exception (from the JdkMarshaller) was eaten as
> this is the code for the default process failed message:
> default:
> throw new IgniteCheckedException("Failed to send response to node.
> Unsupported direct type [message="
> + msg + "]");
> }
> you should also include the original stack from msg.getError() in the newly
> thrown IgniteCheckedException
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1553) Optimize transaction prepare step when store is enabled
[
https://issues.apache.org/jira/browse/IGNITE-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1553:
Labels: important (was: )
> Optimize transaction prepare step when store is enabled
> ---
>
> Key: IGNITE-1553
> URL: https://issues.apache.org/jira/browse/IGNITE-1553
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Alexey Goncharuk
> Labels: important
>
> Currently entries are enlisted in a database transaction after grid
> transaction is in PREPARED state. We can do this in parallel in the following
> fashion (pseudo-code):
> {code}
> fut = tx.prepareAsync();
> db.write(tx.writes());
> fut.get();
> try {
> db.commit();
>
> tx.commit();
> }
> catch (Exception e) {
> tx.rollback();
> }
> {code}
> If this approach is applied, we should be able to reduce latency for
> transactions when write-through is enabled.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1864) Cannot configure jndiNames for CacheJndiTmLookup
[ https://issues.apache.org/jira/browse/IGNITE-1864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1864: Labels: important (was: ) > Cannot configure jndiNames for CacheJndiTmLookup > - > > Key: IGNITE-1864 > URL: https://issues.apache.org/jira/browse/IGNITE-1864 > Project: Ignite > Issue Type: Bug > Components: general >Reporter: Yakov Zhdanov >Assignee: Artem Shutak >Priority: Critical > Labels: important > Fix For: 1.5 > > > Since user have an ability to configure only lookup class name via > org.apache.ignite.configuration.TransactionConfiguration#getTxManagerLookupClassName, > he lacks ability to properly configure all of its properties. > This seems to be a general problem for this approach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2249) Services are sometimes deserialized on client
[ https://issues.apache.org/jira/browse/IGNITE-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2249: Labels: important (was: ) > Services are sometimes deserialized on client > - > > Key: IGNITE-2249 > URL: https://issues.apache.org/jira/browse/IGNITE-2249 > Project: Ignite > Issue Type: Bug > Components: managed services >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Critical > Labels: important > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2212) Transactional put triggers several deserializations on server of there are recordable events
[ https://issues.apache.org/jira/browse/IGNITE-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2212: Labels: important (was: ) > Transactional put triggers several deserializations on server of there are > recordable events > > > Key: IGNITE-2212 > URL: https://issues.apache.org/jira/browse/IGNITE-2212 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Alexey Goncharuk > Labels: important > Fix For: 1.6 > > Attachments: TxTest.java > > > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter
[ https://issues.apache.org/jira/browse/IGNITE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2004: Labels: important (was: ) > Asynchronous execution of ContinuousQuery's remote filter > - > > Key: IGNITE-2004 > URL: https://issues.apache.org/jira/browse/IGNITE-2004 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: ignite-1.4 >Reporter: Denis Magda >Assignee: Nikolay Tikhonov > Labels: important > Fix For: 1.6 > > > Presently remote filters are executed synchronously an entry update. This > leads to the limitation when it's disallowed to perform cache related > operation in a filter body. > It's required to add the ability to execute remote filters asynchronously. > This will let to execute any kind of operations including cache operations > directly in the filter body. > The solution must be fault-tolerant. At least once execution of a filter in > case of a failure works fine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1403) forOldest() cluster group returns predicate that is not updated when topology changes
[
https://issues.apache.org/jira/browse/IGNITE-1403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1403:
Labels: important (was: )
> forOldest() cluster group returns predicate that is not updated when topology
> changes
> -
>
> Key: IGNITE-1403
> URL: https://issues.apache.org/jira/browse/IGNITE-1403
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Labels: important
>
> {{AgeClusterGroup}} that implements {{forOldest()}} and {{forYoungest}}
> cluster groups is dynamically updated when topology changes. But the
> predicate that can be acquired from this group via {{predicate()}} method is
> static, which is incorrect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1523:
Labels: important user-request (was: user-request)
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: important, user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1186) Filter is sent instead of factory when continuous query is created
[
https://issues.apache.org/jira/browse/IGNITE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1186:
Labels: important (was: )
> Filter is sent instead of factory when continuous query is created
> --
>
> Key: IGNITE-1186
> URL: https://issues.apache.org/jira/browse/IGNITE-1186
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> {{CacheContinuousQueryHandler}}, which is sent to remote nodes on query
> creation always contains {{CacheEntryEventSerializableFilter}}. This is OK
> for our {{ContinuousQuery}} API, because it doesn't work with factories, but
> not OK for JCache entry listener API. {{CacheEntryListenerConfiguration}}
> contains factory and it's assumed that the filter is created on remote node
> and is never sent through network. But we require the filter to be
> {{Serializable}}.
> We need to always send factory instead of the filter. In case of
> {{ContinuousQuery}} API we can use singleton factory that will wrap the
> instance that already exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1979) Support case insensitive nonquoted cache names in SQL queries
[
https://issues.apache.org/jira/browse/IGNITE-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1979:
Labels: important (was: )
> Support case insensitive nonquoted cache names in SQL queries
> -
>
> Key: IGNITE-1979
> URL: https://issues.apache.org/jira/browse/IGNITE-1979
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Critical
> Labels: important
> Fix For: 1.6
>
>
> According to SQL ANSI-99 standard the schema name (corresponds to a cache
> name in Ignite) is case insensitive.
> However Ignite has the requirement to put a cache name into the quotation
> marks. This violates the standard.
> The main reasons of that is because a cache name in Ignite is case sensitive
> and can contain all kind of symbols that are not supported by underlying H2
> engine.
> Proposed to introduce a new configuration property to {{CacheConfiguration}}
> that will let the end user use a cache name in case insensitive manner
> without quoted identifiers in SQL queries.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-426) Make sure continuous queries notifications are not missed in case primary node fails
[ https://issues.apache.org/jira/browse/IGNITE-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-426: --- Labels: important (was: ) > Make sure continuous queries notifications are not missed in case primary > node fails > > > Key: IGNITE-426 > URL: https://issues.apache.org/jira/browse/IGNITE-426 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Yakov Zhdanov >Assignee: Nikolay Tikhonov >Priority: Critical > Labels: important > Fix For: 1.5 > > > * Maintain updates queue on backup node(s) in addition to primary node. > * If primary node crushes, this queue is flushed to listening clients. > * To avoid notification duplicates we will have a per-partition update > counter. Once an entry in some partition is updated, counter for this > partition is incremented on both primary and backups. The value of this > counter is also sent along with the update to the client, which also > maintains the copy of this mapping. If at some moment it receives an update > with the counter less than in its local map, this update is a duplicate and > can be discarded. > * To cleanup the backup queue we will use communication acks. When batch > receival is acked by the client, we will send special ack message to backup > nodes that will remove items that are not longer needed. This message has to > contain partition to latest update counter map. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2213) Handle duplicate field names in BinaryMarshaller.
[
https://issues.apache.org/jira/browse/IGNITE-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2213:
Labels: important (was: )
> Handle duplicate field names in BinaryMarshaller.
> -
>
> Key: IGNITE-2213
> URL: https://issues.apache.org/jira/browse/IGNITE-2213
> Project: Ignite
> Issue Type: Bug
> Components: general, interop
>Affects Versions: ignite-1.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Blocker
> Labels: important
> Fix For: 1.5
>
>
> Consider the following scenario:
> {code}
> class A {
> int field;
> }
> class B : class A {
> int field;
> }
> {code}
> In this case BinaryMarshaller will throw an exception about duplicate field
> names. And there is no sensible workaround for user.
> We can add some prefix/suffix to comflicting fields. E.g. A.field will be
> written as "field", B.field will be written as "field_B".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2289) Eviction policy doesn't work with OFFHEAP_VALUES mode
Valentin Kulichenko created IGNITE-2289: --- Summary: Eviction policy doesn't work with OFFHEAP_VALUES mode Key: IGNITE-2289 URL: https://issues.apache.org/jira/browse/IGNITE-2289 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: 1.6 For issue description and the test refer to this discussion: http://apache-ignite-users.70518.x6.nabble.com/Eviction-for-OFFHEAP-TIERED-vs-OFFHEAP-VALUES-td2302.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2310) Add lock/unlock partition operations on IgniteCache
Valentin Kulichenko created IGNITE-2310:
---
Summary: Add lock/unlock partition operations on IgniteCache
Key: IGNITE-2310
URL: https://issues.apache.org/jira/browse/IGNITE-2310
Project: Ignite
Issue Type: New Feature
Components: cache
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
Need to add public API methods that will allow to lock and unlock partitions.
This may be useful to avoid data movements when using {{affinityRun}} during
topology changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2311) Need to add an option to store cache objects only in deserialized form
Valentin Kulichenko created IGNITE-2311: --- Summary: Need to add an option to store cache objects only in deserialized form Key: IGNITE-2311 URL: https://issues.apache.org/jira/browse/IGNITE-2311 Project: Ignite Issue Type: New Feature Components: cache Reporter: Valentin Kulichenko Priority: Critical Fix For: 1.6 In this new mode objects should be always deserialized when saved in cache and serialized form should be discarded. Serialization should happen only on demand (e.g., for get() or rebalancing). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2311) Need to add an option to store cache objects only in deserialized form
[ https://issues.apache.org/jira/browse/IGNITE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2311: Flags: Important > Need to add an option to store cache objects only in deserialized form > -- > > Key: IGNITE-2311 > URL: https://issues.apache.org/jira/browse/IGNITE-2311 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > > In this new mode objects should be always deserialized when saved in cache > and serialized form should be discarded. Serialization should happen only on > demand (e.g., for get() or rebalancing). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2225) Externalizable classes are serialized twice with binary marshaller
Valentin Kulichenko created IGNITE-2225: --- Summary: Externalizable classes are serialized twice with binary marshaller Key: IGNITE-2225 URL: https://issues.apache.org/jira/browse/IGNITE-2225 Project: Ignite Issue Type: Bug Components: general Reporter: Valentin Kulichenko Priority: Blocker Fix For: 1.5 Test that reproduces that issue is attached to IGNITE-2212 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2087) Ignite CacheManager ignores provided class loader
[
https://issues.apache.org/jira/browse/IGNITE-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15063265#comment-15063265
]
Valentin Kulichenko commented on IGNITE-2087:
-
Anton,
Changes look good. Please add tests and if OK, good to merge.
> Ignite CacheManager ignores provided class loader
> -
>
> Key: IGNITE-2087
> URL: https://issues.apache.org/jira/browse/IGNITE-2087
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
>Priority: Critical
> Fix For: 1.5
>
>
> {{CacheManager}} should delegate the provided class loader to
> {{IgniteConfiguration.setClassLoader()}}. Currently it's ignored.
> user@ thread:
> http://apache-ignite-users.70518.x6.nabble.com/Help-with-integrating-Ignite-as-JCache-with-JBoss-EAP-6-4-td2134.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2203) CacheEntryImplEx contains version twice
[
https://issues.apache.org/jira/browse/IGNITE-2203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2203:
Attachment: EpTest.java
> CacheEntryImplEx contains version twice
> ---
>
> Key: IGNITE-2203
> URL: https://issues.apache.org/jira/browse/IGNITE-2203
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.5
>
> Attachments: EpTest.java
>
>
> {{CacheEntryImplEx}} extends {{CacheEntryImpl}}, which duplicated the version.
> This makes it impossible to serialize with the {{BinaryMarshaller}}:
> {code}
> class org.apache.ignite.binary.BinaryObjectException: Duplicate field name
> [fieldName=ver,
> cls=org.apache.ignite.internal.processors.cache.CacheEntryImplEx]
> {code}
> Test that reproduces the failure is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2202) Query result entries don't include versions
Valentin Kulichenko created IGNITE-2202: --- Summary: Query result entries don't include versions Key: IGNITE-2202 URL: https://issues.apache.org/jira/browse/IGNITE-2202 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Priority: Critical Fix For: 1.6 Cache entries returned as query results don't contain versions even if the query is local. Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2202) Query result entries don't include versions
[ https://issues.apache.org/jira/browse/IGNITE-2202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2202: Attachment: QueryTest2.java > Query result entries don't include versions > --- > > Key: IGNITE-2202 > URL: https://issues.apache.org/jira/browse/IGNITE-2202 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > Attachments: QueryTest2.java > > > Cache entries returned as query results don't contain versions even if the > query is local. > Test attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-1988) NPE when explicit lock is acquired within a transaction
[
https://issues.apache.org/jira/browse/IGNITE-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1988.
---
> NPE when explicit lock is acquired within a transaction
> ---
>
> Key: IGNITE-1988
> URL: https://issues.apache.org/jira/browse/IGNITE-1988
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.5
>
>
> This code:
> {code}
> try (Transaction tx = Ignition.ignite().transactions().txStart()) {
> cache.lock(1).lock();
> }
> {code}
> result in the NPE:
> {code}
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.addEntry(GridDhtColocatedLockFuture.java:294)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.addLocalKey(GridDhtColocatedLockFuture.java:1172)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapAsPrimary(GridDhtColocatedLockFuture.java:1118)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:736)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.mapOnTopology(GridDhtColocatedLockFuture.java:677)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.map(GridDhtColocatedLockFuture.java:629)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.lockAllAsync(GridDhtColocatedCache.java:628)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheAdapter.lockAllAsync(GridDistributedCacheAdapter.java:117)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.lockAll(GridCacheAdapter.java:3150)
> at
> org.apache.ignite.internal.processors.cache.CacheLockImpl.lock(CacheLockImpl.java:72)
> at
> org.apache.ignite.examples.datagrid.CacheTransactionExample.deposit(CacheTransactionExample.java:92)
> at
> org.apache.ignite.examples.datagrid.CacheTransactionExample.main(CacheTransactionExample.java:70)
> {code}
> If such usage is invalid, proper exception should be thrown.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-967:
---
Priority: Critical (was: Blocker)
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-967) Internal thread locals are not always cleaned
[
https://issues.apache.org/jira/browse/IGNITE-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-967:
---
Fix Version/s: 1.6
> Internal thread locals are not always cleaned
> -
>
> Key: IGNITE-967
> URL: https://issues.apache.org/jira/browse/IGNITE-967
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: sprint-4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Fix For: 1.6
>
>
> One of our users reported that he sees warnings in Tomcat's log when the
> application that's running Ignite in embedded mode is undeployed:
> {code}
> SEVERE: The web application [/XXX] created a ThreadLocal with key of type
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1] (value
> [org.apache.ignite.internal.util.GridSpinReadWriteLock$1@2c2858af]) and a
> value of type [java.lang.Integer] (value [0]) but failed to remove it when
> the web application was stopped. Threads are going to be renewed over time to
> try and avoid a probable memory leak.
> {code}
> There is also the similar warning for {{GridToStringBuilder.threadCache}}.
> While it's usually OK not to clean thread locals on standalone node, in app
> server it can cause a memory leak.
> To avoid such issues I suggest to add a special step after all test suites
> that will check thread locals in test runner thread. If we have this check in
> CI, we will fix it once and for always.
> Thread local values can be introspected through {{Thread.threadLocals}}
> variable. It would also be a good idea to check Tomcat's sources on how it's
> done there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1523:
Priority: Critical (was: Blocker)
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1523:
Fix Version/s: 1.6
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Blocker
> Labels: user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1186) Filter is sent instead of factory when continuous query is created
[
https://issues.apache.org/jira/browse/IGNITE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1186:
Fix Version/s: 1.6
> Filter is sent instead of factory when continuous query is created
> --
>
> Key: IGNITE-1186
> URL: https://issues.apache.org/jira/browse/IGNITE-1186
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> {{CacheContinuousQueryHandler}}, which is sent to remote nodes on query
> creation always contains {{CacheEntryEventSerializableFilter}}. This is OK
> for our {{ContinuousQuery}} API, because it doesn't work with factories, but
> not OK for JCache entry listener API. {{CacheEntryListenerConfiguration}}
> contains factory and it's assumed that the filter is created on remote node
> and is never sent through network. But we require the filter to be
> {{Serializable}}.
> We need to always send factory instead of the filter. In case of
> {{ContinuousQuery}} API we can use singleton factory that will wrap the
> instance that already exist.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1538) Query performance is 2 times slower in OFFHEAP_TIERED mode
[ https://issues.apache.org/jira/browse/IGNITE-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1538: Assignee: (was: Valentin Kulichenko) > Query performance is 2 times slower in OFFHEAP_TIERED mode > -- > > Key: IGNITE-1538 > URL: https://issues.apache.org/jira/browse/IGNITE-1538 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Blocker > Labels: performance, user-request > Fix For: 1.6 > > > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-td1352.html > Need to run benchmarks and investigate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1538) Query performance is 2 times slower in OFFHEAP_TIERED mode
[ https://issues.apache.org/jira/browse/IGNITE-1538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-1538: Fix Version/s: (was: 1.5) 1.6 > Query performance is 2 times slower in OFFHEAP_TIERED mode > -- > > Key: IGNITE-1538 > URL: https://issues.apache.org/jira/browse/IGNITE-1538 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Assignee: Valentin Kulichenko >Priority: Blocker > Labels: performance, user-request > Fix For: 1.6 > > > Corresponding user@ thread: > http://apache-ignite-users.70518.x6.nabble.com/SQL-Performance-indexing-performance-on-heap-vs-off-heap-td1352.html > Need to run benchmarks and investigate. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-1840) Exception in eviction manager on startup
[
https://issues.apache.org/jira/browse/IGNITE-1840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1840:
Fix Version/s: (was: 1.5)
1.6
> Exception in eviction manager on startup
>
>
> Key: IGNITE-1840
> URL: https://issues.apache.org/jira/browse/IGNITE-1840
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.6
>
>
> It's rarely reproduced and looks like a race condition on startup. In some
> cases eviction backup worker start to work too early which leads to this
> exception on first iterations:
> {noformat}
> Exception in thread "cache-eviction-backup-worker-#40%null%"
> java.lang.AssertionError: AffinityTopologyVersion [topVer=-1, minorTopVer=0]
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:423)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.primaryPartitions(GridAffinityAssignmentCache.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryPartitions(GridCacheAffinityManager.java:352)
> at
> org.apache.ignite.internal.processors.cache.GridCacheEvictionManager$BackupWorker.body(GridCacheEvictionManager.java:1478)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-1956) Portable object requires to have a class to get Enum field value
Valentin Kulichenko created IGNITE-1956:
---
Summary: Portable object requires to have a class to get Enum
field value
Key: IGNITE-1956
URL: https://issues.apache.org/jira/browse/IGNITE-1956
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Fix For: 1.6
{{PortableObject.field()}} method implementation attempts to resolve the class
if the field type is Enum. This is wrong, because this method should work on
server side without classes on classpath. Also this breaks the {{toString()}}
method in this case.
In addition, .NET always writes {{-1}} as a type ID for any enum, so on Java
side it is resolved into {{java.lang.Object}}. As a result, {{field()}} and
{{toString()} method fail with this exception:
{code}
Caused by: org.apache.ignite.internal.portable.api.PortableException: Class
does not represent enum type: java.lang.Object
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-1956) Portable object requires to have a class to get Enum field value
[
https://issues.apache.org/jira/browse/IGNITE-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-1956:
Description:
{{PortableObject.field()}} method implementation attempts to resolve the class
if the field type is Enum. This is wrong, because this method should work on
server side without classes on classpath. Also this breaks the {{toString()}}
method in this case.
In addition, .NET always writes {{-1}} as a type ID for any enum, so on Java
side it is resolved into {{java.lang.Object}}. As a result, {{field()}} and
{{toString()}} method fail with this exception:
{code}
Caused by: org.apache.ignite.internal.portable.api.PortableException: Class
does not represent enum type: java.lang.Object
{code}
was:
{{PortableObject.field()}} method implementation attempts to resolve the class
if the field type is Enum. This is wrong, because this method should work on
server side without classes on classpath. Also this breaks the {{toString()}}
method in this case.
In addition, .NET always writes {{-1}} as a type ID for any enum, so on Java
side it is resolved into {{java.lang.Object}}. As a result, {{field()}} and
{{toString()} method fail with this exception:
{code}
Caused by: org.apache.ignite.internal.portable.api.PortableException: Class
does not represent enum type: java.lang.Object
{code}
> Portable object requires to have a class to get Enum field value
>
>
> Key: IGNITE-1956
> URL: https://issues.apache.org/jira/browse/IGNITE-1956
> Project: Ignite
> Issue Type: Bug
> Components: general, interop
>Reporter: Valentin Kulichenko
>Assignee: Vladimir Ozerov
> Fix For: 1.5
>
>
> {{PortableObject.field()}} method implementation attempts to resolve the
> class if the field type is Enum. This is wrong, because this method should
> work on server side without classes on classpath. Also this breaks the
> {{toString()}} method in this case.
> In addition, .NET always writes {{-1}} as a type ID for any enum, so on Java
> side it is resolved into {{java.lang.Object}}. As a result, {{field()}} and
> {{toString()}} method fail with this exception:
> {code}
> Caused by: org.apache.ignite.internal.portable.api.PortableException: Class
> does not represent enum type: java.lang.Object
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1227) Need to implement Ignite-based Spring transaction manager
[
https://issues.apache.org/jira/browse/IGNITE-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1227.
---
> Need to implement Ignite-based Spring transaction manager
> -
>
> Key: IGNITE-1227
> URL: https://issues.apache.org/jira/browse/IGNITE-1227
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Labels: newbie
> Fix For: 1.5
>
> Attachments: IGNITE-1227.patch
>
>
> This will allow to use Spring transaction interceptor for wrapping cache
> operations into Ignite transaction.
> Essentially, we need to implement Spring's {{PlatformTransactionManager}}
> interface using {{IgniteTransactions}} API.
> Corresponding user list thread:
> http://apache-ignite-users.70518.x6.nabble.com/Transactions-td885.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2358) Write behind store swallows exception trace in case of error
Valentin Kulichenko created IGNITE-2358:
---
Summary: Write behind store swallows exception trace in case of
error
Key: IGNITE-2358
URL: https://issues.apache.org/jira/browse/IGNITE-2358
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Fix For: 1.6
See {{GridCacheWriteBehindStore:708}}:
{code}
LT.warn(log, e, "Unable to update underlying store: " + store);
{code}
The exception trace is never printed out in case of warnings, therefore user
sees only message, which is usually not enough.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
[
https://issues.apache.org/jira/browse/IGNITE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320679#comment-15320679
]
Valentin Kulichenko commented on IGNITE-3153:
-
Anton,
I was under impression that {{onSpiContextDestroyed}} can be called on client
disconnect. If this is not true, I think you're right. But the usage of
{{initGuard}} should be revisited in any case.
> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP
> finder is used. Most likely this is caused by the fact that {{initGuard}} is
> flipped back to {{false}} when the context is destroyed and new curator
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
> {noformat}
> 2016-05-16 12:00:59,096 5786 ERROR
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught
> during grid runnable execution: IgniteSpiThread
> [name=tcp-client-disco-reconnector-#5%Default%]
> java.lang.IllegalStateException: Cannot be started more than once
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
> ...
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3232) Ignite RDD: need to add transformer closure to saveValues and savePairs
[ https://issues.apache.org/jira/browse/IGNITE-3232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko closed IGNITE-3232. --- > Ignite RDD: need to add transformer closure to saveValues and savePairs > --- > > Key: IGNITE-3232 > URL: https://issues.apache.org/jira/browse/IGNITE-3232 > Project: Ignite > Issue Type: Improvement > Components: Ignite RDD >Reporter: Yakov Zhdanov >Assignee: Valentin Kulichenko > Fix For: 1.7 > > > We need to add transformer closure that allows inline transformation. > Closure should accept rdd row and return result eligible to be saved in > cache. User should also should have access to Ignite instance inside closure > to be able to provide affinity key to store on desired node. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3175) BigDecimal fields are not supported if query is executed from IgniteRDD
[
https://issues.apache.org/jira/browse/IGNITE-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-3175.
---
> BigDecimal fields are not supported if query is executed from IgniteRDD
> ---
>
> Key: IGNITE-3175
> URL: https://issues.apache.org/jira/browse/IGNITE-3175
> Project: Ignite
> Issue Type: Bug
> Components: Ignite RDD
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> If one of the fields participating in the query is {{BigDecimal}}, the query
> will fail when executed from {{IgniteRDD}} with the following error:
> {noformat}
> scala.MatchError: 1124757 (of class java.math.BigDecimal)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:255)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:260)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$$anonfun$createToCatalystConverter$2.apply(CatalystTypeConverters.scala:401)
> at
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
> at
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
> at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.processInputs(TungstenAggregationIterator.scala:505)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.(TungstenAggregationIterator.scala:686)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:95)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:86)
> at
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
> at
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
> at
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:73)
> at
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:41)
> at org.apache.spark.scheduler.Task.run(Task.scala:89)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Most likely this is caused by the fact that {{IgniteRDD.dataType()}} method
> doesn't honor {{BigDecimal}} and returns {{StructType}} by default. We should
> fix this and check other possible types as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3175) BigDecimal fields are not supported if query is executed from IgniteRDD
[
https://issues.apache.org/jira/browse/IGNITE-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15316520#comment-15316520
]
Valentin Kulichenko commented on IGNITE-3175:
-
Taras,
The change looks good to me, I merged it into master.
Can you provide more info on what is not working now and which types are
problematic? Do we have corresponding tests? I think this should go to the dev
list, I will resolve the ticket.
Thanks!
> BigDecimal fields are not supported if query is executed from IgniteRDD
> ---
>
> Key: IGNITE-3175
> URL: https://issues.apache.org/jira/browse/IGNITE-3175
> Project: Ignite
> Issue Type: Bug
> Components: Ignite RDD
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> If one of the fields participating in the query is {{BigDecimal}}, the query
> will fail when executed from {{IgniteRDD}} with the following error:
> {noformat}
> scala.MatchError: 1124757 (of class java.math.BigDecimal)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:255)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:260)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$$anonfun$createToCatalystConverter$2.apply(CatalystTypeConverters.scala:401)
> at
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
> at
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
> at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.processInputs(TungstenAggregationIterator.scala:505)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.(TungstenAggregationIterator.scala:686)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:95)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:86)
> at
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
> at
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
> at
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:73)
> at
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:41)
> at org.apache.spark.scheduler.Task.run(Task.scala:89)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Most likely this is caused by the fact that {{IgniteRDD.dataType()}} method
> doesn't honor {{BigDecimal}} and returns {{StructType}} by default. We should
> fix this and check other possible types as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3310) Need to document Visor scripting capabilities
Valentin Kulichenko created IGNITE-3310: --- Summary: Need to document Visor scripting capabilities Key: IGNITE-3310 URL: https://issues.apache.org/jira/browse/IGNITE-3310 Project: Ignite Issue Type: Improvement Components: documentation Affects Versions: 1.6 Reporter: Valentin Kulichenko Assignee: Alexey Kuznetsov Fix For: 1.7 The functionality was added in scope of IGNITE-185, but it's not documented yet. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder
[
https://issues.apache.org/jira/browse/IGNITE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329646#comment-15329646
]
Valentin Kulichenko commented on IGNITE-3216:
-
{{viewSetReadOnly}} is not used anymore, so I would prefer to remove it
completely. Otherwise, looks good.
> Need to deduplicate addresses registered in the IP finder
> -
>
> Key: IGNITE-3216
> URL: https://issues.apache.org/jira/browse/IGNITE-3216
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> {{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with
> duplicated addresses in some cases (e.g., if one of hostnames is provided as
> an IP). We should deduplicate the list before returning it (most likely we
> should simply use {{Set}} instead).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3152) Client node's addresses are registered in IP finder
[
https://issues.apache.org/jira/browse/IGNITE-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15329667#comment-15329667
]
Valentin Kulichenko commented on IGNITE-3152:
-
Yes, you're right, but this means that one the places in the code is incorrect
:) Why we have the {{TcpDiscoveryIpFinderAdapter.discoveryClientMode()}} method
then?
I'm actually not sure that it's correct to return {{false}} from
{{ClusterNode.isClient()}} method in case it's actually a client, but with
forced server mode on discovery level.
Should this be discussed on dev@?
> Client node's addresses are registered in IP finder
> ---
>
> Key: IGNITE-3152
> URL: https://issues.apache.org/jira/browse/IGNITE-3152
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Labels: important
> Fix For: 1.7
>
> Attachments: Test.java
>
>
> Currently client node register its addresses in IP finder and never
> deregisters them. Also looks like coordinator address is also not removed.
> The simple test that shows this behavior is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2344) WebSessionFilter doesn't support session ID renewal
[
https://issues.apache.org/jira/browse/IGNITE-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-2344.
---
> WebSessionFilter doesn't support session ID renewal
> ---
>
> Key: IGNITE-2344
> URL: https://issues.apache.org/jira/browse/IGNITE-2344
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Saikat Maitra
>
> It's quite a common scenario to update a session ID after a user successfully
> logged in preserving the session content for further usage.
> Ignite's {{WebSessionFilter}} doesn't support such a use case creating a
> session from scratch.
> To support this behavior we can store a special Cookie that will hold latest
> session ID. When a session is passed to {{WebSessionFilter}} and the filter
> detects that this is a fresh session it will check the Cookie in advance. If
> the Cookie exists and holds an old session ID then the filter will be able to
> get a session content from the cache using the old ID and put it back using
> the new ID.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder
[
https://issues.apache.org/jira/browse/IGNITE-3216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320611#comment-15320611
]
Valentin Kulichenko commented on IGNITE-3216:
-
Anton,
Why do we need the {{F.viewSetReadOnly}} call there? Can we avoid it? I would
prefer to remove usages of {{F.}} where possible.
> Need to deduplicate addresses registered in the IP finder
> -
>
> Key: IGNITE-3216
> URL: https://issues.apache.org/jira/browse/IGNITE-3216
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Fix For: 1.7
>
>
> {{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with
> duplicated addresses in some cases (e.g., if one of hostnames is provided as
> an IP). We should deduplicate the list before returning it (most likely we
> should simply use {{Set}} instead).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3152) Client node's addresses are registered in IP finder
[
https://issues.apache.org/jira/browse/IGNITE-3152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15320625#comment-15320625
]
Valentin Kulichenko commented on IGNITE-3152:
-
Anton,
Client node can work in forced server mode. I think we should register
addresses in this case.
See {{TcpDiscoveryIpFinderAdapter.discoveryClientMode()}} and its usages on how
this can be properly checked.
> Client node's addresses are registered in IP finder
> ---
>
> Key: IGNITE-3152
> URL: https://issues.apache.org/jira/browse/IGNITE-3152
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Anton Vinogradov
> Labels: important
> Fix For: 1.7
>
> Attachments: Test.java
>
>
> Currently client node register its addresses in IP finder and never
> deregisters them. Also looks like coordinator address is also not removed.
> The simple test that shows this behavior is attached.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2680) Terminating running SQL queries
[
https://issues.apache.org/jira/browse/IGNITE-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15302320#comment-15302320
]
Valentin Kulichenko commented on IGNITE-2680:
-
I think we also add an ability to cancel the query automatically after a
configurable timeout.
> Terminating running SQL queries
> ---
>
> Key: IGNITE-2680
> URL: https://issues.apache.org/jira/browse/IGNITE-2680
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
> Labels: important
>
> If to start a long running SQL query over a huge cache will millions of
> entries there should be a way terminate it. Even if {{QueryCursor}} is closed
> the query won't be cancelled consuming available resources.
> There should be a way to close a query having using an object that is related
> to it. Seems that ideally we can use {{QueryCursor.close()}} method for that;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3209) Need to wait for affinity assignment change during affinityCall failover
Valentin Kulichenko created IGNITE-3209:
---
Summary: Need to wait for affinity assignment change during
affinityCall failover
Key: IGNITE-3209
URL: https://issues.apache.org/jira/browse/IGNITE-3209
Project: Ignite
Issue Type: Bug
Components: compute
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Fix For: 1.7
{{AlwaysFailoverSpi.failover()}} method makes several attempts (5 by default)
to get new primary node for the affinity key. Affinity assignment takes time,
so there is a big chance to make all these attempts before new node is returned.
We need to add discovery event that initiated failover to {{FailoverContext}}
and wait for affinity is assigned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects
[
https://issues.apache.org/jira/browse/IGNITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko reassigned IGNITE-3215:
---
Assignee: Valentin Kulichenko
> IgniteRDD should be able to work with BinaryObjects
> ---
>
> Key: IGNITE-3215
> URL: https://issues.apache.org/jira/browse/IGNITE-3215
> Project: Ignite
> Issue Type: Improvement
> Components: Ignite RDD
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to
> {{IgniteCache}}. If set, functions used in methods like {{foreachPartition}}
> will work with {{BinaryObject}} instances instead of deserialized objects.
> Currently if such methods are used, classes are required to be deployed on
> executors' classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3204) java.lang.NoClassDefFoundError: org/h2/constant/SysProperties
[
https://issues.apache.org/jira/browse/IGNITE-3204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15301919#comment-15301919
]
Valentin Kulichenko commented on IGNITE-3204:
-
{{ignite-indexing}} module depends on H2 1.3.175 (see [1]), but you have
1.4.191. Most likely you have it defined separately in your POM (or fetched as
a transitive dependency by something else). Can you check this?
https://github.com/apache/ignite/blob/1.6.0/parent/pom.xml#L72
> java.lang.NoClassDefFoundError: org/h2/constant/SysProperties
> -
>
> Key: IGNITE-3204
> URL: https://issues.apache.org/jira/browse/IGNITE-3204
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.6
>Reporter: kcheng.mvp
>
> Hi All,
> I ran into above issue. here is the error stack
> Caused by: java.lang.NoClassDefFoundError: org/h2/constant/SysProperties
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.start(IgniteH2Indexing.java:1487)
> ~[ignite-indexing-1.6.0.jar:1.6.0]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.start(GridQueryProcessor.java:171)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1549)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:869)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1736)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1589)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1042)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:549)
> ~[ignite-core-1.6.0.jar:1.6.0]
> at org.apache.ignite.IgniteSpring.start(IgniteSpring.java:66)
> ~[ignite-spring-1.6.0.jar:1.6.0]
> at
> org.apache.ignite.IgniteSpringBean.afterPropertiesSet(IgniteSpringBean.java:128)
> ~[ignite-spring-1.6.0.jar:1.6.0]
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1637)
> ~[spring-beans-4.2.6.RELEASE.jar:4.2.6.RELEASE]
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1574)
> ~[spring-beans-4.2.6.RELEASE.jar:4.2.6.RELEASE]
> ... 21 common frames omitted
> Caused by: java.lang.ClassNotFoundException: org.h2.constant.SysProperties
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> ~[na:1.8.0_77]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[na:1.8.0_77]
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> ~[na:1.8.0_77]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[na:1.8.0_77]
> I am using v1.6.0
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
> below is the dependency tree
> [INFO] +- org.apache.ignite:ignite-core:jar:1.6.0:compile
> [INFO] | +- javax.cache:cache-api:jar:1.0.0:compile
> [INFO] | \- org.gridgain:ignite-shmem:jar:1.0.0:compile
> [INFO] +- org.apache.ignite:ignite-spring:jar:1.6.0:compile
> [INFO] | +- org.springframework:spring-core:jar:4.2.6.RELEASE:compile
> [INFO] | +- org.springframework:spring-aop:jar:4.2.6.RELEASE:compile
> [INFO] | | \- aopalliance:aopalliance:jar:1.0:compile
> [INFO] | +- org.springframework:spring-beans:jar:4.2.6.RELEASE:compile
> [INFO] | +- org.springframework:spring-context:jar:4.2.6.RELEASE:compile
> [INFO] | +- org.springframework:spring-expression:jar:4.2.6.RELEASE:compile
> [INFO] | +- org.springframework:spring-tx:jar:4.2.6.RELEASE:compile
> [INFO] | +- org.springframework:spring-jdbc:jar:4.2.6.RELEASE:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] \- org.apache.ignite:ignite-indexing:jar:1.6.0:compile
> [INFO]+- commons-codec:commons-codec:jar:1.6:compile
> [INFO]+- org.apache.lucene:lucene-core:jar:3.5.0:compile
> [INFO]\- com.h2database:h2:jar:1.4.191:compile
> I check there is no org/h2/constant/SysProperties, on the contrary
> there is org.h2.engine.SysProperties
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3230) External addresses are not registered in IP finder
Valentin Kulichenko created IGNITE-3230:
---
Summary: External addresses are not registered in IP finder
Key: IGNITE-3230
URL: https://issues.apache.org/jira/browse/IGNITE-3230
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
If a user configures {{AddressResolver}}, addresses returned by it are not
registered in shared IP finders. So the only way to configure discovery in case
is using static IP finder.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3175) BigDecimal fields are not supported if query is executed from IgniteRDD
[
https://issues.apache.org/jira/browse/IGNITE-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15310895#comment-15310895
]
Valentin Kulichenko commented on IGNITE-3175:
-
I'm reopening the ticket, because looks like {{BigDecimal}} is not the only
unsupported type. The same exception fails at least for {{java.sql.Date}}.
Taras, as you were fixing this, can you please take a look and check what other
types can be problematic?
> BigDecimal fields are not supported if query is executed from IgniteRDD
> ---
>
> Key: IGNITE-3175
> URL: https://issues.apache.org/jira/browse/IGNITE-3175
> Project: Ignite
> Issue Type: Bug
> Components: Ignite RDD
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 1.7
>
>
> If one of the fields participating in the query is {{BigDecimal}}, the query
> will fail when executed from {{IgniteRDD}} with the following error:
> {noformat}
> scala.MatchError: 1124757 (of class java.math.BigDecimal)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:255)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:260)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$StructConverter.toCatalystImpl(CatalystTypeConverters.scala:250)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$CatalystTypeConverter.toCatalyst(CatalystTypeConverters.scala:102)
> at
> org.apache.spark.sql.catalyst.CatalystTypeConverters$$anonfun$createToCatalystConverter$2.apply(CatalystTypeConverters.scala:401)
> at
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
> at
> org.apache.spark.sql.SQLContext$$anonfun$6.apply(SQLContext.scala:492)
> at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.processInputs(TungstenAggregationIterator.scala:505)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregationIterator.(TungstenAggregationIterator.scala:686)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:95)
> at
> org.apache.spark.sql.execution.aggregate.TungstenAggregate$$anonfun$doExecute$1$$anonfun$2.apply(TungstenAggregate.scala:86)
> at
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
> at
> org.apache.spark.rdd.RDD$$anonfun$mapPartitions$1$$anonfun$apply$20.apply(RDD.scala:710)
> at
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at
> org.apache.spark.rdd.MapPartitionsRDD.compute(MapPartitionsRDD.scala:38)
> at org.apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:306)
> at org.apache.spark.rdd.RDD.iterator(RDD.scala:270)
> at
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:73)
> at
> org.apache.spark.scheduler.ShuffleMapTask.runTask(ShuffleMapTask.scala:41)
> at org.apache.spark.scheduler.Task.run(Task.scala:89)
> at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Most likely this is caused by the fact that {{IgniteRDD.dataType()}} method
> doesn't honor {{BigDecimal}} and returns {{StructType}} by default. We should
> fix this and check other possible types as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
[
https://issues.apache.org/jira/browse/IGNITE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306883#comment-15306883
]
Valentin Kulichenko commented on IGNITE-3153:
-
Thanks, Roman! I added the trace.
> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP
> finder is used. Most likely this is caused by the fact that {{initGuard}} is
> flipped back to {{false}} when the context is destroyed and new curator
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
> {noformat}
> 2016-05-16 12:00:59,096 5786 ERROR
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught
> during grid runnable execution: IgniteSpiThread
> [name=tcp-client-disco-reconnector-#5%Default%]
> java.lang.IllegalStateException: Cannot be started more than once
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
> ...
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
[
https://issues.apache.org/jira/browse/IGNITE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko reassigned IGNITE-3153:
---
Assignee: Valentin Kulichenko
> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP
> finder is used. Most likely this is caused by the fact that {{initGuard}} is
> flipped back to {{false}} when the context is destroyed and new curator
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3216) Need to deduplicate addresses registered in the IP finder
Valentin Kulichenko created IGNITE-3216:
---
Summary: Need to deduplicate addresses registered in the IP finder
Key: IGNITE-3216
URL: https://issues.apache.org/jira/browse/IGNITE-3216
Project: Ignite
Issue Type: Bug
Components: general
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
{{IgniteUtils.toSocketAddresses(...)}} method can produce the collection with
duplicated addresses in some cases (e.g., if one of hostnames is provided as an
IP). We should deduplicate the list before returning it (most likely we should
simply use {{Set}} instead).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects
Valentin Kulichenko created IGNITE-3215:
---
Summary: IgniteRDD should be able to work with BinaryObjects
Key: IGNITE-3215
URL: https://issues.apache.org/jira/browse/IGNITE-3215
Project: Ignite
Issue Type: Improvement
Components: Ignite RDD
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Fix For: 1.7
Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to
{{IgniteCache}}. If set, functions used in methods like {{foreachPartition}}
will work with {{BinaryObject}} instances instead of deserialized objects.
Currently if such methods are used, classes are required to be deployed on
executors' classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-3153) TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
[
https://issues.apache.org/jira/browse/IGNITE-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-3153:
Description:
The exception below is possible when client reconnects and ZooKeeper IP finder
is used. Most likely this is caused by the fact that {{initGuard}} is flipped
back to {{false}} when the context is destroyed and new curator instance is not
created during the reconnect.
This should be fixed and test coverage for this scenario should be improved.
{noformat}
2016-05-16 12:00:59,096 5786 ERROR
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught during
grid runnable execution: IgniteSpiThread
[name=tcp-client-disco-reconnector-#5%Default%]
java.lang.IllegalStateException: Cannot be started more than once
at
org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
...
at
org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
at
org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
at
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
at
org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{noformat}
was:
The exception below is possible when client reconnects and ZooKeeper IP finder
is used. Most likely this is caused by the fact that {{initGuard}} is flipped
back to {{false}} when the context is destroyed and new curator instance is not
created during the reconnect.
This should be fixed and test coverage for this scenario should be improved.
> TcpDiscoveryZookeeperIpFinder doesn't properly handle client reconnections
> --
>
> Key: IGNITE-3153
> URL: https://issues.apache.org/jira/browse/IGNITE-3153
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 1.5.0.final
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> The exception below is possible when client reconnects and ZooKeeper IP
> finder is used. Most likely this is caused by the fact that {{initGuard}} is
> flipped back to {{false}} when the context is destroyed and new curator
> instance is not created during the reconnect.
> This should be fixed and test coverage for this scenario should be improved.
> {noformat}
> 2016-05-16 12:00:59,096 5786 ERROR
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi Runtime error caught
> during grid runnable execution: IgniteSpiThread
> [name=tcp-client-disco-reconnector-#5%Default%]
> java.lang.IllegalStateException: Cannot be started more than once
> at
> org.apache.curator.framework.imps.CuratorFrameworkImpl.start(CuratorFrameworkImpl.java:237)
> ...
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.init(TcpDiscoveryZookeeperIpFinder.java:144)
> at
> org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder.getRegisteredAddresses(TcpDiscoveryZookeeperIpFinder.java:169)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:1603)
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1552)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.joinTopology(ClientImpl.java:475)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl.access$900(ClientImpl.java:118)
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$Reconnector.body(ClientImpl.java:1175)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15102489#comment-15102489
]
Valentin Kulichenko commented on IGNITE-2394:
-
Described solution will break data loading for local cache created on client
(test attached). I think we should treat local cache as a special case and just
invoke the {{CacheStore}} only locally, regardless of whether it's a server or
client.
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Denis Magda
>Priority: Critical
> Labels: newbie
> Fix For: 1.6
>
> Attachments: LocalLoadTest.java
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2394:
Attachment: LocalLoadTest.java
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5
>Reporter: Denis Magda
>Priority: Critical
> Labels: newbie
> Fix For: 1.6
>
> Attachments: LocalLoadTest.java
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2375) Expiration is not set when value is loaded from store
Valentin Kulichenko created IGNITE-2375: --- Summary: Expiration is not set when value is loaded from store Key: IGNITE-2375 URL: https://issues.apache.org/jira/browse/IGNITE-2375 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: 1.6 Discussed on the user@ forum: http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html Test reproducing the issue is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2374) Expiration is not set when value is loaded from store
Valentin Kulichenko created IGNITE-2374: --- Summary: Expiration is not set when value is loaded from store Key: IGNITE-2374 URL: https://issues.apache.org/jira/browse/IGNITE-2374 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Fix For: 1.6 Discussed on the user@ forum: http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html Test reproducing the issue is attached -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2375) Expiration is not set when value is loaded from store
[ https://issues.apache.org/jira/browse/IGNITE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2375: Attachment: ExpireTest.java > Expiration is not set when value is loaded from store > - > > Key: IGNITE-2375 > URL: https://issues.apache.org/jira/browse/IGNITE-2375 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko > Fix For: 1.6 > > Attachments: ExpireTest.java > > > Discussed on the user@ forum: > http://apache-ignite-users.70518.x6.nabble.com/Cache-read-through-with-expiry-policy-td2521.html > Test reproducing the issue is attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2384) Notification missed in continuous query
[ https://issues.apache.org/jira/browse/IGNITE-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Kulichenko updated IGNITE-2384: Attachment: ListenerTest.java > Notification missed in continuous query > --- > > Key: IGNITE-2384 > URL: https://issues.apache.org/jira/browse/IGNITE-2384 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Valentin Kulichenko >Priority: Critical > Fix For: 1.6 > > Attachments: ListenerTest.java > > > Test reproducing the issue is attached, fails on assertion on line 76. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2384) Notification missed in continuous query
Valentin Kulichenko created IGNITE-2384: --- Summary: Notification missed in continuous query Key: IGNITE-2384 URL: https://issues.apache.org/jira/browse/IGNITE-2384 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Priority: Critical Fix For: 1.6 Test reproducing the issue is attached, fails on assertion on line 76. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2386) affinityCall() execution hangs
Valentin Kulichenko created IGNITE-2386:
---
Summary: affinityCall() execution hangs
Key: IGNITE-2386
URL: https://issues.apache.org/jira/browse/IGNITE-2386
Project: Ignite
Issue Type: Bug
Components: cache
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
Test reproducing the issue is attached. affinityCall() invocation hangs with
the following trace:
{code}
"main" prio=5 tid=0x7f8b1b001800 nid=0x1703 waiting on condition
[0x70218000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0007ab170eb8> (a
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture)
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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:477)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:435)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.assignments(GridAffinityAssignmentCache.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignments(GridCacheAffinityManager.java:159)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:333)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityKey(GridAffinityProcessor.java:238)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.affinityCall(GridClosureProcessor.java:442)
at
org.apache.ignite.internal.IgniteComputeImpl.affinityCall(IgniteComputeImpl.java:130)
at AffinityTest.main(AffinityTest.java:42)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2386) affinityCall() execution hangs
[
https://issues.apache.org/jira/browse/IGNITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2386:
Description:
Test reproducing the issue is attached. affinityCall() invocation hangs with
the following trace:
{noformat}
"main" prio=5 tid=0x7f8b1b001800 nid=0x1703 waiting on condition
[0x70218000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0007ab170eb8> (a
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture)
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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:477)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:435)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.assignments(GridAffinityAssignmentCache.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignments(GridCacheAffinityManager.java:159)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:333)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityKey(GridAffinityProcessor.java:238)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.affinityCall(GridClosureProcessor.java:442)
at
org.apache.ignite.internal.IgniteComputeImpl.affinityCall(IgniteComputeImpl.java:130)
at AffinityTest.main(AffinityTest.java:42)
{noformat}
was:
Test reproducing the issue is attached. affinityCall() invocation hangs with
the following trace:
{code}
"main" prio=5 tid=0x7f8b1b001800 nid=0x1703 waiting on condition
[0x70218000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0007ab170eb8> (a
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture)
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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:477)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:435)
at
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.assignments(GridAffinityAssignmentCache.java:306)
at
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignments(GridCacheAffinityManager.java:159)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:333)
at
org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityKey(GridAffinityProcessor.java:238)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor.affinityCall(GridClosureProcessor.java:442)
at
org.apache.ignite.internal.IgniteComputeImpl.affinityCall(IgniteComputeImpl.java:130)
at AffinityTest.main(AffinityTest.java:42)
{code}
> affinityCall() execution hangs
> --
>
> Key: IGNITE-2386
> URL: https://issues.apache.org/jira/browse/IGNITE-2386
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
[jira] [Updated] (IGNITE-2386) affinityCall() execution hangs
[
https://issues.apache.org/jira/browse/IGNITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2386:
Flags: Important
> affinityCall() execution hangs
> --
>
> Key: IGNITE-2386
> URL: https://issues.apache.org/jira/browse/IGNITE-2386
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
>
> Test reproducing the issue is attached. affinityCall() invocation hangs with
> the following trace:
> {code}
> "main" prio=5 tid=0x7f8b1b001800 nid=0x1703 waiting on condition
> [0x70218000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007ab170eb8> (a
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture)
> 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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:477)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:435)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.assignments(GridAffinityAssignmentCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignments(GridCacheAffinityManager.java:159)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:333)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityKey(GridAffinityProcessor.java:238)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.affinityCall(GridClosureProcessor.java:442)
> at
> org.apache.ignite.internal.IgniteComputeImpl.affinityCall(IgniteComputeImpl.java:130)
> at AffinityTest.main(AffinityTest.java:42)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2386) affinityCall() execution hangs
[
https://issues.apache.org/jira/browse/IGNITE-2386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2386:
Attachment: AffinityTest.java
> affinityCall() execution hangs
> --
>
> Key: IGNITE-2386
> URL: https://issues.apache.org/jira/browse/IGNITE-2386
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
> Attachments: AffinityTest.java
>
>
> Test reproducing the issue is attached. affinityCall() invocation hangs with
> the following trace:
> {noformat}
> "main" prio=5 tid=0x7f8b1b001800 nid=0x1703 waiting on condition
> [0x70218000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007ab170eb8> (a
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache$AffinityReadyFuture)
> 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.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:115)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.awaitTopologyVersion(GridAffinityAssignmentCache.java:477)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:435)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.assignments(GridAffinityAssignmentCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.assignments(GridCacheAffinityManager.java:159)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityCache(GridAffinityProcessor.java:333)
> at
> org.apache.ignite.internal.processors.affinity.GridAffinityProcessor.affinityKey(GridAffinityProcessor.java:238)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor.affinityCall(GridClosureProcessor.java:442)
> at
> org.apache.ignite.internal.IgniteComputeImpl.affinityCall(IgniteComputeImpl.java:130)
> at AffinityTest.main(AffinityTest.java:42)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2389) Need to add ability to swap the queue if it's too long
Valentin Kulichenko created IGNITE-2389:
---
Summary: Need to add ability to swap the queue if it's too long
Key: IGNITE-2389
URL: https://issues.apache.org/jira/browse/IGNITE-2389
Project: Ignite
Issue Type: Improvement
Components: data structures
Reporter: Valentin Kulichenko
Fix For: 1.6
In some cases there can be a requirement to start swapping new queue elements
to avoid out of memory errors. For example, if the consumer temporarily stopped
for some reason, but the producer still adds elements.
We can do this based on cache swap space and evictions. I think we should:
# Add max allowed in-memory elements property to {{CollectionConfiguration}}.
We can also support limit by memory size.
# Implement special eviction policy that will evict new queue elements if
limits are reached.
# Automatically unswap latest elements when consumer resumes polling (can be
achieved by a background process).
In case of {{IgniteSet}}, limits should be also honored, but here we don't have
ordering. So I think we can use our standard LRU, but make sure that only
elements are swapped. Header and other meta objects should be always in memory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2383) Non-string system properties should be ignored in node attributes and update checker
Valentin Kulichenko created IGNITE-2383:
---
Summary: Non-string system properties should be ignored in node
attributes and update checker
Key: IGNITE-2383
URL: https://issues.apache.org/jira/browse/IGNITE-2383
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
user@ discussion:
http://apache-ignite-users.70518.x6.nabble.com/Ignite-quot-bugs-quot-td2534.html
Some frameworks can put non-string and/or non-serializable values into system
properties. We should ignore them in
{{GridUpdateNotifier.getSystemProperties()}} method and when adding properties
to node attributes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects
[
https://issues.apache.org/jira/browse/IGNITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-3215.
---
> IgniteRDD should be able to work with BinaryObjects
> ---
>
> Key: IGNITE-3215
> URL: https://issues.apache.org/jira/browse/IGNITE-3215
> Project: Ignite
> Issue Type: Improvement
> Components: Ignite RDD
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to
> {{IgniteCache}}. If set, functions used in methods like {{foreachPartition}}
> will work with {{BinaryObject}} instances instead of deserialized objects.
> Currently if such methods are used, classes are required to be deployed on
> executors' classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3215) IgniteRDD should be able to work with BinaryObjects
[
https://issues.apache.org/jira/browse/IGNITE-3215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15335879#comment-15335879
]
Valentin Kulichenko commented on IGNITE-3215:
-
Merged to master.
> IgniteRDD should be able to work with BinaryObjects
> ---
>
> Key: IGNITE-3215
> URL: https://issues.apache.org/jira/browse/IGNITE-3215
> Project: Ignite
> Issue Type: Improvement
> Components: Ignite RDD
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> Need to add {{withKeepBinary}} flag to {{IgniteRDD}}, similar to
> {{IgniteCache}}. If set, functions used in methods like {{foreachPartition}}
> will work with {{BinaryObject}} instances instead of deserialized objects.
> Currently if such methods are used, classes are required to be deployed on
> executors' classpath.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3334) TcpDiscoveryZookeeperIpFinder uses INFO logging without isInfoEnabled() check
Valentin Kulichenko created IGNITE-3334:
---
Summary: TcpDiscoveryZookeeperIpFinder uses INFO logging without
isInfoEnabled() check
Key: IGNITE-3334
URL: https://issues.apache.org/jira/browse/IGNITE-3334
Project: Ignite
Issue Type: Bug
Components: ignite-zookeeper
Affects Versions: 1.6
Reporter: Valentin Kulichenko
Assignee: Valentin Kulichenko
Fix For: 1.7
This leads to the warnings in case INFO is disabled:
{noformat}
[org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder]
Logging at INFO level without checking if INFO level is enabled
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IGNITE-3334) TcpDiscoveryZookeeperIpFinder uses INFO logging without isInfoEnabled() check
[
https://issues.apache.org/jira/browse/IGNITE-3334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-3334.
-
Resolution: Fixed
Fixed in master.
> TcpDiscoveryZookeeperIpFinder uses INFO logging without isInfoEnabled() check
> -
>
> Key: IGNITE-3334
> URL: https://issues.apache.org/jira/browse/IGNITE-3334
> Project: Ignite
> Issue Type: Bug
> Components: ignite-zookeeper
>Affects Versions: 1.6
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
> Fix For: 1.7
>
>
> This leads to the warnings in case INFO is disabled:
> {noformat}
> [org.apache.ignite.spi.discovery.tcp.ipfinder.zk.TcpDiscoveryZookeeperIpFinder]
> Logging at INFO level without checking if INFO level is enabled
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1144) Need to have a capability to run a closure collocated with a queue/set
[
https://issues.apache.org/jira/browse/IGNITE-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15141459#comment-15141459
]
Valentin Kulichenko commented on IGNITE-1144:
-
Yes, my bad. You can disregard the comment about {{CU.outTx}}.
> Need to have a capability to run a closure collocated with a queue/set
> --
>
> Key: IGNITE-1144
> URL: https://issues.apache.org/jira/browse/IGNITE-1144
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Oddo
>Priority: Critical
>
> Currently there is no way to do this since all collocated queues and sets are
> stored in special system cache. This makes {{affinityRun()}} and
> {{affinityCall()}} methods useless because it requires to explicitly provide
> cache name which user doesn't know in this case.
> I suggest to add {{affinityRun()}} and {{affinityCall()}} methods on
> {{IgniteQueue}} and {{IgniteSet}}. They will:
> * take only closure as a parameter
> * throw exception for non-collocated mode
> * properly delegate to sibling methods in {{Ignite}} with proper cache name
> Alternatively we can add these methods on {{Ignite}} interface, which is more
> consistent with the current API. But I'm not sure how to call them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1144) Need to have a capability to run a closure collocated with a queue/set
[
https://issues.apache.org/jira/browse/IGNITE-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133115#comment-15133115
]
Valentin Kulichenko commented on IGNITE-1144:
-
Hi Oddo.
I reviewed your changes. Looks like you're making progress, but I have several
comments:
* Code after your changes can't be compiled against Java7 (looks like you're
working with Java8). Please make sure it compiles with both 7 and 8.
* Can you explain {{CU.outTx}} calls in {{GridCacheQueueProxy}} and
{{GridCacheSetProxy}}? You execute closure twice for transactional caches which
is obviously wrong. Actually, proxy should only block the gateway and delegate,
all other code should be in corresponding implementation classes. Anyway, most
likely taht these pieces of code should be removed.
* Since you added async methods annotated with {{@IgniteAsyncSupported}}, you
should also implement {{IgniteAsyncSupport}} interface. Currently there is no
way to execute these operations asynchronously.
* You should improve test coverage. Couple of tests you added check almost
nothing, they don't even have a single assertion. Moreover, they fail. Please
don't forget to run TC before submitting a patch.
I would also rephrase the error message and mention the data structure name
there. Smth like this:
{code}
throw new IgniteException("Failed to execute affinityCall() for non-collocated
set: " + name +
". This operation is supported only for collocated sets.");
{code}
Thanks!
> Need to have a capability to run a closure collocated with a queue/set
> --
>
> Key: IGNITE-1144
> URL: https://issues.apache.org/jira/browse/IGNITE-1144
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Oddo
>Priority: Critical
>
> Currently there is no way to do this since all collocated queues and sets are
> stored in special system cache. This makes {{affinityRun()}} and
> {{affinityCall()}} methods useless because it requires to explicitly provide
> cache name which user doesn't know in this case.
> I suggest to add {{affinityRun()}} and {{affinityCall()}} methods on
> {{IgniteQueue}} and {{IgniteSet}}. They will:
> * take only closure as a parameter
> * throw exception for non-collocated mode
> * properly delegate to sibling methods in {{Ignite}} with proper cache name
> Alternatively we can add these methods on {{Ignite}} interface, which is more
> consistent with the current API. But I'm not sure how to call them.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2592) Aggregation query with subquery returns incorrect result
Valentin Kulichenko created IGNITE-2592: --- Summary: Aggregation query with subquery returns incorrect result Key: IGNITE-2592 URL: https://issues.apache.org/jira/browse/IGNITE-2592 Project: Ignite Issue Type: Bug Components: cache Reporter: Valentin Kulichenko Priority: Critical Fix For: 1.6 Issue is discussed here: http://apache-ignite-users.70518.x6.nabble.com/SQL-query-result-variation-td2889.html Here is the code that reproduces it: https://gist.github.com/anonymous/8e2af218598e46577b2a -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-2594) Cached web session requires setAttribute() to be called on each update
Valentin Kulichenko created IGNITE-2594: --- Summary: Cached web session requires setAttribute() to be called on each update Key: IGNITE-2594 URL: https://issues.apache.org/jira/browse/IGNITE-2594 Project: Ignite Issue Type: Bug Components: general Reporter: Valentin Kulichenko Assignee: Valentin Kulichenko Fix For: 1.6 Issue is described here: http://stackoverflow.com/questions/35268184/updating-apache-ignite-websession-attributes -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko resolved IGNITE-1523.
-
Resolution: Fixed
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: important, user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133189#comment-15133189
]
Valentin Kulichenko commented on IGNITE-1523:
-
Looks like setting correct class loader is enough, currently there is no need
to rework the code. Closing the ticket.
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: important, user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-1523) Need to always serialize user objects with configured marshaller
[
https://issues.apache.org/jira/browse/IGNITE-1523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko closed IGNITE-1523.
---
> Need to always serialize user objects with configured marshaller
>
>
> Key: IGNITE-1523
> URL: https://issues.apache.org/jira/browse/IGNITE-1523
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Valentin Kulichenko
>Priority: Critical
> Labels: important, user-request
> Fix For: 1.6
>
>
> Currently some components (at least discovery) use {{JdkMarshaller}} for all
> objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2559) Transaction hangs if entry processor is not serializable
Valentin Kulichenko created IGNITE-2559:
---
Summary: Transaction hangs if entry processor is not serializable
Key: IGNITE-2559
URL: https://issues.apache.org/jira/browse/IGNITE-2559
Project: Ignite
Issue Type: Bug
Reporter: Valentin Kulichenko
Priority: Critical
Fix For: 1.6
Test attached. If entry processor doesn't implement {{Serializable}}, the
exception is thrown, but transaction hangs forever.
Hanged thread dump:
{noformat}
"main" #1 prio=5 os_prio=31 tid=0x7faf8380 nid=0x1703 waiting on
condition [0x70218000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x00076b1e75f0> (a
org.apache.ignite.internal.util.future.GridEmbeddedFuture)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$24.op(GridCacheAdapter.java:2296)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter$24.op(GridCacheAdapter.java:2283)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4291)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2283)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2261)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1518)
at ScratchClient.main(ScratchClient.java:29)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-2558) NearCacheConfiguration should not extend MutableConfiguration
Valentin Kulichenko created IGNITE-2558:
---
Summary: NearCacheConfiguration should not extend
MutableConfiguration
Key: IGNITE-2558
URL: https://issues.apache.org/jira/browse/IGNITE-2558
Project: Ignite
Issue Type: Improvement
Components: cache
Reporter: Valentin Kulichenko
Fix For: 1.6
Currently {{NearCacheConfiguration}} extends {{MutableConfiguration}} which
means that it inherits all the properties that don't make sense for it. Also
it's possible to use it to create a cache with {{CacheManager}}, which is also
confusing.
{{NearCacheConfiguration}} should not extend and classes and should be used
only directly in {{CacheConfiguration.setNearConfiguration()}} or
{{Ignite.createCache()}} and similar methods.
In addition, it would be useful to add {{setCopyOnRead}} property for near
cache. Now it's not possible to control this behavior for near cache only.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2559) Transaction hangs if entry processor is not serializable
[
https://issues.apache.org/jira/browse/IGNITE-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Kulichenko updated IGNITE-2559:
Attachment: TxTest.java
> Transaction hangs if entry processor is not serializable
>
>
> Key: IGNITE-2559
> URL: https://issues.apache.org/jira/browse/IGNITE-2559
> Project: Ignite
> Issue Type: Bug
>Reporter: Valentin Kulichenko
>Priority: Critical
> Fix For: 1.6
>
> Attachments: TxTest.java
>
>
> Test attached.
> If entry processor doesn't implement {{Serializable}}, the exception is
> thrown, but transaction hangs forever. If you try to join more nodes after
> this happens, they will not be able to do this as well.
> Hanged thread dump:
> {noformat}
> "main" #1 prio=5 os_prio=31 tid=0x7f8b6580 nid=0x1703 waiting on
> condition [0x70218000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00076ca274f8> (a
> org.apache.ignite.internal.util.future.GridEmbeddedFuture)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:157)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:117)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$24.op(GridCacheAdapter.java:2296)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter$24.op(GridCacheAdapter.java:2283)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4291)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke0(GridCacheAdapter.java:2283)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.invoke(GridCacheAdapter.java:2261)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxy.invoke(IgniteCacheProxy.java:1518)
> at TxTest.main(TxTest.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:483)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
