[jira] [Updated] (IGNITE-9981) Web Console: We need to update the counters on the tables.
[ https://issues.apache.org/jira/browse/IGNITE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-9981: - Fix Version/s: 2.8 > Web Console: We need to update the counters on the tables. > -- > > Key: IGNITE-9981 > URL: https://issues.apache.org/jira/browse/IGNITE-9981 > Project: Ignite > Issue Type: Improvement > Components: UI, wizards >Reporter: Vica Abramova >Assignee: Alexey Kuznetsov >Priority: Major > Fix For: 2.8 > > Attachments: Renew Table.png > > Original Estimate: 12h > Time Spent: 10h 13m > Remaining Estimate: 1h 47m > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11716) Web console: can't select cluster memory eviction mode
[ https://issues.apache.org/jira/browse/IGNITE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-11716: -- Fix Version/s: 2.8 > Web console: can't select cluster memory eviction mode > -- > > Key: IGNITE-11716 > URL: https://issues.apache.org/jira/browse/IGNITE-11716 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.8 > > Attachments: image-2019-04-10-17-02-17-310.png > > Time Spent: 10m > Remaining Estimate: 0h > > What happens: > Memory eviction mode select has no options to choose from and there's an > error in console. > !image-2019-04-10-17-02-17-310.png! > Expected behavior: > The error should not happen, user should be able to select eviction mode. > Note: select configuration version 2.1 to see "memory" section in advanced > cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11716) Web console: can't select cluster memory eviction mode
[ https://issues.apache.org/jira/browse/IGNITE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reassigned IGNITE-11716: - Assignee: Alexey Kuznetsov (was: Vasiliy Sisko) > Web console: can't select cluster memory eviction mode > -- > > Key: IGNITE-11716 > URL: https://issues.apache.org/jira/browse/IGNITE-11716 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: image-2019-04-10-17-02-17-310.png > > Time Spent: 10m > Remaining Estimate: 0h > > What happens: > Memory eviction mode select has no options to choose from and there's an > error in console. > !image-2019-04-10-17-02-17-310.png! > Expected behavior: > The error should not happen, user should be able to select eviction mode. > Note: select configuration version 2.1 to see "memory" section in advanced > cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11724) IgniteSpark integration forget to close the IgniteContext and stops the client node in case if error during PairFunction logic
Andrey Aleksandrov created IGNITE-11724:
---
Summary: IgniteSpark integration forget to close the IgniteContext
and stops the client node in case if error during PairFunction logic
Key: IGNITE-11724
URL: https://issues.apache.org/jira/browse/IGNITE-11724
Project: Ignite
Issue Type: Bug
Components: spark
Affects Versions: 2.7
Reporter: Andrey Aleksandrov
Fix For: 2.8
Next code could hang in case if PairFunction logic will throw the exception:
JavaPairRDD rdd_records = records.mapToPair(new MapFunction());
JavaIgniteContext igniteContext = new JavaIgniteContext<>(sparkCtx,
configUrl);
JavaIgniteRDD igniteRdd = igniteContext.fromCache(cacheName);
igniteRdd.savePairs(rdd_records);
Looks like next internal code (saveValues method)should also close the
IgniteContext in case of an unexpected exception, not only data streamer:
try {
it.foreach(value ⇒ {
val key = affinityKeyFunc(value, node.orNull)
streamer.addData(key, value)
})
}
finally {
streamer.close()
}
})
}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11723) IgniteSpark integration should support skipStore option for internal dataStreamer (IgniteRdd and Ignite DataFrame)
Andrey Aleksandrov created IGNITE-11723: --- Summary: IgniteSpark integration should support skipStore option for internal dataStreamer (IgniteRdd and Ignite DataFrame) Key: IGNITE-11723 URL: https://issues.apache.org/jira/browse/IGNITE-11723 Project: Ignite Issue Type: Improvement Components: spark Affects Versions: 2.7 Reporter: Andrey Aleksandrov Assignee: Andrey Aleksandrov Fix For: 2.8 At the moment this option can't be set. But this integrations could be used for initial data loading also for the caches with cache stores implementation. With skipStore option, we could avoid write-through behavior during this initial data loading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11690) .NET: Unable to locate external assembly with enabled peerAssemblyLoading
[
https://issues.apache.org/jira/browse/IGNITE-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814867#comment-16814867
]
Ignite TC Bot commented on IGNITE-11690:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 TIMEOUT , Exit Code
, Failure on metric |https://ci.ignite.apache.org/viewLog.html?buildId=3563427]]
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3563418]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests
26|https://ci.ignite.apache.org/viewLog.html?buildId=3563478]]
* ZookeeperDiscoverySpiTestSuite4:
DistributedMetaStoragePersistentTest.testJoinDirtyNodeFullData - 0,0% fails in
last 134 master runs.
* ZookeeperDiscoverySpiTestSuite4:
DistributedMetaStoragePersistentTest.testWrongStartOrder3 - 0,0% fails in last
134 master runs.
{color:#d04437}Continuous Query 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3563391]]
* IgniteCacheQuerySelfTestSuite3:
CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.testMultiThreaded -
0,0% fails in last 141 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3563614buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Unable to locate external assembly with enabled peerAssemblyLoading
> --
>
> Key: IGNITE-11690
> URL: https://issues.apache.org/jira/browse/IGNITE-11690
> Project: Ignite
> Issue Type: Bug
> Components: clients
>Affects Versions: 2.7
>Reporter: Alexandr Shapkin
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Original reproducer:
> [https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0] With
> two server nodes, and a client that spawn a computation with a simple cache
> iteration for custom class value
> Problem:
> If peer assembly loading enabled and no assembly exist for the nodes, then
> there is an endless loop: nodes are requesting the assembly from each other
> and no one is able to locate it.
> As an example of missing dll there could be a
> "System.Configuration.Configuration" for the .NET Core app
> [https://github.com/dotnet/standard/issues/506]
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11722) Batch BPlustTree updates for cache batch operations
[ https://issues.apache.org/jira/browse/IGNITE-11722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814850#comment-16814850 ] Semen Boikov commented on IGNITE-11722: --- Batch operations on BPlusTree were implemented by sergi.vladykin (invokeAll/putAll), for batch updates on BPlusTree it is necessary to sort keys in advance. To integrate it in cache updates it is necessary first group keys by partition, and then prepare sorted batches for each partition. Initial integration for ATOMIC cache batch operations is implemented in branch ignite-invokeAll: * changed method GridCacheMapEntry.innerUpdate, now tree closure is passed as parameter, it makes code little bit more clear * updates are sorted by partition/key on client (GridNearAtomicAbstractUpdateRequest.sort), so there is no need to group/sort updates on serves. As a side effect this also resolves issue with potential deadlocks in ATOMIC cache when user does not sort keys. * on primary nodes all entries are already locked before BPlusTree updates and it is safe to call BPlusTree.invokeAll * keys are added in backups update requests in sorted orders, so it is not necessary group/sort updates on backups. But on backups it is necessary to lock all entries before updating BPlusTree and cache data store, this was implemented. With these changes we got strange results in putAll benchmark with various batch sizes (IgnitePutAllBenchmark, 4 servers / 8 clients, 64 threads). There was performance boost only with batchSize=10, with others batch sizes there was performance drop. Need find out reason of performance drop, possible reasons: * added overhead for keys sorting * added overhead to prepare batches for BPlusTree.invokeAll, now for each batch collection of closures is created. This is necessary since we need update result for each key and currently result is stored in closure itself * batches are created per-partition, with default partition number and small servers number batches can be too small, so фввув overhead is bigger than BPlusTree.invokeAll benefit * maybe IgnitePutAllBenchmark is not really fair, it does not generate random keys for each iteration, but pre-generates 256 random maps in advance (all changes in branch ignite-invokeAll) > Batch BPlustTree updates for cache batch operations > --- > > Key: IGNITE-11722 > URL: https://issues.apache.org/jira/browse/IGNITE-11722 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Semen Boikov >Priority: Major > Fix For: 2.8 > > > Now cache batch operations (putAll, invokeAll, removeAll) update BPlustTree > entries one by one. It makes sense to support batch updates in BPlustTree > and use it for cache batch operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11722) Batch BPlustTree updates for cache batch operations
Semen Boikov created IGNITE-11722: - Summary: Batch BPlustTree updates for cache batch operations Key: IGNITE-11722 URL: https://issues.apache.org/jira/browse/IGNITE-11722 Project: Ignite Issue Type: Improvement Components: cache Reporter: Semen Boikov Fix For: 2.8 Now cache batch operations (putAll, invokeAll, removeAll) update BPlustTree entries one by one. It makes sense to support batch updates in BPlustTree and use it for cache batch operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814819#comment-16814819
]
Pavel Kuznetsov commented on IGNITE-11563:
--
So we cannot find the value in the cache except full scan which is slow for the
PK lookup.
What I think we can do
Let's treat scale of the decimal part of the column type: If user defined
column type as {{DECIMAL(19, 5)}} we should store internally decimal number
with 5 digits after point.
as [1]:
{quote}For decimal and numeric data types, SQL Server considers each
combination of precision and scale as a different data type. For example,
decimal(5,5) and decimal(5,0) are considered different data types.{quote}
If user specified value with more scale digits, let's raise error, as H2 does.
MsSQL uses rounding by default, though. But it rises error if special system
property is set (also see [1])
What to do with the decimal keys, that have been inserted using cache api -
open question. In this case full scans would include some "weird" records.
Could we forbid such puts (with different scale)? Another option - is to add
filter condition in the indexes.
[1]
https://docs.microsoft.com/en-us/sql/t-sql/data-types/decimal-and-numeric-transact-sql?view=sql-server-2017
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11563) DELETE WHERE does not work in prepared statements
[
https://issues.apache.org/jira/browse/IGNITE-11563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814801#comment-16814801
]
Pavel Kuznetsov commented on IGNITE-11563:
--
bug is that we use {{BPlusTree#findOne}} that has the same issue with
BigDecimal 1 and 1.0
https://github.com/apache/ignite/blob/af041491423cc2c91668de3790a81e3631bcfa5c/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/database/H2TreeIndex.java#L353
> DELETE WHERE does not work in prepared statements
> -
>
> Key: IGNITE-11563
> URL: https://issues.apache.org/jira/browse/IGNITE-11563
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.7
>Reporter: Stefan
>Assignee: Pavel Kuznetsov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> With SQL I cannot delete a row using a prepared statement. The following
> statement is simply ignored:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = ?}}
> This happens with JDBC-Thin and with ODBC so I suspect that the cluster gets
> the correct data but handles it wrong. By adding an always-true-condition it
> works as expected:
> {{DELETE}} {{FROM}} {{AnyTable WHERE}} {{id = id AND}} {{id = ?}}
> I tested with a very simple table that was created with:
> {{CREATE TABLE testtable (}}
> {{ "ID" NUMBER(19,0),}}
> {{ "VALUE" VARCHAR2(255 CHAR),}}
> {{ PRIMARY KEY (ID)}}
> {{) WITH "template=replicated,cache_name=testtable"}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods
[
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814623#comment-16814623
]
Nikolai Kulagin commented on IGNITE-9160:
-
[~dpavlov], I agree with your comment and fix it soon.
> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object
> cannot be cast to
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> Or NPE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
> return false;{code}
> + List of classes with similar problems: +
> * *GridTopic$T1-T8* - NPE
> * *GridCachePreloadLifecycleAbstractTest -* NPE
> * *GridDhtPartitionFullMap -* NPE and CCE
> * *GridDhtPartitionMap -* NPE and CCE
> * *OptimizedMarshallerSelfTest -* NPE and CCE
> * *GatewayProtectedCacheProxy -* NPE and CCE
> * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
> * *GridCacheDistributedQueryManager -* NPE and CCE
> * *GridServiceMethodReflectKey -* NPE and CCE
> * *GridListSetSelfTest -* NPE and CCE
> * *GridTestKey -* NPE and CCE
> * *GridCacheMvccCandidate -* CCE
> * *GridDhtPartitionExchangeId -* CCE
> * *GridTuple6 -* CCE
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814617#comment-16814617
]
Alexandr Shapkin commented on IGNITE-7101:
--
[~ptupitsyn] done
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7538) Update several maven plugins version for Java 9 compilation
[ https://issues.apache.org/jira/browse/IGNITE-7538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814595#comment-16814595 ] Dmitriy Pavlov commented on IGNITE-7538: [~vveider] branch is quite old, so TC bot complains about a number of failed tests. Could you please merge current master to your branch? so TC Bot can generate a green VISA using re-run. > Update several maven plugins version for Java 9 compilation > --- > > Key: IGNITE-7538 > URL: https://issues.apache.org/jira/browse/IGNITE-7538 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Critical > > * rat plugin > * flat plugin > * java plugin -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11721) IgniteJdbcDriver with streaming enabled doesn't use IgniteDataStreamer on executeBatch
Anton Kurbanov created IGNITE-11721: --- Summary: IgniteJdbcDriver with streaming enabled doesn't use IgniteDataStreamer on executeBatch Key: IGNITE-11721 URL: https://issues.apache.org/jira/browse/IGNITE-11721 Project: Ignite Issue Type: Bug Components: jdbc, streaming Affects Versions: 2.7 Reporter: Anton Kurbanov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11392) Improve LRT diagnostic messages
[
https://issues.apache.org/jira/browse/IGNITE-11392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814588#comment-16814588
]
Ivan Rakov commented on IGNITE-11392:
-
[~Denis Chudov],
1. I propose to throttle with lrtDumpLimiter only logic that sends and prints
stack trace from near node. Logic that prints current state of LRTs should be
kept as is.
2. Catch clauses should be on the separate line.
{code:java}
} catch (Exception e) { // Incorrect
{code}
3. IDEA suggests to replace "new StackTraceElement[0]" with constant, I tend to
agree.
4. Warning message is not quite correct:
{code:java}
U.warn(diagnosticLog, "Could not receive dump from transaction owner near node:
" + e.getMessage());
{code}
We can't "receive" anything in this try block as we just trigger asynchronous
computation. "Can't send" would be more honest.
5. Let's mention any transaction identifier (e.g. xid or nearXidVersion) in
this message:
{code:java}
if (traceDump != null)
U.warn(diagnosticLog, traceDump);
{code}
It would be easier to analyze trace dump messages in log afterwards.
6. Maybe inheritdoc instead of blank javadoc?
{code:java}
/** */
@Override public void run() {
((IgniteEx)ignite)
.context()
.cache()
.context()
.tm()
.setTxOwnerDumpRequestsAllowed(allowed);
{code}
> Improve LRT diagnostic messages
> ---
>
> Key: IGNITE-11392
> URL: https://issues.apache.org/jira/browse/IGNITE-11392
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Assignee: Denis Chudov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently we print out only local information about long-running
> transactions. This makes it hard to understand the cause of the LRT when an
> ACTIVE transaction is initiated by a client in a large system and is not
> being committed.
> Given that a primary node knows the near node ID, we can send a diagnostic
> message to the near node for an ACTIVE transaction, find the thread that
> started the transaction and dump it's stack, so the server node logs can at
> least give an idea why the transaction is not being committed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11043) CPP Thin: Improve Best Effort Affinity for C++ thin client
[
https://issues.apache.org/jira/browse/IGNITE-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814586#comment-16814586
]
Igor Sapego commented on IGNITE-11043:
--
[~vozerov] regarding connection failure logic - I believe it should be next big
ticket to unify how we deal with connections in all clients. Currently, the
logic is simple - if thin client have a connection failure it invalidates
connection and throws an exception. In my opinion, we can improve user
experience here:
1. We should handle cluster connections in background asynchronously.
2. We can safely re-run read-only operations (such as {{cache.get()}}) without
throwing exception.
> CPP Thin: Improve Best Effort Affinity for C++ thin client
> --
>
> Key: IGNITE-11043
> URL: https://issues.apache.org/jira/browse/IGNITE-11043
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.7
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: iep-23
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients]
> was updated recently, and we need to implement described changes in C++
> thin client.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-11669) Research/test reflection based approach for creating direct buffers
[ https://issues.apache.org/jira/browse/IGNITE-11669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov resolved IGNITE-11669. - Resolution: Fixed The new alternative approach for creating byte buffers works, all tests passed. Changes will be merged under parent ticket [IGNITE-11600] > Research/test reflection based approach for creating direct buffers > --- > > Key: IGNITE-11669 > URL: https://issues.apache.org/jira/browse/IGNITE-11669 > Project: Ignite > Issue Type: Sub-task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > In 2.7.5 discussion > https://lists.apache.org/thread.html/e575a96bd1eb2fe323006314c15f9fcce7400d56b8ba7a5587ebe44c@%3Cdev.ignite.apache.org%3E > Ivan Pavluchin proposed a simple fix for the byte buffer creation problem: > https://lists.apache.org/thread.html/84a35e720af7a0af849685d6abfd7d80a72eab9d7513106262568afa@%3Cdev.ignite.apache.org%3E > It is necessary to test this approach (probably enforcing to apply it for all > Javas) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[
https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814558#comment-16814558
]
Ivan Pavlukhin commented on IGNITE-11708:
-
[~ivanan.fed], the problem seems to be a mistake in
{code}
private final TestRule rulePrivate = (base, description) -> new Statement() {
@Override public void evaluate() {
assert getName() != null : "getName returned null";
testsCfg = testsCfgInjected;
}
};
{code}
It simply does not call {{base.evaluate}} inside.
But also I suggest to address following items as well:
# Fix rules execution order for {{IgniteConfigVariationsAbstractTest}}.
# Unignore ignored tests.
# Add code making sure that _variation_ tests are really executed but not
skipped.
# Pay attention to other _variation_ tests. I saw that {{LegacyLifecycleTest}}
used {{@BeforeClass}} annotation but an annotated methods was not executed.
> Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
>
>
> Key: IGNITE-11708
> URL: https://issues.apache.org/jira/browse/IGNITE-11708
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that test classes that extend from
> IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test
> annotation.
> It is easy to check: if throw exception in any test methods, nothing will
> happen.
> Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1],
> maybe it destroys existing test workflow.
> [1]
> https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814552#comment-16814552
]
Ivan Pavlukhin commented on IGNITE-11412:
-
[~ivanan.fed], I agree to proceed with {{IgniteConfigVariationsAbstractTest}}
in a separate ticket. I think that we can proceed with merge as long as green
visa is ready.
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814541#comment-16814541
]
Ivan Fedotov commented on IGNITE-11412:
---
[~Pavlukhin], it really looks like {{GridAbstractTest#runRule}} must be
replaced by {{nameAndRunRulesChain}} in {{IgniteConfigVariationsAbstractTest}},
according to the master branch, but it does not fix {{LegacyLifecycleTest}}. I
did replacement in the last commit and marked failed test as {{@Ignore}}. Now
the order is the following:
{noformat}
GridAbstractTest nameRule
GridAbstractTest runRule
IgniteConfigVariationsAbstractTest rulePrivate
{noformat}
I tried to check an order of rules execution in master and got interesting
results:
{noformat}
GridAbstractTest nameRule
IgniteConfigVariationsAbstractTest rulePrivate
{noformat}
It is clear from output that test does not run. This problem must be resolved
in a separate ticket since it relates to the master branch, do you think so?
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9160) FindBugs: NPE and CCE on equals() methods
[
https://issues.apache.org/jira/browse/IGNITE-9160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814527#comment-16814527
]
Dmitriy Pavlov commented on IGNITE-9160:
I'm not sure I agree with the fix because of instance of usages. I think it is
better to use X.class==x.getClass(). It does not allow to subclasses to be
equal to current object. Please change instanceofs to getClass.
> FindBugs: NPE and CCE on equals() methods
> -
>
> Key: IGNITE-9160
> URL: https://issues.apache.org/jira/browse/IGNITE-9160
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Nikolai Kulagin
>Assignee: Nikolai Kulagin
>Priority: Minor
> Labels: newbie
> Fix For: 2.8
>
>
> Some classes have Incorrect equals() method:
> {code:java}
> // GridDhtPartitionMap.java
> @Override public boolean equals(Object o) {
> if (this == o)
> return true;
> GridDhtPartitionMap other = (GridDhtPartitionMap)o;
> return other.nodeId.equals(nodeId) && other.updateSeq == updateSeq;
> }{code}
> In this case, we can get CCE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(new Object());
> --
> Exception in thread "main" java.lang.ClassCastException: java.lang.Object
> cannot be cast to
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:319)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> Or NPE
> {code:java}
> GridDhtPartitionMap gridDhtPartMap = new GridDhtPartitionMap();
> gridDhtPartMap.equals(null);
> --
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionMap.equals(GridDhtPartitionMap.java:321)
> at ru.zzzadruga.Ignite.main(Ignite.java:9){code}
> The following code will prevent this
> {code:java}
> if (o == null || getClass() != o.getClass())
> return false;{code}
> + List of classes with similar problems: +
> * *GridTopic$T1-T8* - NPE
> * *GridCachePreloadLifecycleAbstractTest -* NPE
> * *GridDhtPartitionFullMap -* NPE and CCE
> * *GridDhtPartitionMap -* NPE and CCE
> * *OptimizedMarshallerSelfTest -* NPE and CCE
> * *GatewayProtectedCacheProxy -* NPE and CCE
> * *GridNearOptimisticTxPrepareFuture -* NPE and CCE
> * *GridCacheDistributedQueryManager -* NPE and CCE
> * *GridServiceMethodReflectKey -* NPE and CCE
> * *GridListSetSelfTest -* NPE and CCE
> * *GridTestKey -* NPE and CCE
> * *GridCacheMvccCandidate -* CCE
> * *GridDhtPartitionExchangeId -* CCE
> * *GridTuple6 -* CCE
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11649) Java thin client: ReliableChannel is not so reliable
[
https://issues.apache.org/jira/browse/IGNITE-11649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814504#comment-16814504
]
Alexey Kukushkin commented on IGNITE-11649:
---
I reviewed the approved the changes without any comments.
> Java thin client: ReliableChannel is not so reliable
>
>
> Key: IGNITE-11649
> URL: https://issues.apache.org/jira/browse/IGNITE-11649
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When only one server address is used ReliableChannel don't recover after
> failure.
> Reproducer:
> {code:java}
> public void testSingleNodeFailover() throws Exception {
> try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
> IgniteClient client = Ignition.startClient(new ClientConfiguration()
> .setAddresses(cluster.clientAddresses().iterator().next()))
> ) {
> ObjectName mbeanName =
> U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
> "ClientListenerProcessor");
> ClientProcessorMXBean mxBean =
> MBeanServerInvocationHandler.newProxyInstance(
> ManagementFactory.getPlatformMBeanServer(), mbeanName,
> ClientProcessorMXBean.class,true);
> ClientCache cache = client.createCache("cache");
> // Before fail.
> cache.put(0, 0);
> // Fail.
> mxBean.dropAllConnections();
> try {
> cache.put(0, 0);
> }
> catch (Exception expected) {
> // No-op.
> }
> // Recover after fail.
> cache.put(0, 0);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11720) Document new SQL system view "COLUMNS"
[ https://issues.apache.org/jira/browse/IGNITE-11720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11720: -- Component/s: sql > Document new SQL system view "COLUMNS" > -- > > Key: IGNITE-11720 > URL: https://issues.apache.org/jira/browse/IGNITE-11720 > Project: Ignite > Issue Type: Task > Components: documentation, sql >Affects Versions: 2.7 >Reporter: Taras Ledkov >Priority: Major > Fix For: 2.8 > > > See the ticket IGNITE-11434 for list of view's columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11720) Document new SQL system view "COLUMNS"
Taras Ledkov created IGNITE-11720: - Summary: Document new SQL system view "COLUMNS" Key: IGNITE-11720 URL: https://issues.apache.org/jira/browse/IGNITE-11720 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 2.7 Reporter: Taras Ledkov Fix For: 2.8 See the ticket IGNITE-11434 for list of view's columns. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814477#comment-16814477
]
Ignite TC Bot commented on IGNITE-11434:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3516966buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_NAME | string | Column name |
> | ORDINAL_POSITION | int | Column ordinal. Starts with 1 |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | DATA_TYPE | string | SQL data type |
> | CHARACTER_LENGTH | int | Size for char CAHR and VARCHAR types |
> | NUMERIC_PRECISION | int | Precision for numeric types |
> | NUMERIC_SCALE | int | Scale for numeric types |
> | IS_AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> | IS_HIDDEN | boolean | {{true}} for hidden _ley nad _val columns. {{false}}
> for all columns available by asterisk mask |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11719) Document cluster read-only mode
Sergey Antonov created IGNITE-11719: --- Summary: Document cluster read-only mode Key: IGNITE-11719 URL: https://issues.apache.org/jira/browse/IGNITE-11719 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Sergey Antonov Assignee: Artem Budnikov Fix For: 2.8 We should document cluster wide read-only mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814458#comment-16814458
]
Sergey Antonov commented on IGNITE-10344:
-
[~Denis Chudov] Code looks good for me!
[~ivan.glukos] Please review changes too!
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814449#comment-16814449
]
Denis Chudov commented on IGNITE-10344:
---
[~antonovsergey93] fixed
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814440#comment-16814440
]
Ivan Pavlukhin commented on IGNITE-11412:
-
[~ivanan.fed], It seems that a little problem was introduced in this patch. It
is caused by reshuffling _rules_ execution. Currently it affects only
{{IgniteConfigVariationsAbstractTest}} subclasses. I checked an order of rules
execution (via prints) with the patch and observed a following sequence:
{code}
GridAbstractTest runRule
IgniteConfigVariationsAbstractTest rulePrivate
GridAbstractTest nameRule
{code}
And it looks really weird and completely not expected for me! And as I see
_protected_ {{GridAbstractTest#runRule}} leads us to such trouble. And I do not
like to leave it for a separate ticket because a problem was just introduced in
current one. Can we use {{nameAndRunRulesChain}} in
{{IgniteConfigVariationsAbstractTest}} to wrap it with {{rulePrivate}}? Will it
do the trick?
And if something will fail still then you can mark it with {{@Ignore}}
annotation.
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11411) Remove tearDown, setUp from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11411: -- Fix Version/s: 2.8 > Remove tearDown, setUp from JUnit3TestLegacySupport > --- > > Key: IGNITE-11411 > URL: https://issues.apache.org/jira/browse/IGNITE-11411 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > TearDown and setUp methods are deprecated for JUnit 4+ version. It is > necessary to replace them with appropriate methods, marked by @Before and > @After annotations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-11124) CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom
[ https://issues.apache.org/jira/browse/IGNITE-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim closed IGNITE-11124. - > CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover > sometimes throwing oom > - > > Key: IGNITE-11124 > URL: https://issues.apache.org/jira/browse/IGNITE-11124 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > This test sometimes throwing OOM it happens because of IgniteTxManager::idMap > contains 2 millions of instances of GridNearTxLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11124) CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover sometimes throwing oom
[ https://issues.apache.org/jira/browse/IGNITE-11124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stepachev Maksim resolved IGNITE-11124. --- Resolution: Duplicate > CacheContinuousQueryAsyncFailoverMvccTxSelfTest::testMultiThreadedFailover > sometimes throwing oom > - > > Key: IGNITE-11124 > URL: https://issues.apache.org/jira/browse/IGNITE-11124 > Project: Ignite > Issue Type: Improvement >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > This test sometimes throwing OOM it happens because of IgniteTxManager::idMap > contains 2 millions of instances of GridNearTxLocal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11718) Authorizing of SERVICE_INVOKE permission
Denis Garus created IGNITE-11718: Summary: Authorizing of SERVICE_INVOKE permission Key: IGNITE-11718 URL: https://issues.apache.org/jira/browse/IGNITE-11718 Project: Ignite Issue Type: Improvement Affects Versions: 2.7 Reporter: Denis Garus We authorize SERVICE_INVOKE only once on creation of service instance however, we have to authorize SERVICE_INVOKE whenever an operation is invoked on the service instance. If we change some permissions in runtime right after a client got instance, it doesn't see those changes. The scenario: * Client A creates a service instance B. * Administrator forbids invocation of service B to client A. * As long as client A keeps service instance, it can invoke any methods of service B. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11043) CPP Thin: Improve Best Effort Affinity for C++ thin client
[ https://issues.apache.org/jira/browse/IGNITE-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814404#comment-16814404 ] Vladimir Ozerov commented on IGNITE-11043: -- [~isapego], also we need to make sure that connection failure logic is tests thoroughly. > CPP Thin: Improve Best Effort Affinity for C++ thin client > -- > > Key: IGNITE-11043 > URL: https://issues.apache.org/jira/browse/IGNITE-11043 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > was updated recently, and we need to implement described changes in C++ > thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11043) CPP Thin: Improve Best Effort Affinity for C++ thin client
[ https://issues.apache.org/jira/browse/IGNITE-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814399#comment-16814399 ] Vladimir Ozerov commented on IGNITE-11043: -- [~isapego], Java part looks good to me except of several minor styling issues (unused imports, missing blank lines, etc). Please review CPP part with [~alapin] and/or [~ptupitsyn]. We need to pay especial attention to caching logic (copy-on-write, no locking on hot path) and to test coverage. > CPP Thin: Improve Best Effort Affinity for C++ thin client > -- > > Key: IGNITE-11043 > URL: https://issues.apache.org/jira/browse/IGNITE-11043 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > was updated recently, and we need to implement described changes in C++ > thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Fedotov updated IGNITE-11708: -- Summary: Unable to run tests in IgniteConfigVariationsAbstractTest subclasses (was: Unable to run tests with IgniteConfigVariationsAbstractTest extension) > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9305) Wrong off-heap size is reported for a node
[
https://issues.apache.org/jira/browse/IGNITE-9305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814374#comment-16814374
]
Dmitriy Pavlov commented on IGNITE-9305:
[~Pavlukhin], I think no, because tickets are slightly different. If we will
agree that Page Memory regions should not be used, then IGNITE-5583 may be
closed as won't fix
> Wrong off-heap size is reported for a node
> --
>
> Key: IGNITE-9305
> URL: https://issues.apache.org/jira/browse/IGNITE-9305
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.6
>Reporter: Denis Magda
>Assignee: Pavel Pereslegin
>Priority: Blocker
> Fix For: 2.7
>
>
> Was troubleshooting an Ignite deployment today and couldn't find out from the
> logs what was the actual off-heap space used.
> Those were the given memory resoures (Ignite 2.6):
> {code}
> [2018-08-16 15:07:49,961][INFO ][main][GridDiscoveryManager] Topology
> snapshot [ver=1, servers=1, clients=0, CPUs=64, offheap=30.0GB, heap=24.0GB]
> {code}
> And that weird stuff was reported by the node (pay attention to the last
> line):
> {code}
> [2018-08-16 15:45:50,211][INFO
> ][grid-timeout-worker-#135%cluster_31-Dec-2017%][IgniteKernal%cluster_31-Dec-2017]
>
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=c033026e, name=cluster_31-Dec-2017, uptime=00:38:00.257]
> ^-- H/N/C [hosts=1, nodes=1, CPUs=64]
> ^-- CPU [cur=0.03%, avg=5.54%, GC=0%]
> ^-- PageMemory [pages=6997377]
> ^-- Heap [used=9706MB, free=61.18%, comm=22384MB]
> ^-- Non heap [used=144MB, free=-1%, comm=148MB] - this line is always the
> same!
> {code}
> Had to change the code by using
> {code}dataRegion.getPhysicalMemoryPages(){code} to find out that actual
> off-heap usage size was
> {code}
> >>> Physical Memory Size: 28651614208 => 27324 MB, 26 GB
> {code}
> The logs have to report the following instead:
> {code}
> ^-- Off-heap {Data Region 1} [used={dataRegion1.getPhysicalMemorySize()},
> free=X%, comm=dataRegion1.maxSize()]
> ^-- Off-heap {Data Region 2} [used={dataRegion2.getPhysicalMemorySize()},
> free=X%, comm=dataRegion2.maxSize()]
> {code}
> If Ignite persistence is enabled then the following extra lines have to be
> added to see the disk used space:
> {code}
> ^-- Ignite persistence {Data Region 1}:
> used={dataRegion1.getTotalAllocatedSize() -
> dataRegion1.getPhysicalMemorySize()}
> ^-- Ignite persistence {Data Region 2}
> [used={dataRegion2.getTotalAllocatedSize() -
> dataRegion2.getPhysicalMemorySize()}]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10344) Speed up cleanupRestoredCaches
[
https://issues.apache.org/jira/browse/IGNITE-10344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814360#comment-16814360
]
Sergey Antonov commented on IGNITE-10344:
-
[~Denis Chudov] I left comments in PR
> Speed up cleanupRestoredCaches
> --
>
> Key: IGNITE-10344
> URL: https://issues.apache.org/jira/browse/IGNITE-10344
> Project: Ignite
> Issue Type: Improvement
>Reporter: Pavel Voronkin
>Assignee: Denis Chudov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> if (!cctx.kernalContext().clientNode() && !isLocalNodeInBaseline())
> { // Stop all recovered caches and groups.
> cctx.cache().onKernalStopCaches(true); cctx.cache().stopCaches(true);
> cctx.database().cleanupRestoredCaches(); // Set initial node started marker.
> cctx.database().nodeStart(null); }
> If we have 100 cache groups we spent a lot of time about 36sec to
> cleanupRestoredCaches().
> We need to speed up this phase and add metrics on this.
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11717) Web console: project generation runtime error caused by IGFS
Ilya Borisov created IGNITE-11717: - Summary: Web console: project generation runtime error caused by IGFS Key: IGNITE-11717 URL: https://issues.apache.org/jira/browse/IGNITE-11717 Project: Ignite Issue Type: Bug Components: wizards Reporter: Ilya Borisov Assignee: Vasiliy Sisko Attachments: image-2019-04-10-17-52-48-599.png *What happens:* Runtime error in console. !image-2019-04-10-17-52-48-599.png! How to reproduce: 1. Go to cluster configuration/create igfs. 2. Choose "Caching" FS factory. 3. Choose "Chained" user name mapper. 4. Open new mapper sub form, choose custom. 5. Change FS factory a couple of time, change it back to "Caching". 6. Do the same with with "Name mapper" select, change it back to "Custom". 7. If the error does not happen, play around by changing other select values. *Expected behavior:* Run time error should not happen. This happens in master. [~vsisko] I think you should look into why `bean` is `null` or handle this case gracefully. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11657) Stripe Threads Deadlock on Cache.putAll(Map)
[
https://issues.apache.org/jira/browse/IGNITE-11657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16812882#comment-16812882
]
Alexander Sterligov edited comment on IGNITE-11657 at 4/10/19 11:01 AM:
We're seeing same issue on 2.7.0 with putAllAsync. Cache is atomic, partitioned
and backups = 0. The workaround is to use iterative put.
was (Author: sterligovak):
We're seeing same issue on 2.7.0 with putAllAsync. Cache is atomic, partitioned
and backups = 0. The workaround is to move to iterative put.
> Stripe Threads Deadlock on Cache.putAll(Map)
>
>
> Key: IGNITE-11657
> URL: https://issues.apache.org/jira/browse/IGNITE-11657
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.5
>Reporter: Gaurav Aggarwal
>Priority: Major
>
> We have been seeing some consistent Deadlocks with Ignite Latest versions, as
> putAll tries to lock all the keys before updating them.
>
> As per the documentation (below) putAll should be Equivalent to individual
> iterative puts and these individual puts should behave atomically but not the
> entire pull, But the error logs pasted further below seem to suggest otherwise
>
> *putAll Documentation*
> h5. void javax.cache.Cache.putAll(Map map)
> Copies all of the entries from the specified map to the {{Cache}}.
> The effect of this call is equivalent to that of calling {{put(k, v)}} on
> this cache once for each mapping from key {{k}} to value {{v}} in the
> specified map.
> The order in which the individual puts occur is undefined.
> The behavior of this operation is undefined if entries in the cache
> corresponding to entries in the map are modified or removed while this
> operation is in progress. or if map is modified while the operation is in
> progress.
> In Default Consistency mode, individual puts occur atomically but not the
> entire putAll. Listeners may observe individual updates.
>
>
> *Error Log suggesting otherwise*
>
> Deadlock: true
> Completed: 12808
> Thread [name="sys-stripe-3-#4%VPS%", id=27, state=WAITING, blockCnt=3,
> waitCnt=121340]
> Lock [object=java.util.concurrent.locks.ReentrantLock$NonfairSync@138205af,
> ownerName=sys-stripe-26-#27%VPS%, ownerId=50]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
> at
> java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
> at
> o.a.i.i.processors.cache.GridCacheMapEntry.lockEntry(GridCacheMapEntry.java:4272)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2848)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1706)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateRequest(GridDhtAtomicCache.java:3056)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$400(GridDhtAtomicCache.java:130)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:266)
> at
> o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$5.apply(GridDhtAtomicCache.java:261)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1054)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
> at
> o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
> at
> o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
> at
> o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:125)
> at
> o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
[jira] [Commented] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814318#comment-16814318 ] Dmitriy Govorukhin commented on IGNITE-11684: - [~ibessonov]Thanks, merged to master. > CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky > > > Key: IGNITE-11684 > URL: https://issues.apache.org/jira/browse/IGNITE-11684 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E] > > Problem occurs when two optimistic transactions are being > executed from the same client with near cache, when one of transaction > removes key and another updates. > In this scenario near node can be removed from "readers" list if "remove" > transaction was completed before "update" transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11706) DistributedMetaStoragePersistentTest.testConflictingData is flaky in zookeeper suite.
[ https://issues.apache.org/jira/browse/IGNITE-11706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11706: Fix Version/s: 2.8 > DistributedMetaStoragePersistentTest.testConflictingData is flaky in > zookeeper suite. > - > > Key: IGNITE-11706 > URL: https://issues.apache.org/jira/browse/IGNITE-11706 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4285807788261365029=testDetails_IgniteTests24Java8=%3Cdefault%3E] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11702) GridCacheNearOnlyTopologySelfTest.testNodeLeave is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-11702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814312#comment-16814312 ] Dmitriy Govorukhin commented on IGNITE-11702: - [~ibessonov] LGTM, merged to master. > GridCacheNearOnlyTopologySelfTest.testNodeLeave is flaky. > - > > Key: IGNITE-11702 > URL: https://issues.apache.org/jira/browse/IGNITE-11702 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5748284805523586815=testDetails] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11702) GridCacheNearOnlyTopologySelfTest.testNodeLeave is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-11702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11702: Fix Version/s: 2.8 > GridCacheNearOnlyTopologySelfTest.testNodeLeave is flaky. > - > > Key: IGNITE-11702 > URL: https://issues.apache.org/jira/browse/IGNITE-11702 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5748284805523586815=testDetails] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11716) Web console: can't select cluster memory eviction mode
[ https://issues.apache.org/jira/browse/IGNITE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vasiliy Sisko reassigned IGNITE-11716: -- Assignee: Vasiliy Sisko (was: Alexey Kuznetsov) > Web console: can't select cluster memory eviction mode > -- > > Key: IGNITE-11716 > URL: https://issues.apache.org/jira/browse/IGNITE-11716 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: image-2019-04-10-17-02-17-310.png > > Time Spent: 10m > Remaining Estimate: 0h > > What happens: > Memory eviction mode select has no options to choose from and there's an > error in console. > !image-2019-04-10-17-02-17-310.png! > Expected behavior: > The error should not happen, user should be able to select eviction mode. > Note: select configuration version 2.1 to see "memory" section in advanced > cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11716) Web console: can't select cluster memory eviction mode
[ https://issues.apache.org/jira/browse/IGNITE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov reassigned IGNITE-11716: - Assignee: Alexey Kuznetsov (was: Ilya Borisov) [~kuaw26] please review. The issue was caused by a minor typo in Pug template. > Web console: can't select cluster memory eviction mode > -- > > Key: IGNITE-11716 > URL: https://issues.apache.org/jira/browse/IGNITE-11716 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: image-2019-04-10-17-02-17-310.png > > Time Spent: 10m > Remaining Estimate: 0h > > What happens: > Memory eviction mode select has no options to choose from and there's an > error in console. > !image-2019-04-10-17-02-17-310.png! > Expected behavior: > The error should not happen, user should be able to select eviction mode. > Note: select configuration version 2.1 to see "memory" section in advanced > cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11716) Web console: can't select cluster memory eviction mode
[ https://issues.apache.org/jira/browse/IGNITE-11716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814285#comment-16814285 ] Ilya Borisov edited comment on IGNITE-11716 at 4/10/19 10:08 AM: - [~kuaw26] please review and merge. The issue was caused by a minor typo in Pug template. was (Author: klaster_1): [~kuaw26] please review. The issue was caused by a minor typo in Pug template. > Web console: can't select cluster memory eviction mode > -- > > Key: IGNITE-11716 > URL: https://issues.apache.org/jira/browse/IGNITE-11716 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexey Kuznetsov >Priority: Minor > Attachments: image-2019-04-10-17-02-17-310.png > > Time Spent: 10m > Remaining Estimate: 0h > > What happens: > Memory eviction mode select has no options to choose from and there's an > error in console. > !image-2019-04-10-17-02-17-310.png! > Expected behavior: > The error should not happen, user should be able to select eviction mode. > Note: select configuration version 2.1 to see "memory" section in advanced > cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11716) Web console: can't select cluster memory eviction mode
Ilya Borisov created IGNITE-11716: - Summary: Web console: can't select cluster memory eviction mode Key: IGNITE-11716 URL: https://issues.apache.org/jira/browse/IGNITE-11716 Project: Ignite Issue Type: Bug Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Attachments: image-2019-04-10-17-02-17-310.png What happens: Memory eviction mode select has no options to choose from and there's an error in console. !image-2019-04-10-17-02-17-310.png! Expected behavior: The error should not happen, user should be able to select eviction mode. Note: select configuration version 2.1 to see "memory" section in advanced cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11715) Add support for nojmx flag when running Ignite in docker
Kresimir Horvat created IGNITE-11715: Summary: Add support for nojmx flag when running Ignite in docker Key: IGNITE-11715 URL: https://issues.apache.org/jira/browse/IGNITE-11715 Project: Ignite Issue Type: Wish Reporter: Kresimir Horvat Add option to run ignite with -nojmx when running Ignite in docker container. Currently run.sh script doesn't support passing -nojmx option. Desired result is to run ignite with -nojmx flag and possibility of passing JMX_MON as env variable over docker run. More details about problem are described in thread [http://apache-ignite-users.70518.x6.nabble.com/Running-control-sh-in-docker-container-when-JXM-is-started-td27812.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11684) CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11684?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814244#comment-16814244 ] Ivan Bessonov commented on IGNITE-11684: [~agoncharuk] No performance drops were discovered after this fix. I believe that we can merge it. > CacheSerializableTransactionsTest#testGetRemoveTxNearCache2 (and 1) is flaky > > > Key: IGNITE-11684 > URL: https://issues.apache.org/jira/browse/IGNITE-11684 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4876515758596068461=testDetails_IgniteTests24Java8=%3Cdefault%3E] > > Problem occurs when two optimistic transactions are being > executed from the same client with near cache, when one of transaction > removes key and another updates. > In this scenario near node can be removed from "readers" list if "remove" > transaction was completed before "update" transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11696) Create JMX metric for current PME execution time
[ https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814243#comment-16814243 ] Sergey Antonov commented on IGNITE-11696: - [~ezhuravl] I left comments in PR. Please fix it. > Create JMX metric for current PME execution time > > > Key: IGNITE-11696 > URL: https://issues.apache.org/jira/browse/IGNITE-11696 > Project: Ignite > Issue Type: Improvement >Reporter: Evgenii Zhuravlev >Assignee: Evgenii Zhuravlev >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Now PME process can't be monitored from JMX, only from the logs. It makes > sense to show the execution time for the current partition map exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11711) Web console: MS SQL server missing JDBC download link
[ https://issues.apache.org/jira/browse/IGNITE-11711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814227#comment-16814227 ] Ilya Borisov edited comment on IGNITE-11711 at 4/10/19 9:08 AM: Actually, the same happens everywhere form-field__dialect Pug mixin is used. was (Author: klaster_1): Actually, the same happen everywhere form-field__dialect Pug mixin is used. > Web console: MS SQL server missing JDBC download link > - > > Key: IGNITE-11711 > URL: https://issues.apache.org/jira/browse/IGNITE-11711 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: image-2019-04-10-12-54-22-561.png > > > *What happens:* > In configuration / advanced / caches / store if user selects "JDBC Pojo store > factory" and "MS SQL Server" dialect, a link labeled "Download JDBC drivers?" > is displayed. When "oracle" or "IBM" dialects are selected, the link leads to > a proper download page, while "MS" dialect link leads nowhere. > !image-2019-04-10-12-54-22-561.png! > *Expected behavior:* > If there is a download page for MS JDBC driver, add it's URL to JDBC_LINKS > provider. If there's none, maybe don't show the link or show appropriate > plain text? > The issue was reproduced in master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11711) Web console: MS SQL server missing JDBC download link
[ https://issues.apache.org/jira/browse/IGNITE-11711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814227#comment-16814227 ] Ilya Borisov commented on IGNITE-11711: --- Actually, the same happen everywhere form-field__dialect Pug mixin is used. > Web console: MS SQL server missing JDBC download link > - > > Key: IGNITE-11711 > URL: https://issues.apache.org/jira/browse/IGNITE-11711 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: image-2019-04-10-12-54-22-561.png > > > *What happens:* > In configuration / advanced / caches / store if user selects "JDBC Pojo store > factory" and "MS SQL Server" dialect, a link labeled "Download JDBC drivers?" > is displayed. When "oracle" or "IBM" dialects are selected, the link leads to > a proper download page, while "MS" dialect link leads nowhere. > !image-2019-04-10-12-54-22-561.png! > *Expected behavior:* > If there is a download page for MS JDBC driver, add it's URL to JDBC_LINKS > provider. If there's none, maybe don't show the link or show appropriate > plain text? > The issue was reproduced in master. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-11346: -- Assignee: (was: Ivan Bessonov) > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Priority: Minor > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11714) Web console: multiple select items overflow
Ilya Borisov created IGNITE-11714: - Summary: Web console: multiple select items overflow Key: IGNITE-11714 URL: https://issues.apache.org/jira/browse/IGNITE-11714 Project: Ignite Issue Type: Bug Components: wizards Reporter: Ilya Borisov Assignee: Ilya Borisov Attachments: image-2019-04-10-16-00-55-734.png *What happens:* !image-2019-04-10-16-00-55-734.png! *Expected behavior:* Overflow is handled gracefully, value is contained in control. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814216#comment-16814216 ] Ivan Bessonov commented on IGNITE-11346: Hello [~Maxoid], I added a few comments in github PR. There are few other questions that I'd like to ask right here instead: * Is there a way to write a test for this problem? * what about running the existing tests? Please provide bot visa or at least RunAll results. Thank you! > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Priority: Minor > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11346) Remote client authentication failed for the CommandHandler in the case where it optional on the server
[ https://issues.apache.org/jira/browse/IGNITE-11346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-11346: -- Assignee: Ivan Bessonov > Remote client authentication failed for the CommandHandler in the case where > it optional on the server > -- > > Key: IGNITE-11346 > URL: https://issues.apache.org/jira/browse/IGNITE-11346 > Project: Ignite > Issue Type: Bug > Components: clients, security, thin client >Affects Versions: 2.7 >Reporter: Maxim Karavaev >Assignee: Ivan Bessonov >Priority: Minor > > h2. Preposition: > Custom _GridSecurityProcessor_ implementation allows optional authentication. > With other words, if some credentials are presents then authentication > performed, otherwise - not (some restricted SecurityContext returned). > REST API works fine. If credentials are present or the auth request was made > then the auth works as desired, if not - it also works but only for some > authorized requests. > h2. The problem: > _CommandHandler_ which is used for controlling a cluster through the CLI > script _command.sh|bat_ doesn't respect credential parameters and sends auth > request only in case of authentication exception for a regular request. In > the described case of optional authentication it never happens, so the result > always depends on the "default" Permissions. > h2. Possible solution: > Change _GridClientNioTcpConnection_ to always send first an auth request in > case of provided credentials. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11412) Actualize JUnit3TestLegacySupport class
[
https://issues.apache.org/jira/browse/IGNITE-11412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814207#comment-16814207
]
Ivan Fedotov commented on IGNITE-11412:
---
[~Pavlukhin], I am not sure that null assertion for {{getName()}} is necessary
here - such assert already exists in {{GridAbstractTest}} [1]. Moreover,
{{testsCfg}} and {{testsCfgInjected}} also already initialized [2] as
{{dummyCfg()}}.
I think other {{variation}} tests are green because there are no assertions
that check test work in {{before/after}} test conditions like in
{{LegacyLifecycleTest}}. So such tests are successfully like empty code. I
inserted throwing exception in methods under {{@Test}} annotation in
{{IgniteConfigVariationsAbstractTest}} subclasses and nothing happened.
According to the current ticket, I will mark failed tests as {{Ingnore}},
right? Do you have any other suggestions to this patch?
[1]
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L183]
[2]
[https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L78]
> Actualize JUnit3TestLegacySupport class
> ---
>
> Key: IGNITE-11412
> URL: https://issues.apache.org/jira/browse/IGNITE-11412
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Specify JUnit3TestLegacySupport class documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11713) Web console: cluster configuration events content fit issue
[ https://issues.apache.org/jira/browse/IGNITE-11713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11713: -- Attachment: screenshot-1.png > Web console: cluster configuration events content fit issue > --- > > Key: IGNITE-11713 > URL: https://issues.apache.org/jira/browse/IGNITE-11713 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: image-2019-04-10-15-46-39-859.png, screenshot-1.png > > > *What happens:* > In master, cluster configuration (2.8) / events / local events listeners > individual event listnered item sub form controls don't fit well when > viewport width is under 1420px: > !image-2019-04-10-15-46-39-859.png! > *Expected behavior:* > Form controls should be laid out such they look don't overflow/wrap. > As a solution, I propose to put each control into separate row. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11713) Web console: cluster configuration events content fit issue
[ https://issues.apache.org/jira/browse/IGNITE-11713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11713: -- Description: *What happens:* In master, cluster configuration (2.8) / events / local events listeners individual event listnered item sub form controls don't fit well when viewport width is under 1420px: !image-2019-04-10-15-46-39-859.png! !screenshot-1.png! *Expected behavior:* Form controls should be laid out such they look don't overflow/wrap. As a solution, I propose to put each control into separate row. was: *What happens:* In master, cluster configuration (2.8) / events / local events listeners individual event listnered item sub form controls don't fit well when viewport width is under 1420px: !image-2019-04-10-15-46-39-859.png! *Expected behavior:* Form controls should be laid out such they look don't overflow/wrap. As a solution, I propose to put each control into separate row. > Web console: cluster configuration events content fit issue > --- > > Key: IGNITE-11713 > URL: https://issues.apache.org/jira/browse/IGNITE-11713 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: image-2019-04-10-15-46-39-859.png, screenshot-1.png > > > *What happens:* > In master, cluster configuration (2.8) / events / local events listeners > individual event listnered item sub form controls don't fit well when > viewport width is under 1420px: > !image-2019-04-10-15-46-39-859.png! > !screenshot-1.png! > *Expected behavior:* > Form controls should be laid out such they look don't overflow/wrap. > As a solution, I propose to put each control into separate row. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11713) Web console: cluster configuration events content fit issue
Ilya Borisov created IGNITE-11713: - Summary: Web console: cluster configuration events content fit issue Key: IGNITE-11713 URL: https://issues.apache.org/jira/browse/IGNITE-11713 Project: Ignite Issue Type: Bug Components: wizards Reporter: Ilya Borisov Assignee: Vasiliy Sisko Attachments: image-2019-04-10-15-46-39-859.png *What happens:* In master, cluster configuration (2.8) / events / local events listeners individual event listnered item sub form controls don't fit well when viewport width is under 1420px: !image-2019-04-10-15-46-39-859.png! Expected behavior: Form controls should be laid out such they look don't overflow/wrap. As a solution, I propose to put each control into separate row. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11713) Web console: cluster configuration events content fit issue
[ https://issues.apache.org/jira/browse/IGNITE-11713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Borisov updated IGNITE-11713: -- Description: *What happens:* In master, cluster configuration (2.8) / events / local events listeners individual event listnered item sub form controls don't fit well when viewport width is under 1420px: !image-2019-04-10-15-46-39-859.png! *Expected behavior:* Form controls should be laid out such they look don't overflow/wrap. As a solution, I propose to put each control into separate row. was: *What happens:* In master, cluster configuration (2.8) / events / local events listeners individual event listnered item sub form controls don't fit well when viewport width is under 1420px: !image-2019-04-10-15-46-39-859.png! Expected behavior: Form controls should be laid out such they look don't overflow/wrap. As a solution, I propose to put each control into separate row. > Web console: cluster configuration events content fit issue > --- > > Key: IGNITE-11713 > URL: https://issues.apache.org/jira/browse/IGNITE-11713 > Project: Ignite > Issue Type: Bug > Components: wizards >Reporter: Ilya Borisov >Assignee: Vasiliy Sisko >Priority: Minor > Attachments: image-2019-04-10-15-46-39-859.png > > > *What happens:* > In master, cluster configuration (2.8) / events / local events listeners > individual event listnered item sub form controls don't fit well when > viewport width is under 1420px: > !image-2019-04-10-15-46-39-859.png! > *Expected behavior:* > Form controls should be laid out such they look don't overflow/wrap. > As a solution, I propose to put each control into separate row. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11668) OSGI: Self-imported package causes failure upon Karaf restart
[
https://issues.apache.org/jira/browse/IGNITE-11668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814194#comment-16814194
]
Oleksii Mohylin commented on IGNITE-11668:
--
Package org.apache.ignite.osgi.classloaders was removed from package imports
for ignite-osgi bundle. Pull request is attached.
> OSGI: Self-imported package causes failure upon Karaf restart
> -
>
> Key: IGNITE-11668
> URL: https://issues.apache.org/jira/browse/IGNITE-11668
> Project: Ignite
> Issue Type: Bug
> Components: osgi
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Apache Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've got problem using Ignite 2.7 in Apache Karaf 4.2.0. The problem is
> caused by strange bundle meta of ignite-osgi. It exports package
> org.apache.ignite.osgi.classloaders and imports it at the same time. Here's
> extract from METADATA.MF:
> {noformat}
> Import-Package: org.apache.ignite;version="[2.7,3)",org.apache.ignite.
> configuration;version="[2.7,3)",org.apache.ignite.internal.util;versi
> on="[2.7,3)",org.apache.ignite.internal.util.tostring;version="[2.7,3
> )",org.apache.ignite.internal.util.typedef.internal;version="[2.7,3)"
> ,org.apache.ignite.osgi.classloaders,org.osgi.framework;version="[1.7
> ,2)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Fragment-Host: org.apache.ignite.ignite-core
> Export-Package: org.apache.ignite.osgi.classloaders;uses:="org.apache.
> ignite.internal.util.tostring,org.osgi.framework";version="2.7.0",org
> .apache.ignite.osgi;uses:="org.apache.ignite,org.apache.ignite.config
> uration,org.apache.ignite.osgi.classloaders,org.osgi.framework";versi
> on="2.7.0"
> {noformat}
> There is no problem with initial installation of my application into Karaf,
> although after Karaf ignite-osgi dependency is not resolved, and this
> exception in log:
> {noformat}
> org.osgi.framework.BundleException: Unable to resolve graphql-core [399](R
> 399.0): missing requirement [graphql-core [399](R 399.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))
> [caused by: Unable to resolve org.apache.ignite.ignite-osgi [432](R 432.0):
> missing requirement [org.apache.ignite.ignite-osgi [432](R 432.0)]
> osgi.wiring.host;
> (&(osgi.wiring.host=org.apache.ignite.ignite-core)(bundle-version>=0.0.0))]
> Unresolved requirements: [[graphql-core [399](R 399.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))]
> {noformat}
> *Proposed solution:*
> remove the self-import by adding instruction to bundle plugin configuration
> in modules/osgi/pom.xml
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
>
>
> org.apache.ignite.ignite-core
>
> !org.apache.ignite.osgi.classloaders,*
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11668) OSGI: Self-imported package causes failure upon Karaf restart
[
https://issues.apache.org/jira/browse/IGNITE-11668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Mohylin updated IGNITE-11668:
-
Environment:
Ignite 2.7
Apache Karaf 4.2.0
> OSGI: Self-imported package causes failure upon Karaf restart
> -
>
> Key: IGNITE-11668
> URL: https://issues.apache.org/jira/browse/IGNITE-11668
> Project: Ignite
> Issue Type: Bug
> Components: osgi
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Apache Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've got problem using Ignite 2.7 in Apache Karaf 4.2.0. The problem is
> caused by strange bundle meta of ignite-osgi. It exports package
> org.apache.ignite.osgi.classloaders and imports it at the same time. Here's
> extract from METADATA.MF:
> {noformat}
> Import-Package: org.apache.ignite;version="[2.7,3)",org.apache.ignite.
> configuration;version="[2.7,3)",org.apache.ignite.internal.util;versi
> on="[2.7,3)",org.apache.ignite.internal.util.tostring;version="[2.7,3
> )",org.apache.ignite.internal.util.typedef.internal;version="[2.7,3)"
> ,org.apache.ignite.osgi.classloaders,org.osgi.framework;version="[1.7
> ,2)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Fragment-Host: org.apache.ignite.ignite-core
> Export-Package: org.apache.ignite.osgi.classloaders;uses:="org.apache.
> ignite.internal.util.tostring,org.osgi.framework";version="2.7.0",org
> .apache.ignite.osgi;uses:="org.apache.ignite,org.apache.ignite.config
> uration,org.apache.ignite.osgi.classloaders,org.osgi.framework";versi
> on="2.7.0"
> {noformat}
> There is no problem with initial installation of my application into Karaf,
> although after Karaf ignite-osgi dependency is not resolved, and this
> exception in log:
> {noformat}
> org.osgi.framework.BundleException: Unable to resolve graphql-core [399](R
> 399.0): missing requirement [graphql-core [399](R 399.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))
> [caused by: Unable to resolve org.apache.ignite.ignite-osgi [432](R 432.0):
> missing requirement [org.apache.ignite.ignite-osgi [432](R 432.0)]
> osgi.wiring.host;
> (&(osgi.wiring.host=org.apache.ignite.ignite-core)(bundle-version>=0.0.0))]
> Unresolved requirements: [[graphql-core [399](R 399.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))]
> {noformat}
> *Proposed solution:*
> remove the self-import by adding instruction to bundle plugin configuration
> in modules/osgi/pom.xml
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
>
>
> org.apache.ignite.ignite-core
>
> !org.apache.ignite.osgi.classloaders,*
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11662) Wrong classloader is used to unmarshal joining node data
[
https://issues.apache.org/jira/browse/IGNITE-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Mohylin updated IGNITE-11662:
-
Ignite Flags: (was: Docs Required)
> Wrong classloader is used to unmarshal joining node data
>
>
> Key: IGNITE-11662
> URL: https://issues.apache.org/jira/browse/IGNITE-11662
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a cluster coordinator node is running in Karaf container it cannot
> accept joining requests from other nodes. Problem lies in unability to
> unmarshal joining node data in
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode()
> This line
> {code:java}
> joiningNodeState = marsh.unmarshal((byte[]) discoData.joiningNodeData(),
> Thread.currentThread().getContextClassLoader());{code}
> fails with
> {noformat}
> Error on unmarshalling discovery data from node
> 10.0.2.15,127.0.0.1,172.17.0.1:47501: Failed to find class with given class
> loader for unmarshalling (make sure same versions of all classes are
> available on all nodes or enable peer-class-loading)
> [clsLdr=jdk.internal.loader.ClassLoaders$AppClassLoader@5c0369c4,
> cls=org.apache.ignite.internal.processors.cluster.DiscoveryDataClusterState];
> node is not allowed to join{noformat}
> Apparently problem is wrong classloader returned by
> {code:java}
> Thread.currentThread().getContextClassLoader()){code}
> which is not the one created in IgniteAbstractOsgiContextActivator.start().
> *Proposed fix:*
> use proper way of obtaining classloader:
> {code:java}
> U.resolveClassLoader(ctx.config()){code}
> Like in other places. i.e. in GridClusterStateProcessor.collectGridNodeData().
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11668) OSGI: Self-imported package causes failure upon Karaf restart
[
https://issues.apache.org/jira/browse/IGNITE-11668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Mohylin updated IGNITE-11668:
-
Ignite Flags: (was: Docs Required)
> OSGI: Self-imported package causes failure upon Karaf restart
> -
>
> Key: IGNITE-11668
> URL: https://issues.apache.org/jira/browse/IGNITE-11668
> Project: Ignite
> Issue Type: Bug
> Components: osgi
>Affects Versions: 2.7
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've got problem using Ignite 2.7 in Apache Karaf 4.2.0. The problem is
> caused by strange bundle meta of ignite-osgi. It exports package
> org.apache.ignite.osgi.classloaders and imports it at the same time. Here's
> extract from METADATA.MF:
> {noformat}
> Import-Package: org.apache.ignite;version="[2.7,3)",org.apache.ignite.
> configuration;version="[2.7,3)",org.apache.ignite.internal.util;versi
> on="[2.7,3)",org.apache.ignite.internal.util.tostring;version="[2.7,3
> )",org.apache.ignite.internal.util.typedef.internal;version="[2.7,3)"
> ,org.apache.ignite.osgi.classloaders,org.osgi.framework;version="[1.7
> ,2)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Fragment-Host: org.apache.ignite.ignite-core
> Export-Package: org.apache.ignite.osgi.classloaders;uses:="org.apache.
> ignite.internal.util.tostring,org.osgi.framework";version="2.7.0",org
> .apache.ignite.osgi;uses:="org.apache.ignite,org.apache.ignite.config
> uration,org.apache.ignite.osgi.classloaders,org.osgi.framework";versi
> on="2.7.0"
> {noformat}
> There is no problem with initial installation of my application into Karaf,
> although after Karaf ignite-osgi dependency is not resolved, and this
> exception in log:
> {noformat}
> org.osgi.framework.BundleException: Unable to resolve graphql-core [399](R
> 399.0): missing requirement [graphql-core [399](R 399.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))
> [caused by: Unable to resolve org.apache.ignite.ignite-osgi [432](R 432.0):
> missing requirement [org.apache.ignite.ignite-osgi [432](R 432.0)]
> osgi.wiring.host;
> (&(osgi.wiring.host=org.apache.ignite.ignite-core)(bundle-version>=0.0.0))]
> Unresolved requirements: [[graphql-core [399](R 399.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))]
> {noformat}
> *Proposed solution:*
> remove the self-import by adding instruction to bundle plugin configuration
> in modules/osgi/pom.xml
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
>
>
> org.apache.ignite.ignite-core
>
> !org.apache.ignite.osgi.classloaders,*
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11668) OSGI: Self-imported package causes failure upon Karaf restart
[
https://issues.apache.org/jira/browse/IGNITE-11668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Mohylin reassigned IGNITE-11668:
Assignee: Oleksii Mohylin
> OSGI: Self-imported package causes failure upon Karaf restart
> -
>
> Key: IGNITE-11668
> URL: https://issues.apache.org/jira/browse/IGNITE-11668
> Project: Ignite
> Issue Type: Bug
> Components: osgi
>Affects Versions: 2.7
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I've got problem using Ignite 2.7 in Apache Karaf 4.2.0. The problem is
> caused by strange bundle meta of ignite-osgi. It exports package
> org.apache.ignite.osgi.classloaders and imports it at the same time. Here's
> extract from METADATA.MF:
> {noformat}
> Import-Package: org.apache.ignite;version="[2.7,3)",org.apache.ignite.
> configuration;version="[2.7,3)",org.apache.ignite.internal.util;versi
> on="[2.7,3)",org.apache.ignite.internal.util.tostring;version="[2.7,3
> )",org.apache.ignite.internal.util.typedef.internal;version="[2.7,3)"
> ,org.apache.ignite.osgi.classloaders,org.osgi.framework;version="[1.7
> ,2)"
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
> Fragment-Host: org.apache.ignite.ignite-core
> Export-Package: org.apache.ignite.osgi.classloaders;uses:="org.apache.
> ignite.internal.util.tostring,org.osgi.framework";version="2.7.0",org
> .apache.ignite.osgi;uses:="org.apache.ignite,org.apache.ignite.config
> uration,org.apache.ignite.osgi.classloaders,org.osgi.framework";versi
> on="2.7.0"
> {noformat}
> There is no problem with initial installation of my application into Karaf,
> although after Karaf ignite-osgi dependency is not resolved, and this
> exception in log:
> {noformat}
> org.osgi.framework.BundleException: Unable to resolve graphql-core [399](R
> 399.0): missing requirement [graphql-core [399](R 399.0)]
> osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))
> [caused by: Unable to resolve org.apache.ignite.ignite-osgi [432](R 432.0):
> missing requirement [org.apache.ignite.ignite-osgi [432](R 432.0)]
> osgi.wiring.host;
> (&(osgi.wiring.host=org.apache.ignite.ignite-core)(bundle-version>=0.0.0))]
> Unresolved requirements: [[graphql-core [399](R 399.0)] osgi.wiring.package;
> (&(osgi.wiring.package=org.apache.ignite.osgi.classloaders)(version>=2.7.0)(!(version>=3.0.0)))]
> {noformat}
> *Proposed solution:*
> remove the self-import by adding instruction to bundle plugin configuration
> in modules/osgi/pom.xml
> {code:java}
>
> org.apache.felix
> maven-bundle-plugin
>
>
> org.apache.ignite.ignite-core
>
> !org.apache.ignite.osgi.classloaders,*
>
>
>
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11662) Wrong classloader is used to unmarshal joining node data
[
https://issues.apache.org/jira/browse/IGNITE-11662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleksii Mohylin reassigned IGNITE-11662:
Assignee: Oleksii Mohylin
> Wrong classloader is used to unmarshal joining node data
>
>
> Key: IGNITE-11662
> URL: https://issues.apache.org/jira/browse/IGNITE-11662
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
> Environment: Ignite 2.7
> Karaf 4.2.0
>Reporter: Oleksii Mohylin
>Assignee: Oleksii Mohylin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a cluster coordinator node is running in Karaf container it cannot
> accept joining requests from other nodes. Problem lies in unability to
> unmarshal joining node data in
> org.apache.ignite.internal.processors.cluster.GridClusterStateProcessor.validateNode()
> This line
> {code:java}
> joiningNodeState = marsh.unmarshal((byte[]) discoData.joiningNodeData(),
> Thread.currentThread().getContextClassLoader());{code}
> fails with
> {noformat}
> Error on unmarshalling discovery data from node
> 10.0.2.15,127.0.0.1,172.17.0.1:47501: Failed to find class with given class
> loader for unmarshalling (make sure same versions of all classes are
> available on all nodes or enable peer-class-loading)
> [clsLdr=jdk.internal.loader.ClassLoaders$AppClassLoader@5c0369c4,
> cls=org.apache.ignite.internal.processors.cluster.DiscoveryDataClusterState];
> node is not allowed to join{noformat}
> Apparently problem is wrong classloader returned by
> {code:java}
> Thread.currentThread().getContextClassLoader()){code}
> which is not the one created in IgniteAbstractOsgiContextActivator.start().
> *Proposed fix:*
> use proper way of obtaining classloader:
> {code:java}
> U.resolveClassLoader(ctx.config()){code}
> Like in other places. i.e. in GridClusterStateProcessor.collectGridNodeData().
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11696) Create JMX metric for current PME execution time
[
https://issues.apache.org/jira/browse/IGNITE-11696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814161#comment-16814161
]
Ignite TC Bot commented on IGNITE-11696:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Scala (Visor Console){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3549566]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3549645buildTypeId=IgniteTests24Java8_RunAll]
> Create JMX metric for current PME execution time
>
>
> Key: IGNITE-11696
> URL: https://issues.apache.org/jira/browse/IGNITE-11696
> Project: Ignite
> Issue Type: Improvement
>Reporter: Evgenii Zhuravlev
>Assignee: Evgenii Zhuravlev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now PME process can't be monitored from JMX, only from the logs. It makes
> sense to show the execution time for the current partition map exchange.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11690) .NET: Unable to locate external assembly with enabled peerAssemblyLoading
[ https://issues.apache.org/jira/browse/IGNITE-11690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814152#comment-16814152 ] Pavel Tupitsyn commented on IGNITE-11690: - [~ashapkin] please see the message from TC Bot above. Linux build fails. Also see my comments in the PR. > .NET: Unable to locate external assembly with enabled peerAssemblyLoading > -- > > Key: IGNITE-11690 > URL: https://issues.apache.org/jira/browse/IGNITE-11690 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.7 >Reporter: Alexandr Shapkin >Assignee: Alexandr Shapkin >Priority: Major > Labels: .NET > Time Spent: 20m > Remaining Estimate: 0h > > Original reproducer: > [https://www.dropbox.com/s/xsgqhwjyctyg3o3/Example%20solution.rar?dl=0] With > two server nodes, and a client that spawn a computation with a simple cache > iteration for custom class value > Problem: > If peer assembly loading enabled and no assembly exist for the nodes, then > there is an endless loop: nodes are requesting the assembly from each other > and no one is able to locate it. > As an example of missing dll there could be a > "System.Configuration.Configuration" for the .NET Core app > [https://github.com/dotnet/standard/issues/506] > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11712) SQL: review security check for SQL/DML queries
Roman Kondakov created IGNITE-11712: --- Summary: SQL: review security check for SQL/DML queries Key: IGNITE-11712 URL: https://issues.apache.org/jira/browse/IGNITE-11712 Project: Ignite Issue Type: Improvement Components: sql Reporter: Roman Kondakov Currently the security check (read/write permissions) is carried out during the query execution. It involves some extra actions (like a query registration) which can be avoided if the security check is conducted on the earlier stage of the query execution, for example right away after the parsing. For SELECT queries only read permission should be checked. For INSERT queries without SELECT only write permission should be checked. For UPDATE queries or INSERT queries with SELECT both read and write permissions should be checked. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member
[
https://issues.apache.org/jira/browse/IGNITE-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814125#comment-16814125
]
Pavel Tupitsyn commented on IGNITE-8588:
Looks good, merged to master: {{1a7e62a84619a25777e74fd9f5a3d68e9f5f6248}}.
> .NET: Serialization issue when derived type hides base type member
> --
>
> Key: IGNITE-8588
> URL: https://issues.apache.org/jira/browse/IGNITE-8588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The following class structure causes an exception that is hard to understand
> (when putting instance of B into Ignite cache):
> {code}
> public class A
> {
> public int bob;
> }
> public class B : A
> {
> public int bob;
> }
> {code}
> Exception:
> {code}
> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs
> [type=SubGridsRequestArgument, field1=Filters, field2=Filters,
> fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type,
> BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
> writer, Object o)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)
> at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job,
> BinaryWriter writer)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
> writer)
> at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1
> action, IBinaryStream stream, Marshaller marsh)
> at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
> task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount,
> Action`1 writeAction)
> --- End of inner exception stack trace ---
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
> CancellationToken cancellationToken)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)
> at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
> 107
> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
> 241
> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
> 262
> ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException:
> Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters,
> field2=Filters, fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered,
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814119#comment-16814119
]
Pavel Tupitsyn commented on IGNITE-7101:
[~ashapkin] one last thing: please add a test for Stage property.
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
