[jira] [Commented] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution
[
https://issues.apache.org/jira/browse/IGNITE-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446637#comment-16446637
]
ASF GitHub Bot commented on IGNITE-8342:
GitHub user shroman opened a pull request:
https://github.com/apache/ignite/pull/3893
IGNITE-8342: When creating an index, unexpected non-default token cau…
…ses an infinite loop.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/shroman/ignite master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3893.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 #3893
commit df03b3677592bd212bb2bfaea5d6b811b156fc1f
Author: shroman
Date: 2018-04-21T05:08:11Z
IGNITE-8342: When creating an index, unexpected non-default token causes an
infinite loop.
> Semi colon in CREATE INDEX causes infinite loop execution
> -
>
> Key: IGNITE-8342
> URL: https://issues.apache.org/jira/browse/IGNITE-8342
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.5
>
>
> Given created table in cache
> {noformat}
> cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
> (age);")).getAll();
> {noformat}
> seems to cause infinite loop
> jstack :
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
> [0x7fa1b1932000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
> at
> org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
> at
> org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
> {noformat}
> without semicolon sign (";") in the end of the query, it performs well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8326) Can't execute SQL query for create index
[
https://issues.apache.org/jira/browse/IGNITE-8326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh resolved IGNITE-8326.
--
Resolution: Duplicate
> Can't execute SQL query for create index
>
>
> Key: IGNITE-8326
> URL: https://issues.apache.org/jira/browse/IGNITE-8326
> Project: Ignite
> Issue Type: Bug
>Reporter: Stepanov Mikhail
>Priority: Major
>
> I try to execute SQL query
> {code:java}
> CREATE INDEX IF NOT EXISTS "personNameIndex" ON "person" ("name");{code}
> using method
> {code:java}
> cache.query(query).getColumnsCount(){code}
> and this call is never ends, because it contains semicolon.
>
> See the code in org.apache.ignite.internal.sql.command.SqlCreateIndexCommand
> method parseIndexProperties. This method doesn't break when tokenType is
> SEMICOLON, but break when tokenType is EOF
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution
[
https://issues.apache.org/jira/browse/IGNITE-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Shtykh reassigned IGNITE-8342:
Assignee: Roman Shtykh
> Semi colon in CREATE INDEX causes infinite loop execution
> -
>
> Key: IGNITE-8342
> URL: https://issues.apache.org/jira/browse/IGNITE-8342
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Roman Shtykh
>Priority: Major
> Fix For: 2.5
>
>
> Given created table in cache
> {noformat}
> cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
> (age);")).getAll();
> {noformat}
> seems to cause infinite loop
> jstack :
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
> [0x7fa1b1932000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
> at
> org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
> at
> org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
> {noformat}
> without semicolon sign (";") in the end of the query, it performs well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7759) Logger does not print sockTimeout and ackTimeout default values for TcpDiscoverySpi
[
https://issues.apache.org/jira/browse/IGNITE-7759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446455#comment-16446455
]
Sergey Nuyanzin commented on IGNITE-7759:
-
Hello [~ruchirc]
could you please tell if you are working on this ticket or not
If not and if you do not mind I would pick it
> Logger does not print sockTimeout and ackTimeout default values for
> TcpDiscoverySpi
> ---
>
> Key: IGNITE-7759
> URL: https://issues.apache.org/jira/browse/IGNITE-7759
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.9, 2.1, 2.3
>Reporter: Roman Guseinov
>Priority: Minor
> Labels: newbie
>
> Logger does not print sockTimeout and ackTimeout default values for
> TcpDiscoverySpi
> Before starting TcpDiscoverySpi logger prints the following message (debug
> mode is enabled):
> {code:java}
> [main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=0, ackTimeout=0, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false]
> {code}
> Note, that sockTimeout=0 and ackTimeout=0. Default values initializing
> happens after TcpDiscoverySpi.spiStart is called:
> {code:java}
> public class TcpDiscoverySpi extends IgniteSpiAdapter implements DiscoverySpi
> {
> /** Node attribute that is mapped to node's external addresses (value is
> disc.tcp.ext-addrs). */
> /** {@inheritDoc} */
> @Override public void spiStart(@Nullable String igniteInstanceName)
> throws IgniteSpiException {
> initializeImpl();
> }
> /**
> *
> */
> private void initializeImpl() {
> if (impl != null)
> return;
> initFailureDetectionTimeout();
> if (!forceSrvMode &&
> (Boolean.TRUE.equals(ignite.configuration().isClientMode( {
> if (ackTimeout == 0)
> ackTimeout = DFLT_ACK_TIMEOUT_CLIENT;
> if (sockTimeout == 0)
> sockTimeout = DFLT_SOCK_TIMEOUT_CLIENT;
> impl = new ClientImpl(this);
> ctxInitLatch.countDown();
> }
> else {
> if (ackTimeout == 0)
> ackTimeout = DFLT_ACK_TIMEOUT;
> if (sockTimeout == 0)
> sockTimeout = DFLT_SOCK_TIMEOUT;
> impl = new ServerImpl(this);
> }
>
> }
> }
> {code}
> To avoid confusion I suggest printing default sockTimeout and ackTimeout if
> they weren't changed like:
> {code:java}
> [main][GridDiscoveryManager] Starting SPI: TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=5000, ackTimeout=5000, marsh=JdkMarshaller
> [clsFilter=org.apache.ignite.internal.IgniteKernal$5@402e37bc], reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8241) Docs: Triggering automatic rebalancing if the whole baseline topology is not recovered
[ https://issues.apache.org/jira/browse/IGNITE-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8241: --- Assignee: Prachi Garg (was: Denis Magda) > Docs: Triggering automatic rebalancing if the whole baseline topology is not > recovered > -- > > Key: IGNITE-8241 > URL: https://issues.apache.org/jira/browse/IGNITE-8241 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 2.4 >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Critical > Fix For: 2.5 > > Attachments: BaselineWatcher.java > > > The ticket is created as a result of the following discussion: > http://apache-ignite-developers.2346864.n4.nabble.com/Triggering-rebalancing-on-timeout-or-manually-if-the-baseline-topology-is-not-reassembled-td29299.html > The rebalancing doesn't happen if one of the nodes goes down, > thus, shrinking the baseline topology. It complies with our assumption that > the node should be recovered soon and there is no need to waste > CPU/memory/networking resources of the cluster shifting the data around. > However, there are always edge cases. I was reasonably asked how to trigger > the rebalancing within the baseline topology manually or on timeout if: > * It's not expected that the failed node would be resurrected in the >nearest time and > * It's not likely that that node will be replaced by the other one. > Until we embedd special facilities in the baseline topology that would > consider such situations we can document the following workaround. A user > application/tool/script has to subscribe to node_left events and remove the > failed node from the baseline topology in some time. Once the node is > removed, the baseline topology will be changed, and the rebalancing will be > kicked off. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8154) Add an ability to provide ExceptionListener to JmsStreamer
[
https://issues.apache.org/jira/browse/IGNITE-8154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446193#comment-16446193
]
Anton Kurbanov commented on IGNITE-8154:
Done.
> Add an ability to provide ExceptionListener to JmsStreamer
> --
>
> Key: IGNITE-8154
> URL: https://issues.apache.org/jira/browse/IGNITE-8154
> Project: Ignite
> Issue Type: Improvement
> Components: streaming
>Affects Versions: 2.4
>Reporter: Valentin Kulichenko
>Assignee: Anton Kurbanov
>Priority: Major
> Fix For: 2.6
>
>
> JMS API allows to provide custom {{ExceptionListener}} that is invoked when
> an exception occurs within JMS queue/topic. Currently, {{JmsStreamer}}
> doesn't use this in any way which creates two issues:
> * If there is an exception, it's lost and not even logged.
> * User can't provide their own listener.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
[
https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446178#comment-16446178
]
Valentin Kulichenko commented on IGNITE-7077:
-
[~dpavlov], [~NIzhikov], [~agura], guys, this was planned for 2.5 according to
dev list discussions. Let's merge it to {{ignite-2.5}}. Nikolay, can you please
do this?
> Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
> --
>
> Key: IGNITE-7077
> URL: https://issues.apache.org/jira/browse/IGNITE-7077
> Project: Ignite
> Issue Type: New Feature
> Components: spark
>Affects Versions: 2.3
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: bigdata
> Fix For: 2.5
>
>
> Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084.
> We need to implement custom spark strategy that can convert whole Spark SQL
> query to Ignite SQL Query if query consists of only Ignite tables.
> The strategy does nothing if spark query includes not only Ignite tables.
> Memsql implementation can be taken as an example -
> https://github.com/memsql/memsql-spark-connector
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-7907) Revisit and update the DBeaver documentations
[ https://issues.apache.org/jira/browse/IGNITE-7907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akmal Chaudhri closed IGNITE-7907. -- Documentation updated. Only minor updates required. All other instructions work as described. > Revisit and update the DBeaver documentations > - > > Key: IGNITE-7907 > URL: https://issues.apache.org/jira/browse/IGNITE-7907 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Assignee: Akmal Chaudhri >Priority: Blocker > Fix For: 2.5 > > > Seems that our documentation is outdated: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-with-dBeaver-td20368.html#a20376 > Need to go from the beginning and update the existing parts. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7963) Futures from DataStreamer.addData() fail to complete if DataStreamer.flush() is never called
[
https://issues.apache.org/jira/browse/IGNITE-7963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446121#comment-16446121
]
Dmitriy Pavlov commented on IGNITE-7963:
[~ilyak] still hope get response here. Could you plese change status if you're
working on ticket
> Futures from DataStreamer.addData() fail to complete if DataStreamer.flush()
> is never called
>
>
> Key: IGNITE-7963
> URL: https://issues.apache.org/jira/browse/IGNITE-7963
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
> Labels: usability
>
> DataStreamer.addData() will return futures for operation.
> Thus the naive use of DataStreamer will look like this:
> {code}
> for (Data d : data)
> futs.add(dataStreamer.addData(d));
> for (IgniteFuture f : futs)
> f.get();
> dataStreamer.close();
> {code}
> However, this does not work. Unless flush is called (manual or otherwisE),
> futures are not being processed. This code will likely hang on f.get().
> The solution, IMHO, is to introduce dataStreamer-flushing clause in f.get().
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8349) Move GA Grid description to ML site page
Denis Magda created IGNITE-8349: --- Summary: Move GA Grid description to ML site page Key: IGNITE-8349 URL: https://issues.apache.org/jira/browse/IGNITE-8349 Project: Ignite Issue Type: Task Components: site Reporter: Denis Magda Assignee: Prachi Garg Fix For: 2.5 Prachi, please move GA grid overview from here [1] to a dedicated section of the main ML page [2]. Don't forget to remove GA grid beta from the features page [3]. [1] https://ignite.apache.org/addons.html#ga-grid [2] https://ignite.apache.org/features/machinelearning.html [3] https://ignite.apache.org/features.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446078#comment-16446078
]
Dmitriy Pavlov commented on IGNITE-8347:
https://ci.ignite.apache.org/viewQueued.html?itemId=1232687
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446080#comment-16446080
]
Dmitriy Pavlov commented on IGNITE-8347:
[~ivan.glukos] could you please review
[https://github.com/apache/ignite/pull/3891]
and commit
[https://github.com/apache/ignite/pull/3891/commits/bfe3b63ad17d86ea5df4e74dfaebdad1ef126041]
Replacement of ThreadLocal to concurrent map seems to solve this issue.
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8271) Add documentation for partition based dataset (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8271: --- Assignee: Akmal Chaudhri (was: Prachi Garg) > Add documentation for partition based dataset (release 2.5) > --- > > Key: IGNITE-8271 > URL: https://issues.apache.org/jira/browse/IGNITE-8271 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Anton Dmitriev >Assignee: Akmal Chaudhri >Priority: Major > Fix For: 2.5 > > > In Apache Ignite 2.5 we have added new infrastructure layer - partition based > dataset, so now we need to add correspondent documentation. > Affected pages: > [Machine > Learning|https://apacheignite.readme.io/v2.4/docs/machine-learning-25] > [Partition Based > Dataset|https://apacheignite.readme.io/v2.4/docs/partition-based-dataset-25] > In release 2.5 > [https://apacheignite.readme.io/docs/machine-learning|https://apacheignite.readme.io/docs/machine-learning] > page should be changed to > [https://apacheignite.readme.io/docs/machine-learning-25|https://apacheignite.readme.io/docs/machine-learning-25]. > In release 2.5 > [https://apacheignite.readme.io/docs/partition-based-dataset-25|https://apacheignite.readme.io/docs/partition-based-dataset-25] > page should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8268) Add documentation for linear regression (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8268: --- Assignee: Akmal Chaudhri (was: Prachi Garg) > Add documentation for linear regression (release 2.5) > - > > Key: IGNITE-8268 > URL: https://issues.apache.org/jira/browse/IGNITE-8268 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Anton Dmitriev >Assignee: Akmal Chaudhri >Priority: Major > Fix For: 2.5 > > > In Apache Ignite 2.5 we have added two implementation of linear regression > based on partition based dataset: LSQR and gradient descent and now we need > to add documentation for these features. > Affected pages: > [Linear > Regression|https://apacheignite.readme.io/v2.4/docs/linear-regression-25] > In release 2.5 > [https://apacheignite.readme.io/v2.4/docs/ols-multiple-linear-regression|https://apacheignite.readme.io/v2.4/docs/ols-multiple-linear-regression] > should be changed to > [https://apacheignite.readme.io/docs/linear-regression-25|https://apacheignite.readme.io/docs/linear-regression-25]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8269) Add documentation for decision tree (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8269: --- Assignee: Akmal Chaudhri (was: Prachi Garg) > Add documentation for decision tree (release 2.5) > - > > Key: IGNITE-8269 > URL: https://issues.apache.org/jira/browse/IGNITE-8269 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Anton Dmitriev >Assignee: Akmal Chaudhri >Priority: Major > Fix For: 2.5 > > > In Apache Ignite 2.5 we have added a decision tree based on partition based > dataset and now we need to documentation for this feature. > Affected pages: > [Decision Tree|https://apacheignite.readme.io/v2.4/docs/decision-tree-25] > In release 2.5 > [https://apacheignite.readme.io/docs/decision-trees|https://apacheignite.readme.io/docs/decision-trees] > page should be changed to > [https://apacheignite.readme.io/docs/decision-tree-25|https://apacheignite.readme.io/docs/decision-tree-25]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8272) Add documentation for normalization preprocessor (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446073#comment-16446073 ] Denis Magda commented on IGNITE-8272: - [~abchaudhri], please review instead. > Add documentation for normalization preprocessor (release 2.5) > -- > > Key: IGNITE-8272 > URL: https://issues.apache.org/jira/browse/IGNITE-8272 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Anton Dmitriev >Assignee: Akmal Chaudhri >Priority: Major > Fix For: 2.5 > > > In Apache Ignite 2.5 we have added a normalization preprocessor working on > top of partition based dataset and now we need to add documentation for this > feature. > Affected pages: > [Preprocessing|https://apacheignite.readme.io/v2.4/docs/preprocessing-25] > In release 2.5 > [https://apacheignite.readme.io/v2.4/docs/preprocessing-25|https://apacheignite.readme.io/v2.4/docs/preprocessing-25] > page should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8272) Add documentation for normalization preprocessor (release 2.5)
[ https://issues.apache.org/jira/browse/IGNITE-8272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-8272: --- Assignee: Akmal Chaudhri (was: Prachi Garg) > Add documentation for normalization preprocessor (release 2.5) > -- > > Key: IGNITE-8272 > URL: https://issues.apache.org/jira/browse/IGNITE-8272 > Project: Ignite > Issue Type: Improvement > Components: documentation, ml >Affects Versions: 2.5 >Reporter: Anton Dmitriev >Assignee: Akmal Chaudhri >Priority: Major > Fix For: 2.5 > > > In Apache Ignite 2.5 we have added a normalization preprocessor working on > top of partition based dataset and now we need to add documentation for this > feature. > Affected pages: > [Preprocessing|https://apacheignite.readme.io/v2.4/docs/preprocessing-25] > In release 2.5 > [https://apacheignite.readme.io/v2.4/docs/preprocessing-25|https://apacheignite.readme.io/v2.4/docs/preprocessing-25] > page should be added. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8330) Docs: Put JDBC/ODBC URL in Brackets When Connecting From Bash
[ https://issues.apache.org/jira/browse/IGNITE-8330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16446054#comment-16446054 ] Denis Magda commented on IGNITE-8330: - Now we support both & and ; as a delimiter. > Docs: Put JDBC/ODBC URL in Brackets When Connecting From Bash > - > > Key: IGNITE-8330 > URL: https://issues.apache.org/jira/browse/IGNITE-8330 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Denis Magda >Assignee: Prachi Garg >Priority: Major > Fix For: 2.5 > > > We need to add a warning callout with the content below to both JDBC and ODBC > documentation pages: > Title: Put JDBC/ODBC URL in Brackets When Connecting From Bash > Description: > Make sure to put the connection URL in " brackets when opening it up from a > bash environment, as follows: > "jdbc:ignite:thin://[address]:[port];user=ignite;password=[password]" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7900) Write Zookeeper Discovery documentation in readme.io
[ https://issues.apache.org/jira/browse/IGNITE-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7900: Description: Describe Zookeeper Discovery in readme.io. The documentation will be based on the details presented in IEP-15: https://cwiki.apache.org/confluence/display/IGNITE/IEP-15%3A+Discovery+SPI+by+ZooKeeper The following sections should present in the doc: * Native discovery SPI vs Zookeeper SPI (pros and cons (aka. ring-based communication vs. consensus-based Zookeeper Cluster; when to use the first and the second) * Configuration example * Describe node join and disconnection process * Describe split-brain handling/protection * Review and clean IEP (will be used as an advanced doc) was: Describe Zookeeper Discovery in readme.io. The documentation will be based on the details presented in IEP-15: https://cwiki.apache.org/confluence/display/IGNITE/IEP-15%3A+Discovery+SPI+by+ZooKeeper > Write Zookeeper Discovery documentation in readme.io > > > Key: IGNITE-7900 > URL: https://issues.apache.org/jira/browse/IGNITE-7900 > Project: Ignite > Issue Type: Task > Components: documentation, zookeeper >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.5 > > Attachments: zookeeper_discovery_diagrams.zip > > > Describe Zookeeper Discovery in readme.io. > The documentation will be based on the details presented in IEP-15: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-15%3A+Discovery+SPI+by+ZooKeeper > The following sections should present in the doc: > * Native discovery SPI vs Zookeeper SPI (pros and cons (aka. ring-based > communication vs. consensus-based Zookeeper Cluster; when to use the first > and the second) > * Configuration example > * Describe node join and disconnection process > * Describe split-brain handling/protection > * Review and clean IEP (will be used as an advanced doc) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7900) Write Zookeeper Discovery documentation in readme.io
[ https://issues.apache.org/jira/browse/IGNITE-7900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-7900: Attachment: zookeeper_discovery_diagrams.zip > Write Zookeeper Discovery documentation in readme.io > > > Key: IGNITE-7900 > URL: https://issues.apache.org/jira/browse/IGNITE-7900 > Project: Ignite > Issue Type: Task > Components: documentation, zookeeper >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Assignee: Prachi Garg >Priority: Major > Fix For: 2.5 > > Attachments: zookeeper_discovery_diagrams.zip > > > Describe Zookeeper Discovery in readme.io. > The documentation will be based on the details presented in IEP-15: > https://cwiki.apache.org/confluence/display/IGNITE/IEP-15%3A+Discovery+SPI+by+ZooKeeper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8075) .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange
[ https://issues.apache.org/jira/browse/IGNITE-8075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-8075: -- Description: Neet to add new methods as part of .NET API: org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange - timeout for automatic rollback on exchange. org.apache.ignite.IgniteTransactions#withLabel - tx label org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local active transactions. org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange Java implementation is currently available at a branch [1] [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 was: Neet to add new methods as part of .NET API: org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange - timeout for automatic rollback on exchange. org.apache.ignite.IgniteTransactions#withLabel - tx label org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local active transactions. Java implementation is currently available at a branch [1] [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 Summary: .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, setTxTimeoutOnPartitionMapExchange (was: .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions) > .NET: setRollbackOnTopologyChangeTimeout, withLabel, localActiveTransactions, > setTxTimeoutOnPartitionMapExchange > > > Key: IGNITE-8075 > URL: https://issues.apache.org/jira/browse/IGNITE-8075 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > > > Neet to add new methods as part of .NET API: > org.apache.ignite.configuration.TransactionConfiguration#txTimeoutOnPartitionMapExchange > - timeout for automatic rollback on exchange. > org.apache.ignite.IgniteTransactions#withLabel - tx label > org.apache.ignite.IgniteTransactions#localActiveTransactions - list of local > active transactions. > org.apache.ignite.IgniteCluster#setTxTimeoutOnPartitionMapExchange > Java implementation is currently available at a branch [1] > [1] https://github.com/gridgain/apache-ignite/tree/ignite-6827-2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
[ https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445982#comment-16445982 ] Nikolay Izhikov commented on IGNITE-7077: - [~agoncharuk] Thank you! > Spark Data Frame Support. Strategy to convert complete query to Ignite SQL > -- > > Key: IGNITE-7077 > URL: https://issues.apache.org/jira/browse/IGNITE-7077 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: bigdata > Fix For: 2.5 > > > Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084. > We need to implement custom spark strategy that can convert whole Spark SQL > query to Ignite SQL Query if query consists of only Ignite tables. > The strategy does nothing if spark query includes not only Ignite tables. > Memsql implementation can be taken as an example - > https://github.com/memsql/memsql-spark-connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
[ https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445965#comment-16445965 ] Dmitriy Pavlov commented on IGNITE-7077: [~NIzhikov] please also fix licenses before cherry-picking [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_LicensesHeaders&branch=%3Cdefault%3E&tab=buildTypeStatusDiv] > Spark Data Frame Support. Strategy to convert complete query to Ignite SQL > -- > > Key: IGNITE-7077 > URL: https://issues.apache.org/jira/browse/IGNITE-7077 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: bigdata > Fix For: 2.5 > > > Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084. > We need to implement custom spark strategy that can convert whole Spark SQL > query to Ignite SQL Query if query consists of only Ignite tables. > The strategy does nothing if spark query includes not only Ignite tables. > Memsql implementation can be taken as an example - > https://github.com/memsql/memsql-spark-connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445969#comment-16445969 ] Roman Shtykh commented on IGNITE-8286: -- Attached TC test results. > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
[ https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445977#comment-16445977 ] Alexey Goncharuk commented on IGNITE-7077: -- Fixed licenses, please do not forget to cherry-pick commit fa841242a3ce7d5179e33663a724f3c3c07ef673 to ignite-2.5 if this ticket should be included to ignite-2.5 > Spark Data Frame Support. Strategy to convert complete query to Ignite SQL > -- > > Key: IGNITE-7077 > URL: https://issues.apache.org/jira/browse/IGNITE-7077 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: bigdata > Fix For: 2.5 > > > Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084. > We need to implement custom spark strategy that can convert whole Spark SQL > query to Ignite SQL Query if query consists of only Ignite tables. > The strategy does nothing if spark query includes not only Ignite tables. > Memsql implementation can be taken as an example - > https://github.com/memsql/memsql-spark-connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445949#comment-16445949
]
Taras Ledkov commented on IGNITE-8347:
--
[~dpavlov] Looks like workaround works without memory leaks on node restarts.
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology
[
https://issues.apache.org/jira/browse/IGNITE-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445929#comment-16445929
]
ASF GitHub Bot commented on IGNITE-8134:
Github user dmekhanikov closed the pull request at:
https://github.com/apache/ignite/pull/3863
> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
> Issue Type: Bug
> Components: managed services, persistence
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.6
>
>
> If a node is not a part of the baseline topology, the services will never be
> deployed on it. In particular, if that node calls a synchronous deploy*
> method, the method will hang.
> After the node is added to the baseline, all previously initiated
> deployments succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the
> GridServiceProcessor on the ignite-sys-cache.
> Example:
> =
> {code}
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)
> )
> );
> try (Ignite ignite1 = Ignition.start(cfg1)) {
> // activate and set baseline topology
> ignite1.cluster().active(true);
> // start another node
> IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
> .setIgniteInstanceName("node2");
> try (Ignite ignite2 = Ignition.start(cfg2)) {
> // try to deploy a service;
> // this call hangs until the second node is added to the BLT
> (e.g. externally via control.sh)
> ignite2.services().deployNodeSingleton("myService", new
> MyServiceImpl()); System.out.println("> Deployed"); }
> }
> }
> private static class MyServiceImpl implements Service {
> @Override public void cancel(ServiceContext ctx) { }
> @Override public void init(ServiceContext ctx) { }
> @Override public void execute(ServiceContext ctx) { }
> }
> }
> }
> {code}
> =
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8134) Services can't be deployed on servers outside of baseline topology
[
https://issues.apache.org/jira/browse/IGNITE-8134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445908#comment-16445908
]
Andrey Gura commented on IGNITE-8134:
-
Merged to master branch.
> Services can't be deployed on servers outside of baseline topology
> --
>
> Key: IGNITE-8134
> URL: https://issues.apache.org/jira/browse/IGNITE-8134
> Project: Ignite
> Issue Type: Bug
> Components: managed services, persistence
>Affects Versions: 2.4
>Reporter: Stanislav Lukyanov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.6
>
>
> If a node is not a part of the baseline topology, the services will never be
> deployed on it. In particular, if that node calls a synchronous deploy*
> method, the method will hang.
> After the node is added to the baseline, all previously initiated
> deployments succeed (and deploy* methods return).
> It seems that the issue is with the continuous query started by the
> GridServiceProcessor on the ignite-sys-cache.
> Example:
> =
> {code}
> public class BltServicesBug {
> public static void main(String[] args) {
> // start one node
> IgniteConfiguration cfg1 = new IgniteConfiguration()
> .setIgniteInstanceName("node1")
> .setDataStorageConfiguration(
> new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(
> new DataRegionConfiguration()
> .setPersistenceEnabled(true)
> )
> );
> try (Ignite ignite1 = Ignition.start(cfg1)) {
> // activate and set baseline topology
> ignite1.cluster().active(true);
> // start another node
> IgniteConfiguration cfg2 = new IgniteConfiguration(cfg1)
> .setIgniteInstanceName("node2");
> try (Ignite ignite2 = Ignition.start(cfg2)) {
> // try to deploy a service;
> // this call hangs until the second node is added to the BLT
> (e.g. externally via control.sh)
> ignite2.services().deployNodeSingleton("myService", new
> MyServiceImpl()); System.out.println("> Deployed"); }
> }
> }
> private static class MyServiceImpl implements Service {
> @Override public void cancel(ServiceContext ctx) { }
> @Override public void init(ServiceContext ctx) { }
> @Override public void execute(ServiceContext ctx) { }
> }
> }
> }
> {code}
> =
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-8347:
---
Fix Version/s: 2.5
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445897#comment-16445897
]
Dmitriy Pavlov commented on IGNITE-8347:
Work around is to set
org.apache.ignite.IgniteSystemProperties#IGNITE_DELAYED_REPLACED_PAGE_WRITE to
"false".
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
> Fix For: 2.5
>
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7918) Huge memory leak when data streamer used together with local cache
[
https://issues.apache.org/jira/browse/IGNITE-7918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445896#comment-16445896
]
Alexey Goncharuk commented on IGNITE-7918:
--
[~aealeksandrov], {{new AffinityAssignmentKey("topVerRmv", topVerRmv)}} does
not look right - what if a cache starts with a name that is smaller than
"topVer"? We need to have a special key here.
Otherwise looks good.
> Huge memory leak when data streamer used together with local cache
> --
>
> Key: IGNITE-7918
> URL: https://issues.apache.org/jira/browse/IGNITE-7918
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Zbyszek B
>Assignee: Andrey Aleksandrov
>Priority: Major
> Fix For: 2.6
>
> Attachments: Demo.java, MemLeak-Ignite.png, MemLeak-Ignite.txt
>
>
> Dear Igniters,
> We observe huge memory leak when data streamer used together with local cache.
> In the attached demo producer produces local cache with single binary object
> and passes this to the queue. Consumer picks up the cache from the queue,
> constructs different binary object from it, adds it to global partitioned
> cache and destroys local cache.
> This design causes a significant leak - the whole heap is used within minutes
> (no matter if this is 4G or 24G).
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6260) Need to rename setDistributedJoins to setNonCollocatedJoins
[
https://issues.apache.org/jira/browse/IGNITE-6260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445891#comment-16445891
]
Dmitriy Pavlov commented on IGNITE-6260:
Folks, ticket is in PA state and there is no activity since 2017. Should we
accept or reject patch?
> Need to rename setDistributedJoins to setNonCollocatedJoins
> ---
>
> Key: IGNITE-6260
> URL: https://issues.apache.org/jira/browse/IGNITE-6260
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc, odbc, sql
>Reporter: Dmitriy Setrakyan
>Assignee: vk
>Priority: Major
> Labels: usability
>
> The name {{distributed join}} is very confusing, as all joins in Ignite are
> distributed. We should do the following:
> * Deprecate {{setDistributedJoins(...)}} property (it should be removed in
> 3.0)
> * Add {{setNonCollocatedJoins(...)}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7778) User's authentication data must be persisted on cluster with disabled persistence
[
https://issues.apache.org/jira/browse/IGNITE-7778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445883#comment-16445883
]
Taras Ledkov commented on IGNITE-7778:
--
The tests are blocked by memory leak. See IGNITE-8347
> User's authentication data must be persisted on cluster with disabled
> persistence
> -
>
> Key: IGNITE-7778
> URL: https://issues.apache.org/jira/browse/IGNITE-7778
> Project: Ignite
> Issue Type: Task
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> The ticket is related to the: IGNITE-7436 (introduce users in Ignite)
> {{IgniteAuthenticationProcessor}} uses metastorage to persist user data. But
> metastorage works only with persistent cluster. We have to support user
> authentication for in-memory cluster.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8348) Debug information about discovery messages in TcpDiscoverySpiMBean
[
https://issues.apache.org/jira/browse/IGNITE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-8348:
--
Description:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
3) Split-brain
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason wants to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
Additional methods should print only significant messages
({{TcpDiscoveryJoinRequestMessage}}, {{TcpDiscoveryNodeAddedMessage}},
{{TcpDiscoveryNodeAddFinishedMessage}}, {{TcpDiscoveryNodeFailedMessage}},
{{TcpDiscoveryCustomEventMessage}}) for a specific period of time. The period
should be customizable through JVM parameters.
was:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
3) Split-brain
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason wants to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
Additional methods should print only significant messages
({{TcpDiscoveryJoinRequestMessage}}, {{TcpDiscoveryNodeAddedMessage}},
{{TcpDiscoveryNodeAddFinishedMessage}}, {{TcpDiscoveryNodeFailedMessage}},
{{TcpDiscoveryCustomEventMessage}}) for a specific period of time.
> Debug information about discovery messages in TcpDiscoverySpiMBean
> --
>
> Key: IGNITE-8348
> URL: https://issues.apache.org/jira/browse/IGNITE-8348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> In some discovery issue, like:
> 1) Behavior on instable network
> 2) Segmentation of several nodes
> 3) Split-brain
> or others, when the SPI works does not obviously.
> Wants to know - what kind of messages has been sent (receive) from particular
> node?
> By that reason wants to add method on TcpDiscoverySpiMBean:
> {code}
> /**
> * Print a list of discarder messages.
> */
> @MXBeanDescription("Print a list of discarded messages to log.")
> public void printListOfDiscardedMessages();
> /**
> * Print a list of received messages.
> */
> @MXBeanDescription("Print a list of received messages to log.")
> public void printListOfReceivedMessages();
> /**
> * Print a list of sent messages.
> */
> @MXBeanDescription("Print a list of sent messages to log.")
> public void printListOfSentMessages();
> {code}
> Additional methods should print only significant messages
> ({{TcpDiscoveryJoinRequestMessage}}, {{TcpDiscoveryNodeAddedMessage}},
> {{TcpDiscoveryNodeAddFinishedMessage}}, {{TcpDiscoveryNodeFailedMessage}},
> {{TcpDiscoveryCustomEventMessage}}) for a specific period of time. The period
> should be customizable through JVM parameters.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8235) Implement execution of selected part of SQL query
[ https://issues.apache.org/jira/browse/IGNITE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-8235: Assignee: Alexander Kalinin (was: Alexey Kuznetsov) # remove unused $comple # rename $event to selection or currentSelection or selectedText > Implement execution of selected part of SQL query > - > > Key: IGNITE-8235 > URL: https://issues.apache.org/jira/browse/IGNITE-8235 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Alexander Kalinin >Assignee: Alexander Kalinin >Priority: Minor > > If we had 3 SQL rows in the notebook, and selected one and clicked execute. > We should only execute the highlighted row. If no row is highlighted, then > all rows should be executed. That's a standard feature of graphical SQL tools. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8348) Debug information about discovery messages in TcpDiscoverySpiMBean
[
https://issues.apache.org/jira/browse/IGNITE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-8348:
--
Description:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
3) Split-brain
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason wants to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
Additional methods should print only significant messages
({{TcpDiscoveryJoinRequestMessage}}, {{TcpDiscoveryNodeAddedMessage}},
{{TcpDiscoveryNodeAddFinishedMessage}}, {{TcpDiscoveryNodeFailedMessage}},
{{TcpDiscoveryCustomEventMessage}}) for a specific period of time.
was:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
3) Split-brain
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason wants to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
> Debug information about discovery messages in TcpDiscoverySpiMBean
> --
>
> Key: IGNITE-8348
> URL: https://issues.apache.org/jira/browse/IGNITE-8348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> In some discovery issue, like:
> 1) Behavior on instable network
> 2) Segmentation of several nodes
> 3) Split-brain
> or others, when the SPI works does not obviously.
> Wants to know - what kind of messages has been sent (receive) from particular
> node?
> By that reason wants to add method on TcpDiscoverySpiMBean:
> {code}
> /**
> * Print a list of discarder messages.
> */
> @MXBeanDescription("Print a list of discarded messages to log.")
> public void printListOfDiscardedMessages();
> /**
> * Print a list of received messages.
> */
> @MXBeanDescription("Print a list of received messages to log.")
> public void printListOfReceivedMessages();
> /**
> * Print a list of sent messages.
> */
> @MXBeanDescription("Print a list of sent messages to log.")
> public void printListOfSentMessages();
> {code}
> Additional methods should print only significant messages
> ({{TcpDiscoveryJoinRequestMessage}}, {{TcpDiscoveryNodeAddedMessage}},
> {{TcpDiscoveryNodeAddFinishedMessage}}, {{TcpDiscoveryNodeFailedMessage}},
> {{TcpDiscoveryCustomEventMessage}}) for a specific period of time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8348) Debug information about discovery messages in TcpDiscoverySpiMBean
[
https://issues.apache.org/jira/browse/IGNITE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-8348:
--
Description:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
3) Split-brain
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason wants to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
was:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason want to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
> Debug information about discovery messages in TcpDiscoverySpiMBean
> --
>
> Key: IGNITE-8348
> URL: https://issues.apache.org/jira/browse/IGNITE-8348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> In some discovery issue, like:
> 1) Behavior on instable network
> 2) Segmentation of several nodes
> 3) Split-brain
> or others, when the SPI works does not obviously.
> Wants to know - what kind of messages has been sent (receive) from particular
> node?
> By that reason wants to add method on TcpDiscoverySpiMBean:
> {code}
> /**
> * Print a list of discarder messages.
> */
> @MXBeanDescription("Print a list of discarded messages to log.")
> public void printListOfDiscardedMessages();
> /**
> * Print a list of received messages.
> */
> @MXBeanDescription("Print a list of received messages to log.")
> public void printListOfReceivedMessages();
> /**
> * Print a list of sent messages.
> */
> @MXBeanDescription("Print a list of sent messages to log.")
> public void printListOfSentMessages();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation
[
https://issues.apache.org/jira/browse/IGNITE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445857#comment-16445857
]
ASF GitHub Bot commented on IGNITE-8323:
GitHub user ilantukh opened a pull request:
https://github.com/apache/ignite/pull/3890
IGNITE-8323 : Fixed discoveryEvent listener calls.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8323
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3890.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 #3890
commit 02dc5a35da7c4d5bb27b2516a38ceb4037f5a0c8
Author: Ilya Lantukh
Date: 2018-04-20T15:00:53Z
ignite-8323 : Fixed discoveryEvent listener calls.
> Assertion error during simultaneous auto-activation and manual activation
> -
>
> Key: IGNITE-8323
> URL: https://issues.apache.org/jira/browse/IGNITE-8323
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I observe the following assertion in
> IgnitePdsDestroyCacheTest.testDestroyCaches
> {code}
> [2018-04-19
> 15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
> Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3,
> minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1],
> customMsg=ChangeGlobalStateMessage
> [id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67,
> reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14,
> initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276,
> branchingType='Cluster activation',
> baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897,
> f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]],
> forceChangeBaselineTopology=false, timestamp=1524141062984]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> From a quick investigation I see that this topology version is updated from
> both auto-activation and manual activation requests.
> Even though this assertion does not affect this particular test, the
> assertion must be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8348) Debug information about discovery messages in TcpDiscoverySpiMBean
[
https://issues.apache.org/jira/browse/IGNITE-8348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-8348:
--
Description:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason want to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
was:
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason want to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
> Debug information about discovery messages in TcpDiscoverySpiMBean
> --
>
> Key: IGNITE-8348
> URL: https://issues.apache.org/jira/browse/IGNITE-8348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> In some discovery issue, like:
> 1) Behavior on instable network
> 2) Segmentation of several nodes
> or others, when the SPI works does not obviously.
> Wants to know - what kind of messages has been sent (receive) from particular
> node?
> By that reason want to add method on TcpDiscoverySpiMBean:
> {code}
> /**
> * Print a list of discarder messages.
> */
> @MXBeanDescription("Print a list of discarded messages to log.")
> public void printListOfDiscardedMessages();
> /**
> * Print a list of received messages.
> */
> @MXBeanDescription("Print a list of received messages to log.")
> public void printListOfReceivedMessages();
> /**
> * Print a list of sent messages.
> */
> @MXBeanDescription("Print a list of sent messages to log.")
> public void printListOfSentMessages();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8348) Debug information about discovery messages in TcpDiscoverySpiMBean
Vladislav Pyatkov created IGNITE-8348:
-
Summary: Debug information about discovery messages in
TcpDiscoverySpiMBean
Key: IGNITE-8348
URL: https://issues.apache.org/jira/browse/IGNITE-8348
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
In some discovery issue, like:
1) Behavior on instable network
2) Segmentation of several nodes
or others, when the SPI works does not obviously.
Wants to know - what kind of messages has been sent (receive) from particular
node?
By that reason want to add method on TcpDiscoverySpiMBean:
{code}
/**
* Print a list of discarder messages.
*/
@MXBeanDescription("Print a list of discarded messages to log.")
public void printListOfDiscardedMessages();
/**
* Print a list of received messages.
*/
@MXBeanDescription("Print a list of received messages to log.")
public void printListOfReceivedMessages();
/**
* Print a list of sent messages.
*/
@MXBeanDescription("Print a list of sent messages to log.")
public void printListOfSentMessages();
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov updated IGNITE-8060: --- Description: For reproducing (master branch) You should start one local server and one local client nodes and follow the instructions: 1)Connect to client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 2)Create new table on client node: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; 3)Check that table exists from server node: !tables On this step table should be shown in the response. 4)Drop the client node 5)Create new client node 6)Connect to new client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 7)Check that table exists from server node: !tables *On this step there is no "city" table in the list.* 8)Try to drop the table: DROP TABLE City; java.sql.SQLException: Table doesn't exist: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) 9)Try to create new table: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; java.sql.SQLException: Table already exists: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) Update: Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done. !tables doen\t work even after SELECT SELECT works OK. was: For reproducing: You should start one local server and one local client nodes and follow the instructions: 1)Connect to client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 2)Create new table on client node: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; 3)Check that table exists from server node: !tables On this step table should be shown in the response. 4)Drop the client node 5)Create new client node 6)Connect to new client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 7)Check that table exists from server node: !tables *On this step there is no "city" table in the list.* 8)Try to drop the table: DROP TABLE City; java.sql.SQLException: Table doesn't exist: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) 9)Try to create new table: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; java.sql.SQLException: Table already exists: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) Update: Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done. !tables doen\t work even after SELECT SELECT works OK. > Sqline creating tables on client nodes works incorrect in case of node's > shutdown > - > > Key: IGNITE-8060 > URL: https://issues.apache.org/jira/browse/IGNITE-8
[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445841#comment-16445841
]
Taras Ledkov commented on IGNITE-8347:
--
[~dpavlov], please take a look at the linked pull request. The PR contains the
test to reproduce mem leak.
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445839#comment-16445839
]
ASF GitHub Bot commented on IGNITE-8347:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/3889
IGNITE-8347 Memory leaks on restart Ignite node with enabled persistence
at ThreadLocal
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8347
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/3889.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 #3889
commit d184bdd5b2fdd5392c8abbc3067839dacd7acfcd
Author: tledkov-gridgain
Date: 2018-04-19T09:39:52Z
IGNITE-8347: add test to reproduce memory leak
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
[
https://issues.apache.org/jira/browse/IGNITE-8347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-8347:
-
Description:
Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
looks suspicious.
I've added the simple test to memory leak on restart Ignite nodes from the
thread that is not terminated after node stopped.
This case is very useful e.g. for all jUnit cache tests that starts Ignite
cluster from the {{beforeTestsStarted()}} (this method is called from the
{{main}} thread and alive for all tests in a test suite).
was:Memory leaks on restart Ignite node with enabled persistence at
ThreadLocal.
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
> ---
>
> Key: IGNITE-8347
> URL: https://issues.apache.org/jira/browse/IGNITE-8347
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.4
>Reporter: Taras Ledkov
>Assignee: Dmitriy Pavlov
>Priority: Critical
>
> Memory leaks on restart Ignite node with enabled persistence at ThreadLocal.
> The ThreadLocal {{DelayedPageReplacementTracker#delayedPageWriteThreadLoc}}
> looks suspicious.
> I've added the simple test to memory leak on restart Ignite nodes from the
> thread that is not terminated after node stopped.
> This case is very useful e.g. for all jUnit cache tests that starts Ignite
> cluster from the {{beforeTestsStarted()}} (this method is called from the
> {{main}} thread and alive for all tests in a test suite).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8323) Assertion error during simultaneous auto-activation and manual activation
[
https://issues.apache.org/jira/browse/IGNITE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Lantukh reassigned IGNITE-8323:
Assignee: Ilya Lantukh
> Assertion error during simultaneous auto-activation and manual activation
> -
>
> Key: IGNITE-8323
> URL: https://issues.apache.org/jira/browse/IGNITE-8323
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Ilya Lantukh
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> I observe the following assertion in
> IgnitePdsDestroyCacheTest.testDestroyCaches
> {code}
> [2018-04-19
> 15:31:02,994][ERROR][tcp-disco-msg-worker-#131%persistence.IgnitePdsDestroyCacheTest0%][TcpDiscoverySpi]
> Failed to unmarshal discovery custom message.
> java.lang.AssertionError: lastAffVer=AffinityTopologyVersion [topVer=3,
> minorTopVer=1], topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1],
> customMsg=ChangeGlobalStateMessage
> [id=59bcd2ed261-f35bb298-fc8b-46dd-9d06-7800f7c11d67,
> reqId=01b3cf41-63e0-4ddc-80bc-a3e9b5414c14,
> initiatingNodeId=0fc03864-7d8a-49bb-ba8a-ff6fb8c0, activate=true,
> baselineTopology=BaselineTopology [id=0, branchingHash=-1713401276,
> branchingType='Cluster activation',
> baselineNodes=[c2d35f40-7229-43b3-9342-305eb5a63897,
> f79b6d68-feaa-4b75-805a-8287b396b3eb, 442fe461-480c-4b32-8b81-28af4f66e165]],
> forceChangeBaselineTopology=false, timestamp=1524141062984]
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3371)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> {code}
> From a quick investigation I see that this topology version is updated from
> both auto-activation and manual activation requests.
> Even though this assertion does not affect this particular test, the
> assertion must be fixed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-7946) IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on TC
[
https://issues.apache.org/jira/browse/IGNITE-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kovalenko resolved IGNITE-7946.
-
Resolution: Won't Fix
Fix Version/s: (was: 2.6)
2.5
Already fixed in IGNITE-8116
> IgniteCacheClientQueryReplicatedNodeRestartSelfTest#testRestarts can hang on
> TC
> ---
>
> Key: IGNITE-7946
> URL: https://issues.apache.org/jira/browse/IGNITE-7946
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> According to test logs there can be unfinished rebalance:
> {noformat}
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,327][INFO
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
> Cancelled rebalancing from all nodes [topology=AffinityTopologyVersion
> [topVer=103, minorTopVer=0]]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,327][INFO
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
> Completed rebalance future: RebalanceFuture [grp=CacheGroupContext [grp=pr],
> topVer=AffinityTopologyVersion [topVer=103, minorTopVer=0], rebalanceId=1]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
> Rebalancing scheduled [order=[pe, pr]]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridCachePartitionExchangeManager]
> Rebalancing started [top=AffinityTopologyVersion [topVer=104,
> minorTopVer=0], evt=NODE_LEFT, node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
> Starting rebalancing [grp=pe, mode=SYNC,
> fromNode=31193890-bf8f-4c85-af76-342efb31, partitionsCount=15,
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO
> ][exchange-worker-#456665%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
> Starting rebalancing [grp=pe, mode=SYNC,
> fromNode=517f4efb-4433-489a-8c8e-e91f9e70, partitionsCount=16,
> topology=AffinityTopologyVersion [topVer=104, minorTopVer=0], rebalanceId=2]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,328][INFO
> ][exchange-worker-#455983%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest0%][GridCachePartitionExchangeManager]
> Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
> [topVer=104, minorTopVer=0], evt=NODE_LEFT,
> node=04d02ea1-286c-4d8c-8870-e147c552]
> [01:21:23] : [Step 4/5] [2018-03-13 22:21:23,332][INFO
> ][sys-#456730%near.IgniteCacheClientQueryReplicatedNodeRestartSelfTest3%][GridDhtPartitionDemander]
> Completed rebalancing [fromNode=517f4efb-4433-489a-8c8e-e91f9e70,
> cacheOrGroup=pe, topology=AffinityTopologyVersion [topVer=104,
> minorTopVer=0], time=0 ms]
> {noformat}
> It can be cause of test hanging.
> {noformat}
> "restart-thread-2" #441778 prio=5 os_prio=0 tid=0x7fd030003800 nid=0x3b8c
> waiting on condition [0x7fce5092f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> 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.GridCacheProcessor.onKernalStart(GridCacheProcessor.java:861)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1059)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
> - locked <0x00070d8a1830> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:642)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:849)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:833)
> at
> org.apache.ignite.testframewo
[jira] [Resolved] (IGNITE-8218) Add exchange latch state to diagnostic messages
[ https://issues.apache.org/jira/browse/IGNITE-8218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Kovalenko resolved IGNITE-8218. - Resolution: Won't Fix Fix Version/s: (was: 2.6) 2.5 Already fixed in IGNITE-8243 > Add exchange latch state to diagnostic messages > --- > > Key: IGNITE-8218 > URL: https://issues.apache.org/jira/browse/IGNITE-8218 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.5 >Reporter: Pavel Kovalenko >Assignee: Pavel Kovalenko >Priority: Major > Fix For: 2.5 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Aleksandrov updated IGNITE-8060: --- Description: For reproducing: You should start one local server and one local client nodes and follow the instructions: 1)Connect to client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 2)Create new table on client node: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; 3)Check that table exists from server node: !tables On this step table should be shown in the response. 4)Drop the client node 5)Create new client node 6)Connect to new client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 7)Check that table exists from server node: !tables *On this step there is no "city" table in the list.* 8)Try to drop the table: DROP TABLE City; java.sql.SQLException: Table doesn't exist: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) 9)Try to create new table: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; java.sql.SQLException: Table already exists: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) Update: Exceptions on CREATE/REMOVE are thrown only until first SELECT isn't done. !tables doen\t work even after SELECT SELECT works OK. was: For reproducing: You should start one local server and one local client nodes and follow the instructions: 1)Connect to client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 2)Create new table on client node: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; 3)Check that table exists from server node: !tables On this step table should be shown in the response. 4)Drop the client node 5)Create new client node 6)Connect to new client node: sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 7)Check that table exists from server node: !tables *On this step there is no "city" table in the list.* 8)Try to drop the table: DROP TABLE City; java.sql.SQLException: Table doesn't exist: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) 9)Try to create new table: CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH "template=replicated"; java.sql.SQLException: Table already exists: CITY at org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) at org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) 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) > Sqline creating tables on client nodes works incorrect in case of node's > shutdown > - > > Key: IGNITE-8060 > URL: https://issues.apache.org/jira/browse/IGNITE-8060 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >
[jira] [Comment Edited] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445793#comment-16445793
]
Alexey Kuznetsov edited comment on IGNITE-5714 at 4/20/18 2:24 PM:
---
[~agoncharuk] There are some scenarios, which need to be handled with thread
id. For instance:
1)look at the code:
{code:java}
cache.lock(key1).lock();
cache.put(key1, 1);// implicit transaction is started here
{code}
Implicit transaction will check whether key is locked explicitly by *current
thread*(thread ID is used here) , see GridNearTxLocal#updateExplicitVersion.
This allows transaction not to gain lock on tx entry, but reuse cache lock.
2) Thread ID is used by explicit transaction to check whether key is *locally*
locked(and throw exception) , see GridNearTxLocal#enlistWriteEntry.
3) Also, thread ID is used to mark candidate as reentry. etc.
was (Author: alexey kuznetsov):
[~agoncharuk] There are some scenarios, which need to be handled with thread
id. For instance:
1)look at the code:
{code:java}
cache.lock(key1).lock();
cache.put(key1, 1);
{code}
Implicit transaction will check whether key is locked explicitly by *current
thread*(thread ID is used here) , see GridNearTxLocal#updateExplicitVersion.
This allows transaction not to gain lock on tx entry, but reuse cache lock.
2) Thread ID is used by explicit transaction to check whether key is locally
locked(and throw exception) , see GridNearTxLocal#enlistWriteEntry.
3) Also, thread ID is used to mark candidate as reentry. etc.
> Implementation of suspend/resume for pessimistic transactions
> -
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> Support transaction suspend()\resume() operations for pessimistic
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in
> thread T1 and then perform put operation, which leads to sending
> GridDistributedLockRequest to another node. Lock request contains thread id
> of the transaction. Then we call suspend, resume in another thread and we
> also must send messages to other nodes to change thread id.
> It seems complicated task.It’s better to get rid of sending thread id to the
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near
> transaction GridDistributedLockRequest#threadId use its xid
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8346) FileDownloaderTest is not included in the test suite
[ https://issues.apache.org/jira/browse/IGNITE-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-8346: - Description: org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest is orphaned and the test code is commented, though the test is supposed to cover important functionality. (was: org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest ) > FileDownloaderTest is not included in the test suite > > > Key: IGNITE-8346 > URL: https://issues.apache.org/jira/browse/IGNITE-8346 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > > org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest > is orphaned and the test code is commented, though the test is supposed to > cover important functionality. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-5714) Implementation of suspend/resume for pessimistic transactions
[
https://issues.apache.org/jira/browse/IGNITE-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445793#comment-16445793
]
Alexey Kuznetsov commented on IGNITE-5714:
--
[~agoncharuk] There are some scenarios, which need to be handled with thread
id. For instance:
1)look at the code:
{code:java}
cache.lock(key1).lock();
cache.put(key1, 1);
{code}
Implicit transaction will check whether key is locked explicitly by *current
thread*(thread ID is used here) , see GridNearTxLocal#updateExplicitVersion.
This allows transaction not to gain lock on tx entry, but reuse cache lock.
2) Thread ID is used by explicit transaction to check whether key is locally
locked(and throw exception) , see GridNearTxLocal#enlistWriteEntry.
3) Also, thread ID is used to mark candidate as reentry. etc.
> Implementation of suspend/resume for pessimistic transactions
> -
>
> Key: IGNITE-5714
> URL: https://issues.apache.org/jira/browse/IGNITE-5714
> Project: Ignite
> Issue Type: Sub-task
> Components: general
>Reporter: Alexey Kuznetsov
>Assignee: Alexey Kuznetsov
>Priority: Major
> Fix For: 2.6
>
>
> Support transaction suspend()\resume() operations for pessimistic
> transactions. Resume can be called in another thread.
>_+But there is a problem+_: Imagine, we started pessimistic transaction in
> thread T1 and then perform put operation, which leads to sending
> GridDistributedLockRequest to another node. Lock request contains thread id
> of the transaction. Then we call suspend, resume in another thread and we
> also must send messages to other nodes to change thread id.
> It seems complicated task.It’s better to get rid of sending thread id to the
> nodes.
> We can use transaction xid on other nodes instead of thread id. Xid is sent
> to nodes in GridDistributedLockRequest#nearXidVer
>_+Proposed solution+_ : On remote nodes instead of thread id of near
> transaction GridDistributedLockRequest#threadId use its xid
> GridDistributedLockRequest#nearXidVer.
> Remove usages of near transaction's thread id on remote nodes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8345) Streamline tests' class names: mark Abstract and Load tests obviously so
[ https://issues.apache.org/jira/browse/IGNITE-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8345: Issue Type: Task (was: Bug) > Streamline tests' class names: mark Abstract and Load tests obviously so > > > Key: IGNITE-8345 > URL: https://issues.apache.org/jira/browse/IGNITE-8345 > Project: Ignite > Issue Type: Task >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > > To make support of our huge tests base easier, I propose we rename all > abstract tests to *AbstractTest (this is already done almost always). > Exceptions are tests whose inner classes are concrete tests. > Also, tests which are designed for stress-test and not included to regular > test suites should be called *LoadTest or *PerformanceTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8346) FileDownloaderTest is not included in the test suite
[ https://issues.apache.org/jira/browse/IGNITE-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8346: --- Fix Version/s: 2.6 > FileDownloaderTest is not included in the test suite > > > Key: IGNITE-8346 > URL: https://issues.apache.org/jira/browse/IGNITE-8346 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > > org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8205) Services are not redeployed when cluster is getting activated
[ https://issues.apache.org/jira/browse/IGNITE-8205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445774#comment-16445774 ] Andrey Gura commented on IGNITE-8205: - Thanks all! Merged to master branch. > Services are not redeployed when cluster is getting activated > - > > Key: IGNITE-8205 > URL: https://issues.apache.org/jira/browse/IGNITE-8205 > Project: Ignite > Issue Type: Bug > Components: managed services, persistence >Affects Versions: 2.4 >Reporter: Denis Mekhanikov >Assignee: Denis Mekhanikov >Priority: Major > Fix For: 2.6 > > Attachments: ServiceDeploymentOnActivationTest.java > > > Steps to reproduce: > # Start a node > # Activate the cluster > # Deploy a service > # Deactivate the cluster > # Activate the cluster > Service is getting cancelled after the step 4, but not coming back after the > step 5. > Test class with a reproducer is attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8346) FileDownloaderTest is not included in the test suite
[ https://issues.apache.org/jira/browse/IGNITE-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445781#comment-16445781 ] ASF GitHub Bot commented on IGNITE-8346: GitHub user DmitriyGovorukhin opened a pull request: https://github.com/apache/ignite/pull/3888 IGNITE-8346 Add FileDownloaderTest to PDS 2 suit … + small refactoring. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-8346 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3888.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 #3888 commit 80d5c4e51f013d0edac0c8a8f4506f762d6926b4 Author: Dmitriy Govorukhin Date: 2018-04-20T14:14:37Z IGNITE-8346 Add FileDownloaderTest to PDS 2 suit. Uncomment test body + small refactoring. > FileDownloaderTest is not included in the test suite > > > Key: IGNITE-8346 > URL: https://issues.apache.org/jira/browse/IGNITE-8346 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > > org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8347) Memory leaks on restart Ignite node with enabled persistence at ThreadLocal
Taras Ledkov created IGNITE-8347: Summary: Memory leaks on restart Ignite node with enabled persistence at ThreadLocal Key: IGNITE-8347 URL: https://issues.apache.org/jira/browse/IGNITE-8347 Project: Ignite Issue Type: Bug Components: persistence Affects Versions: 2.4 Reporter: Taras Ledkov Assignee: Dmitriy Pavlov Memory leaks on restart Ignite node with enabled persistence at ThreadLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8346) FileDownloaderTest is not included in the test suite
[ https://issues.apache.org/jira/browse/IGNITE-8346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin reassigned IGNITE-8346: -- Assignee: Dmitriy Govorukhin > FileDownloaderTest is not included in the test suite > > > Key: IGNITE-8346 > URL: https://issues.apache.org/jira/browse/IGNITE-8346 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Govorukhin >Assignee: Dmitriy Govorukhin >Priority: Major > Fix For: 2.6 > > > org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8346) FileDownloaderTest is not included in the test suite
Dmitriy Govorukhin created IGNITE-8346: -- Summary: FileDownloaderTest is not included in the test suite Key: IGNITE-8346 URL: https://issues.apache.org/jira/browse/IGNITE-8346 Project: Ignite Issue Type: Test Reporter: Dmitriy Govorukhin org.apache.ignite.internal.processors.cache.persistence.file.FileDownloaderTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering
[ https://issues.apache.org/jira/browse/IGNITE-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445767#comment-16445767 ] Dmitriy Govorukhin edited comment on IGNITE-7755 at 4/20/18 2:06 PM: - Duplicate of [IGNITE-7933]. was (Author: dmitriygovorukhin): Fixed in [IGNITE-7933]. Close. > Potentially crash during write cp-***-start.bin can lead to the impossibility > of recovering > --- > > Key: IGNITE-7755 > URL: https://issues.apache.org/jira/browse/IGNITE-7755 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.5 > > > We can crashed after cp-***-start.bin created but before content (wal point) > is recorded. On recovery after trying read wal point we got an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering
[ https://issues.apache.org/jira/browse/IGNITE-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin resolved IGNITE-7755. Resolution: Fixed Fix Version/s: (was: 2.6) 2.5 > Potentially crash during write cp-***-start.bin can lead to the impossibility > of recovering > --- > > Key: IGNITE-7755 > URL: https://issues.apache.org/jira/browse/IGNITE-7755 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.5 > > > We can crashed after cp-***-start.bin created but before content (wal point) > is recorded. On recovery after trying read wal point we got an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7755) Potentially crash during write cp-***-start.bin can lead to the impossibility of recovering
[ https://issues.apache.org/jira/browse/IGNITE-7755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445767#comment-16445767 ] Dmitriy Govorukhin commented on IGNITE-7755: Fixed in [IGNITE-7933]. Close. > Potentially crash during write cp-***-start.bin can lead to the impossibility > of recovering > --- > > Key: IGNITE-7755 > URL: https://issues.apache.org/jira/browse/IGNITE-7755 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.3, 2.4 >Reporter: Dmitriy Govorukhin >Priority: Critical > Fix For: 2.6 > > > We can crashed after cp-***-start.bin created but before content (wal point) > is recorded. On recovery after trying read wal point we got an exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445760#comment-16445760
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 2:01 PM:
building ignite from sources with instructions from DEVNOTES.txt
{noformat}
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean install
-Pall-java,all-scala,licenses -DskipTests
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn initialize -Prelease
{noformat}
results in `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` in `target/bin`
directory.
however, moving this file around to `packaging` and running
{noformat}
./package.sh --rpm
{noformat}
again leads to 404 error.
renaming archive `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` to
`apache-ignite-fabric-2.5.0-bin.zip` and running
{noformat}
./package.sh --rpm
{noformat}
leads to
{noformat}
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/BUILD'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/RPMS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SOURCES'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SPECS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.XVNElrwoAJ/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.lgqIhD
+ umask 022
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /usr/bin/unzip -qq
/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd apache-ignite-fabric-2.5.0-bin
/var/tmp/rpm-tmp.lgqIhD: 39: cd: can't cd to apache-ignite-fabric-2.5.0-bin
error: Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
Removing temporary work directories: /tmp/tmp.XVNElrwoAJ
=== Run time: 0h:00m:03s ===
{noformat}
was (Author: mshonichev):
building ignite from sources with
{noformat}
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean install
-Pall-java,all-scala,licenses -DskipTests
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn initialize -Prelease
{noformat}
results in `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` in `target/bin`
directory.
however, moving this file around to `packaging` and running
{noformat}
./package.sh --rpm
{noformat}
again leads to 404 error.
renaming archive `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` to
`apache-ignite-fabric-2.5.0-bin.zip` and running
{noformat}
./package.sh --rpm
{noformat}
leads to
{noformat}
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/BUILD'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/RPMS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SOURCES'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SPECS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.XVNElrwoAJ/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.lgqIhD
+ umask 022
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /usr/bin/unzip -qq
/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd apache-ignite-fabric-2.5.0-bin
/var/tmp/rpm-tmp.lgqIhD: 39: cd: can't cd to apache-ignite-fabric-2.5.0-bin
error: Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
Removing temporary work directories: /tmp/tmp.XVNElrwoAJ
=== Run time: 0h:00m:03s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445760#comment-16445760
]
Max Shonichev commented on IGNITE-7108:
---
building ignite from sources with
{noformat}
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn clean install
-Pall-java,all-scala,licenses -DskipTests
JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ mvn initialize -Prelease
{noformat}
results in `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` in `target/bin`
directory.
however, moving this file around to `packaging` and running
{noformat}
./package.sh --rpm
{noformat}
again leads to 404 error.
renaming archive `apache-ignite-fabric-2.5.0-SNAPSHOT-bin.zip` to
`apache-ignite-fabric-2.5.0-bin.zip` and running
{noformat}
./package.sh --rpm
{noformat}
leads to
{noformat}
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/BUILD'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/RPMS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SOURCES'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SPECS'
mkdir: created directory '/tmp/tmp.XVNElrwoAJ/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.XVNElrwoAJ/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.XVNElrwoAJ/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.lgqIhD
+ umask 022
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ cd /tmp/tmp.XVNElrwoAJ/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /usr/bin/unzip -qq
/tmp/tmp.XVNElrwoAJ/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
+ STATUS=0
+ [ 0 -ne 0 ]
+ cd apache-ignite-fabric-2.5.0-bin
/var/tmp/rpm-tmp.lgqIhD: 39: cd: can't cd to apache-ignite-fabric-2.5.0-bin
error: Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.lgqIhD (%prep)
Removing temporary work directories: /tmp/tmp.XVNElrwoAJ
=== Run time: 0h:00m:03s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7039) SQL: local query should pin affected partitions
[ https://issues.apache.org/jira/browse/IGNITE-7039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445756#comment-16445756 ] Dmitriy Pavlov commented on IGNITE-7039: [~vozerov] are there any news on this issue? There is no new messages since 2017 but issue is in PA state. > SQL: local query should pin affected partitions > --- > > Key: IGNITE-7039 > URL: https://issues.apache.org/jira/browse/IGNITE-7039 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vladimir Ozerov >Assignee: Roman Kondakov >Priority: Major > Fix For: 2.6 > > > When distributed query is executed, we pin cache partitions for particular > topology version on map nodes [1]. However, it seems that we do no do that > for local queries. This is a bug because partition with required data could > be evicted from local node at any time, leading to incorrect results. > [1] > https://github.com/apache/ignite/blob/ignite-2.3/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridMapQueryExecutor.java#L288 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7823) Separate cache for non collocated IgniteSet.
[
https://issues.apache.org/jira/browse/IGNITE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-7823:
-
Description:
Existing collocated version of {{IgniteSet}} datastructure is good enough for
small sets.
For big sets it's too expensive to maintain redundant onheap data copies. Thus
it would be better to use separate cache for non collocated {{IgniteSet}}
version. The difference between these two kinds of sets should be properly
documented afterwards.
was:Existing {{IgniteSet}} datastructure is good enough for small sets. For
big sets it's too expensive to maintain redundant onheap data copies. Thus we'd
better to add new {{IgniteCache::asSet}} method returning set adapter to
existing cache. The difference between these two kinds of sets should be
properly documented afterwards.
> Separate cache for non collocated IgniteSet.
>
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
> Issue Type: New Feature
> Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.6
>
>
> Existing collocated version of {{IgniteSet}} datastructure is good enough for
> small sets.
> For big sets it's too expensive to maintain redundant onheap data copies.
> Thus it would be better to use separate cache for non collocated
> {{IgniteSet}} version. The difference between these two kinds of sets should
> be properly documented afterwards.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8175) Missed CRC update in Lucene index.
[ https://issues.apache.org/jira/browse/IGNITE-8175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445758#comment-16445758 ] Dmitriy Pavlov commented on IGNITE-8175: Who could review this fix? > Missed CRC update in Lucene index. > -- > > Key: IGNITE-8175 > URL: https://issues.apache.org/jira/browse/IGNITE-8175 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.1, 2.2, 2.3, 2.4 >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.6 > > > We've missed CRC update in GridLuceneOutputStream.copyBytes() method. > See for [1] details. > [1] > [http://apache-ignite-developers.2346864.n4.nabble.com/Lucene-CorruptIndexException-checksum-failed-on-GridLuceneIndex-suggested-patch-tp29016.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7823) Separate cache for non collocated IgniteSet.
[
https://issues.apache.org/jira/browse/IGNITE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-7823:
-
Summary: Separate cache for non collocated IgniteSet. (was: Enrich
IgniteCache with asSet method)
> Separate cache for non collocated IgniteSet.
>
>
> Key: IGNITE-7823
> URL: https://issues.apache.org/jira/browse/IGNITE-7823
> Project: Ignite
> Issue Type: New Feature
> Components: data structures
>Reporter: Andrey Kuznetsov
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.6
>
>
> Existing {{IgniteSet}} datastructure is good enough for small sets. For big
> sets it's too expensive to maintain redundant onheap data copies. Thus we'd
> better to add new {{IgniteCache::asSet}} method returning set adapter to
> existing cache. The difference between these two kinds of sets should be
> properly documented afterwards.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445752#comment-16445752
]
Dmitriy Pavlov commented on IGNITE-7113:
Any news on this issue? It is PA since 2017, are there any plans to make it
resolved?
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Alexander Paschenko
>Priority: Major
> Fix For: 2.5
>
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7342) SQL TX: Fix checking whether currently updating row was updated after it pass query filter
[ https://issues.apache.org/jira/browse/IGNITE-7342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445751#comment-16445751 ] Dmitriy Pavlov commented on IGNITE-7342: Could we enrich decription? what was done? was it merged? > SQL TX: Fix checking whether currently updating row was updated after it pass > query filter > -- > > Key: IGNITE-7342 > URL: https://issues.apache.org/jira/browse/IGNITE-7342 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.6 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7615) Find orphaned tests without test suites, create separate test suite for them
[ https://issues.apache.org/jira/browse/IGNITE-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445749#comment-16445749 ] Ilya Kasnacheev commented on IGNITE-7615: - Decision was to try and integrate these tests into "regular" test suites. > Find orphaned tests without test suites, create separate test suite for them > > > Key: IGNITE-7615 > URL: https://issues.apache.org/jira/browse/IGNITE-7615 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.4 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > > It was noticed that some tests are written and updated, but not included in > any suite and therefore never run. > Also look for duplicate tests and other oddities. In the end, every > non-abstract test should be included in some suite. > This will be a first step towards either fixing those tests or discarding > them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-8345) Streamline tests' class names: mark Abstract and Load tests obviously so
Ilya Kasnacheev created IGNITE-8345: --- Summary: Streamline tests' class names: mark Abstract and Load tests obviously so Key: IGNITE-8345 URL: https://issues.apache.org/jira/browse/IGNITE-8345 Project: Ignite Issue Type: Bug Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev To make support of our huge tests base easier, I propose we rename all abstract tests to *AbstractTest (this is already done almost always). Exceptions are tests whose inner classes are concrete tests. Also, tests which are designed for stress-test and not included to regular test suites should be called *LoadTest or *PerformanceTest. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8344) Remove duplicate tests and suites
[ https://issues.apache.org/jira/browse/IGNITE-8344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-8344: Issue Type: Task (was: Bug) > Remove duplicate tests and suites > - > > Key: IGNITE-8344 > URL: https://issues.apache.org/jira/browse/IGNITE-8344 > Project: Ignite > Issue Type: Task > Components: general >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Minor > > There are several tests which present in the code base as two distinct files > with near-similar content. We should only keep one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8052) Clear error message needed when using a non-existing column name for CREATE TABLE primary key
[
https://issues.apache.org/jira/browse/IGNITE-8052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445743#comment-16445743
]
Dmitriy Pavlov commented on IGNITE-8052:
[~vozerov], could you please take a look?
> Clear error message needed when using a non-existing column name for CREATE
> TABLE primary key
> -
>
> Key: IGNITE-8052
> URL: https://issues.apache.org/jira/browse/IGNITE-8052
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Shtykh
>Assignee: Roman Shtykh
>Priority: Minor
> Labels: usability
> Fix For: 2.5
>
>
> On _CREATE TABLE_ with a misspelled column name for _PRIMARY KEY_ we have the
> following error with assertions enabled
> {code:java}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parseCreateTable(GridSqlQueryParser.java:1044)
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQueryParser.parse(GridSqlQueryParser.java:1647)
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:245)
> ...
> {code}
> and when disabled
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: null
> at
> org.apache.ignite.internal.processors.query.h2.ddl.DdlStatementsProcessor.runDdlStatement(DdlStatementsProcessor.java:492)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.doRunPrepared(IgniteH2Indexing.java:1643)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1577)
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8344) Remove duplicate tests and suites
Ilya Kasnacheev created IGNITE-8344: --- Summary: Remove duplicate tests and suites Key: IGNITE-8344 URL: https://issues.apache.org/jira/browse/IGNITE-8344 Project: Ignite Issue Type: Bug Components: general Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev There are several tests which present in the code base as two distinct files with near-similar content. We should only keep one. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
[ https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445740#comment-16445740 ] Dmitriy Pavlov commented on IGNITE-7077: [~vkulichenko], thank you for review. > Spark Data Frame Support. Strategy to convert complete query to Ignite SQL > -- > > Key: IGNITE-7077 > URL: https://issues.apache.org/jira/browse/IGNITE-7077 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: bigdata > Fix For: 2.5 > > > Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084. > We need to implement custom spark strategy that can convert whole Spark SQL > query to Ignite SQL Query if query consists of only Ignite tables. > The strategy does nothing if spark query includes not only Ignite tables. > Memsql implementation can be taken as an example - > https://github.com/memsql/memsql-spark-connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7077) Spark Data Frame Support. Strategy to convert complete query to Ignite SQL
[ https://issues.apache.org/jira/browse/IGNITE-7077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445738#comment-16445738 ] Dmitriy Pavlov commented on IGNITE-7077: [~NIzhikov] please set version 2.6 in JIRA, as it seems that change is not included into branch ignite-2.5. Alternatively cherry-pick commit to ignite-2.5 if [~agura] agree. > Spark Data Frame Support. Strategy to convert complete query to Ignite SQL > -- > > Key: IGNITE-7077 > URL: https://issues.apache.org/jira/browse/IGNITE-7077 > Project: Ignite > Issue Type: New Feature > Components: spark >Affects Versions: 2.3 >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: bigdata > Fix For: 2.5 > > > Basic support of Spark Data Frame for Ignite implemented in IGNITE-3084. > We need to implement custom spark strategy that can convert whole Spark SQL > query to Ignite SQL Query if query consists of only Ignite tables. > The strategy does nothing if spark query includes not only Ignite tables. > Memsql implementation can be taken as an example - > https://github.com/memsql/memsql-spark-connector -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445732#comment-16445732
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 1:37 PM:
running
{noformat}
./package.sh --rpm
{noformat}
leads to:
{noformat}
mkdir: created directory '/tmp/tmp.EHS5qfo623/BUILD'
mkdir: created directory '/tmp/tmp.EHS5qfo623/RPMS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SOURCES'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SPECS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.EHS5qfo623/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.EHS5qfo623/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.EHS5qfo623/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XkGvkv
+ umask 022
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /bin/tar -xf /tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
Removing temporary work directories: /tmp/tmp.EHS5qfo623
=== Run time: 0h:00m:00s ===
{noformat}
due to file apache-ignite-fabric-2.5.0-bin.zip created even in case of 404
error from site with following contents:
{noformat}
404 Not Found
Not Found
The requested URL /dist/ignite/2.5.0/apache-ignite-fabric-2.5.0-bin.zip was
not found on this server.
{noformat}
was (Author: mshonichev):
running
{noformat}
./package.sh --rpm
{noformat}
twice, leads to:
{noformat}
mkdir: created directory '/tmp/tmp.EHS5qfo623/BUILD'
mkdir: created directory '/tmp/tmp.EHS5qfo623/RPMS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SOURCES'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SPECS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.EHS5qfo623/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.EHS5qfo623/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.EHS5qfo623/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XkGvkv
+ umask 022
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /bin/tar -xf /tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
Removing temporary work directories: /tmp/tmp.EHS5qfo623
=== Run time: 0h:00m:00s ===
{noformat}
due to file apache-ignite-fabric-2.5.0-bin.zip created even in case of 404
error from site with following contents:
{noformat}
404 Not Found
Not Found
The requested URL /dist/ignite/2.5.0/apache-ignite-fabric-2.5.0-bin.zip was
not found on this server.
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445732#comment-16445732
]
Max Shonichev commented on IGNITE-7108:
---
running
{noformat}
./package.sh --rpm
{noformat}
twice, leads to:
{noformat}
mkdir: created directory '/tmp/tmp.EHS5qfo623/BUILD'
mkdir: created directory '/tmp/tmp.EHS5qfo623/RPMS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SOURCES'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SPECS'
mkdir: created directory '/tmp/tmp.EHS5qfo623/SRPMS'
'apache-ignite-fabric-2.5.0-bin.zip' ->
'/tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip'
'rpm/name.service' -> '/tmp/tmp.EHS5qfo623/SOURCES/name.service'
'rpm/service.sh' -> '/tmp/tmp.EHS5qfo623/SOURCES/service.sh'
'rpm/apache-ignite.spec' -> '/tmp/tmp.EHS5qfo623/SPECS/apache-ignite.spec'
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.XkGvkv
+ umask 022
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ cd /tmp/tmp.EHS5qfo623/BUILD
+ rm -rf apache-ignite-fabric-2.5.0-bin
+ /bin/tar -xf /tmp/tmp.EHS5qfo623/SOURCES/apache-ignite-fabric-2.5.0-bin.zip
/bin/tar: This does not look like a tar archive
/bin/tar: Exiting with failure status due to previous errors
error: Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.XkGvkv (%prep)
Removing temporary work directories: /tmp/tmp.EHS5qfo623
=== Run time: 0h:00m:00s ===
{noformat}
due to file apache-ignite-fabric-2.5.0-bin.zip created even in case of 404
error from site with following contents:
{noformat}
404 Not Found
Not Found
The requested URL /dist/ignite/2.5.0/apache-ignite-fabric-2.5.0-bin.zip was
not found on this server.
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8077) Implement new JMX metrics for transactions
[
https://issues.apache.org/jira/browse/IGNITE-8077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445715#comment-16445715
]
ASF GitHub Bot commented on IGNITE-8077:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3879
> Implement new JMX metrics for transactions
> --
>
> Key: IGNITE-8077
> URL: https://issues.apache.org/jira/browse/IGNITE-8077
> Project: Ignite
> Issue Type: New Feature
>Reporter: Dmitriy Govorukhin
>Assignee: Anton Kalashnikov
>Priority: Major
> Labels: iep-6
> Fix For: 2.5
>
>
> These additional metrics should be implemented to monitor transactions.
> {code}
> class TransactionsMXbean{
> /** The number of transactions which was commited. */
> long getTxCommited();
> /** The number of transactions which was rollbacked. */
> long getTxRolledBack();
> /** The number of transactions holding at least one key lock. */
> long getTxHoldingLock();
> /** The number of keys locked on the node. */
> long getLockedKeys();
> /** The number of transactions for which node is the initiator. */
> int getOwnerTxs();
> }
> {code}
> For more details see in IgniteTxAdapter and IgniteTxManager.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445685#comment-16445685
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 1:17 PM:
would you please add {noformat}-f (--force) {noformat} option to package.sh so
it would pass proper arguments to yum/apt it order to run unattented.
was (Author: mshonichev):
would you please add {noformat}-f (--force) {noformat} option to package.sh so
it could be run unattented, meaning that it should pass proper arguments to
yum/apt.
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445685#comment-16445685
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 1:03 PM:
would you please add {noformat}-f (--force) {noformat} option to package.sh so
it could be run unattented, meaning that it should pass proper arguments to
yum/apt.
was (Author: mshonichev):
would you please add -f (--force) option to package.sh so it could be run
unattented.
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[ https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445685#comment-16445685 ] Max Shonichev commented on IGNITE-7108: --- would you please add -f (--force) option to package.sh so it could be run unattented. > Apache Ignite 2.5 RPM and DEB packages > -- > > Key: IGNITE-7108 > URL: https://issues.apache.org/jira/browse/IGNITE-7108 > Project: Ignite > Issue Type: New Feature > Components: binary >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > Labels: important > Fix For: 2.5 > > > # (/) Update RPM build process to unify with DEB build. > # (/) Prepare build of DEB package (using architecture and layout from RPM > package). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7910) Improve transaction debugging support
[ https://issues.apache.org/jira/browse/IGNITE-7910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445681#comment-16445681 ] ASF GitHub Bot commented on IGNITE-7910: GitHub user ascherbakoff opened a pull request: https://github.com/apache/ignite/pull/3886 IGNITE-7910 Improve transaction debugging support You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-7910 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/3886.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 #3886 commit 99a05f50be24a6dbebe6e9a3cd57513a1dbeb4fb Author: Aleksei Scherbakov Date: 2017-12-06T11:26:44Z IGNITE-6827 wip. commit 1e7ee0f0fd10e21b36cc57e1499358dd46c616b7 Author: Aleksei Scherbakov Date: 2017-12-06T14:34:25Z IGNITE-6827 wip. commit 0b0c0ff5f736b6cb299bf8ee32d6705d3c2adfb2 Author: Aleksei Scherbakov Date: 2017-12-06T14:47:13Z IGNITE-6827 wip. commit 2e7e7a2eca9b45ca1488403d86c28df055d215a7 Author: Aleksei Scherbakov Date: 2017-12-06T15:01:37Z IGNITE-6827 wip. commit 50dbdb8f14751f470f605884f195256531f4176f Author: Aleksei Scherbakov Date: 2017-12-06T15:04:40Z IGNITE-6827 wip. commit 4da15f51af7302dc70fa5ee705042dec36cb120b Author: Aleksei Scherbakov Date: 2017-12-06T16:46:22Z IGNITE-6827 wip. commit bc024837e12627a011c8a1b43f30783bb3b08f2d Author: Aleksei Scherbakov Date: 2017-12-06T17:11:04Z IGNITE-6827 wip. commit 8f5693361b018ee78ca7b6fd9a9e4d88017a87ea Author: ascherbakoff Date: 2017-12-06T21:05:42Z IGNITE-6827 wip. commit c4b9fab158769fb21e7dbbb641746868698a6652 Author: Aleksei Scherbakov Date: 2017-12-07T11:23:25Z IGNITE-6827 wip. commit f0a6113798df0e20e2d3b4a5573a5c722a2fd948 Author: Aleksei Scherbakov Date: 2017-12-07T11:27:16Z IGNITE-6827 wip. commit 5d9d22c7cb27c39516d0340ab72fa0a4f56e004b Author: Aleksei Scherbakov Date: 2017-12-07T11:46:21Z IGNITE-6827 wip. commit a008c220923d95155285b3408945f6e2c94104e5 Author: Aleksei Scherbakov Date: 2017-12-07T13:47:40Z IGNITE-6827 wip. commit f0ba7bd90ab16f0933353901fd73586e998443ba Author: Aleksei Scherbakov Date: 2017-12-07T14:05:14Z IGNITE-6827 wip. commit 7c6542553f041339f712bbde1541aa54c9418ed9 Author: Aleksei Scherbakov Date: 2017-12-07T17:10:24Z IGNITE-6827 wip. commit 91545f3bc98fc6c58d42d87fc0edd70abcb398d6 Author: Aleksei Scherbakov Date: 2017-12-07T17:21:46Z IGNITE-6827 wip. commit 663889d8c242c2681524cd11878838fb8b2f11ab Author: Aleksei Scherbakov Date: 2017-12-08T10:28:49Z IGNITE-6827 wip. commit 7da5e9582a995c39d0fa9cc6aa7e42d44eaf2d3f Author: Aleksei Scherbakov Date: 2017-12-08T16:22:23Z IGNITE-6827 wip. commit 65023a5b4983b871e0a8522e1493c285ab75b07d Author: Aleksei Scherbakov Date: 2017-12-08T16:28:21Z IGNITE-6827 wip. commit 5951ff5e2a72293577392aea84582f8831c37163 Author: Aleksei Scherbakov Date: 2017-12-08T16:52:50Z IGNITE-6827 wip. commit 35aeeb2bf0f671569979e1782832a1371c479791 Author: Aleksei Scherbakov Date: 2017-12-08T17:19:12Z IGNITE-6827 wip. commit fb9779e12ecaa27a1a00a2eac97747f2e7175c32 Author: ascherbakoff Date: 2017-12-09T13:31:29Z IGNITE-6827 wip. commit 327eb805aad6f2608e6af8032a9a5e7c67c47c20 Author: ascherbakoff Date: 2017-12-09T13:32:03Z IGNITE-6827 wip. commit 00f9b695d46886c89087b0061701a42429abb05e Author: ascherbakoff Date: 2017-12-09T14:06:07Z IGNITE-6827 wip. commit 5cd8fa0a34c34529cde58f859a6fd82955c3d57c Author: ascherbakoff Date: 2017-12-09T14:29:38Z IGNITE-6827 wip. commit 27f38f24992e2eb2d1418e503a3cd39b581dd2e0 Author: ascherbakoff Date: 2017-12-09T14:54:04Z IGNITE-6827 wip. commit 9d47569d4a28125fefb4781c70855ca14a2c1c6c Author: ascherbakoff Date: 2017-12-09T15:09:04Z IGNITE-6827 wip. commit 50a545a01cb1d7a3c015196dd4384d77010fdee3 Author: ascherbakoff Date: 2017-12-09T15:25:07Z IGNITE-6827 wip. commit 0b90e453bd6036528ccf6723340220dc4acde4be Author: ascherbakoff Date: 2017-12-10T13:16:31Z IGNITE-6827 wip. commit b1e0900110c4b4d815f238289c0bb0777591d953 Author: ascherbakoff Date: 2017-12-10T16:30:12Z IGNITE-6827 wip. commit 3fdfb2698acf526b5db8e5697ec263d8da219145 Author: ascherbakoff Date: 2017-12-10T16:39:47Z IGNITE-6827 wip. > Improve transaction debugging support > - > > Key: IGNITE-7910 > URL: https://issues.apache.org/jira/browse/IGNITE-7910 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Alexei Scherbakov >Priority: Major > Fix For: 2.6 > >
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445672#comment-16445672
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 12:48 PM:
-
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
fails with
{noformat}
[ERROR] Can't find | get Apache Ignite's binary archive
Removing temporary work directories:
=== Run time: 0h:00m:48s ===
{noformat}
would be nice to dump what exactly binary archive we could not find
was (Author: mshonichev):
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
fails with
{noformat}
[ERROR] Can't find | get Apache Ignite's binary archive
Removing temporary work directories:
=== Run time: 0h:00m:48s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445672#comment-16445672
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 12:47 PM:
-
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
fails with
{noformat}
[ERROR] Can't find | get Apache Ignite's binary archive
Removing temporary work directories:
=== Run time: 0h:00m:48s ===
{noformat}
was (Author: mshonichev):
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445672#comment-16445672
]
Max Shonichev edited comment on IGNITE-7108 at 4/20/18 12:43 PM:
-
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# apt-get update
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
was (Author: mshonichev):
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
leads to
{noformat}
[INFO] Software installation required root privileges
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package unzip
E: Unable to locate package curl
E: Unable to locate package alien
E: Unable to locate package gcc
E: Unable to locate package rpm
Removing temporary work directories:
=== Run time: 0h:00m:00s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7108) Apache Ignite 2.5 RPM and DEB packages
[
https://issues.apache.org/jira/browse/IGNITE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445672#comment-16445672
]
Max Shonichev commented on IGNITE-7108:
---
{noformat}
# docker run -it -v $(readlink -f incubator-ignite):/mnt ubuntu bash
# cd /mnt/packaging
# ./package.sh --rpm
{noformat}
leads to
{noformat}
[INFO] Software installation required root privileges
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package unzip
E: Unable to locate package curl
E: Unable to locate package alien
E: Unable to locate package gcc
E: Unable to locate package rpm
Removing temporary work directories:
=== Run time: 0h:00m:00s ===
{noformat}
> Apache Ignite 2.5 RPM and DEB packages
> --
>
> Key: IGNITE-7108
> URL: https://issues.apache.org/jira/browse/IGNITE-7108
> Project: Ignite
> Issue Type: New Feature
> Components: binary
>Reporter: Peter Ivanov
>Assignee: Peter Ivanov
>Priority: Critical
> Labels: important
> Fix For: 2.5
>
>
> # (/) Update RPM build process to unify with DEB build.
> # (/) Prepare build of DEB package (using architecture and layout from RPM
> package).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-8343) InetSocketAddress.getAddress() returns null, should check it in TcpCommunicationSpi
Ilya Kasnacheev created IGNITE-8343:
---
Summary: InetSocketAddress.getAddress() returns null, should check
it in TcpCommunicationSpi
Key: IGNITE-8343
URL: https://issues.apache.org/jira/browse/IGNITE-8343
Project: Ignite
Issue Type: Bug
Components: general
Reporter: Ilya Kasnacheev
This is especially notorious in the following scenario:
{code}
// -Djava.net.preferIPv4Stack=true
System.err.println(new InetSocketAddress("0:0:0:0:0:0:0:1%lo",
12345).getAddress()); // null
{code}
Yes we already warn if different nodes have differing preferIPv4Stack, still
this is warning not a error, and there may be other cases where getAddress()
returns null. Should make a check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8149) MVCC TX Size method should use tx snapshot
[ https://issues.apache.org/jira/browse/IGNITE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Kalashnikov reassigned IGNITE-8149: -- Assignee: Sergey Kalashnikov > MVCC TX Size method should use tx snapshot > -- > > Key: IGNITE-8149 > URL: https://issues.apache.org/jira/browse/IGNITE-8149 > Project: Ignite > Issue Type: Task > Components: cache >Reporter: Igor Seliverstov >Assignee: Sergey Kalashnikov >Priority: Major > > Currently cache.size() returns number of entries in cache trees while there > can be several versions of one key-value pairs. > We should use tx snapshot and count all passed mvcc filter entries instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8258) Ignite PDS 1 suite, test probably failed suite IgnitePdsPageReplacementTest.testPageReplacement (last started)
[
https://issues.apache.org/jira/browse/IGNITE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445666#comment-16445666
]
ASF GitHub Bot commented on IGNITE-8258:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3821
> Ignite PDS 1 suite, test probably failed suite
> IgnitePdsPageReplacementTest.testPageReplacement (last started)
> --
>
> Key: IGNITE-8258
> URL: https://issues.apache.org/jira/browse/IGNITE-8258
> Project: Ignite
> Issue Type: Test
>Reporter: Dmitriy Pavlov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.5
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1199095&buildTypeId=IgniteTests24Java8_IgnitePds1&tab=buildLog
> {noformat}
> [2018-04-13
> 03:06:28,479][ERROR][db-checkpoint-thread-#52662%file.IgnitePdsPageReplacementTest0%][IgniteTestResources]
> Critical failure. Will be handled accordingly to configured handler
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteCheckedException: Compound
> exception for CountDownFuture.]]
> class org.apache.ignite.IgniteCheckedException: Compound exception for
> CountDownFuture.
> at
> org.apache.ignite.internal.util.future.CountDownFuture.addError(CountDownFuture.java:72)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:46)
> at
> org.apache.ignite.internal.util.future.CountDownFuture.onDone(CountDownFuture.java:28)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:462)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3545)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Suppressed: java.lang.IllegalMonitorStateException: Attempted to
> release write lock while not holding it [lock=7f360ad0d630,
> state=0001
> at
> org.apache.ignite.internal.util.OffheapReadWriteLock.writeUnlock(OffheapReadWriteLock.java:266)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.copyPageForCheckpoint(PageMemoryImpl.java:1185)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.getForCheckpoint(PageMemoryImpl.java:1117)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$WriteCheckpointPages.run(GridCacheDatabaseSharedManager.java:3508)
> ... 3 more
> [2018-04-13
> 03:06:28,483][ERROR][db-checkpoint-thread-#52662%file.IgnitePdsPageReplacementTest0%][IgniteTestResources]
> Critical failure. Will be handled accordingly to configured handler
> [hnd=class o.a.i.failure.NoOpFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=class o.a.i.IgniteException: Failed to
> begin checkpoint (it is already in progress).]]
> class org.apache.ignite.IgniteException: Failed to begin checkpoint (it is
> already in progress).
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.beginCheckpoint(PageMemoryImpl.java:997)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.beginAllCheckpoints(GridCacheDatabaseSharedManager.java:3309)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.markCheckpointBegin(GridCacheDatabaseSharedManager.java:3183)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.doCheckpoint(GridCacheDatabaseSharedManager.java:2909)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.body(GridCacheDatabaseSharedManager.java:2808)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> [2018-04-13
> 03:06:28,485][ERROR][db-checkpoint-thread-#52662%file.IgnitePdsPageReplacementTest0%][GridCacheDatabaseSharedManager]
> Runtime error caught during grid runnable execution: GridWorker
> [name=db-checkpoint-thread,
> igniteInstanceName=file.IgnitePdsPageReplacementTest0, finished=false,
> hashCode=564969718, interrupted=false,
> runner=db-checkpoint-thread-#52662%file.IgnitePdsPageRep
[jira] [Commented] (IGNITE-8219) B+Tree operation may result in an infinite loop in some case
[ https://issues.apache.org/jira/browse/IGNITE-8219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445664#comment-16445664 ] Dmitriy Pavlov commented on IGNITE-8219: Are there Run-All run? It is easier to check if there is new test failures. [~astelmak] could you share link? > B+Tree operation may result in an infinite loop in some case > - > > Key: IGNITE-8219 > URL: https://issues.apache.org/jira/browse/IGNITE-8219 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexey Stelmak >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.5 > > > B+Tree operation may result in an infinite loop in case. Test > DynamicIndexServerCoordinatorBasicSelfTest#testCreateIndexWithInlineSizePartitionedAtomic > region size = 512Mb, KEY_BEFORE=1, KEY_AFTER=2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8286) ScanQuery ignore setLocal with non local partition
[ https://issues.apache.org/jira/browse/IGNITE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445648#comment-16445648 ] Dmitriy Pavlov commented on IGNITE-8286: [~vozerov] could you please take a look? > ScanQuery ignore setLocal with non local partition > -- > > Key: IGNITE-8286 > URL: https://issues.apache.org/jira/browse/IGNITE-8286 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Alexander Belyak >Assignee: Roman Shtykh >Priority: Major > > 1) Create partitioned cache on 2+ nodes cluster > 2) Select some partition N, local node should not be OWNER of partition N > 3) execute: cache.query(new ScanQuery<>().setLocal(true).setPartition(N)) > Expected result: > empty result (probaply with logging smth like "Trying to execute local query > with non local partition N") or even throw exception > Actual result: > executing (with ScanQueryFallbackClosableIterator) query on remote node. > Problem is that we execute local query on remote node. > Same behaviour can be achieved if we get empty node list from > GridCacheQueryAdapter.node() by any reasons, for example - if we run "local" > query from non data node from given cache (see > GridDiscoveryNamager.cacheAffinityNode(ClusterNode node, String cacheName) in > GridcacheQueryAdapter.executeScanQuery() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8060) Sqline creating tables on client nodes works incorrect in case of node's shutdown
[ https://issues.apache.org/jira/browse/IGNITE-8060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8060: Fix Version/s: 2.5 > Sqline creating tables on client nodes works incorrect in case of node's > shutdown > - > > Key: IGNITE-8060 > URL: https://issues.apache.org/jira/browse/IGNITE-8060 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Priority: Major > Fix For: 2.5 > > Attachments: ignite-76cc6387.log, ignite-a1c90af9.log > > > For reproducing: > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 2)Create new table on client node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Drop the client node > 5)Create new client node > 6)Connect to new client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 7)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > 8)Try to drop the table: > DROP TABLE City; > java.sql.SQLException: Table doesn't exist: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > 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) > 9)Try to create new table: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > java.sql.SQLException: Table already exists: CITY > at > org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:671) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:130) > at > org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:299) > 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) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution
[
https://issues.apache.org/jira/browse/IGNITE-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16445645#comment-16445645
]
Pavel Kuznetsov commented on IGNITE-8342:
-
reproduced on b810bd44805
> Semi colon in CREATE INDEX causes infinite loop execution
> -
>
> Key: IGNITE-8342
> URL: https://issues.apache.org/jira/browse/IGNITE-8342
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Given created table in cache
> {noformat}
> cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
> (age);")).getAll();
> {noformat}
> seems to cause infinite loop
> jstack :
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
> [0x7fa1b1932000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
> at
> org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
> at
> org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
> {noformat}
> without semicolon sign (";") in the end of the query, it performs well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution
[
https://issues.apache.org/jira/browse/IGNITE-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8342:
Fix Version/s: 2.5
> Semi colon in CREATE INDEX causes infinite loop execution
> -
>
> Key: IGNITE-8342
> URL: https://issues.apache.org/jira/browse/IGNITE-8342
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.5
>
>
> Given created table in cache
> {noformat}
> cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
> (age);")).getAll();
> {noformat}
> seems to cause infinite loop
> jstack :
> {noformat}
> "main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
> [0x7fa1b1932000]
>java.lang.Thread.State: RUNNABLE
> at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
> at
> org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
> at
> org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
> at
> org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
> at
> org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
> {noformat}
> without semicolon sign (";") in the end of the query, it performs well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8340) .NET: Implement new JMX metrics for transactions
[ https://issues.apache.org/jira/browse/IGNITE-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8340: --- Description: Need to support new metrics on .NET side. New metrics and interface see in [IGNITE-8077] (was: Need support new metrics on .NET side. New metrics and interface see in [IGNITE-8077]) > .NET: Implement new JMX metrics for transactions > > > Key: IGNITE-8340 > URL: https://issues.apache.org/jira/browse/IGNITE-8340 > Project: Ignite > Issue Type: New Feature >Reporter: Dmitriy Govorukhin >Priority: Major > > Need to support new metrics on .NET side. New metrics and interface see in > [IGNITE-8077] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8055) Sqline command !tables works incorrect for client node
[ https://issues.apache.org/jira/browse/IGNITE-8055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8055: Fix Version/s: 2.5 > Sqline command !tables works incorrect for client node > -- > > Key: IGNITE-8055 > URL: https://issues.apache.org/jira/browse/IGNITE-8055 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.4 >Reporter: Andrey Aleksandrov >Priority: Minor > Fix For: 2.5 > > > For reproducing: > You should start one local server and one local client nodes and follow the > instructions: > 1)Connect to server node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10800 > 2)Create new table on server node: > CREATE TABLE City (id LONG PRIMARY KEY, name VARCHAR)WITH > "template=replicated"; > 3)Check that table exists from server node: > !tables > On this step table should be shown in the response. > 4)Connect to client node: > sqlline.bat --color=true --verbose=true -u jdbc:ignite:thin://127.0.0.1:10801 > 5)Check that table exists from server node: > !tables > *On this step there is no "city" table in the list.* > Next commands work from client node as well: > SELECT * FROM City > DROP TABLE City > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8341) .NET: Add new metrics for data storage
[ https://issues.apache.org/jira/browse/IGNITE-8341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8341: --- Description: Need support new metrics on .NET side. New metrics and interface see in [IGNITE-8078] > .NET: Add new metrics for data storage > -- > > Key: IGNITE-8341 > URL: https://issues.apache.org/jira/browse/IGNITE-8341 > Project: Ignite > Issue Type: New Feature >Reporter: Dmitriy Govorukhin >Priority: Major > > Need support new metrics on .NET side. New metrics and interface see in > [IGNITE-8078] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8340) .NET: Implement new JMX metrics for transactions
[ https://issues.apache.org/jira/browse/IGNITE-8340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-8340: --- Summary: .NET: Implement new JMX metrics for transactions (was: .NET Implement new JMX metrics for transactions) > .NET: Implement new JMX metrics for transactions > > > Key: IGNITE-8340 > URL: https://issues.apache.org/jira/browse/IGNITE-8340 > Project: Ignite > Issue Type: New Feature >Reporter: Dmitriy Govorukhin >Priority: Major > > Need support new metrics on .NET side. New metrics and interface see in > [IGNITE-8077] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8342) Semi colon in CREATE INDEX causes infinite loop execution
[
https://issues.apache.org/jira/browse/IGNITE-8342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Kuznetsov updated IGNITE-8342:
Description:
Given created table in cache
{noformat}
cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
(age);")).getAll();
{noformat}
seems to cause infinite loop
jstack :
{noformat}
"main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
[0x7fa1b1932000]
java.lang.Thread.State: RUNNABLE
at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
at
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
at
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
at
org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
at
org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
at
org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
at
org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
{noformat}
without semicolon sign (";") in the end of the query, it performs well.
was:
Given created table in cache
{noformat}
cache.query(new SqlFieldsQuery("CREATE INDEX AgeIndex ON Employee
(age);")).getAll();
{noformat}
seems to cause infinite loop
jstack :
{noformat}
"main" #1 prio=5 os_prio=0 tid=0x7fa1a800d000 nid=0x4b7c runnable
[0x7fa1b1932000]
java.lang.Thread.State: RUNNABLE
at org.apache.ignite.internal.sql.SqlLexer.lookAhead(SqlLexer.java:73)
at
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parseIndexProperties(SqlCreateIndexCommand.java:250)
at
org.apache.ignite.internal.sql.command.SqlCreateIndexCommand.parse(SqlCreateIndexCommand.java:172)
at
org.apache.ignite.internal.sql.SqlParser.processCreate(SqlParser.java:207)
at
org.apache.ignite.internal.sql.SqlParser.nextCommand0(SqlParser.java:106)
at
org.apache.ignite.internal.sql.SqlParser.nextCommand(SqlParser.java:76)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.tryQueryDistributedSqlFieldsNative(IgniteH2Indexing.java:1509)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1599)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:664)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:615)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:356)
at
org.apache.ignite.sqltests.BaseSqlTest.fillCommonData(BaseSqlTest.java:107)
{noformat}
> Semi colon in CREATE INDEX causes infinite loop execution
> -
>
> Key: IGNITE-8342
> URL: https://issues.apache.org/jira/browse/IGNITE-8342
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>
