[jira] [Commented] (IGNITE-6019) SQL: client node should not hold the whole data set in-memory when possible
[
https://issues.apache.org/jira/browse/IGNITE-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128408#comment-16128408
]
ASF GitHub Bot commented on IGNITE-6019:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2430
> SQL: client node should not hold the whole data set in-memory when possible
> ---
>
> Key: IGNITE-6019
> URL: https://issues.apache.org/jira/browse/IGNITE-6019
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Alexander Paschenko
>Priority: Critical
> Labels: performance
> Fix For: 2.2
>
>
> Our SQL engine requests request data from server nodes in pieces called
> "page". This allows us to control memory consumption on client side. However,
> currently our client code is designed in a way that all pages are requested
> from all servers before a single cursor row is returned to the user. It
> defeats the whole idea of "cursor" and "page", and could easily crash client
> node with OOME.
> We need to fix that and request further pages in a kind of sliding window,
> keeping no more than "N" pages in memory simultaneously. Note that sometimes
> it is not possible, e.g. in case of {{DISTINCT}} or non-collocated {{GROUP
> BY}}. In this case we would have to build the whole result set first anyway.
> So let's focus on a scenario when the whole result set is not needed.
> As currently everything is requested synchronously page-by-page, in the first
> version it would be enough to distribute synchronous page requests between
> cursor reads, without any prefetch.
> Implementation details:
> 1) Optimization should be applied only to {{skipMergeTbl=true}} cases, when
> complete result set of map queries is not needed.
> 2) Starting point is {{GridReduceQueryExecutor#query}}, see
> {{skipMergeTbl=true}} branch - this is where we get all pages eagerly.
> 3) Get no more than one page from the server at a time. We request the page,
> iterate over it, then request another page.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6072) SQL: client node should not hold the whole data set in-memory when possible when merge table is there
Vladimir Ozerov created IGNITE-6072: --- Summary: SQL: client node should not hold the whole data set in-memory when possible when merge table is there Key: IGNITE-6072 URL: https://issues.apache.org/jira/browse/IGNITE-6072 Project: Ignite Issue Type: Task Components: sql Affects Versions: 2.1 Reporter: Vladimir Ozerov Assignee: Alexander Paschenko Fix For: 2.2 We implemented a fix for a case without merge table (IGNITE-6019). Let's try to do the same for merge table case. Essentially, we need to split all queries into two groups: - Blocking - i.e. it require the whole result set from mappers first - Non-blocking - everything what is not blocking :-) Fix should be applied only to non-blocking case. Raw estimation from my side, what is "blocking": 1) GROUP BY/HAVING 2) DISTINCT 3) LIMIT/OFFSET 4) Subqueries -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6053) IgniteCache.clear clears local caches with same names on all server nodes
[ https://issues.apache.org/jira/browse/IGNITE-6053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128297#comment-16128297 ] Roman Shtykh commented on IGNITE-6053: -- TC looks ok (no related failures found). > IgniteCache.clear clears local caches with same names on all server nodes > - > > Key: IGNITE-6053 > URL: https://issues.apache.org/jira/browse/IGNITE-6053 > Project: Ignite > Issue Type: Bug >Affects Versions: 1.7 >Reporter: Evgenii Zhuravlev >Assignee: Roman Shtykh > Fix For: 2.2 > > > Clear on LOCAL cache should clear cache on the current node only, not on all > nodes, that have local caches with same names. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5620) Meaningful error codes and types of exceptions for SQL operations
[
https://issues.apache.org/jira/browse/IGNITE-5620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128111#comment-16128111
]
Denis Magda commented on IGNITE-5620:
-
Consider inputs from this more generic discussion:
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-not-friendly-for-Monitoring-td20802.html
> Meaningful error codes and types of exceptions for SQL operations
> --
>
> Key: IGNITE-5620
> URL: https://issues.apache.org/jira/browse/IGNITE-5620
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.0
>Reporter: Denis Magda
>Assignee: Alexander Paschenko
> Fix For: 2.2
>
>
> Presently, SQL engine throws a generic type of exception with custom text in
> case of an operation failure. In result, Ignite ODBC driver returns a similar
> error code (2000) for different kind of failures.
> For example, error code 2000 is returned for the following
> {code}
> Duplicate key during INSERT [key=CorpcontactcountKey [idHash=1412656257,
> hash=2004096461, mdn=9192]]
> {code}
> {code}
> Failed to parse query: INSERT INTO "DG".Corpcontactcount
> (mdn,contactcount,lastupdatetime)
> values(?,?,?,?)
> {code}
> {code}
> Wrong value has been set [typeName=Pocsubscrinfo, fieldName=vocoderid,
> fieldType=short, assignedValueType=byte] Error Code: 2000
> {code}
> The following has to be done:
> * Create unique types of exceptions for Java whenever applicable.
> * Add {{errorCode}} parameter and method to a generic SQL exception.
> * ODBC and JDBC drivers have to return unique codes based on the exception
> code or type.
> * All the codes have to be documented on readme.io.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6069: Description: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. Once the feature is implemented, it has to be documented extensively. was: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. Once the feature is implemented and has to be documented extensively. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6069: Description: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. Once the feature is implemented, it has to be documented extensively. The ticket must not be closed until this happens. was: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. Once the feature is implemented, it has to be documented extensively. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented, it has to be documented extensively. The > ticket must not be closed until this happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6069: Description: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. Once the feature is implemented and has to be documented extensively. was: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. > Once the feature is implemented and has to be documented extensively. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda updated IGNITE-6064: Description: Current behavior control.sh is not clear. 1. control.sh is a confusing name, need more suitable name. 2. Print help description if incorrect command was entered 3. Do not print stacktrace if connection fail, add more conveniently message. 4. Print information about connection, like "Connecting to [ip-address]:[port] etc." 5. Document the usage on a special page. Ping Denis Magda when it's time to do that. was: Current behavior control.sh is not clear. 1. control.sh is a confusing name, need more suitable name. 2. Print help description if incorrect command was entered 3. Do not print stacktrace if connection fail, add more conveniently message. 4. Print information about connection, like "Connecting to [ip-address]:[port] etc." > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." > 5. Document the usage on a special page. Ping Denis Magda when it's time to > do that. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6037) Ignite 2.1 features changes on the website
[ https://issues.apache.org/jira/browse/IGNITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127953#comment-16127953 ] Denis Magda commented on IGNITE-6037: - The content for the memory-centric page is ready: https://docs.google.com/document/d/1AgQL9iL40o0PE_mrhQehY55qUMfKbBxJTgJQCF6Sp4A/edit [~pgarg], please create a new page and put a link to it naming "What is Memory-Centric?" under "What is Ignite?" in the "Features" menu. Fill the page out with the content from the Google Doc. > Ignite 2.1 features changes on the website > -- > > Key: IGNITE-6037 > URL: https://issues.apache.org/jira/browse/IGNITE-6037 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Denis Magda > Labels: site > > Make the following changes to Features: > # add What is Memory Centric > # change Persistence to either "Native Persistence" or "Persistent Store" > # change More to black font and rename to "More..." > # add Beta symbol to Machine Learning -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6037) Ignite 2.1 features changes on the website
[ https://issues.apache.org/jira/browse/IGNITE-6037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Magda reassigned IGNITE-6037: --- Assignee: Prachi Garg (was: Denis Magda) > Ignite 2.1 features changes on the website > -- > > Key: IGNITE-6037 > URL: https://issues.apache.org/jira/browse/IGNITE-6037 > Project: Ignite > Issue Type: Bug > Components: website >Reporter: Dmitriy Setrakyan >Assignee: Prachi Garg > Labels: site > > Make the following changes to Features: > # add What is Memory Centric > # change Persistence to either "Native Persistence" or "Persistent Store" > # change More to black font and rename to "More..." > # add Beta symbol to Machine Learning -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5790) Xml config can not be used in jdbs and user code simultaneously
[ https://issues.apache.org/jira/browse/IGNITE-5790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127530#comment-16127530 ] Ilya Kasnacheev commented on IGNITE-5790: - I'm afraid we can't use solution 1). We can mind the lifecycle of Ignite we've got or started, but JDBC driver can't make sure Ignite that was already existing, and now shared, isn't closed while still being needed by JDBC. 2) should probably be implemented, with appended UUID as in loadConfiguration() method but in more generic way. > Xml config can not be used in jdbs and user code simultaneously > --- > > Key: IGNITE-5790 > URL: https://issues.apache.org/jira/browse/IGNITE-5790 > Project: Ignite > Issue Type: Bug > Components: jdbc >Affects Versions: 2.1 >Reporter: Mikhail Cherkasov >Assignee: Mikhail Cherkasov > Fix For: 2.2 > > > when user uses the same xml config for jdbc driver and for his own ignite > instance there can be : > java.sql.SQLException: Failed to start Ignite node. > Caused by: class org.apache.ignite.IgniteCheckedException: Ignite instance > with this name has already been started: CustomeIgniteName > because JDBC creates separate ignite instance, while user already has one > with the same name. > Of course that can be easily workarounded, user can support two configs or > create jdbc connect first and then use Ignition.getOrStart(). > However it's inconvenient for user and should be treated as usability issue. > I see 2 solutions: > 1) jdbc driver should use Ignition.getOrStart() > 2) jdbc driver should connection string as ignite name. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6071) Client may detect necessity for reconnect for too long
Yakov Zhdanov created IGNITE-6071:
-
Summary: Client may detect necessity for reconnect for too long
Key: IGNITE-6071
URL: https://issues.apache.org/jira/browse/IGNITE-6071
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Yakov Zhdanov
There was a GC pause on client that caused servers to drop client due to
inability to establish TCP communication connection. Then it took some time for
client to detect that it has been dropped. During that time client many times
attempted to connect to server which can be seen in the logs. After client
detected its drop and reconnected servers fired node added event and no log
flood can be found any more.
We need to find out why client was reconnecting via communication and did not
detect the drop for such a long time.
I hope this can be reproduced in test:
* start 2 servers
* start client
* suspend all client threads with Thread.suspend() - just filter threads of
current JVM by name and suspend ones belonging to the client.
{noformat}
[10:12:24,785][WARNING][disco-event-worker-#71%null%][GridDiscoveryManager]
Node FAILED: TcpDiscoveryNode [id=dd71479c-41ba-443e-b25c-3803a2a94f4f,
addrs=[10.44.3.14, 127.0.0.1], sockAddrs=[/127.0.0.1:0, XXX.com/10.44.3.14:0],
discPort=0, order=2, intOrder=2, lastExchangeTime=1502269008673, loc=false,
ver=2.1.1#20170618-sha1:09ce29e0, isClient=true]
[10:12:24,785][INFO][disco-event-worker-#71%null%][GridDiscoveryManager]
Topology snapshot [ver=5, servers=2, clients=1, CPUs=144, heap=76.0GB]
[10:12:24,794][INFO][exchange-worker-#72%null%][time] Started exchange init
[topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false, evt=12,
node=TcpDiscoveryNode [id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d,
addrs=[10.44.3.11, 127.0.0.1], sockAddrs=[/127.0.0.1:47500,
XXX.com/10.44.3.11:47500], discPort=47500, order=3, intOrder=3,
lastExchangeTime=1502269944782, loc=true, ver=2.1.1#20170618-sha1:09ce29e0,
isClient=false], evtNode=TcpDiscoveryNode
[id=98c1fdf7-09db-4fa0-bb01-8ca7f046643d, addrs=[10.44.3.11, 127.0.0.1],
sockAddrs=[/127.0.0.1:47500, XXX.com/10.44.3.11:47500], discPort=47500,
order=3, intOrder=3, lastExchangeTime=1502269944782, loc=true,
ver=2.1.1#20170618-sha1:09ce29e0, isClient=false], customEvt=null]
[10:12:24,813][INFO][exchange-worker-#72%null%][time] Finished exchange init
[topVer=AffinityTopologyVersion [topVer=5, minorTopVer=0], crd=false]
[10:12:24,819][INFO][exchange-worker-#72%null%][GridCachePartitionExchangeManager]
Skipping rebalancing (nothing scheduled) [top=AffinityTopologyVersion
[topVer=5, minorTopVer=0], evt=NODE_FAILED,
node=dd71479c-41ba-443e-b25c-3803a2a94f4f]
[10:12:28,344][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52474]
[10:12:28,348][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52482]
[10:12:28,356][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52506]
[10:12:28,362][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52522]
[10:12:28,368][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52538]
[10:12:28,374][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52554]
[10:12:28,380][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52570]
[10:12:28,386][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52586]
[10:12:28,392][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52602]
[10:12:28,397][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52618]
[10:12:28,402][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52634]
[10:12:28,407][INFO][grid-nio-worker-tcp-comm-1-#58%null%][TcpCommunicationSpi]
Accepted incoming communication connection [locAddr=/10.44.3.11:47100,
rmtAddr=/10.44.3.14:52650]
[10:12:28,412][INFO][grid-nio-worker-tcp-comm-0-#57%null%][TcpCommun
[jira] [Assigned] (IGNITE-6068) We try to add entry to partition which was concurrently evicted
[
https://issues.apache.org/jira/browse/IGNITE-6068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk reassigned IGNITE-6068:
Assignee: Alexey Goncharuk
> We try to add entry to partition which was concurrently evicted
> ---
>
> Key: IGNITE-6068
> URL: https://issues.apache.org/jira/browse/IGNITE-6068
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Eduard Shangareev
>Assignee: Alexey Goncharuk
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> https://ci.ignite.apache.org/viewLog.html?buildId=768819&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteQueries2
> {code}
> rg.apache.ignite.internal.processors.query.schema.SchemaOperationException:
> Schema change operation failed: Adding entry to partition that is
> concurrently evicted [part=817, shouldBeMoving=false, belongs=false,
> topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
> curTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0]]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processIndexOperationLocal(GridQueryProcessor.java:1290)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> Caused by:
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException:
> Adding entry to partition that is concurrently evicted [part=817,
> shouldBeMoving=false, belongs=false, topVer=AffinityTopologyVersion
> [topVer=4, minorTopVer=0], curTopVer=AffinityTopologyVersion [topVer=4,
> minorTopVer=0]]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:752)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:644)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:933)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:524)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:924)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:141)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:120)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.visit(SchemaIndexCacheVisitorImpl.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dynamicIndexCreate(IgniteH2Indexing.java:684)
> at
> org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest$BlockingIndexing.dynamicIndexCreate(DynamicIndexAbstractConcurrentSelfTest.java:1065)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.processIndexOperationLocal(GridQueryProcessor.java:1276)
> at
> org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6070:
Attachment: webtest.zip
Maven project to reproduce the issue
> Infinite redirects at Spring Security Web Session Clustering with Tomcat
>
>
> Key: IGNITE-6070
> URL: https://issues.apache.org/jira/browse/IGNITE-6070
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 2.1
> Environment: Spring Security, Apache Tomcat
>Reporter: Ilya Kasnacheev
>Priority: Minor
> Labels: easyfix, newbie
> Attachments: IGNITE-6070.patch, webtest.zip
>
>
> See
> https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
> description.
> When Session comes from Ignite but its Authentication is anonymous, Spring
> Security does the following check:
> {code}
> } else if (request.getRequestedSessionId() != null &&
> !request.isRequestedSessionIdValid()) {
> this.logger.debug("Requested session ID " +
> request.getRequestedSessionId() + " is invalid.");
>
> this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
> }
> {code}
> The problem is, in Ignite we never override isRequestedSessionIdValid() in
> our request wrappers, so it falls back to Tomcat's own (session) Manager,
> which will then find that it has never seen this Session and it is therefore
> invalid. Thus failover is triggered, and if there's "invalid-session-url"
> clause in Spring Security config, redirect will be issued, possibly circular.
> I've attaching a sample Maven WAR project. It should be deployed to two
> different Tomcat instances operating on two different ports of same machine,
> e.g. 8080 and 8180, and then
> http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the
> same Web Browser one after another for two ports. The second one should cause
> infinite 302 Redirect to same URL.
> There's also a minor bug in the same code: see session.jsp in the example. It
> will needlessly throw NPE in WebSessionFilter:1001 and confuse web server.
> Should output "OK" when fixed.
> Discussion:
> By the way, letting the web server to get hold on Sessions that it creates
> for us causes additional problems: it's going to store these sessions in
> parallel with Ignite, consuming memory in the process that first saw a given
> session. We should probably have (possibly a third party) an Ignite-using
> Manager implementation for Tomcat specifically. It will be much simpler than
> filter-based approach while performing better.
> Or maybe we should create our own Sessions that we never allow the web server
> to see.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat
[
https://issues.apache.org/jira/browse/IGNITE-6070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-6070:
Attachment: IGNITE-6070.patch
Suggested fix
> Infinite redirects at Spring Security Web Session Clustering with Tomcat
>
>
> Key: IGNITE-6070
> URL: https://issues.apache.org/jira/browse/IGNITE-6070
> Project: Ignite
> Issue Type: Bug
> Components: websession
>Affects Versions: 2.1
> Environment: Spring Security, Apache Tomcat
>Reporter: Ilya Kasnacheev
>Priority: Minor
> Labels: easyfix, newbie
> Attachments: IGNITE-6070.patch, webtest.zip
>
>
> See
> https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
> description.
> When Session comes from Ignite but its Authentication is anonymous, Spring
> Security does the following check:
> {code}
> } else if (request.getRequestedSessionId() != null &&
> !request.isRequestedSessionIdValid()) {
> this.logger.debug("Requested session ID " +
> request.getRequestedSessionId() + " is invalid.");
>
> this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
> }
> {code}
> The problem is, in Ignite we never override isRequestedSessionIdValid() in
> our request wrappers, so it falls back to Tomcat's own (session) Manager,
> which will then find that it has never seen this Session and it is therefore
> invalid. Thus failover is triggered, and if there's "invalid-session-url"
> clause in Spring Security config, redirect will be issued, possibly circular.
> I've attaching a sample Maven WAR project. It should be deployed to two
> different Tomcat instances operating on two different ports of same machine,
> e.g. 8080 and 8180, and then
> http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the
> same Web Browser one after another for two ports. The second one should cause
> infinite 302 Redirect to same URL.
> There's also a minor bug in the same code: see session.jsp in the example. It
> will needlessly throw NPE in WebSessionFilter:1001 and confuse web server.
> Should output "OK" when fixed.
> Discussion:
> By the way, letting the web server to get hold on Sessions that it creates
> for us causes additional problems: it's going to store these sessions in
> parallel with Ignite, consuming memory in the process that first saw a given
> session. We should probably have (possibly a third party) an Ignite-using
> Manager implementation for Tomcat specifically. It will be much simpler than
> filter-based approach while performing better.
> Or maybe we should create our own Sessions that we never allow the web server
> to see.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5732) Provide API to test compatibility with old releases
[
https://issues.apache.org/jira/browse/IGNITE-5732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127445#comment-16127445
]
Vyacheslav Daradur commented on IGNITE-5732:
Waiting for review within IGNITE-5736.
> Provide API to test compatibility with old releases
> ---
>
> Key: IGNITE-5732
> URL: https://issues.apache.org/jira/browse/IGNITE-5732
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.1
>Reporter: Vyacheslav Daradur
>Assignee: Vyacheslav Daradur
> Fix For: 2.2
>
>
> Need to provide an opportunity to test compatibility with old releases.
> The main idea is the method {code}startGrid(ver){code} in the testing
> framework, which would start an instance via downloaded "jar" from the Maven
> repo.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6070) Infinite redirects at Spring Security Web Session Clustering with Tomcat
Ilya Kasnacheev created IGNITE-6070:
---
Summary: Infinite redirects at Spring Security Web Session
Clustering with Tomcat
Key: IGNITE-6070
URL: https://issues.apache.org/jira/browse/IGNITE-6070
Project: Ignite
Issue Type: Bug
Components: websession
Affects Versions: 2.1
Environment: Spring Security, Apache Tomcat
Reporter: Ilya Kasnacheev
Priority: Minor
See
https://stackoverflow.com/questions/45648884/apache-ignite-spring-secutiry-error
description.
When Session comes from Ignite but its Authentication is anonymous, Spring
Security does the following check:
{code}
} else if (request.getRequestedSessionId() != null &&
!request.isRequestedSessionIdValid()) {
this.logger.debug("Requested session ID " +
request.getRequestedSessionId() + " is invalid.");
this.invalidSessionStrategy.onInvalidSessionDetected(request, response);
}
{code}
The problem is, in Ignite we never override isRequestedSessionIdValid() in our
request wrappers, so it falls back to Tomcat's own (session) Manager, which
will then find that it has never seen this Session and it is therefore invalid.
Thus failover is triggered, and if there's "invalid-session-url" clause in
Spring Security config, redirect will be issued, possibly circular.
I've attaching a sample Maven WAR project. It should be deployed to two
different Tomcat instances operating on two different ports of same machine,
e.g. 8080 and 8180, and then
http://localhost:PORT/webtest-1.0-SNAPSHOT/index.jsp should be opened in the
same Web Browser one after another for two ports. The second one should cause
infinite 302 Redirect to same URL.
There's also a minor bug in the same code: see session.jsp in the example. It
will needlessly throw NPE in WebSessionFilter:1001 and confuse web server.
Should output "OK" when fixed.
Discussion:
By the way, letting the web server to get hold on Sessions that it creates for
us causes additional problems: it's going to store these sessions in parallel
with Ignite, consuming memory in the process that first saw a given session. We
should probably have (possibly a third party) an Ignite-using Manager
implementation for Tomcat specifically. It will be much simpler than
filter-based approach while performing better.
Or maybe we should create our own Sessions that we never allow the web server
to see.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5736) Add test of backward-compatibility
[ https://issues.apache.org/jira/browse/IGNITE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127411#comment-16127411 ] Vyacheslav Daradur commented on IGNITE-5736: [Ci.tests|https://ci.ignite.apache.org/viewLog.html?buildId=767976] looks good to me, except CPP-platform. The PR doesn't contain CPP-changes. > Add test of backward-compatibility > -- > > Key: IGNITE-5736 > URL: https://issues.apache.org/jira/browse/IGNITE-5736 > Project: Ignite > Issue Type: Sub-task > Components: general >Reporter: Vyacheslav Daradur >Assignee: Vyacheslav Daradur > Fix For: 2.2 > > > Need to add unit-test to test compatibility with AI 2.0. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join
[ https://issues.apache.org/jira/browse/IGNITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127388#comment-16127388 ] Eduard Shangareev commented on IGNITE-5943: --- Thank you for feedback. Comments were implemented. Ready to review! Please, take a look. > Communication. Server node may reject client connection during massive > clients join > --- > > Key: IGNITE-5943 > URL: https://issues.apache.org/jira/browse/IGNITE-5943 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Eduard Shangareev >Assignee: Yakov Zhdanov >Priority: Critical > Fix For: 2.2 > > > There is a race between a client join discovery event on server nodes and the > moment when a client starts to establish outgoing communication connections. > It would cause to rejecting communication connections on server nodes (for > example. on requesting data from caches). > The issue happens on really big topologies (> 300 nodes) or when many clients > join simultaneously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver
[
https://issues.apache.org/jira/browse/IGNITE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127345#comment-16127345
]
Taras Ledkov commented on IGNITE-4642:
--
[Tests
results|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&tab=projectOverview&branch_Ignite20Tests=pull%2F2446%2Fhead]
are OK.
The {{enforceJoinOrder}} is added for {{jdbc2.JdbcConnection}}
> Support enforceJoinOrder flag for JDBC driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's
> not exposed on JDBC driver.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh updated IGNITE-6069: - Description: Make services upgradable -again-. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. was: Make services upgradable again. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable -again-. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5943) Communication. Server node may reject client connection during massive clients join
[ https://issues.apache.org/jira/browse/IGNITE-5943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127333#comment-16127333 ] Alexey Goncharuk commented on IGNITE-5943: -- A few comments: 1) Should not we close the channel on client side (for safety) when we receive NEED_WAIT? 2) The test is not added to any suite > Communication. Server node may reject client connection during massive > clients join > --- > > Key: IGNITE-5943 > URL: https://issues.apache.org/jira/browse/IGNITE-5943 > Project: Ignite > Issue Type: Bug > Components: general >Affects Versions: 2.0 >Reporter: Eduard Shangareev >Assignee: Yakov Zhdanov >Priority: Critical > Fix For: 2.2 > > > There is a race between a client join discovery event on server nodes and the > moment when a client starts to establish outgoing communication connections. > It would cause to rejecting communication connections on server nodes (for > example. on requesting data from caches). > The issue happens on really big topologies (> 300 nodes) or when many clients > join simultaneously. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh updated IGNITE-6069: - Description: Make services upgradable again. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version ( ?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. was: Make services upgradable again. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version (?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable again. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version ( ?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6069) Service versioning
[ https://issues.apache.org/jira/browse/IGNITE-6069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Lantukh updated IGNITE-6069: - Description: Make services upgradable again. Main points: - compute binary type ID by (classname + version) - use serialVersionUuid as version (?) - all service instances with the same name must have the same version - make ServiceProxy aware of versions and upgrade process, pause requests while service is being upgraded - extend Service interface (UpgradableService?) - add ability to collect state of previous version before start. > Service versioning > -- > > Key: IGNITE-6069 > URL: https://issues.apache.org/jira/browse/IGNITE-6069 > Project: Ignite > Issue Type: New Feature > Components: general >Affects Versions: 2.1 >Reporter: Ilya Lantukh >Assignee: Ilya Lantukh > > Make services upgradable again. > Main points: > - compute binary type ID by (classname + version) > - use serialVersionUuid as version (?) > - all service instances with the same name must have the same version > - make ServiceProxy aware of versions and upgrade process, pause requests > while service is being upgraded > - extend Service interface (UpgradableService?) - add ability to collect > state of previous version before start. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6069) Service versioning
Ilya Lantukh created IGNITE-6069: Summary: Service versioning Key: IGNITE-6069 URL: https://issues.apache.org/jira/browse/IGNITE-6069 Project: Ignite Issue Type: New Feature Components: general Affects Versions: 2.1 Reporter: Ilya Lantukh Assignee: Ilya Lantukh -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
[
https://issues.apache.org/jira/browse/IGNITE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127267#comment-16127267
]
ASF GitHub Bot commented on IGNITE-6032:
Github user isapego closed the pull request at:
https://github.com/apache/ignite/pull/2431
> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
>
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQL_SCROLL_OPTIONS}}. Need to add
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null
[
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127249#comment-16127249
]
Alexander Menshikov commented on IGNITE-5994:
-
[~shia] I can't. You need to ask for permission in dev-list first.
> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
> Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but
> the IgniteInternalCache.invokeAsync().get() can return the null in case when
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127197#comment-16127197
]
Max Shonichev edited comment on IGNITE-6064 at 8/15/17 1:52 PM:
current output for both successful activation:
{noformat}
10.116.206.1:11214 - was activate
{noformat}
and unsuccessful activation:
{noformat}
Something fail during activation, exception message: Failed to perform request
(connection failed): /10.116.215.130:11214
{noformat}
proposed:
for 'activate' command, we have following cases :
1. grid was not active and was activated by 'activate' command
2. grid was already active and 'activate' command left it active
3. grid was not active and activation failed due to error
for 1 and 2 we should return 0 exit code from script and print following
messages:
"successfully activated"
"was already active"
for 3 we should return != 0 exit code and print following message:
"activation failed due to error: ..."
for 'deactivate' command, we have following cases :
4. grid was not active and 'deactivate' command left it inactive
5. grid was active and was deactivated
6. grid was active but some exception happens upon deactivation
for 4 and 5 we should return 0 exit code from script and print following
messages:
"was already inactive"
"successfully deactivated"
for 6 we should return != 0 exit code and print following message:
"deactivation failed due to error: ..."
as of prefix before message, the current CLUSTER_IP:PORT looks good to me
was (Author: mshonichev):
current output for both successful activation:
{noformat}
10.116.206.1:11214 - was activate
{noformat}
and unsuccessful activation:
{noformat}
Something fail during activation, exception message: Failed to perform request
(connection failed): /10.116.215.130:11214
{noformat}
proposed:
for 'activate' command, we have following cases :
1. grid was not active and was activated by 'activate' command
2. grid was already active and 'activate' command left it active
3. grid was not active and activation failed due to error
for 1 and 2 we should return 0 exit code from script and print following
messages:
"successfully activated"
"was already active"
for 3 we should return != 0 exit code and print following message:
"activation failed due to error: ..."
for 'deactivate' command, we have following cases :
4. grid was not active and 'deactivate' command left it inactive
5. grid was active and was deactivated
6. grid was active but some exception happens upon deactivation
for 4 and 5 we should return 0 exit code from script and print following
messages:
"was already inactive"
"successfully deactivated"
for 6 we should return != 0 exit code and print following message:
"deactivation failed due to error: ..."
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null
[
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127249#comment-16127249
]
Alexander Menshikov edited comment on IGNITE-5994 at 8/15/17 1:52 PM:
--
[~shia] I can't. You need to ask for account permission in dev-list first.
was (Author: sharpler):
[~shia] I can't. You need to ask for permission in dev-list first.
> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
> Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but
> the IgniteInternalCache.invokeAsync().get() can return the null in case when
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Max Shonichev updated IGNITE-6064: -- Comment: was deleted (was: and I would add to the list: 5. document script exit codes for success/failure and return them correspondingly) > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127197#comment-16127197
]
Max Shonichev edited comment on IGNITE-6064 at 8/15/17 1:51 PM:
current output for both successful activation:
{noformat}
10.116.206.1:11214 - was activate
{noformat}
and unsuccessful activation:
{noformat}
Something fail during activation, exception message: Failed to perform request
(connection failed): /10.116.215.130:11214
{noformat}
proposed:
for 'activate' command, we have following cases :
1. grid was not active and was activated by 'activate' command
2. grid was already active and 'activate' command left it active
3. grid was not active and activation failed due to error
for 1 and 2 we should return 0 exit code from script and print following
messages:
"successfully activated"
"was already active"
for 3 we should return != 0 exit code and print following message:
"activation failed due to error: ..."
for 'deactivate' command, we have following cases :
4. grid was not active and 'deactivate' command left it inactive
5. grid was active and was deactivated
6. grid was active but some exception happens upon deactivation
for 4 and 5 we should return 0 exit code from script and print following
messages:
"was already inactive"
"successfully deactivated"
for 6 we should return != 0 exit code and print following message:
"deactivation failed due to error: ..."
was (Author: mshonichev):
current output for both successful activation:
{noformat}
10.116.206.1:11214 - was activate
{noformat}
and unsuccessful activation:
{noformat}
Something fail during activation, exception message: Failed to perform request
(connection failed): /10.116.215.130:11214
{noformat}
really lacks proper english.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
[
https://issues.apache.org/jira/browse/IGNITE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127210#comment-16127210
]
Sergey Kalashnikov commented on IGNITE-6032:
[~isapego], Looks good to me.
> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
>
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQL_SCROLL_OPTIONS}}. Need to add
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127201#comment-16127201 ] Max Shonichev commented on IGNITE-6064: --- and I would add to the list: 5. document script exit codes for success/failure and return them correspondingly > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127197#comment-16127197
]
Max Shonichev commented on IGNITE-6064:
---
current output for both successful activation:
{noformat}
10.116.206.1:11214 - was activate
{noformat}
and unsuccessful activation:
{noformat}
Something fail during activation, exception message: Failed to perform request
(connection failed): /10.116.215.130:11214
{noformat}
really lacks proper english.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6032) ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
[
https://issues.apache.org/jira/browse/IGNITE-6032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127195#comment-16127195
]
Igor Sapego commented on IGNITE-6032:
-
[~skalashnikov], fixed. Can you check it out?
> ODBC: SQL_SCROLL_OPTIONS is not supported for SQLGetInfo
>
>
> Key: IGNITE-6032
> URL: https://issues.apache.org/jira/browse/IGNITE-6032
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
> Fix For: 2.2
>
>
> Currently {{SQLGetInfo}} does not support {{SQL_SCROLL_OPTIONS}}. Need to add
> support.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5991) SQL: lazy ResultSet for map query
[
https://issues.apache.org/jira/browse/IGNITE-5991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127178#comment-16127178
]
Vladimir Ozerov commented on IGNITE-5991:
-
Added tests. Waiting for TC.
> SQL: lazy ResultSet for map query
> -
>
> Key: IGNITE-5991
> URL: https://issues.apache.org/jira/browse/IGNITE-5991
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Critical
> Labels: performance
> Fix For: 2.2
>
>
> Currently we move the whole {{ResultSet}} to memory when executing SQL query
> on mapper. If result set is large enough, this could easily bring server down
> due to high GC pressure or even OOME.
> To avoid that we should stream H2's {{ResultSet}} to our own consumer, which
> will construct a page and send it to the client When a page is sent,
> consumer will block current thread until "next page request" is received.
> This approach has disadvantage - query thread will be blocked. However,
> implementation should be fairly easy and will allow us to avoid OOMEs on
> server. In future we will improve it to minimize blocking (or even avoid it
> completely).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6035) Indexes aren't cleaned on cache clear/destroy
[
https://issues.apache.org/jira/browse/IGNITE-6035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eduard Shangareev updated IGNITE-6035:
--
Fix Version/s: 2.2
> Indexes aren't cleaned on cache clear/destroy
> -
>
> Key: IGNITE-6035
> URL: https://issues.apache.org/jira/browse/IGNITE-6035
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> Curently on cache clear or destroy cache in a group, where other caches exist
> (this operation executes cache clear internally) the query indexes (if
> present) aren't cleaned/destroyed.
> {{IgniteCacheOffheapManagerImpl.CacheDataStoreImpl#clear}} has to call
> finishUpdate(...)
> This leads issues on next insertions or updates (on attempt to teplace an
> alreadyu deleted item)
> {{org/apache/ignite/internal/processors/cache/persistence/tree/BPlusTree.java:370}}:
> {noformat}Caused by: java.lang.AssertionError: itemId=0, directCnt=0,
> page=000100010005 [][][free=970]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.getDataOffset(DataPageIO.java:437)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.DataPageIO.readPayload(DataPageIO.java:488)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:149)
> at
> org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:101)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:62)
> at
> org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:124)
> at
> org.apache.ignite.internal.processors.query.h2.database.io.H2ExtrasLeafIO.getLookupRow(H2ExtrasLeafIO.java:36)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:123)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:40)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.getRow(BPlusTree.java:4372)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:370)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Replace.run0(BPlusTree.java:330)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4697)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4682)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.writePage(PageHandler.java:342)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.write(DataStructure.java:261)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$11200(BPlusTree.java:81)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Put.tryReplace(BPlusTree.java:2875)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2279)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2006)
> ... 28 more{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6050) Eternal wait in DataStreamerTest.TestBufferSize()
[ https://issues.apache.org/jira/browse/IGNITE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127161#comment-16127161 ] ASF GitHub Bot commented on IGNITE-6050: GitHub user gvvinblade opened a pull request: https://github.com/apache/ignite/pull/2448 IGNITE-6050 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6050 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2448.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 #2448 commit 0726b593de316a284e899c4b0b7702e8fc286182 Author: Igor Seliverstov Date: 2017-08-15T12:36:20Z IGNITE-6050 Eternal wait in DataStreamerTest.TestBufferSize() > Eternal wait in DataStreamerTest.TestBufferSize() > - > > Key: IGNITE-6050 > URL: https://issues.apache.org/jira/browse/IGNITE-6050 > Project: Ignite > Issue Type: Test > Components: platforms >Affects Versions: 2.1 >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov > Labels: MakeTeamcityGreenAgain > > There are several places where Future.Wait() is used without timeout. This > leads tests failures on timeout and makes difficult to determine the cause of > the issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6050) Eternal wait in DataStreamerTest.TestBufferSize()
[ https://issues.apache.org/jira/browse/IGNITE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov updated IGNITE-6050: - Labels: MakeTeamcityGreenAgain (was: ) > Eternal wait in DataStreamerTest.TestBufferSize() > - > > Key: IGNITE-6050 > URL: https://issues.apache.org/jira/browse/IGNITE-6050 > Project: Ignite > Issue Type: Test > Components: platforms >Affects Versions: 2.1 >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov > Labels: MakeTeamcityGreenAgain > > There are several places where Future.Wait() is used without timeout. This > leads tests failures on timeout and makes difficult to determine the cause of > the issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6067) Refactor cache configuration initialization with proper defaults
[ https://issues.apache.org/jira/browse/IGNITE-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127160#comment-16127160 ] ASF GitHub Bot commented on IGNITE-6067: Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/2445 > Refactor cache configuration initialization with proper defaults > > > Key: IGNITE-6067 > URL: https://issues.apache.org/jira/browse/IGNITE-6067 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Dudkov >Assignee: Konstantin Dudkov > Fix For: 2.2 > > > Move cache configuration initialization from GridCacheProcessor#initialize to > GridCacheUtils -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-6050) Eternal wait in DataStreamerTest.TestBufferSize()
[ https://issues.apache.org/jira/browse/IGNITE-6050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-6050: Assignee: Igor Seliverstov > Eternal wait in DataStreamerTest.TestBufferSize() > - > > Key: IGNITE-6050 > URL: https://issues.apache.org/jira/browse/IGNITE-6050 > Project: Ignite > Issue Type: Test > Components: platforms >Affects Versions: 2.1 >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov > > There are several places where Future.Wait() is used without timeout. This > leads tests failures on timeout and makes difficult to determine the cause of > the issue -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6068) We try to add entry to partition which was concurrently evicted
Eduard Shangareev created IGNITE-6068:
-
Summary: We try to add entry to partition which was concurrently
evicted
Key: IGNITE-6068
URL: https://issues.apache.org/jira/browse/IGNITE-6068
Project: Ignite
Issue Type: Bug
Affects Versions: 2.1
Reporter: Eduard Shangareev
Fix For: 2.2
https://ci.ignite.apache.org/viewLog.html?buildId=768819&tab=buildResultsDiv&buildTypeId=Ignite20Tests_IgniteQueries2
{code}
rg.apache.ignite.internal.processors.query.schema.SchemaOperationException:
Schema change operation failed: Adding entry to partition that is concurrently
evicted [part=817, shouldBeMoving=false, belongs=false,
topVer=AffinityTopologyVersion [topVer=4, minorTopVer=0],
curTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0]]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.processIndexOperationLocal(GridQueryProcessor.java:1290)
at
org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
Caused by:
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtInvalidPartitionException:
Adding entry to partition that is concurrently evicted [part=817,
shouldBeMoving=false, belongs=false, topVer=AffinityTopologyVersion [topVer=4,
minorTopVer=0], curTopVer=AffinityTopologyVersion [topVer=4, minorTopVer=0]]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition0(GridDhtPartitionTopologyImpl.java:752)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtPartitionTopologyImpl.localPartition(GridDhtPartitionTopologyImpl.java:644)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.localPartition(GridCachePartitionedConcurrentMap.java:69)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCachePartitionedConcurrentMap.putEntryIfObsoleteOrAbsent(GridCachePartitionedConcurrentMap.java:88)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:933)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.entryEx(GridDhtCacheAdapter.java:524)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.entryEx(GridCacheAdapter.java:924)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processKey(SchemaIndexCacheVisitorImpl.java:141)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.processPartition(SchemaIndexCacheVisitorImpl.java:120)
at
org.apache.ignite.internal.processors.query.schema.SchemaIndexCacheVisitorImpl.visit(SchemaIndexCacheVisitorImpl.java:90)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.dynamicIndexCreate(IgniteH2Indexing.java:684)
at
org.apache.ignite.internal.processors.cache.index.DynamicIndexAbstractConcurrentSelfTest$BlockingIndexing.dynamicIndexCreate(DynamicIndexAbstractConcurrentSelfTest.java:1065)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.processIndexOperationLocal(GridQueryProcessor.java:1276)
at
org.apache.ignite.internal.processors.query.schema.SchemaOperationWorker.body(SchemaOperationWorker.java:108)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6051) Improve future listeners model in DataStreamerImpl
[
https://issues.apache.org/jira/browse/IGNITE-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127157#comment-16127157
]
ASF GitHub Bot commented on IGNITE-6051:
GitHub user gvvinblade opened a pull request:
https://github.com/apache/ignite/pull/2447
IGNITE-6051
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6051
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2447.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 #2447
commit df15e070b3634c25eb57f65facd6ad49f327bce1
Author: Igor Seliverstov
Date: 2017-08-14T11:53:12Z
IGNITE-6051 Improve future listeners model in DataStreamerImpl
commit 445dfab79c3de2013b5efd661232f70ad9730ac8
Author: Igor Seliverstov
Date: 2017-08-15T12:27:31Z
IGNITE-6051 Improve future listeners model in DataStreamerImpl
> Improve future listeners model in DataStreamerImpl
> --
>
> Key: IGNITE-6051
> URL: https://issues.apache.org/jira/browse/IGNITE-6051
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>
> Improve future listeners model on update not to add the same listener to a
> future more than once ({{DataStreamerImpl.java:1410}})
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver
[
https://issues.apache.org/jira/browse/IGNITE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127153#comment-16127153
]
ASF GitHub Bot commented on IGNITE-4642:
GitHub user tledkov-gridgain opened a pull request:
https://github.com/apache/ignite/pull/2446
IGNITE-4642 Support enforceJoinOrder flag for JDBC driver
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-4642
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2446.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 #2446
commit 4ceb63fc78d2729e6758f0c2863e2df0d44570e7
Author: tledkov-gridgain
Date: 2017-08-15T12:16:25Z
IGNITE-4642 Support enforceJoinOrder flag for JDBC driver
> Support enforceJoinOrder flag for JDBC driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's
> not exposed on JDBC driver.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6061) Increase default index inline size
[ https://issues.apache.org/jira/browse/IGNITE-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127152#comment-16127152 ] Taras Ledkov commented on IGNITE-6061: -- Minor comments: Inline header for var-bytes types is: 1 byte - value type / null. 2 bytes - length > Increase default index inline size > -- > > Key: IGNITE-6061 > URL: https://issues.apache.org/jira/browse/IGNITE-6061 > Project: Ignite > Issue Type: Task > Components: persistence, sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov > Labels: performance > Fix For: 2.2 > > > Currently default value of maximum inline size is set to 10 bytes. Looks like > this is too small for string keys (1 byte overhead, 4 bytes length, 5 bytes > for chars - am I right?). I would propose to increase it to greater value, > say, 32. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support
[ https://issues.apache.org/jira/browse/IGNITE-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127132#comment-16127132 ] Taras Ledkov commented on IGNITE-5233: -- [~vozerov], comments are fixed. Tests are OK. > JDBC thin Driver: implement metadata support > - > > Key: IGNITE-5233 > URL: https://issues.apache.org/jira/browse/IGNITE-5233 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.0 >Reporter: Taras Ledkov >Assignee: Taras Ledkov > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127116#comment-16127116
]
ASF GitHub Bot commented on IGNITE-6063:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2444
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.2
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127113#comment-16127113
]
Alexey Goncharuk commented on IGNITE-6063:
--
Thanks, Igor, merged your changes to master.
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.2
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-6063:
-
Affects Version/s: 2.2
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.2
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-6063:
-
Fix Version/s: 2.2
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Affects Versions: 2.2
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.2
>
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-6063:
-
Labels: MakeTeamcityGreenAgain (was: )
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
> Labels: MakeTeamcityGreenAgain
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6067) Refactor cache configuration initialization with proper defaults
[ https://issues.apache.org/jira/browse/IGNITE-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127105#comment-16127105 ] Konstantin Dudkov commented on IGNITE-6067: --- [TC run|https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests&branch_Ignite20Tests=pull%2F2445%2Fhead] > Refactor cache configuration initialization with proper defaults > > > Key: IGNITE-6067 > URL: https://issues.apache.org/jira/browse/IGNITE-6067 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Dudkov >Assignee: Konstantin Dudkov > Fix For: 2.2 > > > Move cache configuration initialization from GridCacheProcessor#initialize to > GridCacheUtils -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6067) Refactor cache configuration initialization with proper defaults
[ https://issues.apache.org/jira/browse/IGNITE-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127088#comment-16127088 ] ASF GitHub Bot commented on IGNITE-6067: GitHub user kdudkov opened a pull request: https://github.com/apache/ignite/pull/2445 IGNITE-6067 move initialize() to GridCacheUtils You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-6067 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/2445.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 #2445 commit f2844f5b0e59e2117b905d1d14d902356cf327d3 Author: Konstantin Dudkov Date: 2017-08-15T11:13:34Z IGNITE-6067 move initialize() to GridCacheUtils > Refactor cache configuration initialization with proper defaults > > > Key: IGNITE-6067 > URL: https://issues.apache.org/jira/browse/IGNITE-6067 > Project: Ignite > Issue Type: Improvement >Reporter: Konstantin Dudkov >Assignee: Konstantin Dudkov > Fix For: 2.2 > > > Move cache configuration initialization from GridCacheProcessor#initialize to > GridCacheUtils -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127059#comment-16127059 ] Alex Volkov commented on IGNITE-6064: - Please add help output for both --help and -help keys and example of use in the help output. > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver
[
https://issues.apache.org/jira/browse/IGNITE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-4642:
---
Assignee: Taras Ledkov
> Support enforceJoinOrder flag for JDBC driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's
> not exposed on JDBC driver.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-4642) Support enforceJoinOrder flag for JDBC driver
[
https://issues.apache.org/jira/browse/IGNITE-4642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-4642:
Fix Version/s: 2.2
> Support enforceJoinOrder flag for JDBC driver
> -
>
> Key: IGNITE-4642
> URL: https://issues.apache.org/jira/browse/IGNITE-4642
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 1.8
>Reporter: Valentin Kulichenko
> Fix For: 2.2
>
>
> There is a useful {{enforceJoinOrder}} flag on {{SqlFieldsQuery}}, but it's
> not exposed on JDBC driver.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6067) Refactor cache configuration initialization with proper defaults
Konstantin Dudkov created IGNITE-6067: - Summary: Refactor cache configuration initialization with proper defaults Key: IGNITE-6067 URL: https://issues.apache.org/jira/browse/IGNITE-6067 Project: Ignite Issue Type: Improvement Reporter: Konstantin Dudkov Assignee: Konstantin Dudkov Fix For: 2.2 Move cache configuration initialization from GridCacheProcessor#initialize to GridCacheUtils -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6066) Grid hangs on partition map exhcange during failover test with 30 physical caches and PDS
[ https://issues.apache.org/jira/browse/IGNITE-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova updated IGNITE-6066: Attachment: ignite-base-load-config.xml run-load.properties run-load.xml > Grid hangs on partition map exhcange during failover test with 30 physical > caches and PDS > - > > Key: IGNITE-6066 > URL: https://issues.apache.org/jira/browse/IGNITE-6066 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ksenia Rybakova > Attachments: ignite-base-load-config.xml, run-load.properties, > run-load.xml > > > Grid hangs on partition map exhcange during failover test with 30 physical > caches and PDS. > Load config: > CacheRandomOperationBenchmark > 7 client nodes, 7 server nodes > 250K perloading, 500K key range > 30 physical caches > 2 backups > 1 server node is being restarted periodically > Complete configs are attached. > Preloading phase is ok, then main test starts and after some time grid hangs. > One of the servers failed with OutOfMemoryError. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null
[
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127034#comment-16127034
]
Zhang Yuan edited comment on IGNITE-5994 at 8/15/17 10:10 AM:
--
[~sharpler] I would like to be work on this issue. Please assigned it to me.
was (Author: shia):
[ ~sharpler] I would like to be work on this issue. Please assigned it to me
> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
> Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but
> the IgniteInternalCache.invokeAsync().get() can return the null in case when
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5994) IgniteInternalCache.invokeAsync().get() can return null
[
https://issues.apache.org/jira/browse/IGNITE-5994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16127034#comment-16127034
]
Zhang Yuan commented on IGNITE-5994:
[ ~sharpler] I would like to be work on this issue. Please assigned it to me
> IgniteInternalCache.invokeAsync().get() can return null
> ---
>
> Key: IGNITE-5994
> URL: https://issues.apache.org/jira/browse/IGNITE-5994
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.1
>Reporter: Alexander Menshikov
>Priority: Minor
> Labels: newbie
> Attachments: IgniteCacheSelfTest.java
>
>
> The IgniteInternalCache.invoke() always return an EntryProcessorResult, but
> the IgniteInternalCache.invokeAsync().get() can return the null in case when
> an EntryProcessor has returned the null.
> Code from reproducer:
> {noformat}
> final EntryProcessor ep = new EntryProcessor Object, Object>() {
> @Override
> public Object process(MutableEntry entry,
> Object... objects) throws EntryProcessorException {
> return null;
> }
> };
> EntryProcessorResult result = utilCache.invoke("test", ep);
> assertNotNull(result);
> assertNull(result.get());
> result = utilCache.invokeAsync("test", ep).get();
> // Assert here!!!
> assertNotNull(result);
> assertNull(result.get());
> {noformat}
> It can be optimization. Nevertheless results of invoke() must be equals with
> results of invokeAsync().get(). So there are two options:
> 1) To do so would be the invokeAsync(key, ep).get() returned the null too for
> the optimization.
> 2) Or to do so would be the invoke(key, ep) returned an EntryProcessorResult
> for a logical consistency.
> NOTE: Don't confuse with IgniteCache.invoke.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6066) Grid hangs on partition map exhcange during failover test with 30 physical caches and PDS
[ https://issues.apache.org/jira/browse/IGNITE-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ksenia Rybakova updated IGNITE-6066: Description: Grid hangs on partition map exhcange during failover test with 30 physical caches and PDS. Load config: CacheRandomOperationBenchmark 7 client nodes, 7 server nodes 250K perloading, 500K key range 30 physical caches 2 backups 1 server node is being restarted periodically Complete configs are attached. Preloading phase is ok, then main test starts and after some time grid hangs. One of the servers failed with OutOfMemoryError. > Grid hangs on partition map exhcange during failover test with 30 physical > caches and PDS > - > > Key: IGNITE-6066 > URL: https://issues.apache.org/jira/browse/IGNITE-6066 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Ksenia Rybakova > > Grid hangs on partition map exhcange during failover test with 30 physical > caches and PDS. > Load config: > CacheRandomOperationBenchmark > 7 client nodes, 7 server nodes > 250K perloading, 500K key range > 30 physical caches > 2 backups > 1 server node is being restarted periodically > Complete configs are attached. > Preloading phase is ok, then main test starts and after some time grid hangs. > One of the servers failed with OutOfMemoryError. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6066) Grid hangs on partition map exhcange during failover test with 30 physical caches and PDS
Ksenia Rybakova created IGNITE-6066: --- Summary: Grid hangs on partition map exhcange during failover test with 30 physical caches and PDS Key: IGNITE-6066 URL: https://issues.apache.org/jira/browse/IGNITE-6066 Project: Ignite Issue Type: Bug Affects Versions: 2.1 Reporter: Ksenia Rybakova -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5867) Web console: Add parameter for adding primary key columns to generated POJO class
[ https://issues.apache.org/jira/browse/IGNITE-5867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-5867: - Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) > Web console: Add parameter for adding primary key columns to generated POJO > class > - > > Key: IGNITE-5867 > URL: https://issues.apache.org/jira/browse/IGNITE-5867 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Vasiliy Sisko > Fix For: 2.2 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6065) Quick way to find broken documentation links
[ https://issues.apache.org/jira/browse/IGNITE-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-6065: - Attachment: configuration more info link.PNG > Quick way to find broken documentation links > > > Key: IGNITE-6065 > URL: https://issues.apache.org/jira/browse/IGNITE-6065 > Project: Ignite > Issue Type: Test > Components: UI, wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Attachments: configuration more info link.PNG > > > Documentation links break from time to time. We need a special test that > walks all links and reports anything we might want to fix. Since all links > are in .pug templates, I suggest to use pug-walk from standard pug package. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (IGNITE-6065) Quick way to find broken documentation links
Ilya Borisov created IGNITE-6065: Summary: Quick way to find broken documentation links Key: IGNITE-6065 URL: https://issues.apache.org/jira/browse/IGNITE-6065 Project: Ignite Issue Type: Test Components: UI, wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Priority: Minor Documentation links break from time to time. We need a special test that walks all links and reports anything we might want to fix. Since all links are in .pug templates, I suggest to use pug-walk from standard pug package. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (IGNITE-5985) WebConsole: add generation of keyFields for queryEntity for multiple primary key
[
https://issues.apache.org/jira/browse/IGNITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vasiliy Sisko reassigned IGNITE-5985:
-
Assignee: Alexey Kuznetsov (was: Vasiliy Sisko)
Affects Version/s: 2.1
> WebConsole: add generation of keyFields for queryEntity for multiple primary
> key
>
>
> Key: IGNITE-5985
> URL: https://issues.apache.org/jira/browse/IGNITE-5985
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Evgenii Zhuravlev
>Assignee: Alexey Kuznetsov
>
> For example, for table like
> {code:java}
> CREATE TABLE TABLE_NAME (
> KEY1 int NOT NULL,
> KEY2 int NOT NULL,
> VALUE int,
> PRIMARY KEY (KEY1,KEY2));
> {code}
> should be generated queryEntity like:
> {code:java}
>
>
>
> value="org.apache.ignite.examples.TableNameKey"/>
> value="org.apache.ignite.examples.TableName"/>
>
>
> key1
> key2
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5985) WebConsole: add generation of keyFields for queryEntity for multiple primary key
[
https://issues.apache.org/jira/browse/IGNITE-5985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126993#comment-16126993
]
Vasiliy Sisko commented on IGNITE-5985:
---
Implemented possibility to configure keyFields property for QueryEntity query
descriptor.
Implemented set of key fields on import of domain model (see "Exclude key
fields in query definition for built-in key types" import property).
> WebConsole: add generation of keyFields for queryEntity for multiple primary
> key
>
>
> Key: IGNITE-5985
> URL: https://issues.apache.org/jira/browse/IGNITE-5985
> Project: Ignite
> Issue Type: Improvement
>Reporter: Evgenii Zhuravlev
>Assignee: Vasiliy Sisko
>
> For example, for table like
> {code:java}
> CREATE TABLE TABLE_NAME (
> KEY1 int NOT NULL,
> KEY2 int NOT NULL,
> VALUE int,
> PRIMARY KEY (KEY1,KEY2));
> {code}
> should be generated queryEntity like:
> {code:java}
>
>
>
> value="org.apache.ignite.examples.TableNameKey"/>
> value="org.apache.ignite.examples.TableName"/>
>
>
> key1
> key2
>
>
>
>
>
>
>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-5233) JDBC thin Driver: implement metadata support
[
https://issues.apache.org/jira/browse/IGNITE-5233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126985#comment-16126985
]
Vladimir Ozerov commented on IGNITE-5233:
-
[~tledkov-gridgain], my comments:
1) {{SqlListenerRequestHandler.handshakeAdditionalResponse}} is a wrong
abstraction. Instead, handler should have something like {{writeHandshake}}
method
2) {{JdbcTableMeta.tblType}]} - unused field
3) {{JdbcMetaSchemasResult}} - unnecessary copying in read/write methods
4) {{JdbcMetaTablesRequest.tableTypes}} - I do not think we need to pass it
5) Make sure that {{toString}} is added to all value objects
6) {{JdbcPrimaryKeyMeta.fields}}, {{JdbcIndexMeta.fields}} - use List instead
of array to avoid unnecesasry copying and simplify the code
7) {{JdbcRequestHandler#getPrimaryKeys}} - why do we pass "_KEY" as primary key
constraint name???
8) {{JdbcRequestHandler#getTablesMeta}} - "TABLE" match can be performed on a
client, no?
> JDBC thin Driver: implement metadata support
> -
>
> Key: IGNITE-5233
> URL: https://issues.apache.org/jira/browse/IGNITE-5233
> Project: Ignite
> Issue Type: Improvement
> Components: jdbc
>Affects Versions: 2.0
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
> Fix For: 2.2
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6023) Index inline should be enabled by default for fixed-length data types
[
https://issues.apache.org/jira/browse/IGNITE-6023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov resolved IGNITE-6023.
--
Resolution: Won't Fix
Inline size is enabled by default at the {{InlineIndexHelper}}.
> Index inline should be enabled by default for fixed-length data types
> -
>
> Key: IGNITE-6023
> URL: https://issues.apache.org/jira/browse/IGNITE-6023
> Project: Ignite
> Issue Type: Improvement
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
> Labels: performance, usability
> Fix For: 2.2
>
>
> Currently index inline is not enabled by default. This is ok for variable
> length types such as strings because we cannot enforce their length at the
> moment (it would require changes to DDL). But for fixed-length data types it
> is perfectly OK to enable inline by default:
> - int
> - long
> - date
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan edited comment on IGNITE-6064 at 8/15/17 9:03 AM:
Another possible name is {{activate.sh}}, in which case the commands should be
{{on}} and {{off}} (instead of activate/deactivate). I think I like this name
better.
was (Author: dsetrakyan):
Another possible name is {{activate.sh}}, in which case the commands should be
{{-on}} and {{-off}}. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6058) Test fail testTransformResourceInjection broken
[ https://issues.apache.org/jira/browse/IGNITE-6058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-6058: Description: Affected tests: GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection > Test fail testTransformResourceInjection broken > --- > > Key: IGNITE-6058 > URL: https://issues.apache.org/jira/browse/IGNITE-6058 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Govorukhin > Labels: MakeTeamcityGreenAgain > Fix For: 2.2 > > > Affected tests: > GridCachePartitionedNearDisabledMultiJvmFullApiSelfTest.testTransformResourceInjection > > GridCachePartitionedNearDisabledMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection > > GridCachePartitionedNearDisabledOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection > > GridCacheReplicatedMultiJvmFullApiSelfTest.testTransformResourceInjection > GridCacheReplicatedMultiJvmP2PDisabledFullApiSelfTest.testTransformResourceInjection > > GridCacheReplicatedNearOnlyMultiJvmFullApiSelfTest.testTransformResourceInjection > > GridCacheReplicatedOnheapMultiJvmFullApiSelfTest.testTransformResourceInjection -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan edited comment on IGNITE-6064 at 8/15/17 9:02 AM:
Another possible name is {{activate.sh}}, in which case the commands should be
{{-on}} and {{-off}}. I think I like this name better.
was (Author: dsetrakyan):
Another possible name is {{activate.sh}}, in which case the commands should be
"--on" and _--off_. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan edited comment on IGNITE-6064 at 8/15/17 9:01 AM:
Another possible name is {{activate.sh}}, in which case the commands should be
"--on" and _--off_. I think I like this name better.
was (Author: dsetrakyan):
Another possible name is {{activate.sh}}, in which case the commands should be
_--on_ and _--off_. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan edited comment on IGNITE-6064 at 8/15/17 9:01 AM:
Another possible name is {{activate.sh}}, in which case the commands should be
_--on_ and _--off_. I think I like this name better.
was (Author: dsetrakyan):
Another possible name is {{activate.sh}}, in which case the commands should be
{{ --on }} and {{--off}}. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan edited comment on IGNITE-6064 at 8/15/17 9:00 AM:
Another possible name is {{activate.sh}}, in which case the commands should be
{{ --on }} and {{--off}}. I think I like this name better.
was (Author: dsetrakyan):
Another possible name is {{activate.sh}}, in which case the commands should be
{{ --on}} and {{--off}}. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan edited comment on IGNITE-6064 at 8/15/17 9:00 AM:
Another possible name is {{activate.sh}}, in which case the commands should be
{{ --on}} and {{--off}}. I think I like this name better.
was (Author: dsetrakyan):
Another possible name is {{activate.sh}}, in which case the commands should be
{{--on}} and {{--off}}. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IGNITE-5983) REST: Memory policy metrics should be available via REST.
[ https://issues.apache.org/jira/browse/IGNITE-5983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shtykh reassigned IGNITE-5983: Assignee: Roman Shtykh > REST: Memory policy metrics should be available via REST. > - > > Key: IGNITE-5983 > URL: https://issues.apache.org/jira/browse/IGNITE-5983 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrew Mashenkov >Assignee: Roman Shtykh > > For now it is possible to get some of cache metrics via REST, but not memory > metrics. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6064) Rework control.sh script
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126966#comment-16126966
]
Dmitriy Setrakyan commented on IGNITE-6064:
---
Another possible name is {{activate.sh}}, in which case the commands should be
{{--on}} and {{--off}}. I think I like this name better.
> Rework control.sh script
>
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is a confusing name, need more suitable name.
> 2. Print help description if incorrect command was entered
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126962#comment-16126962 ] Dmitriy Setrakyan commented on IGNITE-6064: --- 1. name - how about "cluster-ops.sh" or "cluster-switch.sh"? 2. Printing help in case of error is not enough. You should print an error message first, and then help. See how other Ignite scripts work. 3. The stack trace should never be printed, not just for failed connection. We should always provide an appropriate error message and possible reasons for it. Perhaps you can add a "--verbose" mode to your script which will print all the stack traces as well. > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Setrakyan updated IGNITE-6064: -- Description: Current behavior control.sh is not clear. 1. control.sh is a confusing name, need more suitable name. 2. Print help description if incorrect command was entered 3. Do not print stacktrace if connection fail, add more conveniently message. 4. Print information about connection, like "Connecting to [ip-address]:[port] etc." was: Current behavior control.sh is not clear. 1. control.sh is confuse name, need more suitable name. 2. Print help description if incorrect command was entered. 3. Do not print stacktrace if connection fail, add more conveniently message. 4. Print information about connection, like "Connecting to [ip-address]:[port] etc." > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is a confusing name, need more suitable name. > 2. Print help description if incorrect command was entered > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6064) Rework control.sh script
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-6064: --- Summary: Rework control.sh script (was: Rework control.sh script.) > Rework control.sh script > > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is confuse name, need more suitable name. > 2. Print help description if incorrect command was entered. > 3. Do not print stacktrace if connection fail, add more conveniently message. > 4. Print information about connection, like "Connecting to > [ip-address]:[port] etc." -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-6064) Rework control.sh script.
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6064:
---
Description:
Current behavior control.sh is not clear.
1. control.sh is confuse name, need more suitable name.
2. Print help description if incorrect command was entered.
3. Do not print stacktrace if connection fail, add more conveniently message.
4. Print information about connection, like "Connecting to {ip-address}:{port}
etc."
was:
Current behavior control.sh is not clear.
1. control.sh is confuse name, need more suitable name.
2. Print help description if incorrect command was entered.
3. Do not print stacktrace if connection fail, add more conveniently message.
> Rework control.sh script.
> -
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is confuse name, need more suitable name.
> 2. Print help description if incorrect command was entered.
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> {ip-address}:{port} etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6064) Rework control.sh script.
[
https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-6064:
---
Description:
Current behavior control.sh is not clear.
1. control.sh is confuse name, need more suitable name.
2. Print help description if incorrect command was entered.
3. Do not print stacktrace if connection fail, add more conveniently message.
4. Print information about connection, like "Connecting to [ip-address]:[port]
etc."
was:
Current behavior control.sh is not clear.
1. control.sh is confuse name, need more suitable name.
2. Print help description if incorrect command was entered.
3. Do not print stacktrace if connection fail, add more conveniently message.
4. Print information about connection, like "Connecting to {ip-address}:{port}
etc."
> Rework control.sh script.
> -
>
> Key: IGNITE-6064
> URL: https://issues.apache.org/jira/browse/IGNITE-6064
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.0, 2.1
>Reporter: Dmitriy Govorukhin
> Fix For: 2.2
>
>
> Current behavior control.sh is not clear.
> 1. control.sh is confuse name, need more suitable name.
> 2. Print help description if incorrect command was entered.
> 3. Do not print stacktrace if connection fail, add more conveniently message.
> 4. Print information about connection, like "Connecting to
> [ip-address]:[port] etc."
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (IGNITE-6064) Rework control.sh script.
[ https://issues.apache.org/jira/browse/IGNITE-6064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-6064: --- Description: Current behavior control.sh is not clear. 1. control.sh is confuse name, need more suitable name. 2. Print help description if incorrect command was entered. 3. Do not print stacktrace if connection fail, add more conveniently message. > Rework control.sh script. > - > > Key: IGNITE-6064 > URL: https://issues.apache.org/jira/browse/IGNITE-6064 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.0, 2.1 >Reporter: Dmitriy Govorukhin > Fix For: 2.2 > > > Current behavior control.sh is not clear. > 1. control.sh is confuse name, need more suitable name. > 2. Print help description if incorrect command was entered. > 3. Do not print stacktrace if connection fail, add more conveniently message. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-5434) Yardstick sql benchmarks broken on Ignite-5267 branch
[ https://issues.apache.org/jira/browse/IGNITE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126959#comment-16126959 ] Vladimir Ozerov commented on IGNITE-5434: - [~xiaolin], I changed resolve status to "Cannot Reproduce". We failed to reproduce it. Feel free to re-open the ticket if you still have any problems. > Yardstick sql benchmarks broken on Ignite-5267 branch > - > > Key: IGNITE-5434 > URL: https://issues.apache.org/jira/browse/IGNITE-5434 > Project: Ignite > Issue Type: Bug > Components: sql, yardstick >Affects Versions: 2.1 >Reporter: Aleksey Chetaev >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 2.1 > > Attachments: IGNITE-5434.zip > > > Yardstick benchmarks: > * sql-query > * sql-query-join > * sql-query-put > broken in Ignite-5267 branch, in master all ok. > Exception: > <00:39:22> Starting warmup. > > > > > Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017] > > > > > ERROR: Shutting down benchmark driver to unexpected exception. > > > > > Type '--help' for usage. > > > > > javax.cache.CacheException: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64) > > > > at > org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.a
[jira] [Resolved] (IGNITE-5434) Yardstick sql benchmarks broken on Ignite-5267 branch
[ https://issues.apache.org/jira/browse/IGNITE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-5434. - Resolution: Cannot Reproduce > Yardstick sql benchmarks broken on Ignite-5267 branch > - > > Key: IGNITE-5434 > URL: https://issues.apache.org/jira/browse/IGNITE-5434 > Project: Ignite > Issue Type: Bug > Components: sql, yardstick >Affects Versions: 2.1 >Reporter: Aleksey Chetaev >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 2.1 > > Attachments: IGNITE-5434.zip > > > Yardstick benchmarks: > * sql-query > * sql-query-join > * sql-query-put > broken in Ignite-5267 branch, in master all ok. > Exception: > <00:39:22> Starting warmup. > > > > > Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017] > > > > > ERROR: Shutting down benchmark driver to unexpected exception. > > > > > Type '--help' for usage. > > > > > javax.cache.CacheException: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64) > > > > at > org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1291) >
[jira] [Reopened] (IGNITE-5434) Yardstick sql benchmarks broken on Ignite-5267 branch
[ https://issues.apache.org/jira/browse/IGNITE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reopened IGNITE-5434: - > Yardstick sql benchmarks broken on Ignite-5267 branch > - > > Key: IGNITE-5434 > URL: https://issues.apache.org/jira/browse/IGNITE-5434 > Project: Ignite > Issue Type: Bug > Components: sql, yardstick >Affects Versions: 2.1 >Reporter: Aleksey Chetaev >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 2.1 > > Attachments: IGNITE-5434.zip > > > Yardstick benchmarks: > * sql-query > * sql-query-join > * sql-query-put > broken in Ignite-5267 branch, in master all ok. > Exception: > <00:39:22> Starting warmup. > > > > > Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017] > > > > > ERROR: Shutting down benchmark driver to unexpected exception. > > > > > Type '--help' for usage. > > > > > javax.cache.CacheException: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64) > > > > at > org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1291) > >
[jira] [Created] (IGNITE-6064) Rework control.sh script.
Dmitriy Govorukhin created IGNITE-6064: -- Summary: Rework control.sh script. Key: IGNITE-6064 URL: https://issues.apache.org/jira/browse/IGNITE-6064 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.1, 2.0 Reporter: Dmitriy Govorukhin Fix For: 2.2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (IGNITE-6060) Make sure that index inline is enabled for String and Date types by default
[
https://issues.apache.org/jira/browse/IGNITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126943#comment-16126943
]
Taras Ledkov commented on IGNITE-6060:
--
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type
- H2TreeIndex#computeInlineSize for the strings. The default size is specified
by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default
H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10)
> Make sure that index inline is enabled for String and Date types by default
> ---
>
> Key: IGNITE-6060
> URL: https://issues.apache.org/jira/browse/IGNITE-6060
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: performance, usability
> Fix For: 2.2
>
>
> Index inline is important performance optimization which should be enabled
> almost always. Let's check whether it is enabled for String and Data types.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6060) Make sure that index inline is enabled for String and Date types by default
[
https://issues.apache.org/jira/browse/IGNITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126943#comment-16126943
]
Taras Ledkov edited comment on IGNITE-6060 at 8/15/17 8:20 AM:
---
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type;
- H2TreeIndex#computeInlineSize for the strings. The default size is specified
by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default is
H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10)
was (Author: tledkov-gridgain):
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type
- H2TreeIndex#computeInlineSize for the strings. The default size is specified
by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default
H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10)
> Make sure that index inline is enabled for String and Date types by default
> ---
>
> Key: IGNITE-6060
> URL: https://issues.apache.org/jira/browse/IGNITE-6060
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: performance, usability
> Fix For: 2.2
>
>
> Index inline is important performance optimization which should be enabled
> almost always. Let's check whether it is enabled for String and Data types.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6004) SQL: add "inlineSize" to QuerySqlField annotation
[
https://issues.apache.org/jira/browse/IGNITE-6004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126945#comment-16126945
]
ASF GitHub Bot commented on IGNITE-6004:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/2420
> SQL: add "inlineSize" to QuerySqlField annotation
> -
>
> Key: IGNITE-6004
> URL: https://issues.apache.org/jira/browse/IGNITE-6004
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: usability
> Fix For: 2.2
>
>
> "inlineSize" is very important optimization allowing to avoid excessive data
> page reads when using index. However, it can only be set through
> {{QueryEntity}} -> {{QueryIndex}} chain, and cannot be set through
> {{\@QuerySqlField}} annotation.
> Let's fix that and add {{int indexInlineSize}} parameter to that annotation.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6060) Make sure that index inline is enabled for String and Date types by default
[
https://issues.apache.org/jira/browse/IGNITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126943#comment-16126943
]
Taras Ledkov edited comment on IGNITE-6060 at 8/15/17 8:21 AM:
---
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type;
- {{H2TreeIndex#computeInlineSize}} for the strings. The default size is
specified by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default value is
{{H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10}})
was (Author: tledkov-gridgain):
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type;
- H2TreeIndex#computeInlineSize for the strings. The default size is specified
by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default value is
H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10)
> Make sure that index inline is enabled for String and Date types by default
> ---
>
> Key: IGNITE-6060
> URL: https://issues.apache.org/jira/browse/IGNITE-6060
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: performance, usability
> Fix For: 2.2
>
>
> Index inline is important performance optimization which should be enabled
> almost always. Let's check whether it is enabled for String and Data types.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-6060) Make sure that index inline is enabled for String and Date types by default
[
https://issues.apache.org/jira/browse/IGNITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126943#comment-16126943
]
Taras Ledkov edited comment on IGNITE-6060 at 8/15/17 8:21 AM:
---
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type;
- H2TreeIndex#computeInlineSize for the strings. The default size is specified
by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default value is
H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10)
was (Author: tledkov-gridgain):
Defaults inline sizes are set up at:
- InlineIndexHelper#InlineIndexHelper for the {{DATE}} type;
- H2TreeIndex#computeInlineSize for the strings. The default size is specified
by the property {{IGNITE_MAX_INDEX_PAYLOAD_SIZE}} (default is
H2TreeIndex#IGNITE_MAX_INDEX_PAYLOAD_SIZE_DEFAULT = 10)
> Make sure that index inline is enabled for String and Date types by default
> ---
>
> Key: IGNITE-6060
> URL: https://issues.apache.org/jira/browse/IGNITE-6060
> Project: Ignite
> Issue Type: Task
> Components: persistence, sql
>Affects Versions: 2.1
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
> Labels: performance, usability
> Fix For: 2.2
>
>
> Index inline is important performance optimization which should be enabled
> almost always. Let's check whether it is enabled for String and Data types.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (IGNITE-6060) Make sure that index inline is enabled for String and Date types by default
[ https://issues.apache.org/jira/browse/IGNITE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov resolved IGNITE-6060. -- Resolution: Won't Fix > Make sure that index inline is enabled for String and Date types by default > --- > > Key: IGNITE-6060 > URL: https://issues.apache.org/jira/browse/IGNITE-6060 > Project: Ignite > Issue Type: Task > Components: persistence, sql >Affects Versions: 2.1 >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov > Labels: performance, usability > Fix For: 2.2 > > > Index inline is important performance optimization which should be enabled > almost always. Let's check whether it is enabled for String and Data types. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (IGNITE-5872) Replace standard java maps for partition counters with more effective data structures
[ https://issues.apache.org/jira/browse/IGNITE-5872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-5872: - Summary: Replace standard java maps for partition counters with more effective data structures (was: Replace standard java maps for partition counters to more effective data structures) > Replace standard java maps for partition counters with more effective data > structures > - > > Key: IGNITE-5872 > URL: https://issues.apache.org/jira/browse/IGNITE-5872 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.1 >Reporter: Alexey Goncharuk >Assignee: Alexey Goncharuk > Fix For: 2.2 > > > Currently we have map of Integer -> Tuple which is passed for > each cache group. This is very inefficient as at causes a lot of boxes and > overheads in marshalling. > This particular map can be replaced with a sorted primitive array. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (IGNITE-5434) Yardstick sql benchmarks broken on Ignite-5267 branch
[ https://issues.apache.org/jira/browse/IGNITE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126930#comment-16126930 ] Xiaolin Zhang edited comment on IGNITE-5434 at 8/15/17 8:11 AM: Can not see any patch for this issue. And, why this issue is RESOLVED? was (Author: xiaolin): Can not see any patch for this issue. > Yardstick sql benchmarks broken on Ignite-5267 branch > - > > Key: IGNITE-5434 > URL: https://issues.apache.org/jira/browse/IGNITE-5434 > Project: Ignite > Issue Type: Bug > Components: sql, yardstick >Affects Versions: 2.1 >Reporter: Aleksey Chetaev >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 2.1 > > Attachments: IGNITE-5434.zip > > > Yardstick benchmarks: > * sql-query > * sql-query-join > * sql-query-put > broken in Ignite-5267 branch, in master all ok. > Exception: > <00:39:22> Starting warmup. > > > > > Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017] > > > > > ERROR: Shutting down benchmark driver to unexpected exception. > > > > > Type '--help' for usage. > > > > > javax.cache.CacheException: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64) > > > > at > org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > >
[jira] [Commented] (IGNITE-5434) Yardstick sql benchmarks broken on Ignite-5267 branch
[ https://issues.apache.org/jira/browse/IGNITE-5434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126930#comment-16126930 ] Xiaolin Zhang commented on IGNITE-5434: --- Can not see any patch for this issue. > Yardstick sql benchmarks broken on Ignite-5267 branch > - > > Key: IGNITE-5434 > URL: https://issues.apache.org/jira/browse/IGNITE-5434 > Project: Ignite > Issue Type: Bug > Components: sql, yardstick >Affects Versions: 2.1 >Reporter: Aleksey Chetaev >Assignee: Vladimir Ozerov >Priority: Critical > Labels: important > Fix For: 2.1 > > Attachments: IGNITE-5434.zip > > > Yardstick benchmarks: > * sql-query > * sql-query-join > * sql-query-put > broken in Ignite-5267 branch, in master all ok. > Exception: > <00:39:22> Starting warmup. > > > > > Finishing main test [ts=1496795962893, date=Wed Jun 07 00:39:22 UTC 2017] > > > > > ERROR: Shutting down benchmark driver to unexpected exception. > > > > > Type '--help' for usage. > > > > > javax.cache.CacheException: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.cache.IgniteCacheProxy.query(IgniteCacheProxy.java:807) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.executeQuery(IgniteSqlQueryBenchmark.java:90) > > > > at > org.apache.ignite.yardstick.cache.IgniteSqlQueryBenchmark.test(IgniteSqlQueryBenchmark.java:64) > > > > at > org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178) > > > > > at java.lang.Thread.run(Thread.java:745) > > > > > Caused by: class > org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to > parse query: SELECT "query"."Person"._KEY, "query"."Person"._VAL FROM > "query"."Person" WHERE salary >= ? and salary <= ? > > > at > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1291) >
[jira] [Assigned] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov reassigned IGNITE-6063:
Assignee: Igor Seliverstov
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Reporter: Igor Seliverstov
>Assignee: Igor Seliverstov
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (IGNITE-6063) InlineIdexHelperTest fails
[
https://issues.apache.org/jira/browse/IGNITE-6063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16126904#comment-16126904
]
ASF GitHub Bot commented on IGNITE-6063:
GitHub user gvvinblade opened a pull request:
https://github.com/apache/ignite/pull/2444
IGNITE-6063
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-6063
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/2444.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 #2444
commit 89d7c06974ef042aac99a4db29058a12421d47ca
Author: Igor Seliverstov
Date: 2017-08-15T07:51:16Z
IGNITE-6063 InlineIdexHelperTest fails
> InlineIdexHelperTest fails
> --
>
> Key: IGNITE-6063
> URL: https://issues.apache.org/jira/browse/IGNITE-6063
> Project: Ignite
> Issue Type: Test
>Reporter: Igor Seliverstov
>
> {noformat}
> java.lang.RuntimeException:
> at org.h2.message.DbException.throwInternalError(DbException.java:242)
> at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
> at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
> at
> org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (IGNITE-6063) InlineIdexHelperTest fails
Igor Seliverstov created IGNITE-6063:
Summary: InlineIdexHelperTest fails
Key: IGNITE-6063
URL: https://issues.apache.org/jira/browse/IGNITE-6063
Project: Ignite
Issue Type: Test
Reporter: Igor Seliverstov
{noformat}
java.lang.RuntimeException:
at org.h2.message.DbException.throwInternalError(DbException.java:242)
at org.h2.value.CompareModeDefault.(CompareModeDefault.java:28)
at org.h2.value.CompareMode.getInstance(CompareMode.java:129)
at org.h2.value.CompareMode.getInstance(CompareMode.java:90)
at
org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.getRes(InlineIndexHelperTest.java:498)
at
org.apache.ignite.internal.processors.query.h2.database.InlineIndexHelperTest.testRelyOnCompare(InlineIndexHelperTest.java:242)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
