[jira] [Updated] (IGNITE-6437) DataStructure can not be obtained on client if it is created on server node.
[ https://issues.apache.org/jira/browse/IGNITE-6437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-6437: --- Affects Version/s: 2.3 Fix Version/s: 2.4 > DataStructure can not be obtained on client if it is created on server node. > > > Key: IGNITE-6437 > URL: https://issues.apache.org/jira/browse/IGNITE-6437 > Project: Ignite > Issue Type: Bug > Components: data structures >Affects Versions: 2.1, 2.3 >Reporter: Mikhail Cherkasov >Assignee: Alexey Goncharuk >Priority: Critical > Fix For: 2.4 > > Attachments: NoQueueOnClientNodeTest.java, tc_111.png > > > DataStructure can not be obtained on client if it is created on server node. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6840) SQL: Parser: support CREATE INDEX command
Vladimir Ozerov created IGNITE-6840: --- Summary: SQL: Parser: support CREATE INDEX command Key: IGNITE-6840 URL: https://issues.apache.org/jira/browse/IGNITE-6840 Project: Ignite Issue Type: Task Security Level: Public (Viewable by anyone) Components: sql Reporter: Vladimir Ozerov Assignee: Vladimir Ozerov Fix For: 2.4 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6833) Web Console: runtime errors after each SCSS save
[ https://issues.apache.org/jira/browse/IGNITE-6833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-6833: - Assignee: Ilya Borisov (was: Alexander Kalinin) The problem with incremental sass compilation was solved by updating dependencies version. Please review > Web Console: runtime errors after each SCSS save > > > Key: IGNITE-6833 > URL: https://issues.apache.org/jira/browse/IGNITE-6833 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: wizards > Environment: Windows 10, MacOS, master branch >Reporter: Ilya Borisov >Assignee: Ilya Borisov > Attachments: screenshot-1.png > > > *What happens:* > Web console frontend throws runtime errors after every SCSS file save. You > have to save any non-stylesheet file to fix the error. > *How to reproduce:* > 1. Checkout master. > 2. Start frontend development environment. > 3. Save any SCSS file, no changes necessary. > 4. Open local web console, open browser console, see the error. > *Expected behavior:* > No errors should happen after SCSS file saves. > *Note:* > I had a hand at this earlier: the error always mentions missing global > dependency of some sort (i.e. _.head). If you replace all implicit lodash > uses with explicit imports in every file, error eventually starts to point at > polyfills (i.e. RegExp.esacpe). Maybe this will be of help, I did not > progress any further. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5635) Web Console: Show query execution progress
[ https://issues.apache.org/jira/browse/IGNITE-5635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-5635: - Assignee: Pavel Konstantinov (was: Alexander Kalinin) Please test indication of progress in export\export all buttons > Web Console: Show query execution progress > -- > > Key: IGNITE-5635 > URL: https://issues.apache.org/jira/browse/IGNITE-5635 > Project: Ignite > Issue Type: Task > Components: wizards >Reporter: Alexey Kuznetsov >Assignee: Pavel Konstantinov > > Show query execution progress, some progress or spinning wheel. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6737) GridDeploymentPerVersionStore retries loading class infinitely
[
https://issues.apache.org/jira/browse/IGNITE-6737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243512#comment-16243512
]
ASF GitHub Bot commented on IGNITE-6737:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2934
> GridDeploymentPerVersionStore retries loading class infinitely
> --
>
> Key: IGNITE-6737
> URL: https://issues.apache.org/jira/browse/IGNITE-6737
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Reporter: Vladislav Pyatkov
> Fix For: 2.4
>
>
> {noformat}
> 2017-10-24 14:34:06 [DEBUG]
> [org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore]
> [pub-#5258%DPL_GRID%DplGridNodeName%] - Deployment meta for local deployment:
> GridDeploymentMetadata [depMode=SHARED,
> alias=com.sbt.bgp.task.AffinityApplicationTaskCallable,
> clsName=com.sbt.bgp.task.AffinityApplicationTaskCallable, userVer=null,
> sndNodeId=1b852edd-1f41-4489-af78-dbe8226a9b16, clsLdrId=null, clsLdr=null,
> participants=null, parentLdr=null, record=true, nodeFilter=null, seqNum=n/a]
> 2017-10-24 14:34:06 [DEBUG]
> [org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore]
> [pub-#5258%DPL_GRID%DplGridNodeName%] - Failed to load class for local
> auto-deployment
> [ldr=grid:com.sbt.core.envelope.container.FileClassLoader@3e4327dc,
> meta=GridDeploymentMetadata [depMode=SHARED,
> alias=com.sbt.bgp.task.AffinityApplicationTaskCallable,
> clsName=com.sbt.bgp.task.AffinityApplicationTaskCallable, userVer=null,
> sndNodeId=1b852edd-1f41-4489-af78-dbe8226a9b16, clsLdrId=null, clsLdr=null,
> participants=null, parentLdr=null, record=true, nodeFilter=null, seqNum=n/a]]
> 2017-10-24 14:34:06 [DEBUG]
> [org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore]
> [pub-#5258%DPL_GRID%DplGridNodeName%] - Deployment cannot be reused (class
> does not exist on participating nodes) [dep=SharedDeployment [rmv=false,
> super=GridDeployment [ts=1508810401226, depMode=SHARED,
> clsLdr=GridDeploymentClassLoader
> [id=7953e0c4f51-1b852edd-1f41-4489-af78-dbe8226a9b16, singleNode=false,
> nodeLdrMap={bc5a1eaa-e056-4bd8-b7d3-684e75522b81=373cd8c4f51-bc5a1eaa-e056-4bd8-b7d3-684e75522b81,
>
> 3018f0bb-7c94-410e-9a0f-028c3fbc8aab=a5b822c4f51-3018f0bb-7c94-410e-9a0f-028c3fbc8aab,
>
> f1774f8d-84e9-43c3-86a3-d7a47c291f45=afd441c4f51-f1774f8d-84e9-43c3-86a3-d7a47c291f45,
>
> 5a0b56e8-a8ae-4742-834c-d688592866c4=a6e985c4f51-5a0b56e8-a8ae-4742-834c-d688592866c4,
>
> 65fdae9e-78c7-49a2-b9ee-a8e99dbb87ea=bcd257c4f51-65fdae9e-78c7-49a2-b9ee-a8e99dbb87ea,
>
> 045ddd4d-3e39-4b25-bf52-c264f59efbc6=e6ec81c4f51-045ddd4d-3e39-4b25-bf52-c264f59efbc6,
>
> afadbbce-542d-435c-b85a-78d395b463a5=967664c4f51-afadbbce-542d-435c-b85a-78d395b463a5,
>
> 4b2662e9-d525-4d96-936c-8cc645464e65=591541c4f51-4b2662e9-d525-4d96-936c-8cc645464e65},
> p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
> clsLdrId=7953e0c4f51-1b852edd-1f41-4489-af78-dbe8226a9b16, userVer=0,
> loc=false,
> sampleClsName=com.sbt.fea_cc.services.business.autoStopTurnkeySettings.AutoStopTurnkeySettingsService$FindOrderTurnkeyForSuspend,
> pendingUndeploy=false, undeployed=false, usage=0]],
> meta=GridDeploymentMetadata [depMode=SHARED,
> alias=com.sbt.bgp.task.AffinityApplicationTaskCallable,
> clsName=com.sbt.bgp.task.AffinityApplicationTaskCallable, userVer=0,
> sndNodeId=4457016c-5f93-450f-b2a7-86bd25f536cf,
> clsLdrId=898962c4f51-4457016c-5f93-450f-b2a7-86bd25f536cf, clsLdr=null,
> participants=null, parentLdr=null, record=true, nodeFilter=null,
> seqNum=150888744]]
> 2017-10-24 14:34:06 [DEBUG]
> [org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore]
> [pub-#5258%DPL_GRID%DplGridNodeName%] - Deployment cannot be reused (random
> class could not be loaded from sender node) [dep=SharedDeployment [rmv=false,
> super=GridDeployment [ts=1508810401226, depMode=SHARED,
> clsLdr=GridDeploymentClassLoader
> [id=7953e0c4f51-1b852edd-1f41-4489-af78-dbe8226a9b16, singleNode=false,
> nodeLdrMap={bc5a1eaa-e056-4bd8-b7d3-684e75522b81=373cd8c4f51-bc5a1eaa-e056-4bd8-b7d3-684e75522b81,
>
> 3018f0bb-7c94-410e-9a0f-028c3fbc8aab=a5b822c4f51-3018f0bb-7c94-410e-9a0f-028c3fbc8aab,
>
> f1774f8d-84e9-43c3-86a3-d7a47c291f45=afd441c4f51-f1774f8d-84e9-43c3-86a3-d7a47c291f45,
>
> 5a0b56e8-a8ae-4742-834c-d688592866c4=a6e985c4f51-5a0b56e8-a8ae-4742-834c-d688592866c4,
>
> 65fdae9e-78c7-49a2-b9ee-a8e99dbb87ea=bcd257c4f51-65fdae9e-78c7-49a2-b9ee-a8e99dbb87ea,
>
> 045ddd4d-3e39-4b25-bf52-c264f59efbc6=e6ec81c4f51-045ddd4d-3e39-4b25-bf52-c264f59efbc6,
>
> afadbbce-542d-435c-b85a-78d395b463a5=967664c4f51-afadbbce-542d-435c-b85a-78d395b463a5,
>
> 4b2662e9-d525-4d96-936c-8cc645464e65=5915
[jira] [Resolved] (IGNITE-4806) Infinite classLoading discovery process
[
https://issues.apache.org/jira/browse/IGNITE-4806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny resolved IGNITE-4806.
Resolution: Duplicate
> Infinite classLoading discovery process
> ---
>
> Key: IGNITE-4806
> URL: https://issues.apache.org/jira/browse/IGNITE-4806
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 1.8
>Reporter: Stanilovsky Evgeny
>Assignee: Alexei Scherbakov
>Priority: Minor
> Attachments: reproduce.tar.gz
>
>
> Hello, i found infinite discovery class loading after very rare usage case.
> In a nutshell to reproduce we need to run sequentially 3 different jvm
> instances.
> FirstNode instance simple start the grid.
> SecondNode connect to grid, initialize custom classLoader, and run
> IgniteCallable (JobA) wrapped into ComputeTask instance.
> ThirdNode connect to grid, initialize custom classLoader, and run two
> IgniteCallable (JobB, jobB2) wrapped into ComputeTask instances.
> Finally we can observe JobA has been running in First and Second nodes, JobB
> has been running in First, Second and Third nodes, while jobB2 starts
> infinite class loading. We could see it simply looking into First Node thread
> dump:
> {code}
> "pub-#69%grid%" prio=10 tid=0x7f9218015800 nid=0x3de5 runnable
> [0x7f9254176000]
>java.lang.Thread.State: RUNNABLE
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Throwable.java:783)
> - locked <0x0007d43ced00> (a java.lang.ClassNotFoundException)
> at java.lang.Throwable.(Throwable.java:287)
> at java.lang.Exception.(Exception.java:84)
> at
> java.lang.ReflectiveOperationException.(ReflectiveOperationException.java:75)
> at
> java.lang.ClassNotFoundException.(ClassNotFoundException.java:82)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> - locked <0x00070c22fd08> (a java.lang.Object)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentLocalStore.getDeployment(GridDeploymentLocalStore.java:191)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getLocalDeployment(GridDeploymentManager.java:383)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.findClass(GridDeploymentClassLoader.java:497)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
> - locked <0x00070c0361e0> (a
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.loadClass(GridDeploymentClassLoader.java:441)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:278)
> at
> org.apache.ignite.internal.managers.deployment.GridDeployment.deployedClass(GridDeployment.java:444)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:454)
> at
> org.apache.ignite.internal.managers.deployment.GridDeploymentManager.getGlobalDeployment(GridDeploymentManager.java:494)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:982)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1894)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:710)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1700(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:673)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5955) Ignite Continuous Query (Queries 3): IgniteCacheContinuousQueryClientReconnectTest fails
[
https://issues.apache.org/jira/browse/IGNITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243544#comment-16243544
]
Sergey Chugunov commented on IGNITE-5955:
-
[~zstan], proposed change looks reasonable to me.
It seems that corner case with disconnected client wasn't addressed in test
framework when cluster activation functionality was refactored.
> Ignite Continuous Query (Queries 3):
> IgniteCacheContinuousQueryClientReconnectTest fails
>
>
> Key: IGNITE-5955
> URL: https://issues.apache.org/jira/browse/IGNITE-5955
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
> Labels: MakeTeamcityGreenAgain, test-failure
>
> Reproducible locally with the same exception as on TC.
> In test log there is the following exception:
> {noformat}
> [2017-08-07
> 03:24:05,694][ERROR][test-runner-#10587%continuous.IgniteCacheContinuousQueryClientReconnectTest%][root]
> Failed to stop grid
> [igniteInstanceName=continuous.IgniteCacheContinuousQueryClientReconnectTest0,
> cancel=true]
> class org.apache.ignite.IgniteClientDisconnectedException: Client node
> disconnected: continuous.IgniteCacheContinuousQueryClientReconnectTest4
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
> at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
> at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.access$200(IgniteCacheContinuousQueryClientReconnectTest.java:42)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest$1.run(IgniteCacheContinuousQueryClientReconnectTest.java:151)
> at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:290)
> at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:221)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.testReconnectClientAndLeftRouter(IgniteCacheContinuousQueryClientReconnectTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> According to [TC
> history|https://ci.ignite.apache.org/project.html?tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E&projectId=Ignite20Tests&testNameId=9004507841514895830&page=5]
> is failing since mid of April.
> Last commit where test has been passing is *b6b3d3754849*.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-898) Ignite does not starts from folder which name contains space
[ https://issues.apache.org/jira/browse/IGNITE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243556#comment-16243556 ] Aleksei Zaitsev commented on IGNITE-898: [~avinogradov] you still didn't have time to look at this small patch? > Ignite does not starts from folder which name contains space > > > Key: IGNITE-898 > URL: https://issues.apache.org/jira/browse/IGNITE-898 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Aleksei Zaitsev >Priority: Trivial > Fix For: 2.4 > > > Observed: > In case folder name contains space character Ignite node cannot be started. > Expected: > Ingine node should be startable even when folder name contains space > character. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6369) 2.11 Spark integration has a dependency on Spark's 2.10 library
[
https://issues.apache.org/jira/browse/IGNITE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov reassigned IGNITE-6369:
Assignee: Denis Mekhanikov
> 2.11 Spark integration has a dependency on Spark's 2.10 library
> ---
>
> Key: IGNITE-6369
> URL: https://issues.apache.org/jira/browse/IGNITE-6369
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Hubert Plociniczak
>Assignee: Denis Mekhanikov
>
> A simple Spark application that uses both Spark and Ignite fails to compile
> in sbt under 2.11 due to conflicting dependencies. For a simple sbt
> definition with:
> {code}
> libraryDependencies += "org.apache.spark" %% "spark-core" % "2.1.0"
> libraryDependencies += "org.apache.spark" %% "spark-sql" % "2.1.0"
> libraryDependencies += "org.apache.ignite" % "ignite-spark" % "2.1.0"
> {code}
> it will fail to compile with:
> {code}
> [error] Modules were resolved with conflicting cross-version suffixes in:
> [error]org.scalatest:scalatest _2.11, _2.10
> [error]com.twitter:chill _2.11, _2.10
> [error]org.apache.spark:spark-unsafe _2.11, _2.10
> [error]org.apache.spark:spark-tags _2.11, _2.10
> [trace] Stack trace suppressed: run 'last *:update' for the full output.
> {code}
> It looks like a single culprit is the entry in ignite-spark's pom.xml for
> {{spark-unsafe_2.10}}.
> When removed, compiled and published, everything works great.
> I don't see why such an entry exists in {{spark}} module when there is a
> separate {{spark-2.10}} module as well.
> Happy to submit a PR if anyone is willing to give a thumbs up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-425) Introduce transformers for continuous queries
[
https://issues.apache.org/jira/browse/IGNITE-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243599#comment-16243599
]
Anton Vinogradov commented on IGNITE-425:
-
[~NIzhikov],
Hi, Sorry for delay, too busy now.
> Introduce transformers for continuous queries
> -
>
> Key: IGNITE-425
> URL: https://issues.apache.org/jira/browse/IGNITE-425
> Project: Ignite
> Issue Type: Sub-task
> Components: cache
>Affects Versions: 2.2
>Reporter: Yakov Zhdanov
>Assignee: Nikolay Izhikov
> Fix For: 2.4
>
>
> Currently if updated entry passes the filter, it is sent to node initiated
> the query entirely. It would be good to provide user with the ability to
> transform entry and, for example, select only fields that are important. This
> may bring huge economy to traffic and lower GC pressure as well.
> Possible signatures will be:
> {noformat}
> public final class ContinuousQuery {..} // T is a type transformer
> transforms to
> public ContinuousQuery setLocalListener(Listener locLsnr) {..} //
> Probably, we will have to introduce new listener type, since user may want to
> wipe out key as well.
> /* new method to add */
> public ContinuousQuery setRemoteTransformerFactory(Factory ContinuousQueryTransformer> factory) { ..}
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-898) Ignite does not starts from folder which name contains space
[ https://issues.apache.org/jira/browse/IGNITE-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243604#comment-16243604 ] Anton Vinogradov commented on IGNITE-898: - [~alexzaitzev], Hi, Sorry for delay, too busy now. > Ignite does not starts from folder which name contains space > > > Key: IGNITE-898 > URL: https://issues.apache.org/jira/browse/IGNITE-898 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Aleksei Zaitsev >Priority: Trivial > Fix For: 2.4 > > > Observed: > In case folder name contains space character Ignite node cannot be started. > Expected: > Ingine node should be startable even when folder name contains space > character. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5955) Ignite Continuous Query (Queries 3): IgniteCacheContinuousQueryClientReconnectTest fails
[
https://issues.apache.org/jira/browse/IGNITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny reassigned IGNITE-5955:
--
Assignee: Stanilovsky Evgeny
> Ignite Continuous Query (Queries 3):
> IgniteCacheContinuousQueryClientReconnectTest fails
>
>
> Key: IGNITE-5955
> URL: https://issues.apache.org/jira/browse/IGNITE-5955
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Stanilovsky Evgeny
> Labels: MakeTeamcityGreenAgain, test-failure
>
> Reproducible locally with the same exception as on TC.
> In test log there is the following exception:
> {noformat}
> [2017-08-07
> 03:24:05,694][ERROR][test-runner-#10587%continuous.IgniteCacheContinuousQueryClientReconnectTest%][root]
> Failed to stop grid
> [igniteInstanceName=continuous.IgniteCacheContinuousQueryClientReconnectTest0,
> cancel=true]
> class org.apache.ignite.IgniteClientDisconnectedException: Client node
> disconnected: continuous.IgniteCacheContinuousQueryClientReconnectTest4
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
> at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
> at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.access$200(IgniteCacheContinuousQueryClientReconnectTest.java:42)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest$1.run(IgniteCacheContinuousQueryClientReconnectTest.java:151)
> at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:290)
> at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:221)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.testReconnectClientAndLeftRouter(IgniteCacheContinuousQueryClientReconnectTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> According to [TC
> history|https://ci.ignite.apache.org/project.html?tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E&projectId=Ignite20Tests&testNameId=9004507841514895830&page=5]
> is failing since mid of April.
> Last commit where test has been passing is *b6b3d3754849*.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5955) Ignite Continuous Query (Queries 3): IgniteCacheContinuousQueryClientReconnectTest fails
[
https://issues.apache.org/jira/browse/IGNITE-5955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny reassigned IGNITE-5955:
--
Assignee: Nikolay Tikhonov (was: Stanilovsky Evgeny)
> Ignite Continuous Query (Queries 3):
> IgniteCacheContinuousQueryClientReconnectTest fails
>
>
> Key: IGNITE-5955
> URL: https://issues.apache.org/jira/browse/IGNITE-5955
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Sergey Chugunov
>Assignee: Nikolay Tikhonov
> Labels: MakeTeamcityGreenAgain, test-failure
>
> Reproducible locally with the same exception as on TC.
> In test log there is the following exception:
> {noformat}
> [2017-08-07
> 03:24:05,694][ERROR][test-runner-#10587%continuous.IgniteCacheContinuousQueryClientReconnectTest%][root]
> Failed to stop grid
> [igniteInstanceName=continuous.IgniteCacheContinuousQueryClientReconnectTest0,
> cancel=true]
> class org.apache.ignite.IgniteClientDisconnectedException: Client node
> disconnected: continuous.IgniteCacheContinuousQueryClientReconnectTest4
> at
> org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:92)
> at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3707)
> at org.apache.ignite.internal.IgniteKernal.active(IgniteKernal.java:3423)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.awaitTopologyChange(GridAbstractTest.java:2105)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1030)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1006)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:997)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.access$200(IgniteCacheContinuousQueryClientReconnectTest.java:42)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest$1.run(IgniteCacheContinuousQueryClientReconnectTest.java:151)
> at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNodes(IgniteClientReconnectAbstractTest.java:290)
> at
> org.apache.ignite.internal.IgniteClientReconnectAbstractTest.reconnectClientNode(IgniteClientReconnectAbstractTest.java:221)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryClientReconnectTest.testReconnectClientAndLeftRouter(IgniteCacheContinuousQueryClientReconnectTest.java:149)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> According to [TC
> history|https://ci.ignite.apache.org/project.html?tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E&projectId=Ignite20Tests&testNameId=9004507841514895830&page=5]
> is failing since mid of April.
> Last commit where test has been passing is *b6b3d3754849*.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6709) Support mvcc filter for H2TreeIndex.findFirstOrLast
[ https://issues.apache.org/jira/browse/IGNITE-6709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-6709. -- Resolution: Fixed > Support mvcc filter for H2TreeIndex.findFirstOrLast > --- > > Key: IGNITE-6709 > URL: https://issues.apache.org/jira/browse/IGNITE-6709 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Igor Seliverstov > > Need implement possibility to pass filter in findFirst/findLast (test already > exists CacheMvccSqlQueriesTest.testMaxMinTransactional). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4939) Receive event before cache initialized
[
https://issues.apache.org/jira/browse/IGNITE-4939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243634#comment-16243634
]
Denis Mekhanikov commented on IGNITE-4939:
--
Here is a reproducer for Ignite 2.3:
{code}
public class CacheNotConfiguredExample {
TcpDiscoveryIpFinder ipFinder = new TcpDiscoveryVmIpFinder(true);
public static void main(String[] args) {
new CacheNotConfiguredExample().doMain();
}
void doMain() {
new Thread(this::startServer).start();
new Thread(this::startClient).start();
}
Ignite startClient() {
IgniteConfiguration igniteCfg = igniteConfiguration();
igniteCfg.setIgniteInstanceName("Client Node");
igniteCfg.setClientMode(true);
return Ignition.start(igniteCfg);
}
Ignite startServer() {
IgniteConfiguration igniteCfg = igniteConfiguration();
igniteCfg.setIgniteInstanceName("Server Node");
igniteCfg.setServiceConfiguration(serviceConfiguration());
igniteCfg.setClientMode(false);
return Ignition.start(igniteCfg);
}
IgniteConfiguration igniteConfiguration() {
IgniteConfiguration cfg = new IgniteConfiguration();
TcpDiscoverySpi spi = new TcpDiscoverySpi();
spi.setIpFinder(ipFinder);
cfg.setDiscoverySpi(spi);
return cfg;
}
ServiceConfiguration serviceConfiguration() {
ServiceConfiguration svcCfg = new ServiceConfiguration();
svcCfg.setName("service");
svcCfg.setTotalCount(1);
svcCfg.setService(new SimpleMapServiceImpl());
return svcCfg;
}
}
{code}
There is a race, so the exception may appear not every time.
> Receive event before cache initialized
> --
>
> Key: IGNITE-4939
> URL: https://issues.apache.org/jira/browse/IGNITE-4939
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.9
>Reporter: Nikolay Tikhonov
>Assignee: Evgenii Zhuravlev
> Fix For: 2.1
>
>
> Receive event before cache initialized that leads to the following:
> {noformat}
> Exception in thread "sys-#755%Default%" java.lang.IllegalArgumentException:
> Cache is not configured: ignite-sys-cache
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.jcache(GridCacheProcessor.java:3343)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.handleEvent(CacheContinuousQueryHandler.java:719)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback0(CacheContinuousQueryHandler.java:691)
> at
> org.apache.ignite.internal.processors.cache.query.continuous.CacheContinuousQueryHandler.notifyCallback(CacheContinuousQueryHandler.java:650)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.processNotification(GridContinuousProcessor.java:1086)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor.access$2000(GridContinuousProcessor.java:97)
> at
> org.apache.ignite.internal.processors.continuous.GridContinuousProcessor$8.onMessage(GridContinuousProcessor.java:741)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1082)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2332)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1042)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1900(GridIoManager.java:102)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$6.run(GridIoManager.java:1011)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6738) Support mvcc filter for local sql queries
[ https://issues.apache.org/jira/browse/IGNITE-6738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-6738: Assignee: Igor Seliverstov > Support mvcc filter for local sql queries > - > > Key: IGNITE-6738 > URL: https://issues.apache.org/jira/browse/IGNITE-6738 > Project: Ignite > Issue Type: Sub-task > Components: cache >Reporter: Semen Boikov >Assignee: Igor Seliverstov > > Need receive/release mvcc version for queries with setLocal flag set, there > are already some tests in CacheMvccSqlQueriesTest. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-6767:
Docs Text: NearCache#loaclPeek(key, NEAR) always returns 'null' if the
node, which owns the primary partition for the given key, left the cluster.
(was: {{NearCache#loaclPeek(key, NEAR) always returns 'null' if the node, which
owns the primary partition for the given key, left the cluster.)
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned or atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6629) Make service automatic redeployment configurable in ServiceConfiguration
[ https://issues.apache.org/jira/browse/IGNITE-6629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov updated IGNITE-6629: --- Labels: Muted_test (was: ) > Make service automatic redeployment configurable in ServiceConfiguration > > > Key: IGNITE-6629 > URL: https://issues.apache.org/jira/browse/IGNITE-6629 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.3 >Reporter: Ivan Rakov >Assignee: Alexey Goncharuk > Labels: Muted_test > Fix For: 2.4 > > > Before 2.3, if persistence was enabled globally, services were recovered > along with system cache. But in 2.3, persistence can be enabled for per data > region (IGNITE-6030), and system data region is not persistent. > We should add feaure to configure service redeployment after restart. > Service-related information should be stored in Metastore instead of system > cache. > IgniteChangeGlobalStateServiceTest#testDeployService should be fixed under > this ticket. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243678#comment-16243678
]
Vyacheslav Koptilin commented on IGNITE-6767:
-
Hi [~Timay]
I would prefer the following patch which is very similar to the provided by you
{code:java}
---
a/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearCacheEntry.java
+++
b/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearCacheEntry.java
@@ -379,7 +379,7 @@ public class GridNearCacheEntry extends
GridDistributedCacheEntry {
CacheObject old = this.val;
boolean hasVal = hasValueUnlocked();
-if (this.dhtVer == null || this.dhtVer.compareTo(dhtVer) < 0) {
+if ((this.dhtVer == null || this.dhtVer.compareTo(dhtVer) < 0)
|| !valid(topVer)) {
primaryNode(primaryNodeId, topVer);
update(val, expireTime, ttl, ver, true);
{code}
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned or atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6841) ODBC: Add new version for multiple result set functionality
Igor Sapego created IGNITE-6841: --- Summary: ODBC: Add new version for multiple result set functionality Key: IGNITE-6841 URL: https://issues.apache.org/jira/browse/IGNITE-6841 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Components: odbc Affects Versions: 2.3 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.4 Changes made in IGNITE-6357 changed ODBC protocol, but protocol version was not increased. Need to fix it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6839) Ignite Compatibility: flaky test testFoldersReuseCompatibility_2_1 & 2_2
[
https://issues.apache.org/jira/browse/IGNITE-6839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243679#comment-16243679
]
Dmitriy Pavlov commented on IGNITE-6839:
Hi [~daradurvs],
could you please advice on the follwing:
https://ci.ignite.apache.org/viewLog.html?buildId=933513&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteCompatibility#testNameId-1418165996957466785
I've added cleanup of directory in my PR, put test is still flaky. I can see
version of Ignite is correct:
{nofromat}
[2017-11-08 10:23:23,529][INFO ][Thread-20][jvm-07abff3d#2_1_0] >>> ver. 2.1.0
{nofromat}
but the same VM prints message introduced in Ignite 2.3
{noformat}
[2017-11-08 10:23:23,893][INFO ][Thread-20][jvm-07abff3d#2_1_0] [2017-11-08
10:23:23,892][INFO ][main][PdsFoldersResolver] Successfully created new
persistent storage folder
[/data/teamcity/work/820be461cd64b574/work/db/node00-4a55251f-725f-4f58-8605-34aa1efb5f3b]
{noformat}
Why classes from actual ignite code are come here?
> Ignite Compatibility: flaky test testFoldersReuseCompatibility_2_1 & 2_2
>
>
> Key: IGNITE-6839
> URL: https://issues.apache.org/jira/browse/IGNITE-6839
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: persistence
>Affects Versions: 2.3
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> Ignite Compatibility: 2 test are flaky:
>
> org.apache.ignite.compatibility.testsuites.IgniteCompatibilityBasicTestSuite:
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_1
> (fails: 2/55):
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-1418165996957466785&branch=%3Cdefault%3E&tab=testDetails
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=1638023358531502921&tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E
> {noformat}
> junit.framework.AssertionFailedError: Directory [binary_meta,
> 135628fa_5763_46a1_88ff_8c0c8e51fc4e] is expected to exist
> [/data/teamcity/work/820be461cd64b574/work/binary_meta/135628fa_5763_46a1_88ff_8c0c8e51fc4e]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.assertTrue(Assert.java:22)
> at junit.framework.TestCase.assertTrue(TestCase.java:192)
> at
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.assertDirectoryExist(FoldersReuseCompatibilityTest.java:220)
> at
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.assertPdsDirsDefaultExist(FoldersReuseCompatibilityTest.java:193)
> at
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.runFoldersReuse(FoldersReuseCompatibilityTest.java:108)
> at
> org.apache.ignite.compatibility.persistence.FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_1(FoldersReuseCompatibilityTest.java:86)
> {noformat}
> Test probaly indicates a bug in
> https://issues.apache.org/jira/browse/IGNITE-6285
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243685#comment-16243685
]
Vyacheslav Koptilin commented on IGNITE-6767:
-
Hi [~sboikov]
Could you please review the patch?
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned or atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6841) ODBC: Add new version for multiple result set functionality
[ https://issues.apache.org/jira/browse/IGNITE-6841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243686#comment-16243686 ] ASF GitHub Bot commented on IGNITE-6841: GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/2995 IGNITE-6841: Increased ODBC protocol version for multiple statements. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6841 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2995.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2995 commit 9feae7a5f6be5de66ee22b360050dc720974f5f6 Author: Igor Sapego Date: 2017-11-08T10:40:29Z IGNITE-6841: Increased ODBC protocol version for multiple statements > ODBC: Add new version for multiple result set functionality > --- > > Key: IGNITE-6841 > URL: https://issues.apache.org/jira/browse/IGNITE-6841 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: odbc >Affects Versions: 2.3 >Reporter: Igor Sapego >Assignee: Igor Sapego > Labels: odbc > Fix For: 2.4 > > > Changes made in IGNITE-6357 changed ODBC protocol, but protocol version was > not increased. Need to fix it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5218) Decision trees
[ https://issues.apache.org/jira/browse/IGNITE-5218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16237974#comment-16237974 ] Oleg Ignatenko edited comment on IGNITE-5218 at 11/8/17 10:51 AM: -- Example provided for decision trees ([MNISTExample|https://github.com/gridgain/apache-ignite/blob/ignite-5218/examples/src/main/ml/org/apache/ignite/examples/ml/math/trees/MNISTExample.java]) looks sufficiently documented and runs fine on my machine. Unit tests run successfully on my machine ([DecisionTreesTestSuite|https://github.com/gridgain/apache-ignite/blob/ignite-5218/modules/ml/src/test/java/org/apache/ignite/ml/trees/DecisionTreesTestSuite.java]), as well as "internal" benchmark [ColumnDecisionTreeTrainerBenchmark|https://github.com/gridgain/apache-ignite/blob/ignite-5218/modules/ml/src/test/java/org/apache/ignite/ml/trees/performance/ColumnDecisionTreeTrainerBenchmark.java]. Worth noting that yesterday Yury did a [trial run on TC|https://ci.ignite.apache.org/viewLog.html?buildId=927458&buildTypeId=Ignite20Tests_IgniteMl&tab=buildResultsDiv] for this pull request and it came out all green. Code formatting looks right in both main and test parts. Code inspections results are okay in both main and test parts. I also re-run this PR on TeamCity in order to make sure that changes made during review didn't introduce failures. [The link of TC results|https://ci.ignite.apache.org/viewLog.html?buildId=933522&;] was added to this ticket so that it's easier to check for the committer. was (Author: oignatenko): Example provided for decision trees ([MNISTExample|https://github.com/gridgain/apache-ignite/blob/ignite-5218/examples/src/main/ml/org/apache/ignite/examples/ml/math/trees/MNISTExample.java]) looks sufficiently documented and runs fine on my machine. Unit tests run successfully on my machine ([DecisionTreesTestSuite|https://github.com/gridgain/apache-ignite/blob/ignite-5218/modules/ml/src/test/java/org/apache/ignite/ml/trees/DecisionTreesTestSuite.java]), as well as "internal" benchmark [ColumnDecisionTreeTrainerBenchmark|https://github.com/gridgain/apache-ignite/blob/ignite-5218/modules/ml/src/test/java/org/apache/ignite/ml/trees/performance/ColumnDecisionTreeTrainerBenchmark.java]. Worth noting that yesterday Yury did a [trial run on TC|https://ci.ignite.apache.org/viewLog.html?buildId=927458&buildTypeId=Ignite20Tests_IgniteMl&tab=buildResultsDiv] for this pull request and it came out all green. Code formatting looks right in both main and test parts. Code inspections results are okay in both main and test parts. (!) [~amalykh] - prior to passing this PR to committer for merge please re-run PR on TeamCity in order to make sure that changes made during review didn't introduce failures. Add the link of TC results to this ticket so that it's easier to check for the committer. > Decision trees > -- > > Key: IGNITE-5218 > URL: https://issues.apache.org/jira/browse/IGNITE-5218 > Project: Ignite > Issue Type: New Feature > Components: ml >Reporter: Yury Babak >Assignee: Artem Malykh > > We want to implement Decision trees for Ignite ML because it's really common > one for ML. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6831) Ignite SPI: Test local port range failed on TC agents
[
https://issues.apache.org/jira/browse/IGNITE-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semen Boikov resolved IGNITE-6831.
--
Resolution: Fixed
Assignee: (was: Alexei Scherbakov)
Test added in IGNITE-6667 did not stop nodes
(IgniteDiscoveryCacheReuseSelfTest), fixed.
> Ignite SPI: Test local port range failed on TC agents
> -
>
> Key: IGNITE-6831
> URL: https://issues.apache.org/jira/browse/IGNITE-6831
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.4
>
>
> Thanks to [~ilyak] for locating failure reasons:
> Test failed on TC agents, but passes locally
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-8122916584508695460&tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E
> Test is failed after applying commit:
> https://github.com/apache/ignite/pull/2972/commits/14f04c4ce80178dc55ee62b3cf09dd4ec129f3e2
> caused by IGNITE-6667 implementation
> {noformat}
> org.apache.ignite.spi.IgniteSpiException: Failed to add node to topology
> because remote node is configured to use loopback address, but local node is
> not (consider changing 'localAddress' configuration parameter)
> [locNodeAddrs=[758001b16ff9/127.0.0.1, /172.17.0.5],
> rmtNodeAddrs=[127.0.0.1], creatorNodeId=24e3282c-a857-4d5f-beb4-25580150]
> {noformat}
> where 172.17.0.5 is IP of TC agent coming from docker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6667) Allow discovery cache instance reuse if only minor topology change has occured.
[ https://issues.apache.org/jira/browse/IGNITE-6667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243772#comment-16243772 ] Alexei Scherbakov commented on IGNITE-6667: --- Fixed in IGNITE-6831 > Allow discovery cache instance reuse if only minor topology change has > occured. > --- > > Key: IGNITE-6667 > URL: https://issues.apache.org/jira/browse/IGNITE-6667 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Affects Versions: 2.2 >Reporter: Alexei Scherbakov > Fix For: 2.4 > > > Currently we always recreating DiscoCache instance even if only minor > topology change has occured and cache may be reused. > Profiling shows what initialization of such object tooks up tens of millis > which adds to ring latency delay and especially sensitive for large > topologies. > Solution: reuse current discovery cache instance whenever possible. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243678#comment-16243678
]
Vyacheslav Koptilin edited comment on IGNITE-6767 at 11/8/17 11:42 AM:
---
Hi [~Timay]
1. Please add the test to the {{IgniteCacheTestSuite2}}
2. I would prefer the following patch which is very similar to the provided by
you
{code:java}
---
a/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearCacheEntry.java
+++
b/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearCacheEntry.java
@@ -379,7 +379,7 @@ public class GridNearCacheEntry extends
GridDistributedCacheEntry {
CacheObject old = this.val;
boolean hasVal = hasValueUnlocked();
-if (this.dhtVer == null || this.dhtVer.compareTo(dhtVer) < 0) {
+if ((this.dhtVer == null || this.dhtVer.compareTo(dhtVer) < 0)
|| !valid(topVer)) {
primaryNode(primaryNodeId, topVer);
update(val, expireTime, ttl, ver, true);
{code}
was (Author: slava.koptilin):
Hi [~Timay]
I would prefer the following patch which is very similar to the provided by you
{code:java}
---
a/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearCacheEntry.java
+++
b/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearCacheEntry.java
@@ -379,7 +379,7 @@ public class GridNearCacheEntry extends
GridDistributedCacheEntry {
CacheObject old = this.val;
boolean hasVal = hasValueUnlocked();
-if (this.dhtVer == null || this.dhtVer.compareTo(dhtVer) < 0) {
+if ((this.dhtVer == null || this.dhtVer.compareTo(dhtVer) < 0)
|| !valid(topVer)) {
primaryNode(primaryNodeId, topVer);
update(val, expireTime, ttl, ver, true);
{code}
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned or atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6835) ODBC driver should handle ungraceful tcp disconnects
[ https://issues.apache.org/jira/browse/IGNITE-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243780#comment-16243780 ] ASF GitHub Bot commented on IGNITE-6835: GitHub user apopovgg opened a pull request: https://github.com/apache/ignite/pull/2997 IGNITE-6835 ODBC driver should handle ungraceful tcp disconnects You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6835 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2997.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2997 commit dd595013ea42af8f5c60a3a8f5ea7a6c7b9c8e7e Author: apopov Date: 2017-11-08T11:42:59Z IGNITE-6835 ODBC driver should handle ungraceful tcp disconnects > ODBC driver should handle ungraceful tcp disconnects > > > Key: IGNITE-6835 > URL: https://issues.apache.org/jira/browse/IGNITE-6835 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: odbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Alexey Popov > > It is found that ungraceful TCP disconnect makes ODBC driver stuck at socket > recv(). > Ungraceful TCP disconnect could be caused: > 1. Network failure (or new firewall rules) > 2. Remote party shutdown (Half Closed Connection) > So, the proposal is: > setup socket options: > 1) SO_KEEPALIVE enabled > 2) TCP_KEEPIDLE to 60 sec. It is 2 hour by default > 3) TCP_KEEPINTVL to 5 (\?) sec. It is 1 sec at Win and 75 sec at Linux by > default. > 4) send/receive buffers to some greater value (8k by default) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6842) Stop all nodes after test by default.
Alexei Scherbakov created IGNITE-6842: - Summary: Stop all nodes after test by default. Key: IGNITE-6842 URL: https://issues.apache.org/jira/browse/IGNITE-6842 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Alexei Scherbakov Currently it's required to manually call stopAllGrids() after test completion. This leads to errors in subsequent tests if someone forgets to call it and to additional boilerplate code in tests. Right choice is to make this default behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6842) Stop all nodes after test by default.
[ https://issues.apache.org/jira/browse/IGNITE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-6842: -- Fix Version/s: 2.4 > Stop all nodes after test by default. > - > > Key: IGNITE-6842 > URL: https://issues.apache.org/jira/browse/IGNITE-6842 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Alexei Scherbakov > Labels: newbie > Fix For: 2.4 > > > Currently it's required to manually call stopAllGrids() after test completion. > This leads to errors in subsequent tests if someone forgets to call it and to > additional boilerplate code in tests. > Right choice is to make this default behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6842) Stop all nodes after test by default.
[ https://issues.apache.org/jira/browse/IGNITE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243801#comment-16243801 ] Dmitriy Pavlov commented on IGNITE-6842: I suggest to assert there is non-stopped ignite and fail test that didn't stopped it's nodes. > Stop all nodes after test by default. > - > > Key: IGNITE-6842 > URL: https://issues.apache.org/jira/browse/IGNITE-6842 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Alexei Scherbakov > Labels: newbie > Fix For: 2.4 > > > Currently it's required to manually call stopAllGrids() after test completion. > This leads to errors in subsequent tests if someone forgets to call it and to > additional boilerplate code in tests. > Right choice is to make this default behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6842) Stop all nodes after test by default.
[ https://issues.apache.org/jira/browse/IGNITE-6842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243801#comment-16243801 ] Dmitriy Pavlov edited comment on IGNITE-6842 at 11/8/17 12:19 PM: -- I suggest to assert there is non-stopped ignite and fail test that didn't stopped it's nodes. Alternatively test author may set some custom flag indicating that alive node after test is correct behaviour. was (Author: dpavlov): I suggest to assert there is non-stopped ignite and fail test that didn't stopped it's nodes. > Stop all nodes after test by default. > - > > Key: IGNITE-6842 > URL: https://issues.apache.org/jira/browse/IGNITE-6842 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) >Reporter: Alexei Scherbakov > Labels: newbie > Fix For: 2.4 > > > Currently it's required to manually call stopAllGrids() after test completion. > This leads to errors in subsequent tests if someone forgets to call it and to > additional boilerplate code in tests. > Right choice is to make this default behavior. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-6767:
Description:
{{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
node, which owns the primary partition for the given key, left the cluster,
even if {{IgniteCache.get(key)}} was called.
How to reproduce:
# start two server nodes.
# create partitioned, atomic cache and populate data.
# start client node with near cache configured.
# perform {{IgniteCache.get(key)}} and check that {{IgniteCache.localPeek(key,
PeekMode.NEAR)}} returns not null value.
# stop server node which owns primary partition for the given {{key}}.
# perform {{IgniteCache.get(key)}}.
# after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns null
value.
This issue was reported on the user-list:
http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
was:
{{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
node, which owns the primary partition for the given key, left the cluster,
even if {{IgniteCache.get(key)}} was called.
How to reproduce:
# start two server nodes.
# create partitioned or atomic cache and populate data.
# start client node with near cache configured.
# perform {{IgniteCache.get(key)}} and check that {{IgniteCache.localPeek(key,
PeekMode.NEAR)}} returns not null value.
# stop server node which owns primary partition for the given {{key}}.
# perform {{IgniteCache.get(key)}}.
# after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns null
value.
This issue was reported on the user-list:
http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned, atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6369) 2.11 Spark integration has a dependency on Spark's 2.10 library
[
https://issues.apache.org/jira/browse/IGNITE-6369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Mekhanikov updated IGNITE-6369:
-
Fix Version/s: 2.4
> 2.11 Spark integration has a dependency on Spark's 2.10 library
> ---
>
> Key: IGNITE-6369
> URL: https://issues.apache.org/jira/browse/IGNITE-6369
> Project: Ignite
> Issue Type: Bug
> Components: spark
>Reporter: Hubert Plociniczak
>Assignee: Denis Mekhanikov
> Fix For: 2.4
>
>
> A simple Spark application that uses both Spark and Ignite fails to compile
> in sbt under 2.11 due to conflicting dependencies. For a simple sbt
> definition with:
> {code}
> libraryDependencies += "org.apache.spark" %% "spark-core" % "2.1.0"
> libraryDependencies += "org.apache.spark" %% "spark-sql" % "2.1.0"
> libraryDependencies += "org.apache.ignite" % "ignite-spark" % "2.1.0"
> {code}
> it will fail to compile with:
> {code}
> [error] Modules were resolved with conflicting cross-version suffixes in:
> [error]org.scalatest:scalatest _2.11, _2.10
> [error]com.twitter:chill _2.11, _2.10
> [error]org.apache.spark:spark-unsafe _2.11, _2.10
> [error]org.apache.spark:spark-tags _2.11, _2.10
> [trace] Stack trace suppressed: run 'last *:update' for the full output.
> {code}
> It looks like a single culprit is the entry in ignite-spark's pom.xml for
> {{spark-unsafe_2.10}}.
> When removed, compiled and published, everything works great.
> I don't see why such an entry exists in {{spark}} module when there is a
> separate {{spark-2.10}} module as well.
> Happy to submit a PR if anyone is willing to give a thumbs up.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6831) Ignite SPI: Test local port range failed on TC agents
[
https://issues.apache.org/jira/browse/IGNITE-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-6831:
---
Labels: MakeTeamcityGreenAgain (was: MakeTeamcityGreenAgain Muted_test)
> Ignite SPI: Test local port range failed on TC agents
> -
>
> Key: IGNITE-6831
> URL: https://issues.apache.org/jira/browse/IGNITE-6831
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> Thanks to [~ilyak] for locating failure reasons:
> Test failed on TC agents, but passes locally
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-8122916584508695460&tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E
> Test is failed after applying commit:
> https://github.com/apache/ignite/pull/2972/commits/14f04c4ce80178dc55ee62b3cf09dd4ec129f3e2
> caused by IGNITE-6667 implementation
> {noformat}
> org.apache.ignite.spi.IgniteSpiException: Failed to add node to topology
> because remote node is configured to use loopback address, but local node is
> not (consider changing 'localAddress' configuration parameter)
> [locNodeAddrs=[758001b16ff9/127.0.0.1, /172.17.0.5],
> rmtNodeAddrs=[127.0.0.1], creatorNodeId=24e3282c-a857-4d5f-beb4-25580150]
> {noformat}
> where 172.17.0.5 is IP of TC agent coming from docker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-6831) Ignite SPI: Test local port range failed on TC agents
[
https://issues.apache.org/jira/browse/IGNITE-6831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov closed IGNITE-6831.
--
[~sboikov], [~ascherbakov], [~ilyak], thank you!
I've unmuted test. Test is now passing:
https://ci.ignite.apache.org/viewLog.html?buildId=933907&buildTypeId=Ignite20Tests_IgniteSpi&tab=testsInfo
> Ignite SPI: Test local port range failed on TC agents
> -
>
> Key: IGNITE-6831
> URL: https://issues.apache.org/jira/browse/IGNITE-6831
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.2
>Reporter: Dmitriy Pavlov
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.4
>
>
> Thanks to [~ilyak] for locating failure reasons:
> Test failed on TC agents, but passes locally
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&testNameId=-8122916584508695460&tab=testDetails&branch_Ignite20Tests=%3Cdefault%3E
> Test is failed after applying commit:
> https://github.com/apache/ignite/pull/2972/commits/14f04c4ce80178dc55ee62b3cf09dd4ec129f3e2
> caused by IGNITE-6667 implementation
> {noformat}
> org.apache.ignite.spi.IgniteSpiException: Failed to add node to topology
> because remote node is configured to use loopback address, but local node is
> not (consider changing 'localAddress' configuration parameter)
> [locNodeAddrs=[758001b16ff9/127.0.0.1, /172.17.0.5],
> rmtNodeAddrs=[127.0.0.1], creatorNodeId=24e3282c-a857-4d5f-beb4-25580150]
> {noformat}
> where 172.17.0.5 is IP of TC agent coming from docker
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX
[
https://issues.apache.org/jira/browse/IGNITE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6843:
Labels: iep-1 performance (was: )
> SQL: optionally do not use WAL when executing CREATE INDEX
> --
>
> Key: IGNITE-6843
> URL: https://issues.apache.org/jira/browse/IGNITE-6843
> Project: Ignite
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> When index is being created through {{CREATE INDEX}} command, every single
> index update is written to WAL. Let's introduce special mode where updates
> are not written to WAL:
> 1) Index updates are not written to WAL
> 2) When index is ready, force checkpoint and wait for it to happen
> 3) Purge index data if node crashed before checkpoint
> Alternatively, we may even not trigger a checkpoint, hoping that that node
> will not crash before the nearest checkpoint is finished. If node crashed
> during this time window, index should be marked as "invalid", and not used
> for queries. Then user should either re-create or rebuild it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX
Vladimir Ozerov created IGNITE-6843:
---
Summary: SQL: optionally do not use WAL when executing CREATE INDEX
Key: IGNITE-6843
URL: https://issues.apache.org/jira/browse/IGNITE-6843
Project: Ignite
Issue Type: Task
Security Level: Public (Viewable by anyone)
Components: sql
Affects Versions: 2.3
Reporter: Vladimir Ozerov
Fix For: 2.4
When index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, index should be marked as "invalid", and not used for
queries. Then user should either re-create or rebuild it.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6687) SQL Error Codes Documentation
[ https://issues.apache.org/jira/browse/IGNITE-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243995#comment-16243995 ] Igor Sapego commented on IGNITE-6687: - [~dmagda], done. Check it out. > SQL Error Codes Documentation > - > > Key: IGNITE-6687 > URL: https://issues.apache.org/jira/browse/IGNITE-6687 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Denis Magda >Assignee: Igor Sapego > Fix For: 2.4 > > > Presently we have JDBC error codes documented: > https://apacheignite-sql.readme.io/docs/jdbc-error-codes > Two things have to be done: > * If there are similar error codes shared between the ODBC and JDBC drivers, > and native APIs then let's put them under SQL reference category below Data > Types: https://apacheignite-sql.readme.io/docs/sql-reference-overview > * ODBC specific error codes with an example of an error handling need to be > listed in ODBC category [~isapego], please assist with this: > https://apacheignite-sql.readme.io/docs/odbc-driver > Discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/SQL-error-codes-td23415.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX
[
https://issues.apache.org/jira/browse/IGNITE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-6843:
Description:
Inspired by Oracle {{NOLOGGING}} option [1].
When index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, index should be marked as "invalid", and not used for
queries. Then user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
was:
When index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, index should be marked as "invalid", and not used for
queries. Then user should either re-create or rebuild it.
> SQL: optionally do not use WAL when executing CREATE INDEX
> --
>
> Key: IGNITE-6843
> URL: https://issues.apache.org/jira/browse/IGNITE-6843
> Project: Ignite
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Inspired by Oracle {{NOLOGGING}} option [1].
> When index is being created through {{CREATE INDEX}} command, every single
> index update is written to WAL. Let's introduce special mode where updates
> are not written to WAL:
> 1) Index updates are not written to WAL
> 2) When index is ready, force checkpoint and wait for it to happen
> 3) Purge index data if node crashed before checkpoint
> Alternatively, we may even not trigger a checkpoint, hoping that that node
> will not crash before the nearest checkpoint is finished. If node crashed
> during this time window, index should be marked as "invalid", and not used
> for queries. Then user should either re-create or rebuild it.
> [1]
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX
[
https://issues.apache.org/jira/browse/IGNITE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Puchnin updated IGNITE-6843:
---
Description:
Inspired by Oracle {{NOLOGGING}} option [1].
When index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates during an index_create operation are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, index should be marked as "invalid", and not used for
queries. Then user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
was:
Inspired by Oracle {{NOLOGGING}} option [1].
When index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, index should be marked as "invalid", and not used for
queries. Then user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
> SQL: optionally do not use WAL when executing CREATE INDEX
> --
>
> Key: IGNITE-6843
> URL: https://issues.apache.org/jira/browse/IGNITE-6843
> Project: Ignite
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Inspired by Oracle {{NOLOGGING}} option [1].
> When index is being created through {{CREATE INDEX}} command, every single
> index update is written to WAL. Let's introduce special mode where updates
> are not written to WAL:
> 1) Index updates during an index_create operation are not written to WAL
> 2) When index is ready, force checkpoint and wait for it to happen
> 3) Purge index data if node crashed before checkpoint
> Alternatively, we may even not trigger a checkpoint, hoping that that node
> will not crash before the nearest checkpoint is finished. If node crashed
> during this time window, index should be marked as "invalid", and not used
> for queries. Then user should either re-create or rebuild it.
> [1]
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX
[
https://issues.apache.org/jira/browse/IGNITE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Puchnin updated IGNITE-6843:
---
Description:
Inspired by Oracle {{NOLOGGING}} option [1].
When an index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates during an index_create operation are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, the index should be marked as "invalid", and not used for
queries. Then the user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
was:
Inspired by Oracle {{NOLOGGING}} option [1].
When index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates during an index_create operation are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, index should be marked as "invalid", and not used for
queries. Then user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
> SQL: optionally do not use WAL when executing CREATE INDEX
> --
>
> Key: IGNITE-6843
> URL: https://issues.apache.org/jira/browse/IGNITE-6843
> Project: Ignite
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Inspired by Oracle {{NOLOGGING}} option [1].
> When an index is being created through {{CREATE INDEX}} command, every single
> index update is written to WAL. Let's introduce special mode where updates
> are not written to WAL:
> 1) Index updates during an index_create operation are not written to WAL
> 2) When index is ready, force checkpoint and wait for it to happen
> 3) Purge index data if node crashed before checkpoint
> Alternatively, we may even not trigger a checkpoint, hoping that that node
> will not crash before the nearest checkpoint is finished. If node crashed
> during this time window, the index should be marked as "invalid", and not
> used for queries. Then the user should either re-create or rebuild it.
> [1]
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6843) SQL: optionally do not use WAL when executing CREATE INDEX
[
https://issues.apache.org/jira/browse/IGNITE-6843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Puchnin updated IGNITE-6843:
---
Description:
Inspired by Oracle {{NOLOGGING}} option [1].
When an index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates during an index_create operation are not written to WAL
2) When the index is ready, force a checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, the index should be marked as "invalid", and not used for
queries. Then the user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
was:
Inspired by Oracle {{NOLOGGING}} option [1].
When an index is being created through {{CREATE INDEX}} command, every single
index update is written to WAL. Let's introduce special mode where updates are
not written to WAL:
1) Index updates during an index_create operation are not written to WAL
2) When index is ready, force checkpoint and wait for it to happen
3) Purge index data if node crashed before checkpoint
Alternatively, we may even not trigger a checkpoint, hoping that that node will
not crash before the nearest checkpoint is finished. If node crashed during
this time window, the index should be marked as "invalid", and not used for
queries. Then the user should either re-create or rebuild it.
[1]
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
> SQL: optionally do not use WAL when executing CREATE INDEX
> --
>
> Key: IGNITE-6843
> URL: https://issues.apache.org/jira/browse/IGNITE-6843
> Project: Ignite
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: sql
>Affects Versions: 2.3
>Reporter: Vladimir Ozerov
> Labels: iep-1, performance
> Fix For: 2.4
>
>
> Inspired by Oracle {{NOLOGGING}} option [1].
> When an index is being created through {{CREATE INDEX}} command, every single
> index update is written to WAL. Let's introduce special mode where updates
> are not written to WAL:
> 1) Index updates during an index_create operation are not written to WAL
> 2) When the index is ready, force a checkpoint and wait for it to happen
> 3) Purge index data if node crashed before checkpoint
> Alternatively, we may even not trigger a checkpoint, hoping that that node
> will not crash before the nearest checkpoint is finished. If node crashed
> during this time window, the index should be marked as "invalid", and not
> used for queries. Then the user should either re-create or rebuild it.
> [1]
> https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_5010.htm#i2182589
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6690) DiscoverySpi: Clientmode Ignite should not fail on handshake errors
[ https://issues.apache.org/jira/browse/IGNITE-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244005#comment-16244005 ] Alexey Popov commented on IGNITE-6690: -- Discovery SPI: Ignite will skip non-Ignite servers during Discovery instead of failure > DiscoverySpi: Clientmode Ignite should not fail on handshake errors > --- > > Key: IGNITE-6690 > URL: https://issues.apache.org/jira/browse/IGNITE-6690 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: general >Affects Versions: 2.2 >Reporter: Alexey Popov >Assignee: Alexey Popov > Labels: discovery > Fix For: 2.4 > > > Ignite in Client mode should not fail on handshake unmarshalling errors. It > should go to the next IP/port from ipFinder list > http://apache-ignite-developers.2346864.n4.nabble.com/DiscoverySpi-Handshake-unmarshalling-errors-at-Client-client-mode-td23467.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-5189) Unexpected error occurs when node left topology.
[ https://issues.apache.org/jira/browse/IGNITE-5189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Popov resolved IGNITE-5189. -- Resolution: Duplicate Fix Version/s: 2.4 Fixed under IGNITE-5225 > Unexpected error occurs when node left topology. > > > Key: IGNITE-5189 > URL: https://issues.apache.org/jira/browse/IGNITE-5189 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 1.8, 1.9, 2.0 >Reporter: Andrew Mashenkov >Assignee: Alexey Popov > Fix For: 2.4 > > > Error occurs sporadically. Usually, it happens when one of server nodes left > topology and client can't connect to other servers via communication. > Using preferIPv4 option solve the issue. > Also, possibly the fact that it seems ok on ignite-1.6 version, may be > helpful. > ERROR 2017-05-10T09:57:58,282 - > de.uplanet.test.integration.RemoteTestServiceBean[pool-4-thread-1] > Failed to send message to remote node: TcpDiscoveryNode > [id=ef626cb1-3880-418e-a9d1-68fd692771fd, addrs=[0:0:0:0:0:0:0:1%lo, > 10.0.2.15, 127.0.0.1, 172.17.0.1], sockAddrs=[/172.17.0.1:0, > 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], discPort=0, order=3, > intOrder=3, lastExchangeTime=1494410235152, loc=false, > ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true] > org.apache.ignite.spi.IgniteSpiException: Failed to send message to remote > node: TcpDiscoveryNode [id=ef626cb1-3880-418e-a9d1-68fd692771fd, > addrs=[0:0:0:0:0:0:0:1%lo, 10.0.2.15, 127.0.0.1, 172.17.0.1], > sockAddrs=[/172.17.0.1:0, 0:0:0:0:0:0:0:1%lo:0, /127.0.0.1:0, /10.0.2.15:0], > discPort=0, order=3, intOrder=3, lastExchangeTime=1494410235152, loc=false, > ver=2.0.0#20170430-sha1:d4eef3c6, isClient=true] > at > org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2483) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage(TcpCommunicationSpi.java:2419) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1329) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.managers.communication.GridIoManager.send(GridIoManager.java:1698) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.managers.communication.GridIoManager.sendOrderedMessageToGridTopic(GridIoManager.java:1473) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.managers.communication.GridIoManager.sendUserMessage(GridIoManager.java:1588) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.IgniteMessagingImpl.sendOrdered(IgniteMessagingImpl.java:165) > ~[ignite-core-2.0.0.jar:2.0.0] > at > de.uplanet.lucy.server.distributed.cloud.datagrid.ignite.IgniteGridTopic.publish(IgniteGridTopic.java:58) > ~[update/:?] > at > de.uplanet.test.integration.RemoteTestServiceBean.lambda$3(RemoteTestServiceBean.java:123) > ~[update/:?] > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > [?:1.8.0_92] > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > [?:1.8.0_92] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [?:1.8.0_92] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [?:1.8.0_92] > at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92] > Caused by: org.apache.ignite.IgniteCheckedException: > java.lang.NullPointerException > at > org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:170) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.reserveClient(TcpCommunicationSpi.java:2630) > ~[ignite-core-2.0.0.jar:2.0.0] > at > org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.sendMessage0(TcpCommunicationSpi.java:2455) > ~[ignite-core-2.0.0.jar:2.0.0] > ... 13 more > Caused by: java.util.concurrent.ExecutionException: > java.lang.NullPointerException > at > java.util.concurrent.FutureTask.report(FutureTask.jav
[jira] [Assigned] (IGNITE-6836) ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
[ https://issues.apache.org/jira/browse/IGNITE-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-6836: --- Assignee: Igor Sapego > ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT > > > Key: IGNITE-6836 > URL: https://issues.apache.org/jira/browse/IGNITE-6836 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: odbc >Affects Versions: 2.1 >Reporter: Alexey Popov >Assignee: Igor Sapego > > It would be great if we can support SQL_ATTR_QUERY_TIMEOUT at ODBC. > That gives a flexibility to end-user code to handle long-running/timeouted > queries. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6836) ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
[
https://issues.apache.org/jira/browse/IGNITE-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6836:
Description:
It would be great if we can support {{SQL_ATTR_QUERY_TIMEOUT}} at ODBC.
That gives a flexibility to end-user code to handle long-running/timeouted
queries.
was:
It would be great if we can support SQL_ATTR_QUERY_TIMEOUT at ODBC.
That gives a flexibility to end-user code to handle long-running/timeouted
queries.
> ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
>
>
> Key: IGNITE-6836
> URL: https://issues.apache.org/jira/browse/IGNITE-6836
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
> Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
>
> It would be great if we can support {{SQL_ATTR_QUERY_TIMEOUT}} at ODBC.
> That gives a flexibility to end-user code to handle long-running/timeouted
> queries.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6840) SQL: Parser: support CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244038#comment-16244038 ] ASF GitHub Bot commented on IGNITE-6840: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/3001 IGNITE-6840 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6840 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3001.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3001 commit bd4a151c548b9b0ecbee50d1bfd97e2b7724b1d6 Author: devozerov Date: 2017-11-08T07:44:55Z Create index without unnecessary classes. commit 9b4c5955f83a395f1a7db9e98de76c77ecdf7793 Author: devozerov Date: 2017-11-08T08:03:33Z Tests. commit ee602d25cfe75143807e7304cf0e9f2b5721eb96 Author: devozerov Date: 2017-11-08T14:27:13Z Merge branch 'master' into ignite-6840 commit b2b73297c66106918ec9b2188f92bea52b3dbeb9 Author: devozerov Date: 2017-11-08T14:34:17Z Finalization. > SQL: Parser: support CREATE INDEX command > - > > Key: IGNITE-6840 > URL: https://issues.apache.org/jira/browse/IGNITE-6840 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6840) SQL: Parser: support CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244042#comment-16244042 ] Vladimir Ozerov commented on IGNITE-6840: - Final test run: https://ci.ignite.apache.org/viewQueued.html?itemId=934365 > SQL: Parser: support CREATE INDEX command > - > > Key: IGNITE-6840 > URL: https://issues.apache.org/jira/browse/IGNITE-6840 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6844) Additional JMX metrics for cluster monitoring.
Pavel Pereslegin created IGNITE-6844: Summary: Additional JMX metrics for cluster monitoring. Key: IGNITE-6844 URL: https://issues.apache.org/jira/browse/IGNITE-6844 Project: Ignite Issue Type: Improvement Security Level: Public (Viewable by anyone) Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin For some monitoring tasks we need to access these metrics through JMX: 1. Total server nodes in cluster. 2. Current topology version. We can’t access them via JMX for now -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6840) SQL: Parser: support CREATE INDEX command
[ https://issues.apache.org/jira/browse/IGNITE-6840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244042#comment-16244042 ] Vladimir Ozerov edited comment on IGNITE-6840 at 11/8/17 2:42 PM: -- Final test run: https://ci.ignite.apache.org/viewQueued.html?itemId=934374 was (Author: vozerov): Final test run: https://ci.ignite.apache.org/viewQueued.html?itemId=934365 > SQL: Parser: support CREATE INDEX command > - > > Key: IGNITE-6840 > URL: https://issues.apache.org/jira/browse/IGNITE-6840 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6836) ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
[
https://issues.apache.org/jira/browse/IGNITE-6836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-6836:
Fix Version/s: 2.4
> ODBC: Add support for SQL_ATTR_QUERY_TIMEOUT
>
>
> Key: IGNITE-6836
> URL: https://issues.apache.org/jira/browse/IGNITE-6836
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
> Components: odbc
>Affects Versions: 2.1
>Reporter: Alexey Popov
>Assignee: Igor Sapego
> Fix For: 2.4
>
>
> It would be great if we can support {{SQL_ATTR_QUERY_TIMEOUT}} at ODBC.
> That gives a flexibility to end-user code to handle long-running/timeouted
> queries.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6762) SparseDistributedMatrixExample failed with NPE
[
https://issues.apache.org/jira/browse/IGNITE-6762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244075#comment-16244075
]
ASF GitHub Bot commented on IGNITE-6762:
GitHub user ybabak opened a pull request:
https://github.com/apache/ignite/pull/3003
IGNITE-6762: SparseDistributedMatrixExample failed with NPE.
Fixed.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6762
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3003.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3003
commit 51cae84a705042e123a063ef0e32d6e1b910
Author: Yury Babak
Date: 2017-11-03T13:01:39Z
IGNITE-6762: SparseDistributedMatrixExample failed with NPE.
Fixed.
> SparseDistributedMatrixExample failed with NPE
> --
>
> Key: IGNITE-6762
> URL: https://issues.apache.org/jira/browse/IGNITE-6762
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: examples, ml
>Affects Versions: 2.3
>Reporter: Sergey Kozlov
>Assignee: Yury Babak
>Priority: Critical
> Fix For: 2.4
>
>
> 1. Open ignite-examples project in IDEA
> 2. Start 3 nodes by {{ExampleNodeStartup}}
> 3. Run {{SparseDistributedMatrixExample}}. It throws the exception:
> {noformat}
> >>> Ignite grid started.
> >>> Create new SparseDistributedMatrix inside IgniteThread.
> Exception in thread "SparseDistributedMatrixExample-#51"
> java.lang.NullPointerException
> at
> org.apache.ignite.ml.math.distributed.CacheUtils.sum(CacheUtils.java:170)
> at
> org.apache.ignite.ml.math.distributed.CacheUtils.sparseSum(CacheUtils.java:160)
> at
> org.apache.ignite.ml.math.impls.matrix.SparseDistributedMatrix.sum(SparseDistributedMatrix.java:185)
> at
> org.apache.ignite.examples.ml.math.matrix.SparseDistributedMatrixExample.lambda$main$1(SparseDistributedMatrixExample.java:58)
> at java.lang.Thread.run(Thread.java:745)
> [15:28:44] Ignite node stopped OK [uptime=00:00:04.399]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-5749) SQL: add ALL condition support.
[ https://issues.apache.org/jira/browse/IGNITE-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-5749: - Attachment: SqlAnyAll.java > SQL: add ALL condition support. > --- > > Key: IGNITE-5749 > URL: https://issues.apache.org/jira/browse/IGNITE-5749 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Andrew Mashenkov > Attachments: SqlAnyAll.java > > > H2 supports ALL,ANY,SOME (same as ANY) conditions. > Ignite seems supports ANY condition and rewrite it to IN condition. > But using ALL condition results with an error. > Seems, we can add support of ALL condition for queries with collocated flag > without serious changes in code. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6276) SQL: Investigate parser generators
[ https://issues.apache.org/jira/browse/IGNITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244102#comment-16244102 ] Sergey Kalashnikov commented on IGNITE-6276: We have identified several shortcomings with the generated parser approach. - Error messages generated by parser are not customizable enough to the point when user may easily understand them. I doubt a user will understand messages like 'no viable alternative'. - The ANTLR lexer cannot be controlled by parser making many useful things impossible. - The performance assesment results aren't really great in terms of scalability. > SQL: Investigate parser generators > -- > > Key: IGNITE-6276 > URL: https://issues.apache.org/jira/browse/IGNITE-6276 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > Attachments: antlr4-ignite.zip > > > Now ignite relies on H2 for SQL processing. It has been discussed many times > on dev list that we must start introducing our own SQL core in small > incremental steps. > Let's start with analyzing the options for implementing the parser part. > We may begin with http://www.antlr.org/ and create a simple separate project > that would generate the parser for some simple DDL commands like DROP INDEX. > This will give us a hint on the complexity and limitations of the approach. > 1) Set up Maven/ANTLR. > 2) Prepare lexer/parser. > 3) Generate. > 4) Write a test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6276) SQL: Investigate parser generators
[ https://issues.apache.org/jira/browse/IGNITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kalashnikov updated IGNITE-6276: --- Attachment: IGNITE-6276.patch > SQL: Investigate parser generators > -- > > Key: IGNITE-6276 > URL: https://issues.apache.org/jira/browse/IGNITE-6276 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > Attachments: IGNITE-6276.patch, antlr4-ignite.zip > > > Now ignite relies on H2 for SQL processing. It has been discussed many times > on dev list that we must start introducing our own SQL core in small > incremental steps. > Let's start with analyzing the options for implementing the parser part. > We may begin with http://www.antlr.org/ and create a simple separate project > that would generate the parser for some simple DDL commands like DROP INDEX. > This will give us a hint on the complexity and limitations of the approach. > 1) Set up Maven/ANTLR. > 2) Prepare lexer/parser. > 3) Generate. > 4) Write a test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (IGNITE-6276) SQL: Investigate parser generators
[ https://issues.apache.org/jira/browse/IGNITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kalashnikov closed IGNITE-6276. -- > SQL: Investigate parser generators > -- > > Key: IGNITE-6276 > URL: https://issues.apache.org/jira/browse/IGNITE-6276 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > Attachments: IGNITE-6276.patch, antlr4-ignite.zip > > > Now ignite relies on H2 for SQL processing. It has been discussed many times > on dev list that we must start introducing our own SQL core in small > incremental steps. > Let's start with analyzing the options for implementing the parser part. > We may begin with http://www.antlr.org/ and create a simple separate project > that would generate the parser for some simple DDL commands like DROP INDEX. > This will give us a hint on the complexity and limitations of the approach. > 1) Set up Maven/ANTLR. > 2) Prepare lexer/parser. > 3) Generate. > 4) Write a test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6320) SQL: ANTLR performance assessment
[ https://issues.apache.org/jira/browse/IGNITE-6320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kalashnikov resolved IGNITE-6320. Resolution: Won't Fix > SQL: ANTLR performance assessment > - > > Key: IGNITE-6320 > URL: https://issues.apache.org/jira/browse/IGNITE-6320 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > > Proposed process: > 1) Download MySQL grammar [1] > 2) Generate parser > 3) Measure parsing performance for both simple and complex SQL queries with > JMH. > 4) Analyze the numbers > [1] https://github.com/antlr/grammars-v4/tree/master/mysql -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6276) SQL: Investigate parser generators
[ https://issues.apache.org/jira/browse/IGNITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244102#comment-16244102 ] Sergey Kalashnikov edited comment on IGNITE-6276 at 11/8/17 3:15 PM: - We have identified several shortcomings with the generated parser approach. - Error messages generated by parser are not customizable enough to the point when user may easily understand them. I doubt a user will understand messages like 'no viable alternative'. - The ANTLR lexer cannot be controlled by parser making many useful things impossible. - The performance assesment results aren't really great in terms of scalability. I have attached a patch for history purposes. was (Author: skalashnikov): We have identified several shortcomings with the generated parser approach. - Error messages generated by parser are not customizable enough to the point when user may easily understand them. I doubt a user will understand messages like 'no viable alternative'. - The ANTLR lexer cannot be controlled by parser making many useful things impossible. - The performance assesment results aren't really great in terms of scalability. > SQL: Investigate parser generators > -- > > Key: IGNITE-6276 > URL: https://issues.apache.org/jira/browse/IGNITE-6276 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > Attachments: IGNITE-6276.patch, antlr4-ignite.zip > > > Now ignite relies on H2 for SQL processing. It has been discussed many times > on dev list that we must start introducing our own SQL core in small > incremental steps. > Let's start with analyzing the options for implementing the parser part. > We may begin with http://www.antlr.org/ and create a simple separate project > that would generate the parser for some simple DDL commands like DROP INDEX. > This will give us a hint on the complexity and limitations of the approach. > 1) Set up Maven/ANTLR. > 2) Prepare lexer/parser. > 3) Generate. > 4) Write a test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (IGNITE-6276) SQL: Investigate parser generators
[ https://issues.apache.org/jira/browse/IGNITE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kalashnikov resolved IGNITE-6276. Resolution: Won't Fix > SQL: Investigate parser generators > -- > > Key: IGNITE-6276 > URL: https://issues.apache.org/jira/browse/IGNITE-6276 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergey Kalashnikov >Assignee: Sergey Kalashnikov > Fix For: 2.4 > > Attachments: IGNITE-6276.patch, antlr4-ignite.zip > > > Now ignite relies on H2 for SQL processing. It has been discussed many times > on dev list that we must start introducing our own SQL core in small > incremental steps. > Let's start with analyzing the options for implementing the parser part. > We may begin with http://www.antlr.org/ and create a simple separate project > that would generate the parser for some simple DDL commands like DROP INDEX. > This will give us a hint on the complexity and limitations of the approach. > 1) Set up Maven/ANTLR. > 2) Prepare lexer/parser. > 3) Generate. > 4) Write a test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6844) Additional JMX metrics for cluster monitoring.
[
https://issues.apache.org/jira/browse/IGNITE-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-6844:
-
Description:
For some monitoring tasks we need to access these metrics through JMX:
1. Total server nodes in cluster.
2. Current topology version.
We can’t access them via JMX for now.
I suggest to add new management bean IgniteClusterMBean that will provide such
information.
@MXBeanDescription("Server nodes count.")
public int getTotalServerNodes();
@MXBeanDescription("Last topology version.")
public long getTopologyVersion();
was:
For some monitoring tasks we need to access these metrics through JMX:
1. Total server nodes in cluster.
2. Current topology version.
We can’t access them via JMX for now
> Additional JMX metrics for cluster monitoring.
> --
>
> Key: IGNITE-6844
> URL: https://issues.apache.org/jira/browse/IGNITE-6844
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>
> For some monitoring tasks we need to access these metrics through JMX:
> 1. Total server nodes in cluster.
> 2. Current topology version.
> We can’t access them via JMX for now.
> I suggest to add new management bean IgniteClusterMBean that will provide
> such information.
> @MXBeanDescription("Server nodes count.")
> public int getTotalServerNodes();
> @MXBeanDescription("Last topology version.")
> public long getTopologyVersion();
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6844) Additional JMX metrics for cluster monitoring.
[
https://issues.apache.org/jira/browse/IGNITE-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-6844:
-
Description:
For some monitoring tasks we need to access these metrics through JMX:
1. Total server nodes in cluster.
2. Current topology version.
We can’t access them via JMX for now.
I suggest to add new management bean IgniteClusterMBean that will provide such
information.
{code:java}
@MXBeanDescription("Server nodes count.")
public int getTotalServerNodes();
@MXBeanDescription("Current topology version.")
public long getTopologyVersion();
{code}
was:
For some monitoring tasks we need to access these metrics through JMX:
1. Total server nodes in cluster.
2. Current topology version.
We can’t access them via JMX for now.
I suggest to add new management bean IgniteClusterMBean that will provide such
information.
@MXBeanDescription("Server nodes count.")
public int getTotalServerNodes();
@MXBeanDescription("Last topology version.")
public long getTopologyVersion();
> Additional JMX metrics for cluster monitoring.
> --
>
> Key: IGNITE-6844
> URL: https://issues.apache.org/jira/browse/IGNITE-6844
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>
> For some monitoring tasks we need to access these metrics through JMX:
> 1. Total server nodes in cluster.
> 2. Current topology version.
> We can’t access them via JMX for now.
> I suggest to add new management bean IgniteClusterMBean that will provide
> such information.
> {code:java}
> @MXBeanDescription("Server nodes count.")
> public int getTotalServerNodes();
> @MXBeanDescription("Current topology version.")
> public long getTopologyVersion();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6844) Additional JMX metrics for cluster monitoring.
[
https://issues.apache.org/jira/browse/IGNITE-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-6844:
-
Affects Version/s: 2.3
> Additional JMX metrics for cluster monitoring.
> --
>
> Key: IGNITE-6844
> URL: https://issues.apache.org/jira/browse/IGNITE-6844
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.3
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
> Fix For: 2.4
>
>
> For some monitoring tasks we need to access these metrics through JMX:
> 1. Total server nodes in cluster.
> 2. Current topology version.
> We can’t access them via JMX for now.
> I suggest to add new management bean IgniteClusterMBean that will provide
> such information.
> {code:java}
> @MXBeanDescription("Server nodes count.")
> public int getTotalServerNodes();
> @MXBeanDescription("Current topology version.")
> public long getTopologyVersion();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6844) Additional JMX metrics for cluster monitoring.
[
https://issues.apache.org/jira/browse/IGNITE-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-6844:
-
Fix Version/s: 2.4
> Additional JMX metrics for cluster monitoring.
> --
>
> Key: IGNITE-6844
> URL: https://issues.apache.org/jira/browse/IGNITE-6844
> Project: Ignite
> Issue Type: Improvement
> Security Level: Public(Viewable by anyone)
>Affects Versions: 2.3
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
> Fix For: 2.4
>
>
> For some monitoring tasks we need to access these metrics through JMX:
> 1. Total server nodes in cluster.
> 2. Current topology version.
> We can’t access them via JMX for now.
> I suggest to add new management bean IgniteClusterMBean that will provide
> such information.
> {code:java}
> @MXBeanDescription("Server nodes count.")
> public int getTotalServerNodes();
> @MXBeanDescription("Current topology version.")
> public long getTopologyVersion();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244384#comment-16244384
]
Tim Onyschak commented on IGNITE-6767:
--
Patch has been updated with suggested changes.
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned, atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6845) WebSessionFilter cannot handle liberty session ids
Andreas Weber created IGNITE-6845: - Summary: WebSessionFilter cannot handle liberty session ids Key: IGNITE-6845 URL: https://issues.apache.org/jira/browse/IGNITE-6845 Project: Ignite Issue Type: Bug Security Level: Public (Viewable by anyone) Reporter: Andreas Weber h2. Problem: Websphere Liberty creates session ids in the following form (way the session id is serialized in the cookie): : e.g. 3XeX_c5NHR5fJLYufFzt5ka:a3e94cfd-b391-4d9b-b9e7-6ddfcbf8c334 If a request is received by the same instance where the session was created, the requested session id is only the part. If a request is received by the another instance, the requested session id is the complete : Because of this behavior, Ignite searches for : in the cache, but only was stored. h2. Solution: Implement a sessionIdTransformer for Websphere Liberty that normalizes : to -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6845) WebSessionFilter cannot handle liberty session ids
[ https://issues.apache.org/jira/browse/IGNITE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244555#comment-16244555 ] Andreas Weber commented on IGNITE-6845: --- Pull Request: https://github.com/apache/ignite/pull/2994 > WebSessionFilter cannot handle liberty session ids > -- > > Key: IGNITE-6845 > URL: https://issues.apache.org/jira/browse/IGNITE-6845 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Andreas Weber > > h2. Problem: > Websphere Liberty creates session ids in the following form (way the session > id is serialized in the cookie): > : > e.g. 3XeX_c5NHR5fJLYufFzt5ka:a3e94cfd-b391-4d9b-b9e7-6ddfcbf8c334 > If a request is received by the same instance where the session was created, > the requested session id is only the part. > If a request is received by the another instance, the requested session id is > the complete > : > Because of this behavior, Ignite searches for : in > the cache, but only was stored. > h2. Solution: > Implement a sessionIdTransformer for Websphere Liberty that normalizes > : to -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6845) WebSessionFilter cannot handle liberty session ids
[ https://issues.apache.org/jira/browse/IGNITE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andreas Weber updated IGNITE-6845: -- Priority: Minor (was: Major) > WebSessionFilter cannot handle liberty session ids > -- > > Key: IGNITE-6845 > URL: https://issues.apache.org/jira/browse/IGNITE-6845 > Project: Ignite > Issue Type: Bug > Security Level: Public(Viewable by anyone) >Reporter: Andreas Weber >Priority: Minor > > h2. Problem: > Websphere Liberty creates session ids in the following form (way the session > id is serialized in the cookie): > : > e.g. 3XeX_c5NHR5fJLYufFzt5ka:a3e94cfd-b391-4d9b-b9e7-6ddfcbf8c334 > If a request is received by the same instance where the session was created, > the requested session id is only the part. > If a request is received by the another instance, the requested session id is > the complete > : > Because of this behavior, Ignite searches for : in > the cache, but only was stored. > h2. Solution: > Implement a sessionIdTransformer for Websphere Liberty that normalizes > : to -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6687) SQL Error Codes Documentation
[ https://issues.apache.org/jira/browse/IGNITE-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6687: --- Assignee: Prachi Garg (was: Igor Sapego) > SQL Error Codes Documentation > - > > Key: IGNITE-6687 > URL: https://issues.apache.org/jira/browse/IGNITE-6687 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg > Fix For: 2.4 > > > Presently we have JDBC error codes documented: > https://apacheignite-sql.readme.io/docs/jdbc-error-codes > Two things have to be done: > * If there are similar error codes shared between the ODBC and JDBC drivers, > and native APIs then let's put them under SQL reference category below Data > Types: https://apacheignite-sql.readme.io/docs/sql-reference-overview > * ODBC specific error codes with an example of an error handling need to be > listed in ODBC category [~isapego], please assist with this: > https://apacheignite-sql.readme.io/docs/odbc-driver > Discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/SQL-error-codes-td23415.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6687) SQL Error Codes Documentation
[ https://issues.apache.org/jira/browse/IGNITE-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244569#comment-16244569 ] Denis Magda commented on IGNITE-6687: - [~isapego], excellent! That's exactly what we need. [~pgarg], please do a final review and close the ticket. > SQL Error Codes Documentation > - > > Key: IGNITE-6687 > URL: https://issues.apache.org/jira/browse/IGNITE-6687 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Denis Magda >Assignee: Igor Sapego > Fix For: 2.4 > > > Presently we have JDBC error codes documented: > https://apacheignite-sql.readme.io/docs/jdbc-error-codes > Two things have to be done: > * If there are similar error codes shared between the ODBC and JDBC drivers, > and native APIs then let's put them under SQL reference category below Data > Types: https://apacheignite-sql.readme.io/docs/sql-reference-overview > * ODBC specific error codes with an example of an error handling need to be > listed in ODBC category [~isapego], please assist with this: > https://apacheignite-sql.readme.io/docs/odbc-driver > Discussion on the dev list: > http://apache-ignite-developers.2346864.n4.nabble.com/SQL-error-codes-td23415.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6064: --- Assignee: Alexey Kuznetsov > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin >Assignee: Alexey Kuznetsov >Priority: Blocker > Labels: usability > Fix For: 2.4 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." > 5. Document the usage on a special page. Ping Denis Magda when it's time to > do that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6846) Add metrics for entry processor invocations
Valentin Kulichenko created IGNITE-6846:
---
Summary: Add metrics for entry processor invocations
Key: IGNITE-6846
URL: https://issues.apache.org/jira/browse/IGNITE-6846
Project: Ignite
Issue Type: Improvement
Security Level: Public (Viewable by anyone)
Components: cache
Affects Versions: 2.3
Reporter: Valentin Kulichenko
{{CacheMetrics}} object has multiple metrics for various cache operations like
{{get}}, {{put}} and {{remove}}, but nothing for {{invoke}}/{{EntryProcessor}}.
It makes sense to add such metrics, for example:
* Total number of `invoke` operations executed.
* Number of `invoke` operations that included updates.
* Number of read-only `invoke` operations.
* Min/max/avg execution time.
* ...
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6698) Document CREATE TABLE "DATA_REGION" option
[ https://issues.apache.org/jira/browse/IGNITE-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prachi Garg reassigned IGNITE-6698: --- Assignee: Denis Magda (was: Prachi Garg) > Document CREATE TABLE "DATA_REGION" option > -- > > Key: IGNITE-6698 > URL: https://issues.apache.org/jira/browse/IGNITE-6698 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Denis Magda >Priority: Critical > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6698) Document CREATE TABLE "DATA_REGION" option
[ https://issues.apache.org/jira/browse/IGNITE-6698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16244768#comment-16244768 ] Prachi Garg commented on IGNITE-6698: - I have some edits to the content of the page - https://apacheignite-sql.readme.io/docs/create-table [~dmagda], Please review. > Document CREATE TABLE "DATA_REGION" option > -- > > Key: IGNITE-6698 > URL: https://issues.apache.org/jira/browse/IGNITE-6698 > Project: Ignite > Issue Type: Task > Security Level: Public(Viewable by anyone) > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Prachi Garg >Priority: Critical > Fix For: 2.4 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-6767:
--
Fix Version/s: 2.4
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
>Assignee: Semen Boikov
> Fix For: 2.4
>
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned, atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6767) NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns the primary partition for the given key, left the cluster.
[
https://issues.apache.org/jira/browse/IGNITE-6767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan reassigned IGNITE-6767:
-
Assignee: Semen Boikov
> NearCache#localPeek(key, NEAR) always returns 'null' if the node, which owns
> the primary partition for the given key, left the cluster.
> ---
>
> Key: IGNITE-6767
> URL: https://issues.apache.org/jira/browse/IGNITE-6767
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: cache
>Affects Versions: 2.1
>Reporter: Vyacheslav Koptilin
>Assignee: Semen Boikov
> Fix For: 2.4
>
> Attachments: GridCacheNearClientHitTest.java
>
>
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns 'null' if the
> node, which owns the primary partition for the given key, left the cluster,
> even if {{IgniteCache.get(key)}} was called.
> How to reproduce:
> # start two server nodes.
> # create partitioned, atomic cache and populate data.
> # start client node with near cache configured.
> # perform {{IgniteCache.get(key)}} and check that
> {{IgniteCache.localPeek(key, PeekMode.NEAR)}} returns not null value.
> # stop server node which owns primary partition for the given {{key}}.
> # perform {{IgniteCache.get(key)}}.
> # after that {{IgniteCache.localPeek(key, PeekMode.NEAR)}} always returns
> null value.
> This issue was reported on the user-list:
> http://apache-ignite-users.70518.x6.nabble.com/Near-Cache-Topoolgy-change-causes-NearCache-to-always-miss-tt17539.html
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Closed] (IGNITE-6741) GridRestProcessor doesn't support authorization on CLUSTER_ACTIVE command.
[
https://issues.apache.org/jira/browse/IGNITE-6741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan closed IGNITE-6741.
-
> GridRestProcessor doesn't support authorization on CLUSTER_ACTIVE command.
> --
>
> Key: IGNITE-6741
> URL: https://issues.apache.org/jira/browse/IGNITE-6741
> Project: Ignite
> Issue Type: Bug
> Security Level: Public(Viewable by anyone)
> Components: rest
>Affects Versions: 2.2
>Reporter: Andrew Mashenkov
> Fix For: 2.3
>
>
> I've found we have a enum GridRestCommand.CLUSTER_ACTIVE,
> but looks like it is not supported by GridRestProcessor and
> enum SecurityPermission doesn't support any permission for cluster
> activation.
> Also CLUSTER_INACTIVE has same issues.
> So, cluster can't be activated with security plugin due to ERROR.
> See userlist thread for details [#\[1\]]
> {code:java}
> id=d2e2b816-61e3-47ff-9d88-ae4c8b3eb2ae, login=null
> 10-23 20:48:30.051 [rest-#47%cdev_cluster%] ERROR
> internal.processors.rest.GridRestProcessor - Client request execution failed
> with error.
> java.lang.AssertionError: Unexpected command: CLUSTER_ACTIVE
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.authorize(GridRestProcessor.java:817)
>
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.handleRequest(GridRestProcessor.java:250)
>
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor.access$100(GridRestProcessor.java:91)
>
> at
> org.apache.ignite.internal.processors.rest.GridRestProcessor$2.body(GridRestProcessor.java:157)
>
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>
> at
> {code}
> [^http://apache-ignite-users.70518.x6.nabble.com/Cannot-activate-Ignite-with-custom-security-plugin-tt17687.html]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6847) Add an ability to provide custom per operation context
Valentin Kulichenko created IGNITE-6847:
---
Summary: Add an ability to provide custom per operation context
Key: IGNITE-6847
URL: https://issues.apache.org/jira/browse/IGNITE-6847
Project: Ignite
Issue Type: Improvement
Security Level: Public (Viewable by anyone)
Components: general
Affects Versions: 2.3
Reporter: Valentin Kulichenko
Sometimes it's useful to attach custom context information to a distributed
operation. For example, an application that uses Ignite cluster may want to
provide its own ID or name so that it could then be used on other nodes for
auditing purposes.
To support this, we can introduce {{withTag(Serializable tag)}} method on
{{IgniteCache}}, {{IgniteCompute}} and other APIs. If provided, tag is attached
to every remote request and propagated to log messages, events, etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6824) Web Console: migrate from angularjs 1.5 to angular 1.6
[ https://issues.apache.org/jira/browse/IGNITE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-6824: - Assignee: Alexander Kalinin (was: Pavel Konstantinov) > Web Console: migrate from angularjs 1.5 to angular 1.6 > -- > > Key: IGNITE-6824 > URL: https://issues.apache.org/jira/browse/IGNITE-6824 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Minor > Fix For: 2.4 > > > angularjs 1.5 version is legacy, let's migrate to last stable version 1.6 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda updated IGNITE-1903:
Labels: community usability (was: community)
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
> Labels: community, usability
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan updated IGNITE-1903:
--
Fix Version/s: 2.4
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
> Labels: community, usability
> Fix For: 2.4
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-1903) Cache configuration is serialized to nodes whether they require it or not
[
https://issues.apache.org/jira/browse/IGNITE-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Setrakyan reassigned IGNITE-1903:
-
Assignee: Vladimir Ozerov
> Cache configuration is serialized to nodes whether they require it or not
> -
>
> Key: IGNITE-1903
> URL: https://issues.apache.org/jira/browse/IGNITE-1903
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Michael Griggs
>Assignee: Vladimir Ozerov
> Labels: community, usability
> Fix For: 2.4
>
>
> See User discussion thread:
> http://apache-ignite-users.70518.x6.nabble.com/CacheStore-being-serialized-to-client-td1931.html
> Brief summary: When a grid client joins the grid (clientMode=true) it
> receives a message from the server node(s) on the grid that contains the
> serialized CacheStore implementation object. If the client does not have
> this class on its CLASSPATH (and there is no reason it should, as it is a
> client) then the de-serialization of this message will fail, causing this
> exception:
> {code}SEVERE: Failed to unmarshal discovery data for component: 1
> class org.apache.ignite.IgniteCheckedException: Failed to find class with
> given class loader for unmarshalling (make sure same versions of all classes
> are available on all nodes or enable peer-class-loading):
> sun.misc.Launcher$AppClassLoader@14dad5dc
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal(JdkMarshaller.java:104)
>
> at
> org.apache.ignite.marshaller.AbstractMarshaller.unmarshal(AbstractMarshaller.java:67)
>
> at
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.onExchange(TcpDiscoverySpi.java:1529)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processNodeAddFinishedMessage(ClientImpl.java:1317)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.processDiscoveryMessage(ClientImpl.java:1229)
>
> at
> org.apache.ignite.spi.discovery.tcp.ClientImpl$MessageWorker.body(ClientImpl.java:1199)
>
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> Caused by: java.lang.ClassNotFoundException:
> c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite
> {code}
> where {{c.g.r.cachewrapper.ignite.CacheMissHandlerIgnite}} is the CacheStore
> implementation.
> The ostensible reason for the CacheStore serialization is so that clients of
> a TRANSACTIONAL cache can begin the transaction on the underlying store.
> The only current solution to this is to add the grid node's CacheStore
> implementation class definition to the CLASSPATH of the client. This creates
> an *undesirable coupling* between server and client.
> ---
> *UPDATE (copy-paste from comment below)*
> This is actually more generic issue. When a new node joins (client or
> server), all existing cache configurations (which include cache stores) are
> sent to this node. It then deserializes it during startup which can cause
> exceptions on clients or servers where cache is not supposed to be deployed
> as defined by node filter.
> As a solution we can do the following:
> * During discovery, send node filter and cache store factory in binary format
> along with the cache configuration, not as its parts.
> * On server, check node filter first and deserialize cache configuration and
> cache store only if it returns true. In case of error, STOP join process (now
> we just print exception in log and go on, which is very error-prone).
> * On client, do not deserialize cache configuration and cache store until
> user's code tries to actually use the cache (calls Ignite.cache. If cache is
> ATOMIC, never deserialize the cache store.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[ https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan reassigned IGNITE-6804: - Assignee: Vladimir Ozerov > Print a warning if HashMap is passed into bulk update operations > > > Key: IGNITE-6804 > URL: https://issues.apache.org/jira/browse/IGNITE-6804 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: cache >Reporter: Denis Magda >Assignee: Vladimir Ozerov >Priority: Critical > Labels: usability > Fix For: 2.4 > > > Ignite newcomers tend to stumble on deadlocks simply because the keys are > passed in an unordered HashMap. Propose to do the following: > * update bulk operations Java docs. > * print out a warning if not SortedMap (e.g. HashMap, > Weak/Identity/Concurrent/Linked HashMap etc) is passed into > a bulk method (instead of SortedMap) and contains more than 1 element. > However, we should make sure that we only print that warning once and not > every time the API is called. > * do not produce warning for explicit optimistic transactions > More details are here: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6735) Java 9: fix Java version resolution/check logic
[
https://issues.apache.org/jira/browse/IGNITE-6735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
of.salakhutdinov reassigned IGNITE-6735:
Assignee: of.salakhutdinov
> Java 9: fix Java version resolution/check logic
> ---
>
> Key: IGNITE-6735
> URL: https://issues.apache.org/jira/browse/IGNITE-6735
> Project: Ignite
> Issue Type: Task
> Security Level: Public(Viewable by anyone)
> Components: general
>Reporter: Vladimir Ozerov
>Assignee: of.salakhutdinov
> Fix For: 2.4
>
>
> We have several places in the code where Java version is validated. First,
> sometimes we do not take in count Java 9 at all. Second, sometimes we rely on
> old version pattern {{1.x}}, while as of Java 9 it is just {{x}}.
> Places to fix:
> 1) {{GridDiscoveryManager.nodeJavaMajorVersion}} - add support for new Java
> version format without {{1.}} prefix.
> 2) {{IgnitionEx.}} - add Java 9 to the list of supported
> versions.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-6824) Web Console: migrate from angularjs 1.5 to angular 1.6
[ https://issues.apache.org/jira/browse/IGNITE-6824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-6824: - Assignee: Pavel Konstantinov (was: Alexander Kalinin) Bugs with transclude have been fixed > Web Console: migrate from angularjs 1.5 to angular 1.6 > -- > > Key: IGNITE-6824 > URL: https://issues.apache.org/jira/browse/IGNITE-6824 > Project: Ignite > Issue Type: Improvement > Security Level: Public(Viewable by anyone) > Components: wizards >Reporter: Alexander Kalinin >Assignee: Pavel Konstantinov >Priority: Minor > Fix For: 2.4 > > > angularjs 1.5 version is legacy, let's migrate to last stable version 1.6 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
