[jira] [Closed] (IGNITE-2926) Create GridNearAtomicSingleUpdateFuture for single key-value pair update.
[ https://issues.apache.org/jira/browse/IGNITE-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-2926. --- > Create GridNearAtomicSingleUpdateFuture for single key-value pair update. > - > > Key: IGNITE-2926 > URL: https://issues.apache.org/jira/browse/IGNITE-2926 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Labels: performance > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-2926) Create GridNearAtomicSingleUpdateFuture for single key-value pair update.
[ https://issues.apache.org/jira/browse/IGNITE-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-2926. - Resolution: Fixed > Create GridNearAtomicSingleUpdateFuture for single key-value pair update. > - > > Key: IGNITE-2926 > URL: https://issues.apache.org/jira/browse/IGNITE-2926 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Critical > Labels: performance > Fix For: 1.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2523) Introduce "single put" NEAR update request.
[ https://issues.apache.org/jira/browse/IGNITE-2523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-2523: Fix Version/s: (was: 1.7) 1.6 > Introduce "single put" NEAR update request. > --- > > Key: IGNITE-2523 > URL: https://issues.apache.org/jira/browse/IGNITE-2523 > Project: Ignite > Issue Type: Task > Components: cache >Affects Versions: 1.5.0.final >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov > Labels: performance > Fix For: 1.6 > > > Essentially, in this case we could get rid of all collections and garbage > inside GridNearAtomicUpdateRequest/GridDhtAtomicUpdateRequest. > This should drastically decrease message size and improve performance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249410#comment-15249410 ] Igor Rudyak commented on IGNITE-1371: - Alexey, I merged changes from you review into "ignite-1371" branch. Also made some minor refactoring of Unit tests and added comments regarding commented lines "CassandraHelper.dropTestKeyspaces()" in Load test classes. Also added DDL generator utility. Here is documentation for it: https://github.com/irudyak/ignite/wiki/DDL-generator > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2944) .NET: IIgnite.GetOrCreateNearCache
[
https://issues.apache.org/jira/browse/IGNITE-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249485#comment-15249485
]
Vladimir Ozerov edited comment on IGNITE-2944 at 4/20/16 8:28 AM:
--
Pavel,
All looks fine, but we still missing two methods: {{CreateCache()}} and
{{GetOrCreateCache()}} where second parameter is {{NearCacheConfiguration}}.
Let's implement and test them.
Vladimir.
was (Author: vozerov):
Pavel,
All looks fine, but we still missing two methods: {{CreateCache()}} and
{{GetOrCraeteCache()}} where second parameter is {{NearCacheConfiguration}}.
Let's implement and test them.
Vladimir.
> .NET: IIgnite.GetOrCreateNearCache
> --
>
> Key: IGNITE-2944
> URL: https://issues.apache.org/jira/browse/IGNITE-2944
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Affects Versions: 1.1.4
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
> Labels: community
> Fix For: 1.6
>
>
> Implement IIgnite.GetOrCreateNearCache (at least without EvictionPolicy).
> Eviction policy can be a set of predefined classes (same approach as with
> IpFinder, etc).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2858) Refactoring Domains screen to AngularJS directives and mixins
[ https://issues.apache.org/jira/browse/IGNITE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-2858: --- Issue Type: Task (was: Bug) > Refactoring Domains screen to AngularJS directives and mixins > - > > Key: IGNITE-2858 > URL: https://issues.apache.org/jira/browse/IGNITE-2858 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.6 >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 1.6 > > Attachments: ig-2858-1.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-2858) Refactoring Domains screen to AngularJS directives and mixins
[ https://issues.apache.org/jira/browse/IGNITE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-2858: --- Issue Type: Bug (was: Sub-task) Parent: (was: IGNITE-2047) > Refactoring Domains screen to AngularJS directives and mixins > - > > Key: IGNITE-2858 > URL: https://issues.apache.org/jira/browse/IGNITE-2858 > Project: Ignite > Issue Type: Bug > Components: wizards >Affects Versions: 1.6 >Reporter: Vasiliy Sisko >Assignee: Pavel Konstantinov > Fix For: 1.6 > > Attachments: ig-2858-1.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3031) 'Domain model for SQL query' section shows the old values for new Type
Pavel Konstantinov created IGNITE-3031: -- Summary: 'Domain model for SQL query' section shows the old values for new Type Key: IGNITE-3031 URL: https://issues.apache.org/jira/browse/IGNITE-3031 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov 1) import some types from DB 2) remove all 3) add new type observed: 'Domain model for SQL query' section shows the old values for new Type -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3032) 'Domain model for SQL query' section doesn't expand if 'Fields' contains invalid field
Pavel Konstantinov created IGNITE-3032: -- Summary: 'Domain model for SQL query' section doesn't expand if 'Fields' contains invalid field Key: IGNITE-3032 URL: https://issues.apache.org/jira/browse/IGNITE-3032 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov 1) expand the 'Domain model for SQL query' section 2) set invalid type for field 3) collapse the section 4) click Save -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (IGNITE-2858) Refactoring Domains screen to AngularJS directives and mixins
[ https://issues.apache.org/jira/browse/IGNITE-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov reopened IGNITE-2858: Assignee: Alexey Kuznetsov (was: Pavel Konstantinov) Created a new sub-tasks for found issues. > Refactoring Domains screen to AngularJS directives and mixins > - > > Key: IGNITE-2858 > URL: https://issues.apache.org/jira/browse/IGNITE-2858 > Project: Ignite > Issue Type: Task > Components: wizards >Affects Versions: 1.6 >Reporter: Vasiliy Sisko >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > Attachments: ig-2858-1.png > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3033) Domain model for SQL query: Name field and Type field do not have red border and triangle in case of invalid value
Pavel Konstantinov created IGNITE-3033: -- Summary: Domain model for SQL query: Name field and Type field do not have red border and triangle in case of invalid value Key: IGNITE-3033 URL: https://issues.apache.org/jira/browse/IGNITE-3033 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov Name field = 7 Type field = !!! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3034) Domain model for SQL query: Undo button not hide after undo
Pavel Konstantinov created IGNITE-3034: -- Summary: Domain model for SQL query: Undo button not hide after undo Key: IGNITE-3034 URL: https://issues.apache.org/jira/browse/IGNITE-3034 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov Assignee: Alexey Kuznetsov the button is hidden only on the second click -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3034) Domain model for SQL query: Undo button doesn't hide after undo
[ https://issues.apache.org/jira/browse/IGNITE-3034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-3034: --- Summary: Domain model for SQL query: Undo button doesn't hide after undo (was: Domain model for SQL query: Undo button not hide after undo) > Domain model for SQL query: Undo button doesn't hide after undo > --- > > Key: IGNITE-3034 > URL: https://issues.apache.org/jira/browse/IGNITE-3034 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > the button is hidden only on the second click -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3026) Import model generates incorrect type for blob field
[
https://issues.apache.org/jira/browse/IGNITE-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kuznetsov resolved IGNITE-3026.
--
Resolution: Fixed
Assignee: Pavel Konstantinov (was: Alexey Kuznetsov)
Fixed support for Blob and Object.
> Import model generates incorrect type for blob field
> -
>
> Key: IGNITE-3026
> URL: https://issues.apache.org/jira/browse/IGNITE-3026
> Project: Ignite
> Issue Type: Sub-task
> Components: UI
>Affects Versions: 1.5.0.final
>Reporter: Pavel Konstantinov
>Assignee: Pavel Konstantinov
> Fix For: 1.6
>
>
> If table contains a field of blob type then such fields imported as Object
> and console generates incorrect java code
> {code}
> import Object;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-533) Implement IgniteZeromqStreamer to stream data from ZeroMQ
[
https://issues.apache.org/jira/browse/IGNITE-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249635#comment-15249635
]
Chandresh Pancholi commented on IGNITE-533:
---
Won't be any licensing problem?
If not then i will implement Pub-Sub with zeromq and put data into ignite cache.
[~dsetrakyan] What do you think?
> Implement IgniteZeromqStreamer to stream data from ZeroMQ
> -
>
> Key: IGNITE-533
> URL: https://issues.apache.org/jira/browse/IGNITE-533
> Project: Ignite
> Issue Type: Sub-task
> Components: streaming
>Reporter: Dmitriy Setrakyan
>Assignee: Chandresh Pancholi
>
> We have {{IgniteDataStreamer}} which is used to load data into Ignite under
> high load. It was previously named {{IgniteDataLoader}}, see ticket
> IGNITE-394.
> See [ZeroMQ|http://zeromq.org/] for more info.
> We should create {{IgniteZeroMqStreamer}} which will consume messages from
> Twitter and stream them into Ignite caches.
> More details to follow, but to the least we should be able to:
> * Convert ZeroMQ messages to Ignite data using an optional pluggable
> converter. If not provided, we should have some default mechanism.
> * Specify the cache name for the Ignite cache to load data into.
> * Specify other flags available on {{IgniteDataStreamer}} class.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3019) Implement config variations test for IgniteCompute
[ https://issues.apache.org/jira/browse/IGNITE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249653#comment-15249653 ] ASF GitHub Bot commented on IGNITE-3019: GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/658 IGNITE-3019 Implement config variations test for IgniteCompute IGNITE-3019 Implement config variations test for IgniteCompute You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3019 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/658.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #658 commit 3e0fdceb3c8512689e34dc101b687e3e537c686c Author: tledkov-gridgain Date: 2016-04-19T15:42:24Z IGNITE-3019 Implement config variations test for IgniteCompute commit 3e6274da0b2ad517763792d009d2cb132788708c Author: tledkov-gridgain Date: 2016-04-20T10:50:00Z IGNITE-3019 add tests for call and affinityCall commit 3fb06ae0722ad288fe608a19e6943f1175c83987 Author: tledkov-gridgain Date: 2016-04-20T10:53:04Z Merge branch 'master' of https://github.com/gridgain/apache-ignite into ignite-3019 > Implement config variations test for IgniteCompute > -- > > Key: IGNITE-3019 > URL: https://issues.apache.org/jira/browse/IGNITE-3019 > Project: Ignite > Issue Type: Test > Components: compute >Reporter: Semen Boikov >Assignee: Taras Ledkov > Fix For: 1.6 > > > Need implement configuration variations test for IgniteCompute (see > IgniteCacheBasicConfigVariationsFullApiTestSuite as example). > Test should cover following cases: > - all supported marshaller (Optimized, Binary, JDK) > - different data types for task parameters/return values (see > IgniteConfigVariationsAbstractTest.runInAllDataModes) > - single server node > - multiple servers, multiple clients, use IgniteCompue API from servers and > clients > - true/false for IgniteConfiguration.peerClassLoadingEnabled > - true/false for IgniteConfiguration.marshalLocalJobs > - need test following types of jobs classes: regular class, Serializable, > Externalizable, Binarylizable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3032) 'Domain model for SQL query' section doesn't expand if 'Fields' contains invalid field
[ https://issues.apache.org/jira/browse/IGNITE-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-3032. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Fixed panel expanding. > 'Domain model for SQL query' section doesn't expand if 'Fields' contains > invalid field > -- > > Key: IGNITE-3032 > URL: https://issues.apache.org/jira/browse/IGNITE-3032 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov > Fix For: 1.6 > > > 1) expand the 'Domain model for SQL query' section > 2) set invalid type for field > 3) collapse the section > 4) click Save -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1977) IgniteSemaphore's failover related tests lead to the deadlock or fail
[
https://issues.apache.org/jira/browse/IGNITE-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-1977:
---
Assignee: Vladimir Ozerov (was: Vladisav Jelisavcic)
> IgniteSemaphore's failover related tests lead to the deadlock or fail
> -
>
> Key: IGNITE-1977
> URL: https://issues.apache.org/jira/browse/IGNITE-1977
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Magda
>Assignee: Vladimir Ozerov
>
> All {{IgniteSemaphore}} related tests from
> {{GridCacheAbstractDataStructuresFailoverSelfTest}} may cause a deadlock
> which leads to the whole suite hanging.
> The threads are waiting for the following condition:
> {noformat}
> "topology-change-thread-3" prio=6 tid=0x1d98d800 nid=0x2b20 waiting
> on condition [0x2066f000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000798149948> (a
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.acquire(GridCacheSemaphoreImpl.java:538)
> at
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.acquire(GridCacheSemaphoreImpl.java:525)
> at
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest$7.apply(GridCacheAbstractDataStructuresFailoverSelfTest.java:571)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosure.run(GridAbsClosure.java:50)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:967)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {noformat}
> Probably the semaphore is not properly released when a node leaves the
> topology abruptly.
> In addition the tests should be rewritten to the way which is followed by
> other data structures and atomics from this suite: using
> {{ConstantTopologyChangeWorker}} and its descendants.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.
[ https://issues.apache.org/jira/browse/IGNITE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249821#comment-15249821 ] Chandresh Pancholi commented on IGNITE-1650: [~vozerov] How can i reproduce it? or from where i can better understand it? > Add ability to specify thread pool for IgniteFuture listen/chain methods. > - > > Key: IGNITE-1650 > URL: https://issues.apache.org/jira/browse/IGNITE-1650 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Priority: Critical > Fix For: 1.6 > > > Closures passed to IgniteFuture listen() and chain() methods are executed > either in the same thread if future is completed, or in a completion thread > (usually this is a thread from one of Ignite pools). > This enforces restrictions on what user can do in closures. He cannot use > call operations, he cannot call any Ignite operations. Otherwise deadlocks or > starvation could occur. > To fix that we should allow user to pass optional thread pool where passed > closure should be executed. This already done in Java 8 CompletableFuture. We > should do almost the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IGNITE-1650) Add ability to specify thread pool for IgniteFuture listen/chain methods.
[ https://issues.apache.org/jira/browse/IGNITE-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chandresh Pancholi reassigned IGNITE-1650: -- Assignee: Chandresh Pancholi > Add ability to specify thread pool for IgniteFuture listen/chain methods. > - > > Key: IGNITE-1650 > URL: https://issues.apache.org/jira/browse/IGNITE-1650 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: ignite-1.4 >Reporter: Vladimir Ozerov >Assignee: Chandresh Pancholi >Priority: Critical > Fix For: 1.6 > > > Closures passed to IgniteFuture listen() and chain() methods are executed > either in the same thread if future is completed, or in a completion thread > (usually this is a thread from one of Ignite pools). > This enforces restrictions on what user can do in closures. He cannot use > call operations, he cannot call any Ignite operations. Otherwise deadlocks or > starvation could occur. > To fix that we should allow user to pass optional thread pool where passed > closure should be executed. This already done in Java 8 CompletableFuture. We > should do almost the same. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249875#comment-15249875
]
Alper Tekinalp commented on IGNITE-2394:
Hi.
I have made changes and wrote tests for it. But I am not sure about the
behaviors so wanted to ask. Code is working as:
1 - Create a local cache on client and load(10 item) from client.
client->cache.size=10, server->cache.size=0
2 - Create a local cache on server and load(10 item) from server.
client->cache.size=0, server->cache.size=10
3 - Create a local cache on server and load(10 item) from client.
client->cache.size=10, server->cache.size=0
4 - Create a replicated cache on client and load(10 item) from client.
client->cache.size=0, server->cache.size=10
5 - Create a replicated cache on server and load(10 item) from client.
client->cache.size=0, server->cache.size=10
The case I couldnt be sure is case 3. You can not load local cache to server
from client.
Is that an acceptable case?
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alper Tekinalp
>Priority: Critical
> Labels: newbie
> Fix For: 1.6
>
> Attachments: LocalLoadTest.java, master_baa1312_IGNITE-2394.patch
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249884#comment-15249884 ] Denis Magda commented on IGNITE-813: Hi guys, how close are you to finish reviewing the integration and closing the ticket? > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > Attachments: IgniteSink.txt > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249894#comment-15249894
]
Denis Magda commented on IGNITE-2394:
-
Actually I don't completely get what you mean in the statements. As an example
you're saying
1 - Create a local cache on client and load(10 item) from client.
client->cache.size=10, server->cache.size=0
What cache do you mean under "server->cache.size=0"? According to your
description you created only a local cache on a client node. Local caches are
visible only on nodes that created and own them.
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alper Tekinalp
>Priority: Critical
> Labels: newbie
> Fix For: 1.6
>
> Attachments: LocalLoadTest.java, master_baa1312_IGNITE-2394.patch
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249898#comment-15249898 ] Roman Shtykh commented on IGNITE-813: - Denis, it is reviewed and merged. Raul reopened it because he had concerns about docs. > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > Attachments: IgniteSink.txt > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249900#comment-15249900 ] Roman Shtykh commented on IGNITE-813: - I will take of it as close. > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > Attachments: IgniteSink.txt > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249900#comment-15249900 ] Roman Shtykh edited comment on IGNITE-813 at 4/20/16 1:44 PM: -- I will take of it and close. was (Author: roman_s): I will take of it as close. > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > Attachments: IgniteSink.txt > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2383) Non-string system properties should be ignored in node attributes and update checker
[
https://issues.apache.org/jira/browse/IGNITE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249994#comment-15249994
]
ASF GitHub Bot commented on IGNITE-2383:
GitHub user vldpyatkov opened a pull request:
https://github.com/apache/ignite/pull/659
IGNITE-2383
Non-string system properties should be ignored in node attributes and
update checker
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/vldpyatkov/ignite ignite-2383
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/659.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #659
commit a810a8e914c070dc65a4889025dfba2ac10b3445
Author: vdpyatkov
Date: 2016-04-20T14:25:36Z
IGNITE-2383
Non-string system properties should be ignored in node attributes and
update checker
> Non-string system properties should be ignored in node attributes and update
> checker
>
>
> Key: IGNITE-2383
> URL: https://issues.apache.org/jira/browse/IGNITE-2383
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Valentin Kulichenko
>Assignee: Vladislav Pyatkov
>Priority: Critical
> Fix For: 1.6
>
>
> user@ discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-quot-bugs-quot-td2534.html
> Some frameworks can put non-string and/or non-serializable values into system
> properties. We should ignore them in
> {{GridUpdateNotifier.getSystemProperties()}} method and when adding
> properties to node attributes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alper Tekinalp updated IGNITE-2394:
---
Attachment: master_186c860_IGNITE-2394.patch
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alper Tekinalp
>Priority: Critical
> Labels: newbie
> Fix For: 1.6
>
> Attachments: LocalLoadTest.java, master_186c860_IGNITE-2394.patch,
> master_baa1312_IGNITE-2394.patch
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2394) Cache loading from storage is called on client nodes
[
https://issues.apache.org/jira/browse/IGNITE-2394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250005#comment-15250005
]
Alper Tekinalp commented on IGNITE-2394:
Hi.
I attached my patch. Lets continue talking over it. I appreciate your comments.
> Cache loading from storage is called on client nodes
>
>
> Key: IGNITE-2394
> URL: https://issues.apache.org/jira/browse/IGNITE-2394
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Alper Tekinalp
>Priority: Critical
> Labels: newbie
> Fix For: 1.6
>
> Attachments: LocalLoadTest.java, master_186c860_IGNITE-2394.patch,
> master_baa1312_IGNITE-2394.patch
>
>
> If to call cache.loadCache(...) then the loading from a storage will happen
> on all the nodes including client nodes.
> However, client nodes must be filtered out.
> If to be more precise at least this place of the code has to be modified
> {noformat}
> IgniteInternalFuture globalLoadCacheAsync(@Nullable
> IgniteBiPredicate p, @Nullable Object... args)
> throws IgniteCheckedException {
> ClusterGroup nodes =
> ctx.kernalContext().grid().cluster().forCacheNodes(ctx.name());
> {noformat}
> where forDataNodes() has to be used instead of forCacheNodes().
> Also additional tests have to be added.
> Discussion on the user list:
> http://apache-ignite-users.70518.x6.nabble.com/Loadcache-behavior-tp2571.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (IGNITE-2688) InterruptException for segmentation issues
[
https://issues.apache.org/jira/browse/IGNITE-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Magda closed IGNITE-2688.
---
> InterruptException for segmentation issues
> --
>
> Key: IGNITE-2688
> URL: https://issues.apache.org/jira/browse/IGNITE-2688
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kozlov
>Assignee: Denis Magda
>Priority: Minor
>
> We're still seeing following exception for segmentation issues:
> {noformat}
> [18:16:31,566][WARNING][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi] Node
> is out of topology (probably, due to short-time network problems).
> [18:16:31,566][WARNING][disco-event-worker-#46%null%][GridDiscoveryManager]
> Local node SEGMENTED: TcpDiscoveryNode
> [id=19cf4b0f-d520-4915-be9f-813a99f945a5, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1,
> 172.22.222.44, 192.168.1.117], sockAddrs=[work-pc/172.22.222.44:47501,
> /0:0:0:0:0:0:0:1:47501, /172.22.222.44:47501, /127.0.0.1:47501,
> /172.22.222.44:47501, /192.168.1.117:47501], discPort=47501, order=4,
> intOrder=4, lastExchangeTime=1455808591566, loc=true,
> ver=1.6.0#19700101-sha1:, isClient=false]
> [18:16:31,629][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> java.lang.InterruptedException
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2017)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2095)
> at
> java.util.concurrent.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:519)
> at
> java.util.concurrent.LinkedBlockingDeque.poll(LinkedBlockingDeque.java:682)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5786)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2160)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [18:16:31,851][WARNING][sys-#22%null%][GridDhtAtomicCache]
> Failed to send near update reply to node
> because it left grid: fad03851-2077-4b50-92b3-00ec6d85fa39
> [18:16:31,866][WARNING][disco-event-worker-#46%null%][GridDiscoveryManager]
> Stopping local node according to configured segmentation policy.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2688) InterruptException for segmentation issues
[
https://issues.apache.org/jira/browse/IGNITE-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250033#comment-15250033
]
Denis Magda commented on IGNITE-2688:
-
Thanks Sam for pointing out to {{GridStringLogger}}. Reworked the tests using
it and removed {{stoppedAbnormally}} field.
Merged the changes into the master.
> InterruptException for segmentation issues
> --
>
> Key: IGNITE-2688
> URL: https://issues.apache.org/jira/browse/IGNITE-2688
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Kozlov
>Assignee: Denis Magda
>Priority: Minor
>
> We're still seeing following exception for segmentation issues:
> {noformat}
> [18:16:31,566][WARNING][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi] Node
> is out of topology (probably, due to short-time network problems).
> [18:16:31,566][WARNING][disco-event-worker-#46%null%][GridDiscoveryManager]
> Local node SEGMENTED: TcpDiscoveryNode
> [id=19cf4b0f-d520-4915-be9f-813a99f945a5, addrs=[0:0:0:0:0:0:0:1, 127.0.0.1,
> 172.22.222.44, 192.168.1.117], sockAddrs=[work-pc/172.22.222.44:47501,
> /0:0:0:0:0:0:0:1:47501, /172.22.222.44:47501, /127.0.0.1:47501,
> /172.22.222.44:47501, /192.168.1.117:47501], discPort=47501, order=4,
> intOrder=4, lastExchangeTime=1455808591566, loc=true,
> ver=1.6.0#19700101-sha1:, isClient=false]
> [18:16:31,629][SEVERE][tcp-disco-msg-worker-#2%null%][TcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> java.lang.InterruptedException
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.reportInterruptAfterWait(AbstractQueuedSynchronizer.java:2017)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2095)
> at
> java.util.concurrent.LinkedBlockingDeque.pollFirst(LinkedBlockingDeque.java:519)
> at
> java.util.concurrent.LinkedBlockingDeque.poll(LinkedBlockingDeque.java:682)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:5786)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2160)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [18:16:31,851][WARNING][sys-#22%null%][GridDhtAtomicCache]
> Failed to send near update reply to node
> because it left grid: fad03851-2077-4b50-92b3-00ec6d85fa39
> [18:16:31,866][WARNING][disco-event-worker-#46%null%][GridDiscoveryManager]
> Stopping local node according to configured segmentation policy.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250072#comment-15250072 ] Semen Boikov commented on IGNITE-2854: -- Some more comments: - need add proper synchronization for TxDeadlockFuture.curNodeId access - please change TxDeadlockFuture.futId from IgniteUuid to Long - please add some basic test for deadlock exception messsage (check correctness of info about keys' values, nodes, threads) > Need to implement deadlock detection > > > Key: IGNITE-2854 > URL: https://issues.apache.org/jira/browse/IGNITE-2854 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Andrey Gura > Fix For: 1.6 > > > Currently, if transactional deadlock occurred, there is no easy way to find > out which locks were reordered. > We need to add a mechanism that will collect information about awating > candidates, analyze it and show guilty keys. Most likely this should be > implemented with the help of custom discovery message. > In addition we should automatically execute this mechanism if transaction > times out and add information to timeout exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2864) Need update local store from primary and backups
[ https://issues.apache.org/jira/browse/IGNITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250094#comment-15250094 ] Anton Vinogradov commented on IGNITE-2864: -- Eventually I've added system property IGNITE_LOCAL_STORE_KEEPS_PRIMARY_ONLY and set it false by default. It means that new behavior will be active by default. Also I added more tests for old and new behavior. In case user will try to combine nodes with versions "before" and "after" fix with configured local store he will gain warning: "Since Ignite 1.5.15 Local Store keeps primary and backup partitions. To keep primary partitions only please set system property IGNITE_LOCAL_STORE_KEEPS_PRIMARY_ONLY to 'true'." > Need update local store from primary and backups > > > Key: IGNITE-2864 > URL: https://issues.apache.org/jira/browse/IGNITE-2864 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Semen Boikov >Assignee: Anton Vinogradov > Fix For: 1.6 > > > Now cache local store is updated only from primary nodes, this means that > data can be lost if primary node is not re-started after crash. Need fix it > and update store from primaries and backups if store is local (for both tx > and atomic caches). > This test should work: > - cache with 1 backup, two server nodes > - execute cache put for key K > - stop both nodes > - restart only node which was backup for K > - load data from local sore, update for K should be restored -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-1371) Key-Value store (like Cassandra) as CacheStore
[ https://issues.apache.org/jira/browse/IGNITE-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15249410#comment-15249410 ] Igor Rudyak edited comment on IGNITE-1371 at 4/20/16 3:57 PM: -- Alexey, I merged changes from your review into "ignite-1371" branch. Also made some minor refactoring of Unit tests and added comments regarding commented lines "CassandraHelper.dropTestKeyspaces()" in Load test classes. Also added DDL generator utility. Here is documentation for it: https://github.com/irudyak/ignite/wiki/DDL-generator was (Author: irudyak): Alexey, I merged changes from you review into "ignite-1371" branch. Also made some minor refactoring of Unit tests and added comments regarding commented lines "CassandraHelper.dropTestKeyspaces()" in Load test classes. Also added DDL generator utility. Here is documentation for it: https://github.com/irudyak/ignite/wiki/DDL-generator > Key-Value store (like Cassandra) as CacheStore > -- > > Key: IGNITE-1371 > URL: https://issues.apache.org/jira/browse/IGNITE-1371 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: ignite-1.4 >Reporter: Alexandre Boudnik >Assignee: Igor Rudyak > Attachments: master_02b59e4_ignite-1371.patch > > Original Estimate: 504h > Remaining Estimate: 504h > > It will provide ability to map particular cache holding POJOs to Cassandra > table. Later it would be generalized to support eventually any any Key-Value > store. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (IGNITE-2864) Need update local store from primary and backups
[
https://issues.apache.org/jira/browse/IGNITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250146#comment-15250146
]
Dmitriy Setrakyan edited comment on IGNITE-2864 at 4/20/16 4:01 PM:
Can you explain why you decided to use a system property instead of regular
configuration property?
Also, I am not sure I like the name, because this property is not about the
local store, but about the cache store in general. I think it should be named
{{isCentralizedStore()}} and should be {{true}} by default. If store is
centralized, then there is no need to write backups to the store. On the other
hand, if store is local to a node, then it should have both, primary and backup
copies for the purpose of recovery.
Do you agree?
was (Author: dsetrakyan):
Can you explain why you decided to use a system property instead of regular
configuration property?
Also, I am not sure I like the name, because this property is not about the
local store, but about the cache store in general. I think it should be named
{{isCentralizedStore}} and should be {{true}} by default. If store is
centralized, then there is no need to write backups to the store. On the other
hand, if store is local to a node, then it should have both, primary and backup
copies for the purpose of recovery.
Do you agree?
> Need update local store from primary and backups
>
>
> Key: IGNITE-2864
> URL: https://issues.apache.org/jira/browse/IGNITE-2864
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
> Fix For: 1.6
>
>
> Now cache local store is updated only from primary nodes, this means that
> data can be lost if primary node is not re-started after crash. Need fix it
> and update store from primaries and backups if store is local (for both tx
> and atomic caches).
> This test should work:
> - cache with 1 backup, two server nodes
> - execute cache put for key K
> - stop both nodes
> - restart only node which was backup for K
> - load data from local sore, update for K should be restored
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2864) Need update local store from primary and backups
[
https://issues.apache.org/jira/browse/IGNITE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250146#comment-15250146
]
Dmitriy Setrakyan commented on IGNITE-2864:
---
Can you explain why you decided to use a system property instead of regular
configuration property?
Also, I am not sure I like the name, because this property is not about the
local store, but about the cache store in general. I think it should be named
{{isCentralizedStore}} and should be {{true}} by default. If store is
centralized, then there is no need to write backups to the store. On the other
hand, if store is local to a node, then it should have both, primary and backup
copies for the purpose of recovery.
Do you agree?
> Need update local store from primary and backups
>
>
> Key: IGNITE-2864
> URL: https://issues.apache.org/jira/browse/IGNITE-2864
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Semen Boikov
>Assignee: Anton Vinogradov
> Fix For: 1.6
>
>
> Now cache local store is updated only from primary nodes, this means that
> data can be lost if primary node is not re-started after crash. Need fix it
> and update store from primaries and backups if store is local (for both tx
> and atomic caches).
> This test should work:
> - cache with 1 backup, two server nodes
> - execute cache put for key K
> - stop both nodes
> - restart only node which was backup for K
> - load data from local sore, update for K should be restored
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3035) Recent JDBC discovery changes cause errors for Postgres and Microsoft SQL Server databases
Peter Griffiths created IGNITE-3035:
---
Summary: Recent JDBC discovery changes cause errors for Postgres
and Microsoft SQL Server databases
Key: IGNITE-3035
URL: https://issues.apache.org/jira/browse/IGNITE-3035
Project: Ignite
Issue Type: Bug
Components: SQL
Affects Versions: 1.6
Reporter: Peter Griffiths
The changes introduced by IGNITE-1993 to the TcpDiscoveryJdbcIpFinder class to
introduce Oracle compatibility cause errors when Postgres or Microsoft SQL
Server are used as the database. No such issues were encountered using either
database before.
The first node to join a grid succeeds and creates the IP table in the
database, but any further node attempting to join the grid throws the following
error (for Postgres):
{code}
Failed to register local node address in IP finder on start (retrying every
2000 ms).: class org.apache.ignite.spi.IgniteSpiException: Failed to initialize
DB schema.
...
Caused by: org.postgresql.util.PSQLException: ERROR: current transaction is
aborted, commands ignored until end of transaction block
{code}
The same behaviour occurs when using Microsoft SQL Server, but it throws a
different error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3035) Recent JDBC discovery changes cause errors for Postgres and Microsoft SQL Server databases
[
https://issues.apache.org/jira/browse/IGNITE-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250309#comment-15250309
]
Peter Griffiths commented on IGNITE-3035:
-
The errors were happening as the dbm.getTables() call failed to determine the
table's existence due to the Oracle required upper case query. The system then
tried to create the IP table twice, but failed both times since it already
existed.
> Recent JDBC discovery changes cause errors for Postgres and Microsoft SQL
> Server databases
> --
>
> Key: IGNITE-3035
> URL: https://issues.apache.org/jira/browse/IGNITE-3035
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.6
>Reporter: Peter Griffiths
>
> The changes introduced by IGNITE-1993 to the TcpDiscoveryJdbcIpFinder class
> to introduce Oracle compatibility cause errors when Postgres or Microsoft SQL
> Server are used as the database. No such issues were encountered using
> either database before.
> The first node to join a grid succeeds and creates the IP table in the
> database, but any further node attempting to join the grid throws the
> following error (for Postgres):
> {code}
> Failed to register local node address in IP finder on start (retrying every
> 2000 ms).: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize DB schema.
> ...
> Caused by: org.postgresql.util.PSQLException: ERROR: current transaction is
> aborted, commands ignored until end of transaction block
> {code}
> The same behaviour occurs when using Microsoft SQL Server, but it throws a
> different error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2004) Asynchronous execution of ContinuousQuery's remote filter & local list
[
https://issues.apache.org/jira/browse/IGNITE-2004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250339#comment-15250339
]
Nikolay Tikhonov commented on IGNITE-2004:
--
Thank you for your review! I've fixed notes.
Yakov, could you please review changes (exceptional look at java-doc in
{{ContinuousQuery}}, {{ContinuousQuery#setLocalListener}},
{{ContinuousQuery#setRemoteFilter}},
{{ContinuousQuery#setRemoteFilterFactory}}, {{IgniteAsyncCallback}},
{{IgniteConfiguration#getAsyncCallbackPoolSize}})?
> Asynchronous execution of ContinuousQuery's remote filter & local list
> --
>
> Key: IGNITE-2004
> URL: https://issues.apache.org/jira/browse/IGNITE-2004
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Assignee: Nikolay Tikhonov
> Labels: important
> Fix For: 1.6
>
>
> Presently remote filters are executed synchronously an entry update. This
> leads to the limitation when it's disallowed to perform cache related
> operation in a filter body.
> It's required to add the ability to execute remote filters asynchronously.
> This will let to execute any kind of operations including cache operations
> directly in the filter body.
> The solution must be fault-tolerant. At least once execution of a filter in
> case of a failure works fine.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1248) Add a method to retrieve Spring application context
[
https://issues.apache.org/jira/browse/IGNITE-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250568#comment-15250568
]
Saikat Maitra commented on IGNITE-1248:
---
[~vkulichenko]
Can you please review this PR.
Regards
Saikat
> Add a method to retrieve Spring application context
> ---
>
> Key: IGNITE-1248
> URL: https://issues.apache.org/jira/browse/IGNITE-1248
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
> Fix For: 1.6
>
>
> Currently there is a way to inject application context instance into task,
> closure, cache store using {{@SpringApplicationContextResource}} annotation.
> But there is no way to get context associated with an {{Ignite}} instance
> from user code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-1248) Add a method to retrieve Spring application context
[
https://issues.apache.org/jira/browse/IGNITE-1248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250586#comment-15250586
]
Valentin Kulichenko commented on IGNITE-1248:
-
Hi Saikat. No problem, I will take a look in next few days.
> Add a method to retrieve Spring application context
> ---
>
> Key: IGNITE-1248
> URL: https://issues.apache.org/jira/browse/IGNITE-1248
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 1.1.4
>Reporter: Valentin Kulichenko
>Assignee: Saikat Maitra
> Fix For: 1.6
>
>
> Currently there is a way to inject application context instance into task,
> closure, cache store using {{@SpringApplicationContextResource}} annotation.
> But there is no way to get context associated with an {{Ignite}} instance
> from user code.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-3035) Recent JDBC discovery changes cause errors for Postgres and Microsoft SQL Server databases
[
https://issues.apache.org/jira/browse/IGNITE-3035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250676#comment-15250676
]
ASF GitHub Bot commented on IGNITE-3035:
GitHub user peter-griffiths opened a pull request:
https://github.com/apache/ignite/pull/660
IGNITE-3035 Postgres mssql JDBC discovery fix
Updated the TcpDiscoveryJdbcIpFinder class to work with Postgres and
Microsoft SQL Server while maintaining the fix for Oracle databases introduced
with IGNITE-1993.
The issue stemmed from the fact that the DatabaseMetaData.getTables(...)
table name value has to be upper case for Oracle, but ran case sensitively for
other databases such as Postgres. This meant the TcpDiscoveryJdbcIpFinder
always failed to correctly determine if the "TBL_ADDRS" table already existed
before trying and failing to create it again. The table creation failures
caused an aborted transaction and subsequent SQL queries to fail with "ERROR:
current transaction is aborted, commands ignored until end of transaction
block".
The fix is to create the and table in the database in upper case.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/peter-griffiths/ignite
ignite-3035-postgres-mssql
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/660.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #660
> Recent JDBC discovery changes cause errors for Postgres and Microsoft SQL
> Server databases
> --
>
> Key: IGNITE-3035
> URL: https://issues.apache.org/jira/browse/IGNITE-3035
> Project: Ignite
> Issue Type: Bug
> Components: SQL
>Affects Versions: 1.6
>Reporter: Peter Griffiths
>
> The changes introduced by IGNITE-1993 to the TcpDiscoveryJdbcIpFinder class
> to introduce Oracle compatibility cause errors when Postgres or Microsoft SQL
> Server are used as the database. No such issues were encountered using
> either database before.
> The first node to join a grid succeeds and creates the IP table in the
> database, but any further node attempting to join the grid throws the
> following error (for Postgres):
> {code}
> Failed to register local node address in IP finder on start (retrying every
> 2000 ms).: class org.apache.ignite.spi.IgniteSpiException: Failed to
> initialize DB schema.
> ...
> Caused by: org.postgresql.util.PSQLException: ERROR: current transaction is
> aborted, commands ignored until end of transaction block
> {code}
> The same behaviour occurs when using Microsoft SQL Server, but it throws a
> different error.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2921) ScanQueries over local partitions are not optimal
[
https://issues.apache.org/jira/browse/IGNITE-2921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250765#comment-15250765
]
Artem Shutak commented on IGNITE-2921:
--
Finished with tests. Fixed all found issues (including non-related to issue).
Currently, I have a little bit tricky bug with Scan query over partition and
fall-tolerance.
> ScanQueries over local partitions are not optimal
> -
>
> Key: IGNITE-2921
> URL: https://issues.apache.org/jira/browse/IGNITE-2921
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 1.5.0.final
>Reporter: Denis Magda
>Assignee: Artem Shutak
>Priority: Blocker
> Labels: community, important, performance
> Fix For: 1.6
>
> Attachments: LocalIteratorStuff.java, ScanQueryStuff.java
>
>
> Presently scan queries over local partitions are not executed optimally.
> If to run a scan query over a specific partition (by setting
> {{query.setPartition(...)}} parameter and or {{query.setLocal(true)}}) and
> start iterating over entries we will see that the Thread, that iterates over
> the data, waits for some event to happen.
> In fact the Thread waits while a system pool's thread prepares an iterator
> with entries for it and only after that iterates over the returned result
> set. The flow looks this way:
> - {{GridCacheLocalQueryFuture}} is created;
> - when {{QueryCursor.iterator().next}} is called from the app thread (the
> Thread above), {{GridCacheLocalQueryFuture.execute()}} methods puts closure
> that will prepare content for the iterator in the system pool.
> - a system Thread execute {{GridCacheQueryManager.runQuery()}} reading all
> the entries from partition and passing them back to the Thread at line 1553
> by calling {{onPageReady(...)}} method.
> The other bottleneck is that a system thread gets all the entries and passes
> them to the Thread which will lead to more garbaged Java heap especially if
> cache is {{OFFHEAP_TIRED}}.
> Run attached test ({{ScanQueryStuff}}) and you will see with Visual VM that
> most of the time the test spends executing the code from system threads.
> Finally, what have to be done:
> - if ScanQuery is supposed to be executed locally (setPartition() refers to
> local partition or setLocal is set to true) then the calling application
> thread has to iterate over the data avoiding usage of the system pool;
> - internal code mustn't read all entries from a partition initially. The
> iterator has to get one entry next after another. This will be a memory
> backpressure mechanism especially for {{OFFHEAP_TIRED}}.
> My assumption is that the fixed version has to work in a similar way to
> iteration over local entries -
> {{cache.localEntries(CachePeekMode.PRIMARY);}}. Run attached
> {{LocalIteratorStuff}} to see with Visual VM that the application thread is
> fully utilized and system threads are idle.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-2906) Embedded / child element types indexing/queryfields (non-flat)
[
https://issues.apache.org/jira/browse/IGNITE-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15250798#comment-15250798
]
Krome Plasma commented on IGNITE-2906:
--
class ClassA
{
@QuerySqlField (name = "clash")
int a;
}
class ClassB
{
@QuerySqlField
ClassA first;
@QuerySqlField
ClassA second;
}
This would not work either.
> Embedded / child element types indexing/queryfields (non-flat)
> --
>
> Key: IGNITE-2906
> URL: https://issues.apache.org/jira/browse/IGNITE-2906
> Project: Ignite
> Issue Type: Improvement
> Components: cache, data structures, general, SQL
>Reporter: Krome Plasma
> Attachments: indexing.patch
>
>
> I've had discussion about this on Apache Ignite Users.
> http://apache-ignite-users.70518.x6.nabble.com/Indexing-Querying-of-child-element-fields-td1704.html#a1734
> The problem occurs when you want to index a non-primitive type that have same
> names of variables as the enclosing type, better described on forum above. As
> a short example:
> Let's say we want to index:
> public class Person
> {
> @QuerySqlField
> long id;
> @QuerySqlField
> PersonData personData;
> }
> public class PersonData
> {
> @QuerySqlField
> long id;
> }
> This will not work as it will detect indexes/query fields with same names for
> index Person.id and PersonData.id because the names are flattened to simply
> 'id'.
> I am attaching a simple patch that resolves this issue. We've been running
> this for (3 months now) and found no problems. However we are using
> annotations and not XML. I am not sure the patch completely solves the
> problem for XML based configuration.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IGNITE-813) Apache Flink Integration -- data streaming connector
[ https://issues.apache.org/jira/browse/IGNITE-813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251099#comment-15251099 ] Roman Shtykh commented on IGNITE-813: - [~samaitra] Can you please provide it in a text format? I will format it to readme.io by myself. The attached file cannot be used in readme.io as is. > Apache Flink Integration -- data streaming connector > > > Key: IGNITE-813 > URL: https://issues.apache.org/jira/browse/IGNITE-813 > Project: Ignite > Issue Type: New Feature > Components: streaming >Reporter: Suminda Dharmasena >Assignee: Saikat Maitra > Fix For: 1.6 > > Attachments: IgniteSink.txt > > > Sink connector -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3032) 'Domain model for SQL query' section doesn't expand if 'Fields' contains invalid field
[ https://issues.apache.org/jira/browse/IGNITE-3032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov closed IGNITE-3032. -- Assignee: (was: Pavel Konstantinov) Tested. > 'Domain model for SQL query' section doesn't expand if 'Fields' contains > invalid field > -- > > Key: IGNITE-3032 > URL: https://issues.apache.org/jira/browse/IGNITE-3032 > Project: Ignite > Issue Type: Sub-task > Components: wizards >Reporter: Pavel Konstantinov > Fix For: 1.6 > > > 1) expand the 'Domain model for SQL query' section > 2) set invalid type for field > 3) collapse the section > 4) click Save -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (IGNITE-3026) Import model generates incorrect type for blob field
[
https://issues.apache.org/jira/browse/IGNITE-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Konstantinov closed IGNITE-3026.
--
Assignee: (was: Pavel Konstantinov)
Tested. Now generated java class doesn't contain 'import Object'.
> Import model generates incorrect type for blob field
> -
>
> Key: IGNITE-3026
> URL: https://issues.apache.org/jira/browse/IGNITE-3026
> Project: Ignite
> Issue Type: Sub-task
> Components: UI
>Affects Versions: 1.5.0.final
>Reporter: Pavel Konstantinov
> Fix For: 1.6
>
>
> If table contains a field of blob type then such fields imported as Object
> and console generates incorrect java code
> {code}
> import Object;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (IGNITE-3036) We need to set red border to empty mandatory fields after Save
Pavel Konstantinov created IGNITE-3036: -- Summary: We need to set red border to empty mandatory fields after Save Key: IGNITE-3036 URL: https://issues.apache.org/jira/browse/IGNITE-3036 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (IGNITE-3037) we need to enable read-through or write-through if cache generated during importing model from DB
Pavel Konstantinov created IGNITE-3037: -- Summary: we need to enable read-through or write-through if cache generated during importing model from DB Key: IGNITE-3037 URL: https://issues.apache.org/jira/browse/IGNITE-3037 Project: Ignite Issue Type: Sub-task Reporter: Pavel Konstantinov In case when cache created from a template which doesn't have these properties enabled we must enable at least one of its. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IGNITE-3037) we need to enable read-through or write-through if cache generated during importing model from DB
[ https://issues.apache.org/jira/browse/IGNITE-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Konstantinov updated IGNITE-3037: --- Assignee: Alexey Kuznetsov > we need to enable read-through or write-through if cache generated during > importing model from DB > - > > Key: IGNITE-3037 > URL: https://issues.apache.org/jira/browse/IGNITE-3037 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Alexey Kuznetsov > Fix For: 1.6 > > > In case when cache created from a template which doesn't have these > properties enabled we must enable at least one of its. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IGNITE-3037) we need to enable read-through or write-through if cache generated during importing model from DB
[ https://issues.apache.org/jira/browse/IGNITE-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov resolved IGNITE-3037. -- Resolution: Fixed Assignee: Pavel Konstantinov (was: Alexey Kuznetsov) Fixed on staging > we need to enable read-through or write-through if cache generated during > importing model from DB > - > > Key: IGNITE-3037 > URL: https://issues.apache.org/jira/browse/IGNITE-3037 > Project: Ignite > Issue Type: Sub-task >Reporter: Pavel Konstantinov >Assignee: Pavel Konstantinov > Fix For: 1.6 > > > In case when cache created from a template which doesn't have these > properties enabled we must enable at least one of its. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IGNITE-2854) Need to implement deadlock detection
[ https://issues.apache.org/jira/browse/IGNITE-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251374#comment-15251374 ] Semen Boikov commented on IGNITE-2854: -- I reviewed last changes, did some changes, please take a look. Have some more comments: - after you changed 'directType' for messages code in DeadlockDetectionListener.processFailedMessage is broken, please fix and add test - let's add sanity check in tests that IgniteTxManager.deadlockDetectFuts on all nodes is empty at the end > Need to implement deadlock detection > > > Key: IGNITE-2854 > URL: https://issues.apache.org/jira/browse/IGNITE-2854 > Project: Ignite > Issue Type: New Feature > Components: cache >Affects Versions: 1.5.0.final >Reporter: Valentin Kulichenko >Assignee: Andrey Gura > Fix For: 1.6 > > > Currently, if transactional deadlock occurred, there is no easy way to find > out which locks were reordered. > We need to add a mechanism that will collect information about awating > candidates, analyze it and show guilty keys. Most likely this should be > implemented with the help of custom discovery message. > In addition we should automatically execute this mechanism if transaction > times out and add information to timeout exception. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
