[jira] [Created] (IGNITE-3450) Web console: Wrong message on fail to connect to database

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3450:
-

 Summary: Web console: Wrong message on fail to connect to database
 Key: IGNITE-3450
 URL: https://issues.apache.org/jira/browse/IGNITE-3450
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.7
Reporter: Vasiliy Sisko


# Open import domains model dialog.
# Input wrong driver, URL, user or password.
Showed message without information what is wrong: 
- java.sql.SQLException: Failed to collect schemas



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3449) Web console: JDBC driver should have valid Java class validator.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3449:
-

 Summary: Web console: JDBC driver should have valid Java class 
validator.
 Key: IGNITE-3449
 URL: https://issues.apache.org/jira/browse/IGNITE-3449
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.7
Reporter: Vasiliy Sisko


On import of domain models it is possible to input wrong JDBC driver class 
name. 
Label should be changed to "JDBC driver:"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Ignite 3227

[Alexey Goncharuk]

Saikat,

I merged your PR to master. Thanks for the contribution!

2016-07-05 16:46 GMT-07:00 Dmitriy Setrakyan :

> I think we should add only 1 new method:
>
> long sizeLong(int partId, CachePeekMode peekMode)
>
> D.
>
> On Tue, Jul 5, 2016 at 3:24 PM, Alexander Paschenko <
> alexander.a.pasche...@gmail.com> wrote:
>
> > Alexey in Jira
> >
> https://issues.apache.org/jira/browse/IGNITE-3227?focusedCommentId=15360787
> > suggested that we remove int sized methods from CacheProxy, and he has
> > indeed removed them, but IgniteCache has such new methods too. Should
> > we let them be or maybe it would be better to get rid of them? Please
> > advise. Dmitriy Setrakyan, your opinion on the matter is of particular
> > interest.
> >
> > 2016-07-04 19:30 GMT+03:00 Saikat Maitra :
> > > Thanks a lot Alexey.
> > >
> > > Regards
> > > Saikat
> > >
> > > On Mon, Jul 4, 2016 at 12:01 PM, Alexey Goncharuk <
> > > alexey.goncha...@gmail.com> wrote:
> > >
> > >> Saikat,
> > >>
> > >> Thanks for the contribution. I will make some minor changes to your
> > patch
> > >> and push it to master soon.
> > >>
> > >> 2016-06-26 9:57 GMT-07:00 Saikat Maitra :
> > >>
> > >> > Hi Alexey, Ilya
> > >> >
> > >> > As discussed I have made the changes in the PR[1]. Please review and
> > let
> > >> me
> > >> > know any feedback.
> > >> >
> > >> > [1] https://github.com/apache/ignite/pull/815
> > >> > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> > >> >
> > >> >
> > >> > Regards
> > >> > Saikat
> > >> >
> > >> > On Mon, Jun 20, 2016 at 10:40 PM, Saikat Maitra <
> > saikat.mai...@gmail.com
> > >> >
> > >> > wrote:
> > >> >
> > >> > > Sure Alexey,
> > >> > >
> > >> > > Thank you
> > >> > > Saikat
> > >> > >
> > >> > > On Mon, Jun 20, 2016 at 10:36 PM, Alexey Goncharuk <
> > >> > > alexey.goncha...@gmail.com> wrote:
> > >> > >
> > >> > >> Saikat,
> > >> > >>
> > >> > >> Please also correct the test to check new methods for PARTITIONED
> > and
> > >> > >> REPLICATED cache - I see that you only test them for local cache
> > and
> > >> > >> partition 0 (I added a comment to the ticket).
> > >> > >>
> > >> > >> 2016-06-20 9:17 GMT-07:00 Saikat Maitra  >:
> > >> > >>
> > >> > >> > Thank you Ilya, I will review and update PR accordingly.
> > >> > >> >
> > >> > >> > Regards
> > >> > >> > Saikat
> > >> > >> >
> > >> > >> > On Mon, Jun 20, 2016 at 8:36 PM, Ilya Lantukh <
> > >> ilant...@gridgain.com>
> > >> > >> > wrote:
> > >> > >> >
> > >> > >> > > Hi Saikat,
> > >> > >> > >
> > >> > >> > > I've added a comment to the jira ticket regarding
> > implementation
> > >> of
> > >> > >> > > GridCacheAdapter#localSizeLong(int partition, CachePeekMode[]
> > >> > >> peekModes)
> > >> > >> > > method.
> > >> > >> > >
> > >> > >> > > On Sat, Jun 18, 2016 at 12:19 PM, Saikat Maitra <
> > >> > >> saikat.mai...@gmail.com
> > >> > >> > >
> > >> > >> > > wrote:
> > >> > >> > >
> > >> > >> > > > Hi
> > >> > >> > > >
> > >> > >> > > > I have raised the PR[1] for the jira ticket Ignite 3227 [2]
> > and
> > >> > >> wanted
> > >> > >> > to
> > >> > >> > > > discuss further on this issue.
> > >> > >> > > >
> > >> > >> > > > 1. I am running 2 nodes cluster and running in client mode
> > >> another
> > >> > >> node
> > >> > >> > > for
> > >> > >> > > > functional test. I added 20 keys and keys are distributed
> in
> > 2
> > >> > >> nodes as
> > >> > >> > > 11
> > >> > >> > > > keys in node 1 and 9 keys in node 2. When I am printing
> > >> partition
> > >> > 1
> > >> > >> > size
> > >> > >> > > > and partition 2 size I can get correct values but incase I
> > >> provide
> > >> > >> some
> > >> > >> > > > other partition like 5 I am observing that I am getting 11
> as
> > >> > value.
> > >> > >> > > >
> > >> > >> > > > 2. I have added unit test testpartitionsize() similar to
> > >> > testSize()
> > >> > >> but
> > >> > >> > > > similar tests are failing for both the tests. Need further
> > >> > >> > investigation
> > >> > >> > > on
> > >> > >> > > > the same.
> > >> > >> > > >
> > >> > >> > > >
> > >> > >> > > > Regards
> > >> > >> > > > Saikat
> > >> > >> > > >
> > >> > >> > > > [1] https://github.com/apache/ignite/pull/815
> > >> > >> > > > [2] https://issues.apache.org/jira/browse/IGNITE-3227
> > >> > >> > > >
> > >> > >> > >
> > >> > >> > >
> > >> > >> > >
> > >> > >> > > --
> > >> > >> > > Best regards,
> > >> > >> > > Ilya
> > >> > >> > >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >>
> >
>

[GitHub] ignite pull request #815: IGNITE-3227 IgniteCache: add method to calculate s...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #859: Ignite 3414 tests

[iveselovskiy]

GitHub user iveselovskiy opened a pull request:

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

Ignite 3414 tests

ignite-3414-tests, PRQ for tests .

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

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

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

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


commit 8083391be726c2bbc27e018983ca713e4b25e2a2
Author: vozerov-gridgain 
Date:   2016-03-14T10:17:58Z

IGNITE-2814: IGFS: File lock/unlock/reserve operations are no longer 
require put/replace on cache. Thin entry processors are used instead.

commit a7c1f44420ae96f183abc2e17125f0c9aa0775d5
Author: vozerov-gridgain 
Date:   2016-03-14T12:57:28Z

IGNITE-2828: IGFS: Introduced processor for "updateTimes" operation.

commit ba30ddbc599d67f398ffba1263d174f5b58b4b7d
Author: thatcoach 
Date:   2016-03-15T17:46:13Z

IGNITE-2838: IGFS: Opimized format of IgfsListingEntry. Now it contains 
only file ID and boolean flag endicating whether this a directory or file.

commit 4f7e3c1c2e82596a26cec3b3587991ae18078b64
Author: vozerov-gridgain 
Date:   2016-03-16T06:14:49Z

IGNITE-2817: IGFS: Optimized "updateProperties" and several other cache 
operations. Reafactored IgfsMetaManager a bit to simplify work with cache.

commit 3e59321ef0ae1d936d94f8f804db45ceeff55844
Author: vozerov-gridgain 
Date:   2016-03-16T09:31:37Z

IGNITE-2842: IGFS: Optimized create/mkdirs operations with help of entry 
processors.

commit f57f3657b1da33abf28f885cd405780dabfd57e3
Author: vozerov-gridgain 
Date:   2016-03-16T10:22:07Z

IGNITE-2846: IGFS: Reworked IgfsMetaManager.updateInfo() operation to use 
"invoke" instead of "put".

commit 8a93c3bf1687e6f2de1a4391d95366d733a44a7d
Author: vozerov-gridgain 
Date:   2016-03-18T13:38:45Z

IGNITE-2860: IGFS: Reworked base meta operations.

commit 8e9e790e482b8911142bf8b21fa3ad7267a62db6
Author: vozerov-gridgain 
Date:   2016-03-18T14:07:58Z

IGNITE-2834: IGFS: Implemented optional metadata co-location.

commit bfa7bf6c3d693406f1dd5121488796687aebbe7d
Author: vozerov-gridgain 
Date:   2016-03-18T14:45:48Z

IGNITE-2813: IGFS: Optimized metadata values splitting file and directory 
into separate classes.

commit 8de40f2f8649c9ffecf86202f9fd4efbc3827e83
Author: thatcoach 
Date:   2016-03-18T18:15:04Z

IGNITE-2860: IGFS: Fixed minor bug in append() operation.

commit 9a4b5bd720c5ed1f96b82a457fa3eaed1bdbb132
Author: thatcoach 
Date:   2016-03-19T18:13:35Z

IGNITE-2861: IGFS: Moved metadata processors into separate top-level 
classes to simplify code. Also cleaned up IgfsMetaManager from unused code.

commit 2cd0dcb37ce43a4cb07885ddfb2e72392fc814a7
Author: vozerov-gridgain 
Date:   2016-03-21T07:29:20Z

IGNITE-2836: IGFS: Ensured that metadata can be serialized through 
BinaryMarshaller in the most efficient way.

commit 76191ff39456a30246df3aca7c026773d00a8446
Author: vozerov-gridgain 
Date:   2016-03-21T07:36:26Z

IGNITE-2861: Added missing Apache headers.

commit ee5ea53bf9c4ad897459466e0b9b5447fc93ec2a
Author: vozerov-gridgain 
Date:   2016-03-22T06:20:32Z

IGNITE-2869: IGFS: Slightly improved serialization of IgfsListingEntry.

commit 218132dc0c3764966294a5f29ad480af4af7b0ff
Author: vozerov-gridgain 
Date:   2016-03-22T06:23:29Z

IGNITE-2868: IGFS: Increased trash concurrency from 16 to 64.

commit e886ad0aa800cddb3308fa5f8400902e5879ee3c
Author: vozerov-gridgain 
Date:   2016-03-22T07:28:13Z

IGNITE-2811: IGFS: Optimized properties handling.

commit 8d95ebacaa01f3f9271a1ce0d1b991dfead1d0c1
Author: vozerov-gridgain 
Date:   2016-03-22T09:06:51Z

IGNITE-2871: IGFS: Removed "path" from IgfsEntryInfo. Purge event is never 
fired now, it will be fixed as a part of IGNITE-1679.

commit b286facc4b8c44ab1628039dded6c7527760df73
Author: vozerov-gridgain 
Date:   2016-03-22T09:34:35Z

IGNITE-2806: IGFS: Implemented relaxed consistency model.

commit 26f115734e7262d4b4b60f1c6016783f67c66986
Author: vozerov-gridgain 
Date:   2016-03-22T09:46:23Z

IGFS: Added misssing "final" modifiers to FileSystemConfiguration defaults.

commit 00a0e4b51c299871ff690bbe6d462cf80dae045e
Author: vozerov-gridgain 
Date:   2016-03-24T07:35:43Z

IGNITE-2878: IGFS: Optimzied serialization of IgfsListingEntry and 
properties map.

commit 

[GitHub] ignite pull request #858: Ignite 3413

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

Ignite 3413



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

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

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

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


commit 85307ea3db04b259bd605802a15f7bf464dbdb10
Author: Alexander Paschenko 
Date:   2016-07-07T13:01:10Z

IGNITE-3413 CacheContinuousQueryHandler - handle and wrap 
NoClassDefFoundErrors occurring inside getEventFilter()

commit e9d7f65110a97b8744e4bb5ec3bae7630a4e6e4a
Author: Alexander Paschenko 
Date:   2016-07-07T17:09:00Z

IGNITE-3413 CacheContinuousQueryHandler - do not wrap and rethrow cache 
entry event filter instantiation exception, rather ignore it




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: IGNITE-2795

[Alexei Scherbakov]

I've updated the fix.

Currently all the copying is performed inside query iterators only if
needed.

2016-07-07 14:38 GMT+03:00 Alexei Scherbakov :

> Denis,
>
> I think the current state of fix for SQL queries is consistent with the
> highlighted topics, except
>
> - server node mustn’t create a copy if a result set will be transferred to
> a remote node;
>
> I afraid it would be difficult to implement without interfering with
> current implementation too much.
> Will look at this more thoughtfully.
>
> Anyway, it would be useful for me if someone will review the current state
> and provide suggestions.
>
>
> 2016-07-07 13:32 GMT+03:00 Denis Magda :
>
>> I would say that, yes, we should make copyOnRead flag consistent across
>> all cache ‘get’ like operations. However we need to make sure that the copy
>> is not created in the following cases
>>
>> - server node mustn’t create a copy if a result set will be transferred
>> to a remote node;
>> - client node or other remote node mustn’t create a copy after it
>> receives the result set from the other node.
>>
>> All this means that the copy has to be created if:
>> - node (server) executes local queries or iterates over local data set;
>> - client does the same executing queries or iterating over its local
>> cache.
>> - in my understanding, in OFF_HEAP mode in doesn’t make sense to make a
>> copy in any case since Java heap already has a copy of data from off heap.
>> However this part must be clarified by someone else from the community.
>>
>> Would you mind covering this scenarios in the tests and implementation?
>>
>> Igniters, other thoughts on this?
>>
>> —
>> Denis
>>
>> > On Jul 7, 2016, at 12:18 PM, Alexei Scherbakov <
>> alexey.scherbak...@gmail.com> wrote:
>> >
>> > Igniters,
>> >
>> > I implemented a fix for copy-on-read semantics for cache objects
>> returned
>> > from SQL queries and need a review.
>> >
>> > See the issue for
>> > details on PR.
>> >
>> > While developing a fix I also noticed the same bug in local cache
>> > iterators.
>> >
>> > To make a behavior of copyOnRead consistent across all cache
>> operations, I
>> > think we should fix it as well.
>> >
>> > Thoughts?
>> >
>> > --
>> >
>> > Best regards,
>> > Alexei Scherbakov
>>
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>



-- 

Best regards,
Alexei Scherbakov

Implement collecting what SQL statements executed on cluster and their metrics.

[Alexey Kuznetsov]

Hi, All!

I'm working on issue "Implement collecting what SQL statements executed on
cluster and their metrics" [1]

For now I'm investigating code and have following questions:

1) We have different types of queries:  GridCacheQueryType: SPI, SCAN, SQL,
SQL_FIELDS, TEXT, SET
Should I implement collecting metrics for ALL of them?
Or for example I could collect:
   SCAN: cache name
   SQL: type name + SQL clauseю
   SQL_FIELDS: SQL statement text
   TEXT: type + searched string

What I could collect for SPI and SET query types? Or I may ignore them?

2) What metrics I could collect? For now I could collect per query:
  Number of executions.
  Number of failures.
  Duration.
Is there something else I could collect?


3) Configuration.
  Should we have this feature configured per cache or globally on
IgniteConfiguration?
  Should this feature be ON or OFF by default?
  How many items I could collect by default? 100? 1000?

Any comments are welcome.

--
https://issues.apache.org/jira/browse/IGNITE-3443

-- 
Alexey Kuznetsov

Re: ignite-2310

[Taras Ledkov]

Igniters,

The issue https://issues.apache.org/jira/browse/IGNITE-2310 is updated 
with comment

about the changes at the IgniteCompute. Please comment the ticket.

The changed javadoc of the affinityRun/Call is available to review at 
the branch

https://github.com/gridgain/apache-ignite/blob/ignite-2310/modules/core/src/main/java/org/apache/ignite/IgniteCompute.java#L123

07.07.2016 14:13, Dmitriy Setrakyan пишет:

Taras, it is very difficult to review API changes this way. Can you please
provide additional APIs in the ticket?

Also, we should add documentation about reserving partitions as well. To my
knowledge, this feature ensures that a partition will not be migrated while
affinityRun/Call is executed, right?

On Thu, Jul 7, 2016 at 3:02 AM, Taras Ledkov  wrote:


Igniters,

Please take a look at the next proposal of changes at
IgniteCompute.affinityRun / affinityCall:


https://github.com/gridgain/apache-ignite/commit/c57f009c44e07240fc8c8e6feed3271c63f31664#diff-b276b8e6e14915f9e5f2f5daeeddec8a

So, two methods is added affinityRun and affinityCall. There is additional
parameter Collection of extra caches names.
An affinity job without the extra caches reserves only one partition (that
contains affinity key) of the affinity cache.
An affinity job with the extra caches parameter reserves the partitions
(similar to affinity partition) of all extra caches.


06.07.2016 15:18, Semyon Boikov wrote:


I think we should detect such situation and throw exception. As I remember
for cross cache qieries we throw exception if caches have different
partitions distribution.

On Wed, Jul 6, 2016 at 3:14 PM, Yakov Zhdanov 
wrote:

Guys, this does not work in general case. If you provide more than one

partition you can end up with a situation when they reside on more than
one
node.

--Yakov

2016-07-06 13:50 GMT+03:00 Vladimir Ozerov :

If we add "partsToLock" to job execute request, then why we allow it only

for "affinity" methods? We can resort to "with" semantics instead:

IgniteCompute.*withPartitionsToLock*(...).affinityRun();

On Wed, Jul 6, 2016 at 12:23 PM, Taras Ledkov 
wrote:

Igniters,

Lets discuss the changes of public API at the IgniteCompute.
The new methods affinityRun & affinityCall is added by working on
IGNITE-2310.

https://issues.apache.org/jira/browse/IGNITE-2310

Please take a look at the signature of the new methods:





https://github.com/gridgain/apache-ignite/commit/991fb60f563ee1630152ca0159d04b4969f883bf#diff-b276b8e6e14915f9e5f2f5daeeddec8a


void affinityRun(@Nullable String cacheName, Object affKey,
IgniteRunnable


job, Map partsToLock)

The parameter Map partsToLock is added.
Map contains the pairs of the cache name and array of partitions that


must


be reserved on the target node before job execution.

Dmitry, colleagues, please comment or approve.

--
Taras Ledkov
Mail-To: tled...@gridgain.com




--
Taras Ledkov
Mail-To: tled...@gridgain.com




--
Taras Ledkov
Mail-To: tled...@gridgain.com

Re: IGNITE-2795

[Alexei Scherbakov]

Denis,

I think the current state of fix for SQL queries is consistent with the
highlighted topics, except

- server node mustn’t create a copy if a result set will be transferred to
a remote node;

I afraid it would be difficult to implement without interfering with
current implementation too much.
Will look at this more thoughtfully.

Anyway, it would be useful for me if someone will review the current state
and provide suggestions.


2016-07-07 13:32 GMT+03:00 Denis Magda :

> I would say that, yes, we should make copyOnRead flag consistent across
> all cache ‘get’ like operations. However we need to make sure that the copy
> is not created in the following cases
>
> - server node mustn’t create a copy if a result set will be transferred to
> a remote node;
> - client node or other remote node mustn’t create a copy after it receives
> the result set from the other node.
>
> All this means that the copy has to be created if:
> - node (server) executes local queries or iterates over local data set;
> - client does the same executing queries or iterating over its local cache.
> - in my understanding, in OFF_HEAP mode in doesn’t make sense to make a
> copy in any case since Java heap already has a copy of data from off heap.
> However this part must be clarified by someone else from the community.
>
> Would you mind covering this scenarios in the tests and implementation?
>
> Igniters, other thoughts on this?
>
> —
> Denis
>
> > On Jul 7, 2016, at 12:18 PM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
> >
> > Igniters,
> >
> > I implemented a fix for copy-on-read semantics for cache objects returned
> > from SQL queries and need a review.
> >
> > See the issue for
> > details on PR.
> >
> > While developing a fix I also noticed the same bug in local cache
> > iterators.
> >
> > To make a behavior of copyOnRead consistent across all cache operations,
> I
> > think we should fix it as well.
> >
> > Thoughts?
> >
> > --
> >
> > Best regards,
> > Alexei Scherbakov
>
>


-- 

Best regards,
Alexei Scherbakov

Re: ignite-2310

[Dmitriy Setrakyan]

Taras, it is very difficult to review API changes this way. Can you please
provide additional APIs in the ticket?

Also, we should add documentation about reserving partitions as well. To my
knowledge, this feature ensures that a partition will not be migrated while
affinityRun/Call is executed, right?

On Thu, Jul 7, 2016 at 3:02 AM, Taras Ledkov  wrote:

> Igniters,
>
> Please take a look at the next proposal of changes at
> IgniteCompute.affinityRun / affinityCall:
>
>
> https://github.com/gridgain/apache-ignite/commit/c57f009c44e07240fc8c8e6feed3271c63f31664#diff-b276b8e6e14915f9e5f2f5daeeddec8a
>
> So, two methods is added affinityRun and affinityCall. There is additional
> parameter Collection of extra caches names.
> An affinity job without the extra caches reserves only one partition (that
> contains affinity key) of the affinity cache.
> An affinity job with the extra caches parameter reserves the partitions
> (similar to affinity partition) of all extra caches.
>
>
> 06.07.2016 15:18, Semyon Boikov wrote:
>
>> I think we should detect such situation and throw exception. As I remember
>> for cross cache qieries we throw exception if caches have different
>> partitions distribution.
>>
>> On Wed, Jul 6, 2016 at 3:14 PM, Yakov Zhdanov 
>> wrote:
>>
>> Guys, this does not work in general case. If you provide more than one
>>> partition you can end up with a situation when they reside on more than
>>> one
>>> node.
>>>
>>> --Yakov
>>>
>>> 2016-07-06 13:50 GMT+03:00 Vladimir Ozerov :
>>>
>>> If we add "partsToLock" to job execute request, then why we allow it only
 for "affinity" methods? We can resort to "with" semantics instead:

 IgniteCompute.*withPartitionsToLock*(...).affinityRun();

 On Wed, Jul 6, 2016 at 12:23 PM, Taras Ledkov 
 wrote:

 Igniters,
>
> Lets discuss the changes of public API at the IgniteCompute.
> The new methods affinityRun & affinityCall is added by working on
> IGNITE-2310.
>
> https://issues.apache.org/jira/browse/IGNITE-2310
>
> Please take a look at the signature of the new methods:
>
>
>
>
>>> https://github.com/gridgain/apache-ignite/commit/991fb60f563ee1630152ca0159d04b4969f883bf#diff-b276b8e6e14915f9e5f2f5daeeddec8a
>>>
 void affinityRun(@Nullable String cacheName, Object affKey,
>
 IgniteRunnable

> job, Map partsToLock)
>
> The parameter Map partsToLock is added.
> Map contains the pairs of the cache name and array of partitions that
>
 must

> be reserved on the target node before job execution.
>
> Dmitry, colleagues, please comment or approve.
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>

Re: IGNITE-2795

[Denis Magda]

I would say that, yes, we should make copyOnRead flag consistent across all 
cache ‘get’ like operations. However we need to make sure that the copy is not 
created in the following cases

- server node mustn’t create a copy if a result set will be transferred to a 
remote node;
- client node or other remote node mustn’t create a copy after it receives the 
result set from the other node.

All this means that the copy has to be created if:
- node (server) executes local queries or iterates over local data set;
- client does the same executing queries or iterating over its local cache.
- in my understanding, in OFF_HEAP mode in doesn’t make sense to make a copy in 
any case since Java heap already has a copy of data from off heap. However this 
part must be clarified by someone else from the community.

Would you mind covering this scenarios in the tests and implementation?

Igniters, other thoughts on this?

—
Denis

> On Jul 7, 2016, at 12:18 PM, Alexei Scherbakov  
> wrote:
> 
> Igniters,
> 
> I implemented a fix for copy-on-read semantics for cache objects returned
> from SQL queries and need a review.
> 
> See the issue for
> details on PR.
> 
> While developing a fix I also noticed the same bug in local cache
> iterators.
> 
> To make a behavior of copyOnRead consistent across all cache operations, I
> think we should fix it as well.
> 
> Thoughts?
> 
> -- 
> 
> Best regards,
> Alexei Scherbakov

[GitHub] ignite pull request #857: Ignite 2310 Lock cache partition for affinityRun/a...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

Ignite 2310 Lock cache partition for affinityRun/affinityCall execution



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

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

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

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


commit aa8dcd11aa311e6dd639e0a25c5b0eb714e663ad
Author: nikolay_tikhonov 
Date:   2016-03-23T12:47:17Z

Fixed Ignite Client Nodes suite.

commit 4cb994a7253c6b493b4a376ed1489513ecefd8f9
Author: nikolay_tikhonov 
Date:   2016-03-25T08:20:39Z

IGNITE-GG-11048 Fix missed event notification in remove-remove case.

commit 31ae7ea791e258c49f1b25944cba75fd08d0ca49
Author: nikolay_tikhonov 
Date:   2016-03-25T09:37:25Z

Removed isDebug from test.

commit 1c04005c08ae7ca2006d6f2f687a95c2638c73fc
Author: nikolay_tikhonov 
Date:   2016-03-25T12:22:37Z

IGNITE-GG-11048 Added tests.

commit 53a87290fe028e12a81058fc4b2f2f2341395f9a
Author: Tikhonov Nikolay 
Date:   2016-03-25T16:49:31Z

Fixed tests (renamed test methods).

commit ce56625099b5253f8baf27bfbcff4682787a5ee1
Author: Anton Vinogradov 
Date:   2016-03-28T11:13:20Z

Query Suite separation : 1,2,3

commit 08f5981509711e65c0d4c6fc1209068f8958eb06
Author: vozerov-gridgain 
Date:   2016-03-28T09:24:16Z

Support optional IO policy resolver in DataStreamer.

commit 60e74618b310dafc28eb5f935859fed4ec87584c
Author: vozerov-gridgain 
Date:   2016-03-28T11:52:13Z

Merge remote-tracking branch 'upstream/gridgain-7.5.10' into gridgain-7.5.10

commit 9e84e508a394b790ef046cdcf2a015bcf853c064
Author: nikolay_tikhonov 
Date:   2016-03-28T13:59:56Z

Divide test suite.

commit d36a2e51e3aa3105dff73839c84e52a531fbd918
Author: Denis Magda 
Date:   2016-03-24T17:07:48Z

IGNITE-2849: BinaryObjectBuilder doesn't properly check metadata

commit 9e62b667e73396d3affbc4d1e62449d07d08ec8b
Author: Anton Vinogradov 
Date:   2016-03-29T11:56:21Z

 IGNITE-2801 Coordinator floods network with partitions full map exchange 
messages

commit 85a675b7bfbc54745ee9ce95d5786b5bae5be963
Author: iveselovskiy 
Date:   2016-01-18T14:28:42Z

IGNITE-1788: Removed duplicate check of a single invariant from 
IgfsProcessor.  This closes #221.

commit 0e753c38a986cbd46eb24845808ec1d0fc7d1dea
Author: dkarachentsev 
Date:   2016-02-10T09:38:43Z

IGNITE-2575: Added validation of IGFS endpoint port value. This closes #469.

commit 99028b509c736b79faac7fb8104b1bc3cfe30720
Author: vozerov-gridgain 
Date:   2016-03-03T09:56:55Z

IGFS: Minor refactoring.

commit 219238f2793a3f3f9f5705a065c67510c286df1c
Author: vozerov-gridgain 
Date:   2016-03-03T10:25:43Z

IGNITE-2754: IGFS: Created separate processor for listing remove operation.

commit ff5b68ca69050817794ef4b142c955a186e03de9
Author: vozerov-gridgain 
Date:   2016-03-14T07:19:23Z

IGNITE-2781: IGFS: Force "copyOnRead=false" for meta and data caches.

commit 37c4d508c9e40dcba274ae1625d7bf59bfeef144
Author: vozerov-gridgain 
Date:   2016-03-14T08:49:03Z

IGNITE-2810: IGFS: Striped trash directory to reduce contention during 
removals.

commit 54e6991cb1d0b68c4490dede603c9e3ba7cc3b9e
Author: vozerov-gridgain 
Date:   2016-03-14T09:05:39Z

IGNITE-2810: IGFS: Minor correction to IgfsUtils.isRootOrTrashId() method.

commit 8083391be726c2bbc27e018983ca713e4b25e2a2
Author: vozerov-gridgain 
Date:   2016-03-14T10:17:58Z

IGNITE-2814: IGFS: File lock/unlock/reserve operations are no longer 
require put/replace on cache. Thin entry processors are used instead.

commit a7c1f44420ae96f183abc2e17125f0c9aa0775d5
Author: vozerov-gridgain 
Date:   2016-03-14T12:57:28Z

IGNITE-2828: IGFS: Introduced processor for "updateTimes" operation.

commit ba30ddbc599d67f398ffba1263d174f5b58b4b7d
Author: thatcoach 
Date:   2016-03-15T17:46:13Z

IGNITE-2838: IGFS: Opimized format of IgfsListingEntry. Now it contains 
only file ID and boolean flag endicating whether this a directory or file.

commit 4f7e3c1c2e82596a26cec3b3587991ae18078b64
Author: vozerov-gridgain 
Date:   2016-03-16T06:14:49Z

IGNITE-2817: IGFS: Optimized "updateProperties" and several other cache 
operations. Reafactored IgfsMetaManager a bit to simplify work with 

Re: ignite-2310

[Taras Ledkov]

Igniters,

Please take a look at the next proposal of changes at 
IgniteCompute.affinityRun / affinityCall:


https://github.com/gridgain/apache-ignite/commit/c57f009c44e07240fc8c8e6feed3271c63f31664#diff-b276b8e6e14915f9e5f2f5daeeddec8a

So, two methods is added affinityRun and affinityCall. There is 
additional parameter Collection of extra caches names.
An affinity job without the extra caches reserves only one partition 
(that contains affinity key) of the affinity cache.
An affinity job with the extra caches parameter reserves the partitions 
(similar to affinity partition) of all extra caches.


06.07.2016 15:18, Semyon Boikov wrote:

I think we should detect such situation and throw exception. As I remember
for cross cache qieries we throw exception if caches have different
partitions distribution.

On Wed, Jul 6, 2016 at 3:14 PM, Yakov Zhdanov  wrote:


Guys, this does not work in general case. If you provide more than one
partition you can end up with a situation when they reside on more than one
node.

--Yakov

2016-07-06 13:50 GMT+03:00 Vladimir Ozerov :


If we add "partsToLock" to job execute request, then why we allow it only
for "affinity" methods? We can resort to "with" semantics instead:

IgniteCompute.*withPartitionsToLock*(...).affinityRun();

On Wed, Jul 6, 2016 at 12:23 PM, Taras Ledkov 
wrote:


Igniters,

Lets discuss the changes of public API at the IgniteCompute.
The new methods affinityRun & affinityCall is added by working on
IGNITE-2310.

https://issues.apache.org/jira/browse/IGNITE-2310

Please take a look at the signature of the new methods:




https://github.com/gridgain/apache-ignite/commit/991fb60f563ee1630152ca0159d04b4969f883bf#diff-b276b8e6e14915f9e5f2f5daeeddec8a

void affinityRun(@Nullable String cacheName, Object affKey,

IgniteRunnable

job, Map partsToLock)

The parameter Map partsToLock is added.
Map contains the pairs of the cache name and array of partitions that

must

be reserved on the target node before job execution.

Dmitry, colleagues, please comment or approve.

--
Taras Ledkov
Mail-To: tled...@gridgain.com




--
Taras Ledkov
Mail-To: tled...@gridgain.com

IGNITE-2795

[Alexei Scherbakov]

Igniters,

I implemented a fix for copy-on-read semantics for cache objects returned
from SQL queries and need a review.

See the issue for
details on PR.

While developing a fix I also noticed the same bug in local cache
iterators.

To make a behavior of copyOnRead consistent across all cache operations, I
think we should fix it as well.

Thoughts?

-- 

Best regards,
Alexei Scherbakov

[jira] [Created] (IGNITE-3447) put/get value by AffinityKey

[Ranger Tsao (JIRA)]

Ranger Tsao created IGNITE-3447:
---

 Summary: put/get value by AffinityKey
 Key: IGNITE-3447
 URL: https://issues.apache.org/jira/browse/IGNITE-3447
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 1.6
 Environment: jdk1.8 ,mac OS EI
Reporter: Ranger Tsao


code is :

IgniteCache ac = ignite.getOrCreateCache("address");
AffinityKey ak1 = new AffinityKey<>("mok");
AffinityKey ak2 = new AffinityKey<>("mok", "mok");
ac.put(ak1, new Address("west"));
ac.put(ak2, new Address("east"));

when ac.put(ak1, new Address("west"));

throw exception:
Exception in thread "main" java.lang.NullPointerException
at 
org.apache.ignite.cache.affinity.rendezvous.RendezvousAffinityFunction.partition(RendezvousAffinityFunction.java:428)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.partition(GridCacheAffinityManager.java:206)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primary(GridCacheAffinityManager.java:278)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapSingleUpdate(GridNearAtomicSingleUpdateFuture.java:601)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:517)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:433)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:202)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$22.apply(GridDhtAtomicCache.java:1007)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$22.apply(GridDhtAtomicCache.java:1005)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:703)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAsync0(GridDhtAtomicCache.java:1005)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:475)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2506)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:452)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2180)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1165)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3446) Visor CMD: improve usability for batch mode

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-3446:


 Summary: Visor CMD: improve usability for batch mode
 Key: IGNITE-3446
 URL: https://issues.apache.org/jira/browse/IGNITE-3446
 Project: Ignite
  Issue Type: Task
  Components: visor
Reporter: Alexey Kuznetsov
 Fix For: 1.7


# Do not require confirmation in batch mode.
# Add two new variables: @n - will return oldest node in cluster, @nl - will 
return oldest local node on host where visor cmd is running
# Add options --all-local --all-remote to kill command.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-3445) Web console: Invalid message on save of profile.

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-3445:
-

 Summary: Web console: Invalid message on save of profile.
 Key: IGNITE-3445
 URL: https://issues.apache.org/jira/browse/IGNITE-3445
 Project: Ignite
  Issue Type: Sub-task
  Components: wizards
Affects Versions: 1.7
Reporter: Vasiliy Sisko


Change profile email to other registered and try to save.
Invalid message is shown: *Failed to save profile: [object Object]*



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)