[jira] [Commented] (IGNITE-8697) Flink sink throws java.lang.IllegalArgumentException when running in flink cluster mode.

2018-07-26 Thread Saikat Maitra (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559227#comment-16559227
 ] 

Saikat Maitra commented on IGNITE-8697:
---

[~amashenkov]

As we discussed I have updated the PR, please take a look. If it looks good I 
can go ahead and merge the changes.

Regards,
Saikat

> Flink sink throws java.lang.IllegalArgumentException when running in flink 
> cluster mode.
> 
>
> Key: IGNITE-8697
> URL: https://issues.apache.org/jira/browse/IGNITE-8697
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.3, 2.4, 2.5
>Reporter: Ray
>Priority: Blocker
>
> if I submit the Application to the Flink Cluster using Ignite flink sink I 
> get this error
>  
> java.lang.ExceptionInInitializerError
>   at 
> org.apache.ignite.sink.flink.IgniteSink$SinkContext.getStreamer(IgniteSink.java:201)
>   at 
> org.apache.ignite.sink.flink.IgniteSink$SinkContext.access$100(IgniteSink.java:175)
>   at org.apache.ignite.sink.flink.IgniteSink.invoke(IgniteSink.java:165)
>   at 
> org.apache.flink.streaming.api.functions.sink.SinkFunction.invoke(SinkFunction.java:52)
>   at 
> org.apache.flink.streaming.api.operators.StreamSink.processElement(StreamSink.java:56)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
>   at 
> org.apache.flink.streaming.api.operators.TimestampedCollector.collect(TimestampedCollector.java:51)
>   at 
> org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:97)
>   at 
> org.myorg.quickstart.InstrumentStreamer$Splitter.flatMap(InstrumentStreamer.java:1)
>   at 
> org.apache.flink.streaming.api.operators.StreamFlatMap.processElement(StreamFlatMap.java:50)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.pushToOperator(OperatorChain.java:560)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:535)
>   at 
> org.apache.flink.streaming.runtime.tasks.OperatorChain$CopyingChainingOutput.collect(OperatorChain.java:515)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:679)
>   at 
> org.apache.flink.streaming.api.operators.AbstractStreamOperator$CountingOutput.collect(AbstractStreamOperator.java:657)
>   at 
> org.apache.flink.streaming.api.operators.StreamSourceContexts$NonTimestampContext.collect(StreamSourceContexts.java:104)
>   at 
> org.apache.flink.streaming.api.functions.source.SocketTextStreamFunction.run(SocketTextStreamFunction.java:110)
>   at 
> org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:87)
>   at 
> org.apache.flink.streaming.api.operators.StreamSource.run(StreamSource.java:56)
>   at 
> org.apache.flink.streaming.runtime.tasks.SourceStreamTask.run(SourceStreamTask.java:99)
>   at 
> org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:306)
>   at org.apache.flink.runtime.taskmanager.Task.run(Task.java:703)
>   at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.IllegalArgumentException: Ouch! Argument is invalid: 
> Cache name must not be null or empty.
>   at 
> org.apache.ignite.internal.util.GridArgumentCheck.ensure(GridArgumentCheck.java:109)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheUtils.validateCacheName(GridCacheUtils.java:1581)
>   at 
> org.apache.ignite.internal.IgniteKernal.dataStreamer(IgniteKernal.java:3284)
>   at 
> org.apache.ignite.sink.flink.IgniteSink$SinkContext$Holder.(IgniteSink.java:183)
>   ... 27 more



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9100) Split Basic and Cache TC configurations on pure in-memory and with disk usage one

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16559022#comment-16559022
 ] 

ASF GitHub Bot commented on IGNITE-9100:


GitHub user EdShangGG opened a pull request:

https://github.com/apache/ignite/pull/4441

IGNITE-9100 Split Basic and Cache TC configurations on pure in-memory…

… and with disk usage one

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9100

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4441.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 #4441


commit 9bf7833d3c0abd761b21347b0e813ca41ce307ad
Author: Eduard Shangareev 
Date:   2018-07-26T22:57:57Z

IGNITE-9100 Split Basic and Cache TC configurations on pure in-memory and 
with disk usage one




> Split Basic and Cache TC configurations on pure in-memory and with disk usage 
> one
> -
>
> Key: IGNITE-9100
> URL: https://issues.apache.org/jira/browse/IGNITE-9100
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9100) Split Basic and Cache TC configurations on pure in-memory and with disk usage one

2018-07-26 Thread Eduard Shangareev (JIRA)
Eduard Shangareev created IGNITE-9100:
-

 Summary: Split Basic and Cache TC configurations on pure in-memory 
and with disk usage one
 Key: IGNITE-9100
 URL: https://issues.apache.org/jira/browse/IGNITE-9100
 Project: Ignite
  Issue Type: Improvement
Reporter: Eduard Shangareev
Assignee: Eduard Shangareev






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

2018-07-26 Thread Valentin Kulichenko (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558891#comment-16558891
 ] 

Valentin Kulichenko commented on IGNITE-8446:
-

[~avinogradov], changes make sense to me, however I would prefer if someone 
else who is more knowledgable in cache internal takes a look as well. I'm not 
100% sure that {{recordStateChangedEvent}} is invoked from a correct place and 
if there are no other places where this should happen.

I have couple usability related comments:
# Message provided for the event is {{null}}. This doesn't look good to me, 
every event should have an explanation about what happened.
# {{UnsupportedOperationException}}-s thrown by {{TransactionEventProxyImpl}} 
should contain a message describing the limitations.

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

2018-07-26 Thread Anton Vinogradov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558830#comment-16558830
 ] 

Anton Vinogradov commented on IGNITE-8446:
--

[~vkulichenko], PR updated

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

2018-07-26 Thread Valentin Kulichenko (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558807#comment-16558807
 ] 

Valentin Kulichenko commented on IGNITE-8446:
-

Anton, I can't merge the PR to master due to conflicts. Can you please check 
and fix?

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9099) IgniteCache java doc does not cover all possible exceptions

2018-07-26 Thread Mikhail Cherkasov (JIRA)
Mikhail Cherkasov created IGNITE-9099:
-

 Summary: IgniteCache java doc does not cover all possible 
exceptions
 Key: IGNITE-9099
 URL: https://issues.apache.org/jira/browse/IGNITE-9099
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Cherkasov


IgniteCache java doc does not cover all possible exceptions.

 

For example on if try to close cache after node stop there would be the 
following exception:

 
org.apache.ignite.IgniteException: Failed to execute dynamic cache change 
request, node is stopping.
        at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:986)
        at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.convertException(IgniteFutureImpl.java:168)
        at 
org.apache.ignite.internal.util.future.IgniteFutureImpl.get(IgniteFutureImpl.java:137)
        at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.close(GatewayProtectedCacheProxy.java:1346)
 
However, API for close method doesn't mention any exception at all.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9056) BinaryTypeMismatchLoggingTest.testEntryWriteQueryEntities is flaky

2018-07-26 Thread Ilya Kasnacheev (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558599#comment-16558599
 ] 

Ilya Kasnacheev commented on IGNITE-9056:
-

[~agoncharuk] please review proposed fix.

Note that it's written with assertion that this class will be removed soon.

> BinaryTypeMismatchLoggingTest.testEntryWriteQueryEntities is flaky
> --
>
> Key: IGNITE-9056
> URL: https://issues.apache.org/jira/browse/IGNITE-9056
> Project: Ignite
>  Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Ilya Kasnacheev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> The test fails because the captured message contains more than one occurence 
> of the payload value.
> Need to investigate the root cause.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9046) Actualize dependency versions for Cassandra Cache Store

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558533#comment-16558533
 ] 

ASF GitHub Bot commented on IGNITE-9046:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4422


> Actualize dependency versions for Cassandra Cache Store
> ---
>
> Key: IGNITE-9046
> URL: https://issues.apache.org/jira/browse/IGNITE-9046
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Nikolai kulagin
>Priority: Major
> Fix For: 2.7
>
>
> It is suggested 
> A. to update commons-beanutils version. It can be done using property 
> commons-beanutils.version in pom.xml:
> change 1.9.2 to latest version, currently it is 1.9.3
> http://central.maven.org/maven2/commons-beanutils/commons-beanutils/1.9.3/commons-beanutils-1.9.3.pom
>  
> B. Update Netty Project netty.version (currently 4.0.33.Final)
> Upgrade at least to 4.0.37.Final or later or to 4.1.1.Final or later
> It is required to run RunAll to check all tests passed, check full build 
> locally using build.sh.
> Probably it is required to run release step to make sure release candidate 
> can be prepared.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8766) TcpDiscoverySpi: discovery threads naming

2018-07-26 Thread Sergey Chugunov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558531#comment-16558531
 ] 

Sergey Chugunov commented on IGNITE-8766:
-

[~dkarachentsev],

Change looks good to me, I triggered TC Run All although there is only a 
minimal chance this improvement could break any tests.

In case on no test failures please proceed with merging.

Thank you for contribution!

> TcpDiscoverySpi: discovery threads naming
> -
>
> Key: IGNITE-8766
> URL: https://issues.apache.org/jira/browse/IGNITE-8766
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Sergey Chugunov
>Assignee: Dmitry Karachentsev
>Priority: Major
>  Labels: discovery
> Fix For: 2.7
>
>
> Including information about next/prev nodes into names of discovery-related 
> threads could be very helpful when investigating situations of network 
> glitches.
> tcp-disco-sock-reader and tcp-disco-msg-worker threads must include such 
> information in their names.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9098) IgniteCacheClientReconnectTest.testClientReconnectOnExchangeHistoryExhaustion is flaky after IGNITE-8998

2018-07-26 Thread Ilya Kasnacheev (JIRA)
Ilya Kasnacheev created IGNITE-9098:
---

 Summary: 
IgniteCacheClientReconnectTest.testClientReconnectOnExchangeHistoryExhaustion 
is flaky after IGNITE-8998
 Key: IGNITE-9098
 URL: https://issues.apache.org/jira/browse/IGNITE-9098
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Ilya Kasnacheev
Assignee: Anton Kalashnikov


Before 78e0bb7efbc53e969c4c4918b6c6272c7b98dc36 test always passed, but after 
this commit test fails sporadically, such as in 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ClientNodes=pull%2F4420%2Fhead=buildTypeStatusDiv

Not part of any released versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-6167) Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled TLS protocols and cipher suites

2018-07-26 Thread Mikhail Cherkasov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Cherkasov reassigned IGNITE-6167:
-

Assignee: Mikhail Cherkasov

> Ability to set custom SSLServerSocketFactory and SSLSocketFactory or enabled 
> TLS protocols and cipher suites
> 
>
> Key: IGNITE-6167
> URL: https://issues.apache.org/jira/browse/IGNITE-6167
> Project: Ignite
>  Issue Type: Wish
>  Components: security
>Affects Versions: 2.1
>Reporter: Jens Borgland
>Assignee: Mikhail Cherkasov
>Priority: Major
>
> It would be very useful to be able to, in addition to the 
> {{javax.net.ssl.SSLContext}}, either specify a custom 
> {{javax.net.ssl.SSLServerSocketFactory}} and a custom 
> {{javax.net.ssl.SSLSocketFactory}}, or to be able to at least specify the 
> enabled TLS protocols and cipher suites.
> I have noticed that the 
> {{org.apache.ignite.internal.util.nio.ssl.GridNioSslFilter}} has support for 
> the latter but I cannot find a way of getting a reference to the filter 
> instance. The {{GridNioSslFilter}} also isn't used by {{TcpDiscoverySpi}} as 
> far as I can tell.
> Currently (as far as I can tell) there is no way of specifying the enabled 
> cipher suites and protocols used by Ignite, without doing it globally for the 
> JRE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9097) CacheContinuousQueryOperationFromCallbackTest fails sporadically in master

2018-07-26 Thread Ilya Kasnacheev (JIRA)
Ilya Kasnacheev created IGNITE-9097:
---

 Summary: CacheContinuousQueryOperationFromCallbackTest fails 
sporadically in master
 Key: IGNITE-9097
 URL: https://issues.apache.org/jira/browse/IGNITE-9097
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Ilya Kasnacheev


Such as 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_ContinuousQuery1=pull%2F4420%2Fhead=buildTypeStatusDiv

It doesn't fail every time, but 2 out of 10, and the first run usually fails.

In 2.6 it doesn't!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9096) ContinuousProcessor fails to handle routines with classes loaded by P2P deployment mechanism

2018-07-26 Thread Sergey Chugunov (JIRA)
Sergey Chugunov created IGNITE-9096:
---

 Summary: ContinuousProcessor fails to handle routines with classes 
loaded by P2P deployment mechanism
 Key: IGNITE-9096
 URL: https://issues.apache.org/jira/browse/IGNITE-9096
 Project: Ignite
  Issue Type: Bug
  Components: zookeeper
Affects Versions: 2.6
Reporter: Sergey Chugunov
 Fix For: 2.7


When server node joins to the cluster where some CQ-routines were deployed with 
P2P deployment mechanism, it fails with the following exception:
{noformat}
class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
GridManagerAdapter [enabled=true, 
name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1760)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1051)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testServerJoinWithP2PClassDeployedInCluster(ZookeeperDiscoverySpiTest.java:404)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start SPI: 
ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
zkConnectionString=127.0.0.1:46727,127.0.0.1:36728,127.0.0.1:34199, 
joinTimeout=0, sesTimeout=1, clientReconnectDisabled=false, 
internalLsnr=null, 
stats=org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryStatistics@2c5b3f94]
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
at org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
... 19 more
Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to join 
cluster
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:713)
at 
org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:474)
at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
... 21 more
Caused by: class org.apache.ignite.IgniteCheckedException: null
at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7307)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at 
org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:700)
... 23 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1797)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.sendResourceRequest(GridDeploymentClassLoader.java:731)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.getResourceAsStream(GridDeploymentClassLoader.java:694)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.checkLoadRemoteClass(GridDeploymentPerVersionStore.java:717)
at 
org.apache.ignite.internal.managers.deployment.GridDeploymentPerVersionStore.getDeployment(GridDeploymentPerVersionStore.java:297)
at 

[jira] [Updated] (IGNITE-9096) ContinuousProcessor fails to handle routines with classes loaded by P2P deployment mechanism

2018-07-26 Thread Sergey Chugunov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-9096:

Ignite Flags:   (was: Docs Required)

> ContinuousProcessor fails to handle routines with classes loaded by P2P 
> deployment mechanism
> 
>
> Key: IGNITE-9096
> URL: https://issues.apache.org/jira/browse/IGNITE-9096
> Project: Ignite
>  Issue Type: Bug
>  Components: zookeeper
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Priority: Critical
> Fix For: 2.7
>
>
> When server node joins to the cluster where some CQ-routines were deployed 
> with P2P deployment mechanism, it fails with the following exception:
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to start manager: 
> GridManagerAdapter [enabled=true, 
> name=org.apache.ignite.internal.managers.discovery.GridDiscoveryManager]
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1760)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1051)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:882)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:845)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:799)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoverySpiTest.testServerJoinWithP2PClassDeployedInCluster(ZookeeperDiscoverySpiTest.java:404)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2087)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2002)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
> SPI: ZookeeperDiscoverySpi [zkRootPath=/apacheIgnite, 
> zkConnectionString=127.0.0.1:46727,127.0.0.1:36728,127.0.0.1:34199, 
> joinTimeout=0, sesTimeout=1, clientReconnectDisabled=false, 
> internalLsnr=null, 
> stats=org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryStatistics@2c5b3f94]
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:300)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1755)
> ... 19 more
> Caused by: class org.apache.ignite.spi.IgniteSpiException: Failed to join 
> cluster
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:713)
> at 
> org.apache.ignite.spi.discovery.zk.ZookeeperDiscoverySpi.spiStart(ZookeeperDiscoverySpi.java:474)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> ... 21 more
> Caused by: class org.apache.ignite.IgniteCheckedException: null
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7307)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:259)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:232)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
> at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
> at 
> org.apache.ignite.spi.discovery.zk.internal.ZookeeperDiscoveryImpl.startJoinAndWait(ZookeeperDiscoveryImpl.java:700)
> ... 23 more
> Caused by: java.lang.NullPointerException
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.node(GridDiscoveryManager.java:1797)
> at 
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader.sendResourceRequest(GridDeploymentClassLoader.java:731)
> at 
> 

[jira] [Created] (IGNITE-9095) IgnitePdsBinarySortObjectFieldsTest always fails due to assertion in master

2018-07-26 Thread Ilya Kasnacheev (JIRA)
Ilya Kasnacheev created IGNITE-9095:
---

 Summary: IgnitePdsBinarySortObjectFieldsTest always fails due to 
assertion in master
 Key: IGNITE-9095
 URL: https://issues.apache.org/jira/browse/IGNITE-9095
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Ilya Kasnacheev


For example 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexing=pull%2F4420%2Fhead=buildTypeStatusDiv

Worked in 2.6!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-8985) Node segmented itself after connRecoveryTimeout

2018-07-26 Thread Dmitry Karachentsev (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitry Karachentsev resolved IGNITE-8985.
-
Resolution: Won't Fix

Will be fixed by IGNITE-8944, no need to change loopback address detection, 
there is always will be space for false positive detection, and this should not 
influence on overall logic.

> Node segmented itself after connRecoveryTimeout
> ---
>
> Key: IGNITE-8985
> URL: https://issues.apache.org/jira/browse/IGNITE-8985
> Project: Ignite
>  Issue Type: Bug
>Reporter: Mikhail Cherkasov
>Assignee: Dmitry Karachentsev
>Priority: Major
> Attachments: Archive.zip
>
>
> I can see the following message in logs:
> [2018-07-10 16:27:13,111][WARN ][tcp-disco-msg-worker-#2] Unable to connect 
> to next nodes in a ring, it seems local node is experiencing connectivity 
> issues. Segmenting local node to avoid case when one node fails a big part of 
> cluster. To disable that behavior set 
> TcpDiscoverySpi.setConnectionRecoveryTimeout() to 0. 
> [connRecoveryTimeout=1, effectiveConnRecoveryTimeout=1]
> [2018-07-10 16:27:13,112][WARN ][disco-event-worker-#61] Local node 
> SEGMENTED: TcpDiscoveryNode [id=e1a19d8e-2253-458c-9757-e3372de3bef9, 
> addrs=[127.0.0.1, 172.17.0.1, 172.25.1.17], sockAddrs=[/172.17.0.1:47500, 
> lab17.gridgain.local/172.25.1.17:47500, /127.0.0.1:47500], discPort=47500, 
> order=2, intOrder=2, lastExchangeTime=1531229233103, loc=true, 
> ver=2.4.7#20180710-sha1:a48ae923, isClient=false]
> I have failure detection time out 60_000 and during the test I had GC 
> <25secs, so I don't expect that node should be segmented.
>  
> Logs are attached.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9094) Request for commit check is sent to backup nodes twice on primary node left.

2018-07-26 Thread Alexei Scherbakov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexei Scherbakov updated IGNITE-9094:
--
Description: 
This causes twice as needed messages during recovery.

First place:
{noformat}
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxFinishRequest.(GridDhtTxFinishRequest.java:161)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.checkCommittedRequest(GridNearTxFinishFuture.java:911)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.access$400(GridNearTxFinishFuture.java:71)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture$FinishMiniFuture.onNodeLeft(GridNearTxFinishFuture.java:1005)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:820)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:741)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:479)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3354)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at 
org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onDone(GridNearPessimisticTxPrepareFuture.java:409)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onDone(GridNearPessimisticTxPrepareFuture.java:58)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture$MiniFuture.onError(GridNearPessimisticTxPrepareFuture.java:515)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture$MiniFuture.onNodeLeft(GridNearPessimisticTxPrepareFuture.java:496)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onNodeLeft(GridNearPessimisticTxPrepareFuture.java:87)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager$4.onEvent(GridCacheMvccManager.java:266)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1384)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:873)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:858)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:341)
at 

[jira] [Created] (IGNITE-9094) Request for commit check is sent to backup nodes twice on primary node left.

2018-07-26 Thread Alexei Scherbakov (JIRA)
Alexei Scherbakov created IGNITE-9094:
-

 Summary: Request for commit check is sent to backup nodes twice on 
primary node left.
 Key: IGNITE-9094
 URL: https://issues.apache.org/jira/browse/IGNITE-9094
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
 Fix For: 2.7


This causes twice as needed messages during recovery.

First place:
{noformat}
at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxFinishRequest.(GridDhtTxFinishRequest.java:161)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.checkCommittedRequest(GridNearTxFinishFuture.java:911)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.access$400(GridNearTxFinishFuture.java:71)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture$FinishMiniFuture.onNodeLeft(GridNearTxFinishFuture.java:1005)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:820)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:741)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.doFinish(GridNearTxFinishFuture.java:479)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.finish(GridNearTxFinishFuture.java:417)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3354)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxLocal$19.apply(GridNearTxLocal.java:3335)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at 
org.apache.ignite.internal.processors.cache.GridCacheCompoundFuture.onDone(GridCacheCompoundFuture.java:56)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onDone(GridNearPessimisticTxPrepareFuture.java:409)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onDone(GridNearPessimisticTxPrepareFuture.java:58)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:451)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:285)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:144)
at 
org.apache.ignite.internal.util.future.GridCompoundFuture.apply(GridCompoundFuture.java:45)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(GridFutureAdapter.java:383)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(GridFutureAdapter.java:347)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter.java:335)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:495)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:474)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture$MiniFuture.onError(GridNearPessimisticTxPrepareFuture.java:515)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture$MiniFuture.onNodeLeft(GridNearPessimisticTxPrepareFuture.java:496)
at 
org.apache.ignite.internal.processors.cache.distributed.near.GridNearPessimisticTxPrepareFuture.onNodeLeft(GridNearPessimisticTxPrepareFuture.java:87)
at 
org.apache.ignite.internal.processors.cache.GridCacheMvccManager$4.onEvent(GridCacheMvccManager.java:266)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1384)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:873)
at 
org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:858)
at 

[jira] [Commented] (IGNITE-8446) Ability to check and completely fill transactions on creation

2018-07-26 Thread Anton Vinogradov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558374#comment-16558374
 ] 

Anton Vinogradov commented on IGNITE-8446:
--

[~dmagda] or [~vkulichenko], 
Could you please review the issue, since Yakov is not able to do this 
temporarily?

> Ability to check and completely fill transactions on creation
> -
>
> Key: IGNITE-8446
> URL: https://issues.apache.org/jira/browse/IGNITE-8446
> Project: Ignite
>  Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.7
>
>
> Since {{label}} added to {{tx}} at IGNITE-6827 we'd like to have ability to 
> guarantee it filled. 
> So, we have to add special event fired on {{tx}} creation. 
> This event can be used to provide such guarantee.
> Plan:
> Event EVT_TX_STARTED should be created.
> Tx.label should be recodred as a part of this event.
> Test, checking it's possible to restrict tx creation without filling the meta 
> should be added.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9073) Ignite modules should use jackson2 dependency rater then jackson1

2018-07-26 Thread Nikolai kulagin (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolai kulagin updated IGNITE-9073:

Summary: Ignite modules should use jackson2 dependency rater then jackson1  
(was: Module ignite-kubernetes should use jackson2 dependency rater then 
jackson1)

> Ignite modules should use jackson2 dependency rater then jackson1
> -
>
> Key: IGNITE-9073
> URL: https://issues.apache.org/jira/browse/IGNITE-9073
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Garus
>Assignee: Nikolai kulagin
>Priority: Major
> Fix For: 2.7
>
>
> Ignite modules should use jackson2 dependency rater then jackson1.
> It is required to run RunAll to check all tests passed, check full build 
> locally using build.sh.
> Probably it is required to run release step to make sure release candidate 
> can be prepared



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9073) Module ignite-kubernetes should use jackson2 dependency rater then jackson1

2018-07-26 Thread Nikolai kulagin (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolai kulagin updated IGNITE-9073:

Description: 
Ignite modules should use jackson2 dependency rater then jackson1.

It is required to run RunAll to check all tests passed, check full build 
locally using build.sh.

Probably it is required to run release step to make sure release candidate can 
be prepared

  was:
Module ignite-kubernetes should use jackson2 dependency rater then jackson1.

It is required to run RunAll to check all tests passed, check full build 
locally using build.sh.

Probably it is required to run release step to make sure release candidate can 
be prepared


> Module ignite-kubernetes should use jackson2 dependency rater then jackson1
> ---
>
> Key: IGNITE-9073
> URL: https://issues.apache.org/jira/browse/IGNITE-9073
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Denis Garus
>Assignee: Nikolai kulagin
>Priority: Major
> Fix For: 2.7
>
>
> Ignite modules should use jackson2 dependency rater then jackson1.
> It is required to run RunAll to check all tests passed, check full build 
> locally using build.sh.
> Probably it is required to run release step to make sure release candidate 
> can be prepared



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-8939) Transaction string reprsentation unhandled exception

2018-07-26 Thread Evgenii Zagumennov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgenii Zagumennov reassigned IGNITE-8939:
--

Assignee: Evgenii Zagumennov

> Transaction string reprsentation unhandled exception
> 
>
> Key: IGNITE-8939
> URL: https://issues.apache.org/jira/browse/IGNITE-8939
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Evgenii Zagumennov
>Assignee: Evgenii Zagumennov
>Priority: Major
>
> IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957)
> {code:java}
> U.error(log, "Failed completing transaction [commit=" + req.commit() + ", 
> tx=" + *tx* + ']', e);{code}
> tx.toString() can lead to excepion (in GridToStringBuilder.toStringImpl()), 
> and original exception in transaction will be lost. We need to log original 
> exception and catch probable tx.toString() exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8935) IgniteConfiguration dependents should have toString

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558339#comment-16558339
 ] 

ASF GitHub Bot commented on IGNITE-8935:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4318


> IgniteConfiguration dependents should have toString
> ---
>
> Key: IGNITE-8935
> URL: https://issues.apache.org/jira/browse/IGNITE-8935
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
> Fix For: 2.7
>
>
> Ignite configuration is printed on startup, but some classes which are 
> usually referred do not have toString() implemented, leading to gems such as 
> connectorCfg=org.apache.ignite.configuration.ConnectorConfiguration@7d8704ef
> Those classes should have toString implemented which will conform to 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-StringOutput



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-8935) IgniteConfiguration dependents should have toString

2018-07-26 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-8935:
---
Fix Version/s: 2.7

> IgniteConfiguration dependents should have toString
> ---
>
> Key: IGNITE-8935
> URL: https://issues.apache.org/jira/browse/IGNITE-8935
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>  Labels: usability
> Fix For: 2.7
>
>
> Ignite configuration is printed on startup, but some classes which are 
> usually referred do not have toString() implemented, leading to gems such as 
> connectorCfg=org.apache.ignite.configuration.ConnectorConfiguration@7d8704ef
> Those classes should have toString implemented which will conform to 
> https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines#CodingGuidelines-StringOutput



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9030) Apache Ignite 2.7 Linux packages version update

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558333#comment-16558333
 ] 

ASF GitHub Bot commented on IGNITE-9030:


GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/4439

IGNITE-9030 Apache Ignite 2.7 Linux packages version update



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9030

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4439.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 #4439


commit c0ffa0660695acf95e906aac3925a69a68b2c20a
Author: Ivanov Petr 
Date:   2018-07-26T13:52:25Z

IGNITE-9030 Apache Ignite 2.7 Linux packages version update




> Apache Ignite 2.7 Linux packages version update
> ---
>
> Key: IGNITE-9030
> URL: https://issues.apache.org/jira/browse/IGNITE-9030
> Project: Ignite
>  Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Blocker
> Fix For: 2.7
>
>
> Update DEB and RPM packages' versions in Apache Ignite for the next version 
> (2.7)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9093) IgniteDbPutGetWithCacheStoreTest.testReadThrough fails every time when run on master

2018-07-26 Thread Ilya Kasnacheev (JIRA)
Ilya Kasnacheev created IGNITE-9093:
---

 Summary: IgniteDbPutGetWithCacheStoreTest.testReadThrough fails 
every time when run on master
 Key: IGNITE-9093
 URL: https://issues.apache.org/jira/browse/IGNITE-9093
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.7
Reporter: Ilya Kasnacheev


Such as in 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Pds1=pull%2F4420%2Fhead=buildTypeStatusDiv

Used to work every time in 2.6 release.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9092) SQL: Support CREATE TABLE .. AS (SELECT...) syntax

2018-07-26 Thread Stepan Pilschikov (JIRA)
Stepan Pilschikov created IGNITE-9092:
-

 Summary: SQL: Support CREATE TABLE .. AS (SELECT...) syntax
 Key: IGNITE-9092
 URL: https://issues.apache.org/jira/browse/IGNITE-9092
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.6, 2.5
Reporter: Stepan Pilschikov


Currently syntax is not supported
{code:java}
create table test as (select * from created_table);
Error: CREATE TABLE ... AS ... syntax is not supported (state=0A000,code=0)
java.sql.SQLException: CREATE TABLE ... AS ... syntax is not supported
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:762)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
at 
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
at sqlline.Commands.execute(Commands.java:823)
at sqlline.Commands.sql(Commands.java:733)
at sqlline.SqlLine.dispatch(SqlLine.java:795)
at sqlline.SqlLine.begin(SqlLine.java:668)
at sqlline.SqlLine.start(SqlLine.java:373)
at sqlline.SqlLine.main(SqlLine.java:265){code}
But in H2 this statement allowed to do



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9092) SQL: Support CREATE TABLE .. AS (SELECT * from ...) syntax

2018-07-26 Thread Stepan Pilschikov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stepan Pilschikov updated IGNITE-9092:
--
Summary: SQL: Support CREATE TABLE .. AS (SELECT * from ...) syntax  (was: 
SQL: Support CREATE TABLE .. AS (SELECT...) syntax)

> SQL: Support CREATE TABLE .. AS (SELECT * from ...) syntax
> --
>
> Key: IGNITE-9092
> URL: https://issues.apache.org/jira/browse/IGNITE-9092
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.5, 2.6
>Reporter: Stepan Pilschikov
>Priority: Major
>  Labels: ANSI99, sql-engine
>
> Currently syntax is not supported
> {code:java}
> create table test as (select * from created_table);
> Error: CREATE TABLE ... AS ... syntax is not supported (state=0A000,code=0)
> java.sql.SQLException: CREATE TABLE ... AS ... syntax is not supported
> at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:762)
> at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at 
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265){code}
> But in H2 this statement allowed to do



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-6846) Add metrics for entry processor invocations

2018-07-26 Thread Dmitriy Govorukhin (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-6846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558309#comment-16558309
 ] 

Dmitriy Govorukhin commented on IGNITE-6846:


[~Alexey Kuznetsov] Changes looks good for me. I guess we should check 
performance benchmarks before a merge. Please, fetch the last master changes.

> Add metrics for entry processor invocations
> ---
>
> Key: IGNITE-6846
> URL: https://issues.apache.org/jira/browse/IGNITE-6846
> Project: Ignite
>  Issue Type: Improvement
>  Components: cache
>Affects Versions: 2.3
>Reporter: Valentin Kulichenko
>Assignee: Alexey Kuznetsov
>Priority: Critical
>  Labels: iep-6
> Fix For: 2.7
>
>
> {{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
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()

2018-07-26 Thread Ilya Kasnacheev (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ilya Kasnacheev updated IGNITE-9068:

Attachment: MyService.java

> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed 
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: test
> Attachments: GridServiceDeadlockTest.java, MyService.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside 
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable 
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005cb7b0468> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
>   at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
>   at 
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
>   at 
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
>   - locked <0x0005cb423f00> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0 
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
>   at 
> 

[jira] [Updated] (IGNITE-9090) When client node make cache.QueryCursorImpl.getAll they have OOM and continue working

2018-07-26 Thread ARomantsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ARomantsov updated IGNITE-9090:
---
Component/s: clients

> When client node make cache.QueryCursorImpl.getAll they have OOM and continue 
> working
> -
>
> Key: IGNITE-9090
> URL: https://issues.apache.org/jira/browse/IGNITE-9090
> Project: Ignite
>  Issue Type: Bug
>  Components: clients
>Affects Versions: 2.4
> Environment: 2 server node, 1 client, 1 cache with 15 kk size
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.7
>
>
> {code:java}
> [12:21:22,390][SEVERE][query-#69][GridCacheIoManager] Failed to process 
> message [senderId=30cab4ec-1da7-4e9f-a262-bdfa4d466865, messageType=class 
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.lang.Long.valueOf(Long.java:840)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:250)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponseEntry.readExternal(GridCacheQueryResponseEntry.java:90)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:555)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:917)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:346)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:227)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1777)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
> at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.unmarshalCollection0(GridCacheQueryResponse.java:189)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.finishUnmarshal(GridCacheQueryResponse.java:162)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1530)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:576)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [12:21:28,573][INFO][ignite-update-notifier-timer][GridUpdateNotifier] Update 
> status is not 

[jira] [Commented] (IGNITE-9089) Web Agent not starting in docker container.

2018-07-26 Thread Ilya Murchenko (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558278#comment-16558278
 ] 

Ilya Murchenko commented on IGNITE-9089:


I've tested this image on docker/kubernetes cluster. Now Web Agent can start 
and establish a session to Web Console.

> Web Agent not starting in docker container.
> ---
>
> Key: IGNITE-9089
> URL: https://issues.apache.org/jira/browse/IGNITE-9089
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Ilya Murchenko
>Assignee: Peter Ivanov
>Priority: Minor
> Fix For: 2.7
>
>
> After a successful build from the Dockerfile in the [Github 
> repository|https://github.com/apache/ignite/blob/master/docker/web-agent/Dockerfile]
>  Web Agent application not starting in docker container with the following 
> error:
>  
> {code:java}
> /bin/sh: ignite-web-agent.sh: not found
> {code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9083) Compute (Affinity Run) TC configuration timeouts because of infinite socket operation

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558258#comment-16558258
 ] 

ASF GitHub Bot commented on IGNITE-9083:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4433


> Compute (Affinity Run) TC configuration timeouts because of infinite socket 
> operation
> -
>
> Key: IGNITE-9083
> URL: https://issues.apache.org/jira/browse/IGNITE-9083
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1491175=buildResultsDiv=IgniteTests24Java8_ComputeAffinityRun
> https://ci.ignite.apache.org/viewLog.html?buildId=1492399=buildResultsDiv=IgniteTests24Java8_ComputeAffinityRun
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7fc29c00d000 nid=0x33e2 runnable 
> [0x7fc2a31c4000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerInputStreamWrapper.read(JdkMarshallerInputStreamWrapper.java:53)
> at 
> java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2320)
> at 
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2333)
> at 
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2804)
> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:802)
> at java.io.ObjectInputStream.(ObjectInputStream.java:299)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:43)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:137)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9939)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.readMessage(TcpDiscoverySpi.java:1729)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendMessageDirectly(ServerImpl.java:1223)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1061)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:905)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:386)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1749)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1049)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xe0ca1e38> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:883)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:834)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:800)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:684)
> at 
> org.apache.ignite.internal.processors.database.baseline.IgniteBaselineLockPartitionOnAffinityRunTxCacheTest.beforeTest(IgniteBaselineLockPartitionOnAffinityRunTxCacheTest.java:57)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:634)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:490)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at 

[jira] [Commented] (IGNITE-9089) Web Agent not starting in docker container.

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558257#comment-16558257
 ] 

ASF GitHub Bot commented on IGNITE-9089:


GitHub user vveider opened a pull request:

https://github.com/apache/ignite/pull/4438

IGNITE-9089 Web Agent not starting in docker container.



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9089

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4438.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 #4438


commit c1effcd6276c111e0a828c4d863c1ce3c4fb0cd3
Author: Ivanov Petr 
Date:   2018-07-26T12:37:39Z

IGNITE-9089 Web Agent not starting in docker container.




> Web Agent not starting in docker container.
> ---
>
> Key: IGNITE-9089
> URL: https://issues.apache.org/jira/browse/IGNITE-9089
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.6
>Reporter: Ilya Murchenko
>Assignee: Peter Ivanov
>Priority: Minor
> Fix For: 2.7
>
>
> After a successful build from the Dockerfile in the [Github 
> repository|https://github.com/apache/ignite/blob/master/docker/web-agent/Dockerfile]
>  Web Agent application not starting in docker container with the following 
> error:
>  
> {code:java}
> /bin/sh: ignite-web-agent.sh: not found
> {code}
>  
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()

2018-07-26 Thread Dmitriy Govorukhin (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Govorukhin reassigned IGNITE-9068:
--

Assignee: Ilya Lantukh  (was: Pavel Kovalenko)

> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed 
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Lantukh
>Priority: Major
>  Labels: test
> Attachments: GridServiceDeadlockTest.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside 
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable 
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005cb7b0468> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
>   at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
>   at 
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
>   at 
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
>   - locked <0x0005cb423f00> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0 
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
>   at 
> 

[jira] [Created] (IGNITE-9091) IEP-25: creating documentation

2018-07-26 Thread Alex Volkov (JIRA)
Alex Volkov created IGNITE-9091:
---

 Summary: IEP-25: creating documentation
 Key: IGNITE-9091
 URL: https://issues.apache.org/jira/browse/IGNITE-9091
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Alex Volkov


It would be great to have proper documentation for IEP-25:

[https://cwiki.apache.org/confluence/display/IGNITE/IEP-25:+Partition+Map+Exchange+hangs+resolving]

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9084) Trash in WAL after node stop may affect WAL rebalance

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558251#comment-16558251
 ] 

ASF GitHub Bot commented on IGNITE-9084:


GitHub user Jokser opened a pull request:

https://github.com/apache/ignite/pull/4437

IGNITE-9084 Fix WAL rebalance iterator exception



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-9084

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4437.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 #4437


commit 6e9012dce35c9a433da6b1be41bb43764d396134
Author: Pavel Kovalenko 
Date:   2018-07-26T12:06:32Z

IGNITE-9084 Tests experiments.




> Trash in WAL after node stop may affect WAL rebalance
> -
>
> Key: IGNITE-9084
> URL: https://issues.apache.org/jira/browse/IGNITE-9084
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.6
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.7
>
>
> During iteration over WAL we can face with trash in WAL segment, which can 
> remains after node restart. We should handle this situation in WAL rebalance 
> iterator and gracefully stop iteration process.
> {noformat}
> [2018-07-25 
> 17:18:21,152][ERROR][sys-#25385%persistence.IgnitePdsTxHistoricalRebalancingTest0%][GridCacheIoManager]
>  Failed to process message [senderId=f0d35df7-ff93-4b6c-b699-45f3e7c3, 
> messageType=class 
> o.a.i.i.processors.cache.distributed.dht.preloader.GridDhtPartitionDemandMessage]
> class org.apache.ignite.IgniteException: Failed to read WAL record at 
> position: 19346739 size: 67108864
>   at 
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.next(GridIteratorAdapter.java:38)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.advance(GridCacheOffheapManager.java:1033)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.next(GridCacheOffheapManager.java:948)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:917)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$WALHistoricalIterator.nextX(GridCacheOffheapManager.java:842)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.nextX(IgniteRebalanceIteratorImpl.java:130)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:185)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.IgniteRebalanceIteratorImpl.next(IgniteRebalanceIteratorImpl.java:37)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:348)
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:370)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:380)
>   at 
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:365)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
>   at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
>   at 
> 

[jira] [Assigned] (IGNITE-9068) Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed inside guard()/unguard()

2018-07-26 Thread Alexander Gerus (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexander Gerus reassigned IGNITE-9068:
---

Assignee: Pavel Kovalenko  (was: Ilya Lantukh)

> Node fails to stop when CacheObjectBinaryProcessor.addMeta() is executed 
> inside guard()/unguard()
> -
>
> Key: IGNITE-9068
> URL: https://issues.apache.org/jira/browse/IGNITE-9068
> Project: Ignite
>  Issue Type: Bug
>  Components: binary, managed services
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kovalenko
>Priority: Major
>  Labels: test
> Attachments: GridServiceDeadlockTest.java
>
>
> When addMeta is called in e.g. service deployment it us executed inside 
> guard()/unguard()
> If node will be stopped at this point, Ignite.stop() will hang.
> Consider the following thread dump:
> {code}
> "Thread-1" #57 prio=5 os_prio=0 tid=0x7f7780005000 nid=0x7f26 runnable 
> [0x7f766cbef000]
>java.lang.Thread.State: TIMED_WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x0005cb7b0468> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
>   at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireNanos(AbstractQueuedSynchronizer.java:934)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireNanos(AbstractQueuedSynchronizer.java:1247)
>   at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.tryLock(ReentrantReadWriteLock.java:1115)
>   at 
> org.apache.ignite.internal.util.StripedCompositeReadWriteLock$WriteLock.tryLock(StripedCompositeReadWriteLock.java:220)
>   at 
> org.apache.ignite.internal.GridKernalGatewayImpl.tryWriteLock(GridKernalGatewayImpl.java:143)
> // Waiting for lock to cancel futures of BinaryMetadataTransport
>   at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2171)
>   at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2094)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2545)
>   - locked <0x0005cb423f00> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2508)
>   at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.run(IgnitionEx.java:2033)
> "test-runner-#1%service.GridServiceDeadlockTest%" #13 prio=5 os_prio=0 
> tid=0x7f77b87d5800 nid=0x7eb8 waiting on condition [0x7f778cdfc000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> // May never return if there's discovery problems
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.addMeta(CacheObjectBinaryProcessorImpl.java:463)
>   at 
> org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.addMeta(CacheObjectBinaryProcessorImpl.java:188)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerUserClassDescriptor(BinaryContext.java:802)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.registerClassDescriptor(BinaryContext.java:761)
>   at 
> org.apache.ignite.internal.binary.BinaryContext.descriptorForClass(BinaryContext.java:627)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal0(BinaryWriterExImpl.java:174)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:157)
>   at 
> org.apache.ignite.internal.binary.BinaryWriterExImpl.marshal(BinaryWriterExImpl.java:144)
>   at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.marshal(GridBinaryMarshaller.java:254)
>   at 
> org.apache.ignite.internal.binary.BinaryMarshaller.marshal0(BinaryMarshaller.java:82)
>   at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.marshal(AbstractNodeNameAwareMarshaller.java:58)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.marshal(IgniteUtils.java:10069)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.prepareServiceConfigurations(GridServiceProcessor.java:570)
>   at 
> org.apache.ignite.internal.processors.service.GridServiceProcessor.deployAll(GridServiceProcessor.java:622)
>   at 
> 

[jira] [Commented] (IGNITE-9064) Decision tree optimization

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558241#comment-16558241
 ] 

ASF GitHub Bot commented on IGNITE-9064:


GitHub user avplatonov opened a pull request:

https://github.com/apache/ignite/pull/4436

IGNITE-9064: Decision tree optimization

@dmitrievanthony 
@artemmalykh 
Please review this code 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite IGNITE-9064

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4436.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 #4436


commit df45dba7dae1c6b9604474ec9fb912781d965a2f
Author: Alexey Platonov 
Date:   2018-07-23T07:43:11Z

O(n^2) in Regression Trees and memory leak elimination

commit 7b31a02dd4ed6ff9396f50c0dab3187165303c39
Author: Alexey Platonov 
Date:   2018-07-24T12:48:21Z

features index

commit 8afc3af5b33bd560a26c081188ba8c19f4a6df3a
Author: Alexey Platonov 
Date:   2018-07-24T14:07:32Z

create tree data index, adopt for classification

commit 615906bdeea7c5cb30d0839ab2906868306d5103
Author: Alexey Platonov 
Date:   2018-07-24T14:31:37Z

adopt index for regression

commit 4b52959a294603c80342511538eeff79071b64cc
Author: Alexey Platonov 
Date:   2018-07-24T14:32:43Z

Merge branch 'master' of https://github.com/apache/ignite into 
ml/optimizations

commit b13e43560d4ec063615951d1c0a3f7810986b257
Author: Alexey Platonov 
Date:   2018-07-25T12:32:05Z

use index projections and caching

commit f697380019c95278c0a98bb1a18b684c3bd6
Author: Alexey Platonov 
Date:   2018-07-26T08:19:06Z

some refactoring and comments

commit 01096df8ab4ae0733285ff37ce37c63eb2a7a87a
Author: Alexey Platonov 
Date:   2018-07-26T10:04:47Z

make indexes is optional

commit 9848faf37325391776f4a3014c6ec814797dc851
Author: Alexey Platonov 
Date:   2018-07-26T10:38:54Z

add useIndex flag exhaustive search to tests




> Decision tree optimization
> --
>
> Key: IGNITE-9064
> URL: https://issues.apache.org/jira/browse/IGNITE-9064
> Project: Ignite
>  Issue Type: Improvement
>  Components: ml
>Reporter: Yury Babak
>Assignee: Alexey Platonov
>Priority: Major
> Fix For: 2.7
>
>
> We need to optimize impurity function calculation by additional index 
> structure for all sorted features and reusing it in learning iterations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9058) Update Apache Tomcat dependency version

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558224#comment-16558224
 ] 

ASF GitHub Bot commented on IGNITE-9058:


GitHub user daradurvs opened a pull request:

https://github.com/apache/ignite/pull/4435

IGNITE-9058 Updated Apache Tomcat dependency to version 9.0.10



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/daradurvs/ignite ignite-9058-fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4435.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 #4435


commit 34e6553a584d6e1f64198beeb952bf70d58a123d
Author: Fedotov 
Date:   2018-07-26T11:56:36Z

updated to 9.0.10




> Update Apache Tomcat dependency version
> ---
>
> Key: IGNITE-9058
> URL: https://issues.apache.org/jira/browse/IGNITE-9058
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
> Fix For: 2.7
>
>
> Update tomcat-servlet-api to newer version (at least 8.0.52,  8.5.31+ or 
> 9.0.9+). E.g. to
> {noformat}
> 
> org.apache.tomcat
> tomcat-servlet-api
> 9.0.10
> 
> {noformat}
> At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected 
> by this change.
> It is required to run TC tartget RunAll to check all tests passed, it is 
> required to build fabric using DEVNOTES.txt to make sure full build will be 
> successfull
> Probably it is required to run release step to make sure release candidate 
> can be prepared.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9090) When client node make cache.QueryCursorImpl.getAll they have OOM and continue working

2018-07-26 Thread ARomantsov (JIRA)
ARomantsov created IGNITE-9090:
--

 Summary: When client node make cache.QueryCursorImpl.getAll they 
have OOM and continue working
 Key: IGNITE-9090
 URL: https://issues.apache.org/jira/browse/IGNITE-9090
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
 Environment: 2 server node, 1 client
Reporter: ARomantsov
 Fix For: 2.7



{code:java}
[12:21:22,390][SEVERE][query-#69][GridCacheIoManager] Failed to process message 
[senderId=30cab4ec-1da7-4e9f-a262-bdfa4d466865, messageType=class 
o.a.i.i.processors.cache.query.GridCacheQueryResponse]
java.lang.OutOfMemoryError: GC overhead limit exceeded
at java.lang.Long.valueOf(Long.java:840)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:250)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponseEntry.readExternal(GridCacheQueryResponseEntry.java:90)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:555)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:917)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:346)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
at 
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:227)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
at 
org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1777)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
at 
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at 
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
at 
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
at 
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.unmarshalCollection0(GridCacheQueryResponse.java:189)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.finishUnmarshal(GridCacheQueryResponse.java:162)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1530)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:576)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[12:21:28,573][INFO][ignite-update-notifier-timer][GridUpdateNotifier] Update 
status is not available.
[12:21:23,759][WARNING][jvm-pause-detector-worker][] Possible too long JVM 
pause: 22446 milliseconds.
[12:21:23,758][INFO][grid-timeout-worker-#39][IgniteKernal]
Metrics for local node (to disable set 'metricsLogFrequency' to 0)
^-- Node [id=c1f087b1, uptime=00:01:25.431]
^-- H/N/C [hosts=2, nodes=3, CPUs=32]
^-- CPU [cur=100%, avg=79.09%, GC=8.93%]
^-- PageMemory [pages=0]
^-- Heap [used=216MB, free=8.57%, comm=236MB]
^-- 

[jira] [Updated] (IGNITE-9090) When client node make cache.QueryCursorImpl.getAll they have OOM and continue working

2018-07-26 Thread ARomantsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ARomantsov updated IGNITE-9090:
---
Environment: 2 server node, 1 client, 1 cache with 15 kk size  (was: 2 
server node, 1 client)

> When client node make cache.QueryCursorImpl.getAll they have OOM and continue 
> working
> -
>
> Key: IGNITE-9090
> URL: https://issues.apache.org/jira/browse/IGNITE-9090
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
> Environment: 2 server node, 1 client, 1 cache with 15 kk size
>Reporter: ARomantsov
>Priority: Critical
> Fix For: 2.7
>
>
> {code:java}
> [12:21:22,390][SEVERE][query-#69][GridCacheIoManager] Failed to process 
> message [senderId=30cab4ec-1da7-4e9f-a262-bdfa4d466865, messageType=class 
> o.a.i.i.processors.cache.query.GridCacheQueryResponse]
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.lang.Long.valueOf(Long.java:840)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:250)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponseEntry.readExternal(GridCacheQueryResponseEntry.java:90)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readExternalizable(OptimizedObjectInputStream.java:555)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedClassDescriptor.read(OptimizedClassDescriptor.java:917)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0(OptimizedObjectInputStream.java:346)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride(OptimizedObjectInputStream.java:198)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:421)
> at 
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshaller.unmarshal0(OptimizedMarshaller.java:227)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at 
> org.apache.ignite.internal.binary.BinaryUtils.doReadOptimized(BinaryUtils.java:1777)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1964)
> at 
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
> at 
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:310)
> at 
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:99)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:82)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.unmarshalCollection0(GridCacheQueryResponse.java:189)
> at 
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryResponse.finishUnmarshal(GridCacheQueryResponse.java:162)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.unmarshall(GridCacheIoManager.java:1530)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:576)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$700(GridCacheIoManager.java:101)
> at 
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1613)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4100(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2752)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1516)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4400(GridIoManager.java:125)
> at 
> org.apache.ignite.internal.managers.communication.GridIoManager$10.run(GridIoManager.java:1485)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 

[jira] [Created] (IGNITE-9089) Web Agent not starting in docker container.

2018-07-26 Thread Ilya Murchenko (JIRA)
Ilya Murchenko created IGNITE-9089:
--

 Summary: Web Agent not starting in docker container.
 Key: IGNITE-9089
 URL: https://issues.apache.org/jira/browse/IGNITE-9089
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Ilya Murchenko
Assignee: Peter Ivanov
 Fix For: 2.7


After a successful build from the Dockerfile in the [Github 
repository|https://github.com/apache/ignite/blob/master/docker/web-agent/Dockerfile]
 Web Agent application not starting in docker container with the following 
error:

 
{code:java}
/bin/sh: ignite-web-agent.sh: not found
{code}
 

 

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9083) Compute (Affinity Run) TC configuration timeouts because of infinite socket operation

2018-07-26 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-9083:
---
Ignite Flags:   (was: Docs Required)

> Compute (Affinity Run) TC configuration timeouts because of infinite socket 
> operation
> -
>
> Key: IGNITE-9083
> URL: https://issues.apache.org/jira/browse/IGNITE-9083
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1491175=buildResultsDiv=IgniteTests24Java8_ComputeAffinityRun
> https://ci.ignite.apache.org/viewLog.html?buildId=1492399=buildResultsDiv=IgniteTests24Java8_ComputeAffinityRun
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7fc29c00d000 nid=0x33e2 runnable 
> [0x7fc2a31c4000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerInputStreamWrapper.read(JdkMarshallerInputStreamWrapper.java:53)
> at 
> java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2320)
> at 
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2333)
> at 
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2804)
> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:802)
> at java.io.ObjectInputStream.(ObjectInputStream.java:299)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:43)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:137)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9939)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.readMessage(TcpDiscoverySpi.java:1729)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendMessageDirectly(ServerImpl.java:1223)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1061)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:905)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:386)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1749)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1049)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xe0ca1e38> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:883)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:834)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:800)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:684)
> at 
> org.apache.ignite.internal.processors.database.baseline.IgniteBaselineLockPartitionOnAffinityRunTxCacheTest.beforeTest(IgniteBaselineLockPartitionOnAffinityRunTxCacheTest.java:57)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:634)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:490)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 

[jira] [Updated] (IGNITE-9083) Compute (Affinity Run) TC configuration timeouts because of infinite socket operation

2018-07-26 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-9083:
---
Fix Version/s: 2.7

> Compute (Affinity Run) TC configuration timeouts because of infinite socket 
> operation
> -
>
> Key: IGNITE-9083
> URL: https://issues.apache.org/jira/browse/IGNITE-9083
> Project: Ignite
>  Issue Type: Bug
>Reporter: Eduard Shangareev
>Assignee: Eduard Shangareev
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1491175=buildResultsDiv=IgniteTests24Java8_ComputeAffinityRun
> https://ci.ignite.apache.org/viewLog.html?buildId=1492399=buildResultsDiv=IgniteTests24Java8_ComputeAffinityRun
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x7fc29c00d000 nid=0x33e2 runnable 
> [0x7fc2a31c4000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:170)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerInputStreamWrapper.read(JdkMarshallerInputStreamWrapper.java:53)
> at 
> java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2320)
> at 
> java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2333)
> at 
> java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2804)
> at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:802)
> at java.io.ObjectInputStream.(ObjectInputStream.java:299)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshallerObjectInputStream.(JdkMarshallerObjectInputStream.java:43)
> at 
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:137)
> at 
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:94)
> at 
> org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:9939)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.readMessage(TcpDiscoverySpi.java:1729)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendMessageDirectly(ServerImpl.java:1223)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1061)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:905)
> at 
> org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:386)
> at 
> org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2002)
> at 
> org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:297)
> at 
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:916)
> at 
> org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1749)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1049)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2020)
> at 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1725)
> - locked <0xe0ca1e38> (a 
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1153)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:651)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:883)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:846)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:834)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:800)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrids(GridAbstractTest.java:684)
> at 
> org.apache.ignite.internal.processors.database.baseline.IgniteBaselineLockPartitionOnAffinityRunTxCacheTest.beforeTest(IgniteBaselineLockPartitionOnAffinityRunTxCacheTest.java:57)
> at 
> org.apache.ignite.testframework.junits.GridAbstractTest.setUp(GridAbstractTest.java:634)
> at 
> org.apache.ignite.testframework.junits.common.GridCommonAbstractTest.setUp(GridCommonAbstractTest.java:490)
> at junit.framework.TestCase.runBare(TestCase.java:139)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 

[jira] [Updated] (IGNITE-9058) Update Apache Tomcat dependency version

2018-07-26 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov updated IGNITE-9058:
---
Description: 
Update tomcat-servlet-api to newer version (at least 8.0.52,  8.5.31+ or 
9.0.9+). E.g. to
{noformat}

org.apache.tomcat
tomcat-servlet-api
9.0.10

{noformat}

At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected by 
this change.

It is required to run TC tartget RunAll to check all tests passed, it is 
required to build fabric using DEVNOTES.txt to make sure full build will be 
successfull

Probably it is required to run release step to make sure release candidate can 
be prepared.

  was:
Update tomcat-servlet-api to newer version (at least 8.0.52,  8.5.31+ or 9.0.8+)
{noformat}

org.apache.tomcat
tomcat-servlet-api
8.0.52

{noformat}

At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected by 
this change.

It is required to run TC tartget RunAll to check all tests passed, it is 
required to build fabric using DEVNOTES.txt to make sure full build will be 
successfull

Probably it is required to run release step to make sure release candidate can 
be prepared.


> Update Apache Tomcat dependency version
> ---
>
> Key: IGNITE-9058
> URL: https://issues.apache.org/jira/browse/IGNITE-9058
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
> Fix For: 2.7
>
>
> Update tomcat-servlet-api to newer version (at least 8.0.52,  8.5.31+ or 
> 9.0.9+). E.g. to
> {noformat}
> 
> org.apache.tomcat
> tomcat-servlet-api
> 9.0.10
> 
> {noformat}
> At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected 
> by this change.
> It is required to run TC tartget RunAll to check all tests passed, it is 
> required to build fabric using DEVNOTES.txt to make sure full build will be 
> successfull
> Probably it is required to run release step to make sure release candidate 
> can be prepared.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9058) Update Apache Tomcat dependency version

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558208#comment-16558208
 ] 

ASF GitHub Bot commented on IGNITE-9058:


Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/4418


> Update Apache Tomcat dependency version
> ---
>
> Key: IGNITE-9058
> URL: https://issues.apache.org/jira/browse/IGNITE-9058
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
> Fix For: 2.7
>
>
> Update tomcat-servlet-api to newer version (at least 8.0.52,  8.5.31+ or 
> 9.0.8+)
> {noformat}
> 
> org.apache.tomcat
> tomcat-servlet-api
> 8.0.52
> 
> {noformat}
> At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected 
> by this change.
> It is required to run TC tartget RunAll to check all tests passed, it is 
> required to build fabric using DEVNOTES.txt to make sure full build will be 
> successfull
> Probably it is required to run release step to make sure release candidate 
> can be prepared.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (IGNITE-9058) Update Apache Tomcat dependency version

2018-07-26 Thread Dmitriy Pavlov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dmitriy Pavlov reopened IGNITE-9058:


I appologize, I've mentioned wrong version. Could we update to higher wersion, 
e.g. https://mvnrepository.com/artifact/org.apache.tomcat/tomcat/9.0.10

[~ivanan.fed] could you please create second PR for this update, because I've 
already merged previous before noticing that.

> Update Apache Tomcat dependency version
> ---
>
> Key: IGNITE-9058
> URL: https://issues.apache.org/jira/browse/IGNITE-9058
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Ivan Fedotov
>Priority: Major
> Fix For: 2.7
>
>
> Update tomcat-servlet-api to newer version (at least 8.0.52,  8.5.31+ or 
> 9.0.8+)
> {noformat}
> 
> org.apache.tomcat
> tomcat-servlet-api
> 8.0.52
> 
> {noformat}
> At least Ignite-rest-http, ignite-urideploy, and ignite-web will be affected 
> by this change.
> It is required to run TC tartget RunAll to check all tests passed, it is 
> required to build fabric using DEVNOTES.txt to make sure full build will be 
> successfull
> Probably it is required to run release step to make sure release candidate 
> can be prepared.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9088) Add ability to dump persistence after particular test

2018-07-26 Thread Pavel Kovalenko (JIRA)
Pavel Kovalenko created IGNITE-9088:
---

 Summary: Add ability to dump persistence after particular test
 Key: IGNITE-9088
 URL: https://issues.apache.org/jira/browse/IGNITE-9088
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.7


Sometimes it's needed to analyze persistence after a particular test finish on 
TeamCity.
We need to add an ability to dump persistence dirs/files to the specified 
directory on test running host for further analysis.
This should be managed by a property.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9087) testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring

2018-07-26 Thread Sergey Chugunov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-9087:

Ignite Flags:   (was: Docs Required)

> testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring
> ---
>
> Key: IGNITE-9087
> URL: https://issues.apache.org/jira/browse/IGNITE-9087
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Initial implementation of the test relied on massive parallel client start to 
> get into a situation of exchange history exhaustion.
> But after fix IGNITE-8998 even in massive start scenario probability of 
> client's exchange being cleaned up from exchange history becomes much smaller.
> Test should be refactored so it won't rely on parallel operations but delay 
> exchange finish (e.g. by delaying particular messages).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9087) testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring

2018-07-26 Thread Sergey Chugunov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-9087:

Affects Version/s: 2.6

> testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring
> ---
>
> Key: IGNITE-9087
> URL: https://issues.apache.org/jira/browse/IGNITE-9087
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Initial implementation of the test relied on massive parallel client start to 
> get into a situation of exchange history exhaustion.
> But after fix IGNITE-8998 even in massive start scenario probability of 
> client's exchange being cleaned up from exchange history becomes much smaller.
> Test should be refactored so it won't rely on parallel operations but delay 
> exchange finish (e.g. by delaying particular messages).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9087) testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring

2018-07-26 Thread Sergey Chugunov (JIRA)
Sergey Chugunov created IGNITE-9087:
---

 Summary: 
testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring
 Key: IGNITE-9087
 URL: https://issues.apache.org/jira/browse/IGNITE-9087
 Project: Ignite
  Issue Type: Test
Reporter: Sergey Chugunov


Initial implementation of the test relied on massive parallel client start to 
get into a situation of exchange history exhaustion.

But after fix IGNITE-8998 even in massive start scenario probability of 
client's exchange being cleaned up from exchange history becomes much smaller.

Test should be refactored so it won't rely on parallel operations but delay 
exchange finish (e.g. by delaying particular messages).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9087) testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring

2018-07-26 Thread Sergey Chugunov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-9087:

Fix Version/s: 2.7

> testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring
> ---
>
> Key: IGNITE-9087
> URL: https://issues.apache.org/jira/browse/IGNITE-9087
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Initial implementation of the test relied on massive parallel client start to 
> get into a situation of exchange history exhaustion.
> But after fix IGNITE-8998 even in massive start scenario probability of 
> client's exchange being cleaned up from exchange history becomes much smaller.
> Test should be refactored so it won't rely on parallel operations but delay 
> exchange finish (e.g. by delaying particular messages).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9087) testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring

2018-07-26 Thread Sergey Chugunov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sergey Chugunov updated IGNITE-9087:

Labels: MakeTeamcityGreenAgain  (was: )

> testClientInForceServerModeStopsOnExchangeHistoryExhaustion refactoring
> ---
>
> Key: IGNITE-9087
> URL: https://issues.apache.org/jira/browse/IGNITE-9087
> Project: Ignite
>  Issue Type: Test
>Affects Versions: 2.6
>Reporter: Sergey Chugunov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain
> Fix For: 2.7
>
>
> Initial implementation of the test relied on massive parallel client start to 
> get into a situation of exchange history exhaustion.
> But after fix IGNITE-8998 even in massive start scenario probability of 
> client's exchange being cleaned up from exchange history becomes much smaller.
> Test should be refactored so it won't rely on parallel operations but delay 
> exchange finish (e.g. by delaying particular messages).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8939) Transaction string reprsentation unhandled exception

2018-07-26 Thread Alexei Scherbakov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558178#comment-16558178
 ] 

Alexei Scherbakov commented on IGNITE-8939:
---

I suggest using CU.txString(tx) for printing transaction.

There are some places where it's not still changed.

> Transaction string reprsentation unhandled exception
> 
>
> Key: IGNITE-8939
> URL: https://issues.apache.org/jira/browse/IGNITE-8939
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Reporter: Evgenii Zagumennov
>Priority: Major
>
> IgniteTxHandler.finishDhtLocal() (IgniteTxHandler.java:957)
> {code:java}
> U.error(log, "Failed completing transaction [commit=" + req.commit() + ", 
> tx=" + *tx* + ']', e);{code}
> tx.toString() can lead to excepion (in GridToStringBuilder.toStringImpl()), 
> and original exception in transaction will be lost. We need to log original 
> exception and catch probable tx.toString() exception.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-9044) Update scala dependency version in Apache Ignite

2018-07-26 Thread Dmitriy Pavlov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-9044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558159#comment-16558159
 ] 

Dmitriy Pavlov commented on IGNITE-9044:


[~zzzadruga], I suggest to upadte   to 2.11.12. It is 
used at least in osgi-karaf.

what do you think?

> Update scala dependency version in Apache Ignite
> 
>
> Key: IGNITE-9044
> URL: https://issues.apache.org/jira/browse/IGNITE-9044
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitriy Pavlov
>Assignee: Nikolai kulagin
>Priority: Major
> Fix For: 2.7
>
>
> *ignite-scalar*
> scala.library.version=2.11.8, need to be at least 2.11.12 or newer.
> *ignite-scalar_2.10*
> scala210.library.version 2.10.6, need to be at least 2.10.7, probably newer
> *visor 2.10*
> scala210.jline.version = 2.10.4 , need to be at least 2.10.7, probably newer
> Probably impact would be wider.
> We need at least run run-all, local build.sh and optionally release candate 
> step on TC.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-8158) Missed cleanups if afterTestsStop throws exception

2018-07-26 Thread Nikolai kulagin (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolai kulagin reassigned IGNITE-8158:
---

Assignee: Nikolai kulagin

> Missed cleanups if afterTestsStop throws exception
> --
>
> Key: IGNITE-8158
> URL: https://issues.apache.org/jira/browse/IGNITE-8158
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 2.4
>Reporter: Maxim Muzafarov
>Assignee: Nikolai kulagin
>Priority: Minor
>  Labels: newbie, test
> Fix For: 2.7
>
>
> Method {{afterTestsStopped}} might throw exception. Contibutor should provide 
> solution for ensuring that all cleanups in {{tearDown}} method would be 
> executed in this case.
> {code:java|title=GridAbstractTest.java}
> /** {@inheritDoc} */
> @Override protected void tearDown() throws Exception {
> ...
> try {
> afterTest();
> }
> finally {
> serializedObj.clear();
> if (isLastTest()) {
> ...
> afterTestsStopped();
> if (startGrid)
> G.stop(getTestIgniteInstanceName(), true);
> // Remove counters.
> tests.remove(getClass());
> // Remove resources cached in static, if any.
> GridClassLoaderCache.clear();
> U.clearClassCache();
> MarshallerExclusions.clearCache();
> BinaryEnumCache.clear();
> }
> Thread.currentThread().setContextClassLoader(clsLdr);
> clsLdr = null;
> cleanReferences();
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-8936) Remove AffinityAssignment#clientEventChange as not used

2018-07-26 Thread Nikolai kulagin (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolai kulagin reassigned IGNITE-8936:
---

Assignee: Nikolai kulagin

> Remove AffinityAssignment#clientEventChange as not used
> ---
>
> Key: IGNITE-8936
> URL: https://issues.apache.org/jira/browse/IGNITE-8936
> Project: Ignite
>  Issue Type: Task
>Affects Versions: 2.7
>Reporter: Maxim Muzafarov
>Assignee: Nikolai kulagin
>Priority: Minor
>  Labels: newbie
> Attachments: ClientEventChange (1).png
>
>
> We should try to keep Ignite project code as simple as possible.
> Motivation: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Cases-of-using-AffinityAssignment-clientEventChange-method-td32068.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-8581) MVCC TX: data streamer support

2018-07-26 Thread Ivan Pavlukhin (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Pavlukhin resolved IGNITE-8581.

Resolution: Fixed

> MVCC TX: data streamer support
> --
>
> Key: IGNITE-8581
> URL: https://issues.apache.org/jira/browse/IGNITE-8581
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Sergey Kalashnikov
>Assignee: Ivan Pavlukhin
>Priority: Major
>  Labels: mvcc, sql
>
> Add support for data streamer for mvcc caches.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9086) Error during commit transaction on primary node may lead to breaking transaction data integrity

2018-07-26 Thread Pavel Kovalenko (JIRA)
Pavel Kovalenko created IGNITE-9086:
---

 Summary: Error during commit transaction on primary node may lead 
to breaking transaction data integrity
 Key: IGNITE-9086
 URL: https://issues.apache.org/jira/browse/IGNITE-9086
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.6, 2.5, 2.4
Reporter: Pavel Kovalenko
 Fix For: 2.7


Transaction properties are PESSIMISTIC, REPEATABLE READ.

If primary partitions participating in the transaction are spread across 
several nodes and commit is failed on some of the primary nodes while other 
primary nodes have committed transaction it may lead to breaking transaction 
data integrity. A data become inconsistent even after rebalance when the node 
with failed commit returns back to the cluster.





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-5795) @AffinityKeyMapped ignored if QueryEntity used

2018-07-26 Thread Denis Mekhanikov (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558079#comment-16558079
 ] 

Denis Mekhanikov commented on IGNITE-5795:
--

[~kukushal], there haven't been any activity on this ticket lately.

I'd like to have this issue fixed. Do you plan to continue working on it? Or 
can I take it over?

> @AffinityKeyMapped ignored if QueryEntity used
> --
>
> Key: IGNITE-5795
> URL: https://issues.apache.org/jira/browse/IGNITE-5795
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 2.0
>Reporter: Dmitry Karachentsev
>Assignee: Alexey Kukushkin
>Priority: Major
>  Labels: usability
> Fix For: 2.7
>
>
> When cache configured with QueryEntity and used key type with 
> @AffinityKeyMapped field, it will be ignored and wrong partition calculated. 
> This happens because QueryEntity processing precedes key type registering in 
> binary meta cache. On that step 
> CacheObjectBinaryProcessorImpl#affinityKeyField called and unable to resolve 
> type, so null returned and null putted in affKeyFields.
> On next put/get operation CacheObjectBinaryProcessorImpl#affinityKeyField 
> will return null from affKeyFields, but should be affinity key field.
> Test that reproduces problem in [PR 
> 2330|https://github.com/apache/ignite/pull/2330]
> To wrorkaround the issue, set IgniteConfiguration#setKeyConfiguration(), it 
> will force registering key.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (IGNITE-6467) Ignite cache 6: new tests CacheExchangeMergeTest.testConcurrentStartServersAndClients() and testDelayExchangeMessages() have flaky junit assertion after cache get

2018-07-26 Thread Semen Boikov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-6467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semen Boikov reopened IGNITE-6467:
--
  Assignee: Semen Boikov

Again noticed failure on TeamCity with 'Invalid value ' error, need further 
investigate.

> Ignite cache 6: new tests 
> CacheExchangeMergeTest.testConcurrentStartServersAndClients() and 
> testDelayExchangeMessages() have flaky junit assertion after cache get
> --
>
> Key: IGNITE-6467
> URL: https://issues.apache.org/jira/browse/IGNITE-6467
> Project: Ignite
>  Issue Type: Bug
>Reporter: Dmitriy Pavlov
>Assignee: Semen Boikov
>Priority: Major
>  Labels: MakeTeamcityGreenAgain, Muted_test
> Fix For: 2.7
>
>
> Ignite cache 6: CacheExchangeMergeTest: 3 tests fails with probability >10% 
> in master and in PRs
> IgniteCacheTestSuite6: 
> CacheExchangeMergeTest.testConcurrentStartServersAndClients() 
> IgniteCacheTestSuite6: CacheExchangeMergeTest.testDelayExchangeMessages() 
> IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeServersFail1_2 (fail 
> rate 22,6%) 
> https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=741151191800314619=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-8990224019412265556=testDetails
> latest failure from master
> https://ci.ignite.apache.org/viewLog.html?buildId=843261=buildResultsDiv=Ignite20Tests_IgniteCache6#testNameId741151191800314619
> {noformat}
> Invalid value [node=distributed.CacheExchangeMergeTest0, client=false, 
> order=1, cache=c1] expected:<0> but was:
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at 
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkNodeCaches(CacheExchangeMergeTest.java:1343)
> at 
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches0(CacheExchangeMergeTest.java:1213)
> at 
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.checkCaches(CacheExchangeMergeTest.java:1195)
> at 
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.concurrentStart(CacheExchangeMergeTest.java:446)
> at 
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest.testConcurrentStartServersAndClients(CacheExchangeMergeTest.java:414)
> Caused by: junit.framework.AssertionFailedError: Invalid value 
> [node=distributed.CacheExchangeMergeTest0, client=false, order=1, cache=c1] 
> expected:<0> but was:
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.Assert.failNotEquals(Assert.java:329)
> at junit.framework.Assert.assertEquals(Assert.java:78)
> at junit.framework.TestCase.assertEquals(TestCase.java:244)
> at 
> org.apache.ignite.internal.processors.cache.distributed.CacheExchangeMergeTest$16.run(CacheExchangeMergeTest.java:1312)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject

2018-07-26 Thread Denis Mekhanikov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Mekhanikov updated IGNITE-9043:
-
Labels: usability  (was: )

> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
>  Labels: usability
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of 
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then 
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache = 
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class 
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set 
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map, 
> fieldType=Object, assignedValueType=Map]
>   at 
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
>   at 
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
>   at 
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
>   at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}
> It would be convenient, if objects of any type could be written as {{Object}} 
> without the need to specify the type explicitly in 
> {{BinaryObjectBuilder.setField(...)}} method.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject

2018-07-26 Thread Denis Mekhanikov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Mekhanikov updated IGNITE-9043:
-
Description: 
When a binary type is registered during first insertion without use of 
BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.

But if you try to assign a {{HashMap}} to this field afterwards, then exception 
is thrown.

The following code results in an exception:
{code:java}
public static void main(String[] args) {
Ignite ignite = Ignition.start("config/ignite.xml");
IgniteCache cache = ignite.getOrCreateCache("cache");

cache.put(1, new ExamplePojo());

BinaryObject val = cache.withKeepBinary().get(1);

Map map = val.field("map");
BinaryObjectBuilder bldr = val.toBuilder();
bldr.setField("map", map);

bldr.build(); // Throws exception.
}

static class ExamplePojo {
Map map = new HashMap<>();
}
{code}
Stacktrace:
{noformat}
Exception in thread "main" class 
org.apache.ignite.binary.BinaryObjectException: Wrong value has been set 
[typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map, 
fieldType=Object, assignedValueType=Map]
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
{noformat}
It would be convenient, if objects of any type could be written as {{Object}} 
without the need to specify the type explicitly in 
{{BinaryObjectBuilder.setField(...)}} method.

  was:
When a binary type is registered during first insertion without use of 
BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.

It leads to inconvenience in further usage of this type over {{BinaryObject}} 
interface.

The following code results in an exception:
{code:java}
public static void main(String[] args) {
Ignite ignite = Ignition.start("config/ignite.xml");
IgniteCache cache = ignite.getOrCreateCache("cache");

cache.put(1, new ExamplePojo());

BinaryObject val = cache.withKeepBinary().get(1);

Map map = val.field("map");
map.put(1, "1");
BinaryObjectBuilder bldr = val.toBuilder();
bldr.setField("map", map);

bldr.build(); // Throws exception.
}

static class ExamplePojo {
Map map = new HashMap<>();
}
{code}
Stacktrace:
{noformat}
Exception in thread "main" class 
org.apache.ignite.binary.BinaryObjectException: Wrong value has been set 
[typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map, 
fieldType=Object, assignedValueType=Map]
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
at 
org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
{noformat}


> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of 
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> But if you try to assign a {{HashMap}} to this field afterwards, then 
> exception is thrown.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache = 
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class 
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set 
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map, 
> fieldType=Object, assignedValueType=Map]
>   at 
> 

[jira] [Updated] (IGNITE-9043) Collections cannot be assigned to fields of type Object in BinaryObject

2018-07-26 Thread Denis Mekhanikov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Denis Mekhanikov updated IGNITE-9043:
-
Summary: Collections cannot be assigned to fields of type Object in 
BinaryObject  (was: Map field is registered as Object in BinaryType)

> Collections cannot be assigned to fields of type Object in BinaryObject
> ---
>
> Key: IGNITE-9043
> URL: https://issues.apache.org/jira/browse/IGNITE-9043
> Project: Ignite
>  Issue Type: Bug
>  Components: binary
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.7
>
>
> When a binary type is registered during first insertion without use of 
> BinaryObject, then fields of type {{Map}} are registered as {{Object}}-s.
> It leads to inconvenience in further usage of this type over {{BinaryObject}} 
> interface.
> The following code results in an exception:
> {code:java}
> public static void main(String[] args) {
> Ignite ignite = Ignition.start("config/ignite.xml");
> IgniteCache cache = 
> ignite.getOrCreateCache("cache");
> cache.put(1, new ExamplePojo());
> BinaryObject val = cache.withKeepBinary().get(1);
> Map map = val.field("map");
> map.put(1, "1");
> BinaryObjectBuilder bldr = val.toBuilder();
> bldr.setField("map", map);
> bldr.build(); // Throws exception.
> }
> static class ExamplePojo {
> Map map = new HashMap<>();
> }
> {code}
> Stacktrace:
> {noformat}
> Exception in thread "main" class 
> org.apache.ignite.binary.BinaryObjectException: Wrong value has been set 
> [typeName=binary.BinaryObjectMapExample$ExamplePojo, fieldName=map, 
> fieldType=Object, assignedValueType=Map]
>   at 
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:428)
>   at 
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:223)
>   at 
> org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:183)
>   at binary.BinaryObjectMapExample.main(BinaryObjectMapExample.java:26)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8361) Use discovery messages for service deployment

2018-07-26 Thread ASF GitHub Bot (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16558030#comment-16558030
 ] 

ASF GitHub Bot commented on IGNITE-8361:


GitHub user daradurvs opened a pull request:

https://github.com/apache/ignite/pull/4434

IGNITE-8361 Use discovery messages for service deployment

The PR contains changes to cover the following tasks:

- [Use discovery messages for service 
deployment](https://issues.apache.org/jira/browse/IGNITE-8361)
- [Collect service deployment results asynchronously on 
coordinator](https://issues.apache.org/jira/browse/IGNITE-8362)
- [Propagate service deployment results from assigned nodes to 
initiator](https://issues.apache.org/jira/browse/IGNITE-3392)
- [Handle topology changes during service 
deployment](https://issues.apache.org/jira/browse/IGNITE-8363)
- [Propagate deployed services to joining 
nodes](https://issues.apache.org/jira/browse/IGNITE-8364)

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/daradurvs/ignite ignite-8361-to-master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/4434.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 #4434


commit 4517b5c43125107cb25f8e5e1da5bc00a8f5c252
Author: Vyacheslav Daradur 
Date:   2018-07-26T07:47:40Z

implemented




> Use discovery messages for service deployment
> -
>
> Key: IGNITE-8361
> URL: https://issues.apache.org/jira/browse/IGNITE-8361
> Project: Ignite
>  Issue Type: Improvement
>  Components: managed services
>Reporter: Denis Mekhanikov
>Assignee: Vyacheslav Daradur
>Priority: Major
>  Labels: iep-17
> Fix For: 2.7
>
>
> Service deployment should be based on discovery messages distribution.
> The procedure is as follows:
>  # Deploying node sends a message with a service configuration.
>  # Coordinator calculates the assignments and sends them in another message.
>  # Nodes check, whether they are assigned to deploy any services, and do so, 
> if they are.
> Utility cache won't be needed after these changes are made. All its mentions 
> should be removed from the code.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-8843) Web console: Actualize "Getting started" content

2018-07-26 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-8843:


Assignee: Pavel Konstantinov  (was: Vasiliy Sisko)

> Web console: Actualize "Getting started" content
> 
>
> Key: IGNITE-8843
> URL: https://issues.apache.org/jira/browse/IGNITE-8843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Pavel Konstantinov
>Priority: Minor
> Fix For: 2.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (IGNITE-9085) Web console: Actualize Login page carousel images

2018-07-26 Thread Vasiliy Sisko (JIRA)
Vasiliy Sisko created IGNITE-9085:
-

 Summary: Web console: Actualize Login page carousel images
 Key: IGNITE-9085
 URL: https://issues.apache.org/jira/browse/IGNITE-9085
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Vasiliy Sisko
Assignee: Vica Abramova






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (IGNITE-8843) Web console: Actualize "Getting started" content

2018-07-26 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov resolved IGNITE-8843.
--
Resolution: Fixed

Looks good. Merged to master.

> Web console: Actualize "Getting started" content
> 
>
> Key: IGNITE-8843
> URL: https://issues.apache.org/jira/browse/IGNITE-8843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (IGNITE-8843) Web console: Actualize "Getting started" content

2018-07-26 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov updated IGNITE-8843:
-
Fix Version/s: 2.7

> Web console: Actualize "Getting started" content
> 
>
> Key: IGNITE-8843
> URL: https://issues.apache.org/jira/browse/IGNITE-8843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Minor
> Fix For: 2.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-8843) Web console: Actualize "Getting started" content

2018-07-26 Thread Alexey Kuznetsov (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alexey Kuznetsov reassigned IGNITE-8843:


Assignee: Vasiliy Sisko  (was: Alexey Kuznetsov)

Please retest.

> Web console: Actualize "Getting started" content
> 
>
> Key: IGNITE-8843
> URL: https://issues.apache.org/jira/browse/IGNITE-8843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Minor
> Fix For: 2.7
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (IGNITE-8843) Web console: Actualize "Getting started" content

2018-07-26 Thread Vasiliy Sisko (JIRA)


[ 
https://issues.apache.org/jira/browse/IGNITE-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16556950#comment-16556950
 ] 

Vasiliy Sisko commented on IGNITE-8843:
---

Getting started dialog is actualized.

> Web console: Actualize "Getting started" content
> 
>
> Key: IGNITE-8843
> URL: https://issues.apache.org/jira/browse/IGNITE-8843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Vasiliy Sisko
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Assigned] (IGNITE-8843) Web console: Actualize "Getting started" content

2018-07-26 Thread Vasiliy Sisko (JIRA)


 [ 
https://issues.apache.org/jira/browse/IGNITE-8843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vasiliy Sisko reassigned IGNITE-8843:
-

Assignee: Alexey Kuznetsov  (was: Vasiliy Sisko)

> Web console: Actualize "Getting started" content
> 
>
> Key: IGNITE-8843
> URL: https://issues.apache.org/jira/browse/IGNITE-8843
> Project: Ignite
>  Issue Type: Bug
>  Components: wizards
>Reporter: Vasiliy Sisko
>Assignee: Alexey Kuznetsov
>Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)