[jira] [Created] (IGNITE-5838) The IgniteCache.loadCacheAsync method is not executed asynchronously.

[Yujue Li (JIRA)]

Yujue Li created IGNITE-5838:


 Summary: The IgniteCache.loadCacheAsync method is not executed 
asynchronously.
 Key: IGNITE-5838
 URL: https://issues.apache.org/jira/browse/IGNITE-5838
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Yujue Li
Priority: Blocker
 Fix For: 2.2


The IgniteCache.loadCacheAsync method is not executed asynchronously.
for example,in the 
https://github.com/apache/ignite/blob/master/examples/src/main/java/org/apache/ignite/examples/datagrid/store/spring/CacheSpringStoreExample.java:
line 129:
If modified to:
cache.loadCacheAsync(null, ENTRY_COUNT);
We will find that the cache is not loaded asynchronously.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Cache Metrics

[Denis Magda]

Andrey,

I would simply take an average if a mixed clients-servers cluster group is used.

In general, the goal of the ticket was to fix the time-based metrics on the 
server side. As far as I understand they are already calculated properly on the 
client’s considering network contribution, right? So, all that’s left to do is 
to count the same on the servers so that those metrics no longer return 0.

—
Denis
 
> On Jul 25, 2017, at 6:53 AM, Andrey Gura  wrote:
> 
> Den,
> 
> doesn't make sense from my point if view. And we create new problem:
> how should we aggregate this metrics when user requests metrics for
> cluster group.
> 
> On Mon, Jul 24, 2017 at 8:48 PM, Denis Magda  wrote:
>> Guys,
>> 
>> What if we calculate it on both sides? The client will keep the total time 
>> needed to complete an operation including network hoops while a server 
>> (primary or backup) will count only local time.
>> 
>> —
>> Denis
>> 
>>> On Jul 17, 2017, at 7:07 AM, Andrey Gura  wrote:
>>> 
>>> Hi,
>>> 
>>> I believe that the first solution is better than second because it
>>> takes into account network communication time. Average time of
>>> communication between nodes doesn't make sense from my point of view.
>>> 
>>> So I vote for #1.
>>> 
>>> On Thu, Jul 13, 2017 at 11:52 PM, Вячеслав Коптилин
>>>  wrote:
 Hi Experts,
 
 I am working on https://issues.apache.org/jira/browse/IGNITE-3495
 
 A few words about this issue:
 It is about that the process of gathering/updating of cache metrics is
 inconsistent in some cases.
 Let's consider the following simple topology which contains only two nodes:
 first node is a client node and the second is a server.
 And client node starts requests to the server node, for instance
 cache.put(), cache.putAll(), cache.get() etc.
 In that case, metrics which are related to counters (cache hits, cache
 misses, removals and puts) are calculated on the server side,
 while time metrics are updated on the client node.
 
 I think that both metrics (counters and time) should be calculated on the
 same node. So, there are two obvious solution:
 
 #1 Node that starts some operation is responsible for updating the cache
 metrics.
 Pro:
 - it will allow to get more accurate results of metrics.
 Contra:
 - this approach does not work in particular cases. for example, partitioned
 cache with FULL_ASYNC write synchronization mode.
 - needs to extend response messages (GridNearAtomicUpdateResponse,
 GridNearGetResponse etc)
 in order to provide additional information from remote node: cache hits,
 number of removal etc.
 So, it will lead to additional pressure on communication channel.
 Perhaps, this impact will be small - 4 bytes per message or something like
 that.
 - backward incompatibility (this is a consequence of the previous point)
 
 #2 Primary node (node that actually executes a request)
 Pro:
 - easy to implement
 - backward compatible
 Contra:
 - time metrics will not include the time of communication between nodes, so
 the results will be less accurate.
 - perhaps we need to provide additional metric which will allow to get avg
 time of communication between nodes.
 
 Please let me know about your thoughts.
 Perhaps, both alternatives are not so good...
 
 Regards,
 Slava.
>> 

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Roman Shtykh]

+1 (non-binding) -- Roman



On Monday, July 24, 2017 10:32 PM, Anton Vinogradov  wrote:
 

 Igniters,

This vote based on same files as RC3.
Only one change is that I signed zips with my signature.
KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS) was
updated as well.

We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
This vote will go for 72 hours but may be closed earlier if Konstantin
Boudnik confirmed security issue solved.

We have uploaded a 2.1.0 release candidate to
https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/

Git tag name is
2.1.0-rc4

This release includes the following changes:

Ignite:
* Persistent cache store
* Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
* Deprecated IgniteConfiguration.marshaller
* Updated Lucene dependency to version 5.5.2
* Machine learning: implemented K-means clusterization algorithm optimized
for distributed storages
* SQL: CREATE TABLE and DROP TABLE commands support
* SQL: New thin JDBC driver
* SQL: Improved performance of certain queries, when affinity node can be
calculated in advance
* SQL: Fixed return type of AVG() function
* SQL: BLOB type support added to thick JDBC driver
* SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
* SQL: Added FieldsQueryCursor interface to get fields metadata for
SqlFieldsQuery
* ODBC: Implemented DML statement batching
* Massive performance and stability improvements

Ignite.NET:
* Automatic remote assembly loading
* NuGet-based standalone node deployment
* Added conditional data removeal via LINQ DeleteAll
* Added TimestampAttribute to control DateTime serialization mode
* Added local collections joins support to LINQ.

Ignite CPP:
* Added Compute::Call and Compute::Broadcast methods

Web Console:
* Implemented support for UNIQUE indexes for key fields on import model
from RDBMS
* Added option to show full stack trace on Queries screen
* Added PK alias generation on Models screen.

Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
20resolved)

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4

RELEASE NOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4

Please start voting.

+1 - to accept Apache Ignite 2.1.0-rc4
0 - don't care either way
-1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)

This vote will go for 72 hours.


   

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Andrey Gura]

+1 (non-binding)

On Wed, Jul 26, 2017 at 12:35 AM, Konstantin Boudnik  wrote:
> +1 [binding]
>
> - Checked the signature
> - Checked the sha1
> - Successfully ran the build
> - RAT is clean
>
> Things that need to be improved in the next release:
> - neither sha1 nor md5 are trustful checksum'ing methods and aren't
>   guaranteeing the authenticity of the source archive. We should be switching
>   to at least sha265 or higher. This has been brought up since the incubation.
>   And warrants for -1 in the next release.
>
> Cos
>
> On Mon, Jul 24, 2017 at 04:32PM, Anton Vinogradov wrote:
>> Igniters,
>>
>> This vote based on same files as RC3.
>> Only one change is that I signed zips with my signature.
>> KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS) was
>> updated as well.
>>
>> We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
>> This vote will go for 72 hours but may be closed earlier if Konstantin
>> Boudnik confirmed security issue solved.
>>
>> We have uploaded a 2.1.0 release candidate to
>> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
>>
>> Git tag name is
>> 2.1.0-rc4
>>
>> This release includes the following changes:
>>
>> Ignite:
>> * Persistent cache store
>> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
>> * Deprecated IgniteConfiguration.marshaller
>> * Updated Lucene dependency to version 5.5.2
>> * Machine learning: implemented K-means clusterization algorithm optimized
>> for distributed storages
>> * SQL: CREATE TABLE and DROP TABLE commands support
>> * SQL: New thin JDBC driver
>> * SQL: Improved performance of certain queries, when affinity node can be
>> calculated in advance
>> * SQL: Fixed return type of AVG() function
>> * SQL: BLOB type support added to thick JDBC driver
>> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
>> * SQL: Added FieldsQueryCursor interface to get fields metadata for
>> SqlFieldsQuery
>> * ODBC: Implemented DML statement batching
>> * Massive performance and stability improvements
>>
>> Ignite.NET:
>> * Automatic remote assembly loading
>> * NuGet-based standalone node deployment
>> * Added conditional data removeal via LINQ DeleteAll
>> * Added TimestampAttribute to control DateTime serialization mode
>> * Added local collections joins support to LINQ.
>>
>> Ignite CPP:
>> * Added Compute::Call and Compute::Broadcast methods
>>
>> Web Console:
>> * Implemented support for UNIQUE indexes for key fields on import model
>> from RDBMS
>> * Added option to show full stack trace on Queries screen
>> * Added PK alias generation on Models screen.
>>
>> Complete list of closed issues:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
>> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
>> 20resolved)
>>
>> DEVNOTES
>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
>>
>> RELEASE NOTES
>> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
>>
>> Please start voting.
>>
>> +1 - to accept Apache Ignite 2.1.0-rc4
>> 0 - don't care either way
>> -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
>>
>> This vote will go for 72 hours.

[GitHub] ignite pull request #2345: IGNITE-5837 Test logic fix.

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5837 Test logic fix.



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

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

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

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


commit 9b91cecdd2cc2fc62a6d8b2eb87f7cd2240f7703
Author: Alexander Paschenko 
Date:   2017-07-25T23:01:34Z

IGNITE-5837 Test logic fix.




---
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 #2344: IGNITE-5572

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5572

ALTER TABLE ADD COLUMN

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

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

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

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


commit 5ccc0e250e91f662fe012bd2c000d67974582b19
Author: Alexander Paschenko 
Date:   2017-07-19T19:00:47Z

IGNITE-5572 ALTER TABLE ADD COLUMN parsing

commit 1602c29f1e4c73f6b926da12f1ad944564529acc
Author: Alexander Paschenko 
Date:   2017-07-25T15:37:48Z

IGNITE-5572 ALTER TABLE ADD COLUMN (no tests)

commit 4a6b39c1f93676f45a3ab0da9b39ec691357a547
Author: Alexander Paschenko 
Date:   2017-07-25T20:51:43Z

IGNITE-5572 First ALTER TABLE ADD COLUMN tests

commit e15e7da7914dd6f73e7bd995bbf4ff166c1e24c3
Author: Alexander Paschenko 
Date:   2017-07-25T22:49:27Z

IGNITE-5572 Minors

commit 4f26e00dc48af1d50c08adb683d6006b590cea9e
Author: Alexander Paschenko 
Date:   2017-07-25T22:57:35Z

Merge remote-tracking branch 'apache/master' into ignite-5572




---
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.
---

[jira] [Created] (IGNITE-5837) Fix logic in DynamicIndexAbstractConcurrentSelfTest

[Alexander Paschenko (JIRA)]

Alexander Paschenko created IGNITE-5837:
---

 Summary: Fix logic in DynamicIndexAbstractConcurrentSelfTest
 Key: IGNITE-5837
 URL: https://issues.apache.org/jira/browse/IGNITE-5837
 Project: Ignite
  Issue Type: Test
Reporter: Alexander Paschenko
Assignee: Alexander Paschenko






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Konstantin Boudnik]

+1 [binding]

- Checked the signature
- Checked the sha1
- Successfully ran the build
- RAT is clean

Things that need to be improved in the next release:
- neither sha1 nor md5 are trustful checksum'ing methods and aren't
  guaranteeing the authenticity of the source archive. We should be switching
  to at least sha265 or higher. This has been brought up since the incubation.
  And warrants for -1 in the next release.

Cos

On Mon, Jul 24, 2017 at 04:32PM, Anton Vinogradov wrote:
> Igniters,
> 
> This vote based on same files as RC3.
> Only one change is that I signed zips with my signature.
> KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS) was
> updated as well.
> 
> We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
> This vote will go for 72 hours but may be closed earlier if Konstantin
> Boudnik confirmed security issue solved.
> 
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
> 
> Git tag name is
> 2.1.0-rc4
> 
> This release includes the following changes:
> 
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
> 
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
> 
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
> 
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
> 20resolved)
> 
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
> 
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
> 
> Please start voting.
> 
> +1 - to accept Apache Ignite 2.1.0-rc4
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
> 
> This vote will go for 72 hours.


signature.asc
Description: Digital signature

Re: Resurrect FairAffinityFunction

[Valentin Kulichenko]

Create a ticket: https://issues.apache.org/jira/browse/IGNITE-5836

-Val

On Tue, Jul 25, 2017 at 11:54 AM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Semyon,
>
> We had some improvements, but to knowledge fair affinity still provides
> much better distribution (at least I haven't seen any results showing
> otherwise). Please correct me if I'm wrong.
>
> Actually, I think it's not an issue with fair function in particular, but
> rather a design flow in affinity manager. The exact same issue will exist
> not only with fair function, but with ANY function that
> uses AffinityFunctionContext#previousAssignment to calculate assignments.
> And the context is provided from the outside, function has nothing to do
> with it.
>
> So let's fix the root cause and bring innocent FairAF back :)
>
> -Val
>
> On Tue, Jul 25, 2017 at 1:07 AM, Semyon Boikov 
> wrote:
>
>> Valentin,
>>
>> As far as I know in 2.0 some changes were made in rendezvous function so
>> now it can provide better result. Do you have some numbers for 2.0 so that
>> we can compare rendezvous and fair affinity functions?
>>
>> Thanks
>>
>> On Tue, Jul 25, 2017 at 5:13 AM,  wrote:
>>
>> > Agree with Val, we should bring it back.
>> >
>> > ⁣D.​
>> >
>> > On Jul 24, 2017, 8:14 PM, at 8:14 PM, Valentin Kulichenko <
>> > valentin.kuliche...@gmail.com> wrote:
>> > >Guys,
>> > >
>> > >Some time ago we removed FairAffinityFunction from the project.
>> > >However, my
>> > >communication with users clearly shows that is was a rush decision.
>> > >Distribution showed by Fair AF is much better than default and for some
>> > >users it's extremely important. Basically, there are cases when
>> > >rendezvous
>> > >function is no-go.
>> > >
>> > >The reason for removal was that it was possible to get inconsistent
>> > >results
>> > >in case multiple caches were created on different topologies. However,
>> > >I
>> > >think this is fixable. As far as I understand, the only thing we need
>> > >to do
>> > >is to maintain a single AffinityFunctionContext for all the caches with
>> > >same affinity function. Currently for each cache we have separate
>> > >context
>> > >which holds the state used by Fair AF. If the state is different, we
>> > >have
>> > >an issue.
>> > >
>> > >The only question is how to check whether two functions are the same or
>> > >not. In case both cache node filter and backup filter are not
>> > >configured,
>> > >this is easy - if number of partitions and excludeNeighbors flag are
>> > >equal
>> > >for two functions, these functions are also equal.
>> > >
>> > >With filters it's a bit more complicated as these are custom
>> > >implementations and in general case we don't know how to compare them.
>> > >Although, to solve this problem, we can enforce user to implement
>> > >equals()
>> > >method for these implementation if Fair AF is used.
>> > >
>> > >I propose to make changes described above and bring Fair AF back.
>> > >
>> > >Thoughts?
>> > >
>> > >-Val
>> >
>>
>
>

[jira] [Created] (IGNITE-5836) AffinityFunctionContext should provide consistent previous assignment

[Valentin Kulichenko (JIRA)]

Valentin Kulichenko created IGNITE-5836:
---

 Summary: AffinityFunctionContext should provide consistent 
previous assignment
 Key: IGNITE-5836
 URL: https://issues.apache.org/jira/browse/IGNITE-5836
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Valentin Kulichenko
Priority: Critical
 Fix For: 2.2


Currently each cache maintains its own {{AffinityFunctionContext}}. This leads 
to the case that {{previousAssignment}} can be different for two caches created 
on different topology versions. In particular, this broke 
{{FairAffinityFunction}} which was removed because of that.

We should do the following:
* Make sure that {{previousAssignment}} is consistent for all caches with same 
affinity function, regardless of topology versions caches were created on.
* Add mechanism to enforce equality check for affinity functions. We probably 
will need to force user to implement {{equals}} for cache node filter and 
backup filter.
* When above is done, bring back {{FairAffinityFunction}}.

This is also discussed on dev list: 
http://apache-ignite-developers.2346864.n4.nabble.com/Resurrect-FairAffinityFunction-td19987.html



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: .Net client call tx,close in other thread

[Nikolay Izhikov]

Pavel.

You will fix .Net client so I don't need to change threadId checks in my 
pull request.

Is that correct?

25.07.2017 20:19, Pavel Tupitsyn пишет:

Further investigation shows that platform code performs unnecessary close()
calls for committed & rolled back transactions (sync and async).
Ticket filed: https://issues.apache.org/jira/browse/IGNITE-5834

I'll fix this tomorrow and it should resolve your issue.

Thanks,
Pavel

On Tue, Jul 25, 2017 at 7:56 PM, Pavel Tupitsyn 
wrote:


Anyway, disallowing close() from another thread would be a breaking
change, we can't do that.

On Tue, Jul 25, 2017 at 7:36 PM, Pavel Tupitsyn 
wrote:


I've reproduced the issue, it happens because in .NET we auto-close the
transaction
on commit/rollback. This involves two things:
* release .NET reference to Java object
* call Transaction.close()

With sync methods this is trivial, but with commitAsync/rollbackAsync we
have to call close()
in IgniteFuture listener, which is called in a different thread.

I think we need to be able to close() a transaction from any thread.
Otherwise I don't see a non-blocking way to deal with
commitAsync/rollbackAsync.

Thanks,
Pavel

On Tue, Jul 25, 2017 at 6:10 PM, Николай Ижиков 
wrote:


Hi, Pavel

You can check my pull request.
https://github.com/apache/ignite/pull/2334

For now I return checks so it has to fail on .Net test suite


2017-07-25 17:16 GMT+03:00 Pavel Tupitsyn :


Hi Николай,

.NET test in question (TestTxStateAndExceptions) does not do any
multithreading,
everything is called from a single thread.

I see that the latest .NET run of your pull request on TeamCity

finished

successfully:
http://ci.ignite.apache.org/viewLog.html?buildId=738277

Do you still have a problem with this? If yes, how can I reproduce it?
Can you prepare a branch where the test fails, so I can run it locally?

Thanks,
Pavel

On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков <

nizhikov@gmail.com>

wrote:


Hello, Igniters.

I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
I found that .Net client perform transaction operation(`tx.close()`)

in

thread that not owns transaction.

So I can't include checks for threadId in my pull request.

Is it a bug or a desirable behabiour?

With my new check I got following stack trace:

Check:

`assert (threadId() == Thread.currentThread().getId());`

Exception:

Test(s) failed. System.AggregateException : One or more errors

occurred.

> Apache.Ignite.Core.Common.IgniteException : Java exception

occurred

[class=java.lang.AssertionError, message=] >
Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError

at

org.apache.ignite.internal.processors.cache.transactions.
TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
at
org.apache.ignite.internal.processors.cache.transactions.
TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
at
org.apache.ignite.internal.processors.cache.transactions.
TransactionProxyImpl.close(TransactionProxyImpl.java:317)
at
org.apache.ignite.internal.processors.platform.transactions.
PlatformTransactions.txClose(PlatformTransactions.java:136)
at
org.apache.ignite.internal.processors.platform.transactions.
PlatformTransactions.processInLongOutLong(PlatformTransactio

ns.java:178)

at
org.apache.ignite.internal.processors.platform.PlatformTarge

tProxyImpl.

inLongOutLong(PlatformTargetProxyImpl.java:53)
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wa

it(Int32

millisecondsTimeout, CancellationToken cancellationToken) at
System.Threading.Tasks.Task.Wait() at
Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest
.TestTxStateAndExceptions()
in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
510 --IgniteException at
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void*

target,

Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
stackTraceCharsLen, Void* errData, Int32 errDataLen) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
1066 at
Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.
TargetInLongOutLong(Void*
ctx, Void* target, Int32 opType, Int64 val) at
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLon

gOutLong(

IUnmanagedTarget
target, Int32 opType, Int64 memPtr) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
429 at Apache.Ignite.Core.Impl.PlatformTarget.DoOutInOp(Int32 type,

Int64

val) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
Ignite.Core\Impl\PlatformTarget.cs:line
717 at
Apache.Ignite.Core.Impl.Transactions.TransactionsImpl.

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Valentin Kulichenko]

Alexey,

Is there exact use case that is currently not supported? I really would
like to see one, because such a big API change should add clear value.
ComputeGrid is not used very often, and so far I've never seen any
questions from users about using it in conjunction with affinity
collocation.

What if we solve this on job level instead by adding the following
interface:

interface AffinityComputeJob extends ComputeJob {
String cacheName();
Object affinityKey();
}

Whenever load balancer sees this job, it maps it based on affinity. Will
this work?

-Val

On Tue, Jul 25, 2017 at 12:37 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Anton,
>
> How does topology change break this functionality? Closures executed with
> affinityRun/Call fail over in the same way as any ComputeJob.
>
> -Val
>
> On Tue, Jul 25, 2017 at 5:48 AM, Anton Vinogradov <
> avinogra...@gridgain.com> wrote:
>
>> Alexei,
>>
>> > How would task know the partition it is running over ?
>> Not sure it necessary.
>> You'll create pair partition-job at task's map phase.
>>
>> > How can I assign task for each cache partition ?
>> Just implement map method generates map with size equals to partition
>> count.
>>
>> > How can I enforce partition reservation if task works with multiple
>> caches at once ?
>> This possible only in case caches use safe affinity function.
>> And it useful only it this case.
>>
>> On Tue, Jul 25, 2017 at 3:22 PM, Alexei Scherbakov <
>> alexey.scherbak...@gmail.com> wrote:
>>
>> > Please read job instead task
>> >
>> > 2017-07-25 15:20 GMT+03:00 Alexei Scherbakov <
>> alexey.scherbak...@gmail.com
>> > >:
>> >
>> > > Main point of the issue is to provide clean API for working with
>> > > computations requiring data collocation
>> > >
>> > > affinityCall/Run provide the ability to run closure near data, but
>> > > map/reduce API is a way reacher: continuous mapping, task session,
>> etc.
>> > >
>> > > As for proposed API, I do not understand fully how it solves the
>> problem.
>> > >
>> > > Maxim, please provide detailed javadoc for each method and each
>> argument
>> > > for presented API, and the answers to the following questions:
>> > >
>> > > 1. How would task know the partition it is running over ?
>> > >
>> > > 2. How can I assign task for each cache partition ?
>> > >
>> > > 3. How can I enforce partition reservation if task works with multiple
>> > > caches at once ?
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > 2017-07-25 12:30 GMT+03:00 Anton Vinogradov > >:
>> > >
>> > >> Val,
>> > >>
>> > >> Sure, we can, but we'd like to use map/reduce without fearing that
>> > >> topology
>> > >> can change.
>> > >>
>> > >> On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko <
>> > >> valentin.kuliche...@gmail.com> wrote:
>> > >>
>> > >> > Anton,
>> > >> >
>> > >> > You can call affinityCallAsync multiple times and then reduce
>> locally.
>> > >> >
>> > >> > -Val
>> > >> >
>> > >> > On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov <
>> > >> > avinogra...@gridgain.com>
>> > >> > wrote:
>> > >> >
>> > >> > > Val,
>> > >> > >
>> > >> > > > What is the use case for which current affinityRun/Call API
>> > doesn't
>> > >> > work?
>> > >> > > It does not work for map/reduce.
>> > >> > >
>> > >> > > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko <
>> > >> > > valentin.kuliche...@gmail.com> wrote:
>> > >> > >
>> > >> > > > Maxim,
>> > >> > > >
>> > >> > > > The issue is that it's currently assumed to support job
>> mapping,
>> > >> but it
>> > >> > > > actually doesn't. However, I agree that AffinityKeyMapped
>> > annotation
>> > >> > > > doesn't fit the use case well. Let's fix documentation and
>> JavaDoc
>> > >> > then.
>> > >> > > >
>> > >> > > > As for the proposed API, it's overcomplicated, took me 15
>> minutes
>> > to
>> > >> > > > understand what it does :)
>> > >> > > >
>> > >> > > > What is the use case for which current affinityRun/Call API
>> > doesn't
>> > >> > work?
>> > >> > > >
>> > >> > > > -Val
>> > >> > > >
>> > >> > > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim <
>> > dreamx@gmail.com
>> > >> >
>> > >> > > > wrote:
>> > >> > > >
>> > >> > > > > Valentin,
>> > >> > > > >
>> > >> > > > > The author of tiket wants to see to provide some API allows
>> to
>> > map
>> > >> > > > > ComputeJobs to partitions or keys. If we use
>> @AffinityKeyMapped
>> > >> then
>> > >> > > you
>> > >> > > > > need to enter the cache name parameter, I think this is not
>> > >> > convenient
>> > >> > > > for
>> > >> > > > > the user. Therefore, I propose to extend the existing API.
>> > >> > > > > Having consulted with Anton V. decided to make a separate
>> > >> interface
>> > >> > > > > ReducibleTask, which will allow us to have different map
>> logic
>> > at
>> > >> > each
>> > >> > > > > inheritor.
>> > >> > > > >
>> > >> > > > > Old method, allows to map to node
>> > >> > > > > public interface ComputeTask extends ReducibleTask {
>> > >> > > > > @Nullable 

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Valentin Kulichenko]

Anton,

How does topology change break this functionality? Closures executed with
affinityRun/Call fail over in the same way as any ComputeJob.

-Val

On Tue, Jul 25, 2017 at 5:48 AM, Anton Vinogradov 
wrote:

> Alexei,
>
> > How would task know the partition it is running over ?
> Not sure it necessary.
> You'll create pair partition-job at task's map phase.
>
> > How can I assign task for each cache partition ?
> Just implement map method generates map with size equals to partition
> count.
>
> > How can I enforce partition reservation if task works with multiple
> caches at once ?
> This possible only in case caches use safe affinity function.
> And it useful only it this case.
>
> On Tue, Jul 25, 2017 at 3:22 PM, Alexei Scherbakov <
> alexey.scherbak...@gmail.com> wrote:
>
> > Please read job instead task
> >
> > 2017-07-25 15:20 GMT+03:00 Alexei Scherbakov <
> alexey.scherbak...@gmail.com
> > >:
> >
> > > Main point of the issue is to provide clean API for working with
> > > computations requiring data collocation
> > >
> > > affinityCall/Run provide the ability to run closure near data, but
> > > map/reduce API is a way reacher: continuous mapping, task session, etc.
> > >
> > > As for proposed API, I do not understand fully how it solves the
> problem.
> > >
> > > Maxim, please provide detailed javadoc for each method and each
> argument
> > > for presented API, and the answers to the following questions:
> > >
> > > 1. How would task know the partition it is running over ?
> > >
> > > 2. How can I assign task for each cache partition ?
> > >
> > > 3. How can I enforce partition reservation if task works with multiple
> > > caches at once ?
> > >
> > >
> > >
> > >
> > >
> > > 2017-07-25 12:30 GMT+03:00 Anton Vinogradov  >:
> > >
> > >> Val,
> > >>
> > >> Sure, we can, but we'd like to use map/reduce without fearing that
> > >> topology
> > >> can change.
> > >>
> > >> On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko <
> > >> valentin.kuliche...@gmail.com> wrote:
> > >>
> > >> > Anton,
> > >> >
> > >> > You can call affinityCallAsync multiple times and then reduce
> locally.
> > >> >
> > >> > -Val
> > >> >
> > >> > On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov <
> > >> > avinogra...@gridgain.com>
> > >> > wrote:
> > >> >
> > >> > > Val,
> > >> > >
> > >> > > > What is the use case for which current affinityRun/Call API
> > doesn't
> > >> > work?
> > >> > > It does not work for map/reduce.
> > >> > >
> > >> > > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko <
> > >> > > valentin.kuliche...@gmail.com> wrote:
> > >> > >
> > >> > > > Maxim,
> > >> > > >
> > >> > > > The issue is that it's currently assumed to support job mapping,
> > >> but it
> > >> > > > actually doesn't. However, I agree that AffinityKeyMapped
> > annotation
> > >> > > > doesn't fit the use case well. Let's fix documentation and
> JavaDoc
> > >> > then.
> > >> > > >
> > >> > > > As for the proposed API, it's overcomplicated, took me 15
> minutes
> > to
> > >> > > > understand what it does :)
> > >> > > >
> > >> > > > What is the use case for which current affinityRun/Call API
> > doesn't
> > >> > work?
> > >> > > >
> > >> > > > -Val
> > >> > > >
> > >> > > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim <
> > dreamx@gmail.com
> > >> >
> > >> > > > wrote:
> > >> > > >
> > >> > > > > Valentin,
> > >> > > > >
> > >> > > > > The author of tiket wants to see to provide some API allows to
> > map
> > >> > > > > ComputeJobs to partitions or keys. If we use
> @AffinityKeyMapped
> > >> then
> > >> > > you
> > >> > > > > need to enter the cache name parameter, I think this is not
> > >> > convenient
> > >> > > > for
> > >> > > > > the user. Therefore, I propose to extend the existing API.
> > >> > > > > Having consulted with Anton V. decided to make a separate
> > >> interface
> > >> > > > > ReducibleTask, which will allow us to have different map logic
> > at
> > >> > each
> > >> > > > > inheritor.
> > >> > > > >
> > >> > > > > Old method, allows to map to node
> > >> > > > > public interface ComputeTask extends ReducibleTask {
> > >> > > > > @Nullable public Map
> > >> > > > > map(List subgrid, @Nullable T arg) throws
> > >> > IgniteException;
> > >> > > > > }
> > >> > > > >
> > >> > > > > Brand new method with mapping to partitions, which solves
> > topology
> > >> > > change
> > >> > > > > issues.
> > >> > > > > public interface AffinityComputeTask extends
> > >> ReducibleTask {
> > >> > > > > @Nullable public Map
> > >> > > > map(@NotnullString
> > >> > > > > cacheName, List partIds, @Nullable T arg) throws
> > >> > > > IgniteException;
> > >> > > > > }
> > >> > > > >
> > >> > > > > public interface ReducibleTask extends Serializable {
> > >> > > > > public ComputeJobResultPolicy result(ComputeJobResult res,
> > >> > > > > List rcvd) throws IgniteException;
> > >> > > > >
> > >> > > > > @Nullable public R reduce(List results)
> > >> throws

Re: Resurrect FairAffinityFunction

[Valentin Kulichenko]

Semyon,

We had some improvements, but to knowledge fair affinity still provides
much better distribution (at least I haven't seen any results showing
otherwise). Please correct me if I'm wrong.

Actually, I think it's not an issue with fair function in particular, but
rather a design flow in affinity manager. The exact same issue will exist
not only with fair function, but with ANY function that
uses AffinityFunctionContext#previousAssignment to calculate assignments.
And the context is provided from the outside, function has nothing to do
with it.

So let's fix the root cause and bring innocent FairAF back :)

-Val

On Tue, Jul 25, 2017 at 1:07 AM, Semyon Boikov  wrote:

> Valentin,
>
> As far as I know in 2.0 some changes were made in rendezvous function so
> now it can provide better result. Do you have some numbers for 2.0 so that
> we can compare rendezvous and fair affinity functions?
>
> Thanks
>
> On Tue, Jul 25, 2017 at 5:13 AM,  wrote:
>
> > Agree with Val, we should bring it back.
> >
> > ⁣D.​
> >
> > On Jul 24, 2017, 8:14 PM, at 8:14 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> > >Guys,
> > >
> > >Some time ago we removed FairAffinityFunction from the project.
> > >However, my
> > >communication with users clearly shows that is was a rush decision.
> > >Distribution showed by Fair AF is much better than default and for some
> > >users it's extremely important. Basically, there are cases when
> > >rendezvous
> > >function is no-go.
> > >
> > >The reason for removal was that it was possible to get inconsistent
> > >results
> > >in case multiple caches were created on different topologies. However,
> > >I
> > >think this is fixable. As far as I understand, the only thing we need
> > >to do
> > >is to maintain a single AffinityFunctionContext for all the caches with
> > >same affinity function. Currently for each cache we have separate
> > >context
> > >which holds the state used by Fair AF. If the state is different, we
> > >have
> > >an issue.
> > >
> > >The only question is how to check whether two functions are the same or
> > >not. In case both cache node filter and backup filter are not
> > >configured,
> > >this is easy - if number of partitions and excludeNeighbors flag are
> > >equal
> > >for two functions, these functions are also equal.
> > >
> > >With filters it's a bit more complicated as these are custom
> > >implementations and in general case we don't know how to compare them.
> > >Although, to solve this problem, we can enforce user to implement
> > >equals()
> > >method for these implementation if Fair AF is used.
> > >
> > >I propose to make changes described above and bring Fair AF back.
> > >
> > >Thoughts?
> > >
> > >-Val
> >
>

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Dmitriy Setrakyan]

On Tue, Jul 25, 2017 at 12:36 PM, Vladimir Ozerov 
wrote:

> Vyacheslav,
> When we finish varlen optimization for string lengths, I am afraid we could
> end up with very messy protocol, should we mix encoded length and encoding.
>
> Dima,
> Encoding must be set on per field basis. This will give us as most flexible
> solution at the cost of 1-byte overhead.
>

Vova, I agree that the encoding should be set on per-field basis, but at
the table level, not at a cell level. I cannot foresee a situation where we
would have different encodings in the same column. If that ever happens,
then user can provide already encoded values.


>
> вт, 25 июля 2017 г. в 20:23, Dmitriy Setrakyan :
>
> > I don't understand why this encoding is done on per-object and not on
> > per-cache level. Shouldn't the column-to-encoding mapping be defined at
> > cache level configuration?
> >
> > On Tue, Jul 25, 2017 at 12:13 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Andrey,
> > >
> > > You cannot have optional part in the middle as it will break
> > compatibility
> > > in dangerous way, probably leading to node crash. Also having INT (4
> > bytes)
> > > looks too much for me.
> > >
> > > Instead, I would add new type "encoded string":
> > > 1 byte - type
> > > 1 byte - encoding code, map frequently used encodings to some byte
> value;
> > > also have a special value, meaning that encoding will be written as
> > string
> > > afterwards, this way we will support any encoding out of the box
> > > [optional] encoding name
> > > 4 bytes - string length
> > > Finally - string bytes
> > >
> > > Vladimir.
> > >
> > > вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov :
> > >
> > > > I apologize for damaged formatting. Below is my message as it should
> > be.
> > > >
> > > >
> > > > Hi Igniters,
> > > >
> > > > I'd like to discuss future changes related to
> > https://issues.apache.org/
> > > > jira/browse/IGNITE-5655
> > > > .
> > > >
> > > > Is it really good idea to introduce new flag (ENCODED_STRING) for
> > > existing
> > > > String datatype? It's possible to use existing STRING flag at
> > negligible
> > > > performance cost.
> > > >
> > > > Currently, utf-8-encoded string looks like
> > > >
> > > > byteFlag nonNegativeIntStrLen bytes
> > > >
> > > > This format can be backward compatibly extended to
> > > >
> > > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > > >
> > > > Next, I suggest to add new BinaryConfiguration property for encoding
> to
> > > use
> > > > instead of using global property. It seems to be more convenient for
> > > user.
> > > >
> > > > I'll appreciate your feedback.
> > > >
> > > > 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov :
> > > >
> > > > > Hi Igniters,I'd like to discuss future changes related to
> > IGNITE-5655
> > > > >   . Is it
> really
> > > good
> > > > > idea to introduce new flag (ENCODED_STRING) for existing String
> > > datatype?
> > > > > It's possible to use existing STRING flag at negligible performance
> > > cost.
> > > > > Currently, utf-8-encoded string looks like
> > > > > byteFlag nonNegativeIntStrLen bytes
> > > > > This format can be backward compatibly extended to
> > > > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > > > > Next, I suggest to add new BinaryConfiguration property for
> encoding
> > to
> > > > use
> > > > > instead of using global property. It seems to be more convenient
> for
> > > > > user.I'll appreciate your feedback.
> > > > >
> > > > >
> > > > >
> > > > > -
> > > > > Best regards,
> > > > >   Andrey Kuznetsov.
> > > > > --
> > > > > View this message in context: http://apache-ignite-
> > > > > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> > > > > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> > > > > Sent from the Apache Ignite Developers mailing list archive at
> > > > Nabble.com.
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > > >
> > >
> >
>

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Andrey Kuznetsov]

Vladimir,

Thanks for reply. In any case, we'll break compatibility by introducing new
feature in marshalling. But both approaches preserve backward
compatibility.

I deemed it's unusual to make two differerent type markers (flags) for
single datatype. I can't see the source right now, but I'm unsure whether
it's possible to map two flags to single type in marshaller implementation.

25 июля 2017 г. 20:13 пользователь "Vladimir Ozerov" 
написал:

> Andrey,
>
> You cannot have optional part in the middle as it will break compatibility
> in dangerous way, probably leading to node crash. Also having INT (4
> bytes)
> looks too much for me.
>
> Instead, I would add new type "encoded string":
> 1 byte - type
> 1 byte - encoding code, map frequently used encodings to some byte value;
> also have a special value, meaning that encoding will be written as string
> afterwards, this way we will support any encoding out of the box
> [optional] encoding name
> 4 bytes - string length
> Finally - string bytes
>
> Vladimir.
>
> вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov <[hidden email]
> >:
>
> > I apologize for damaged formatting. Below is my message as it should be.
> >
> >
> > Hi Igniters,
> >
> > I'd like to discuss future changes related to https://issues.apache.org/
> > jira/browse/IGNITE-5655
> > .
> >
> > Is it really good idea to introduce new flag (ENCODED_STRING) for
> existing
> > String datatype? It's possible to use existing STRING flag at negligible
> > performance cost.
> >
> > Currently, utf-8-encoded string looks like
> >
> > byteFlag nonNegativeIntStrLen bytes
> >
> > This format can be backward compatibly extended to
> >
> > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> >
> > Next, I suggest to add new BinaryConfiguration property for encoding to
> use
> > instead of using global property. It seems to be more convenient for
> user.
> >
> > I'll appreciate your feedback.
> >
> > 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov <[hidden email]
> >:
> >
> > > Hi Igniters,I'd like to discuss future changes related to  IGNITE-5655
> > >   . Is it really
> good
> > > idea to introduce new flag (ENCODED_STRING) for existing String
> datatype?
> > > It's possible to use existing STRING flag at negligible performance
> cost.
> > > Currently, utf-8-encoded string looks like
> > > byteFlag nonNegativeIntStrLen bytes
> > > This format can be backward compatibly extended to
> > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > > Next, I suggest to add new BinaryConfiguration property for encoding
> to
> > use
> > > instead of using global property. It seems to be more convenient for
> > > user.I'll appreciate your feedback.
> > >
> > >
> > >
> > > -
> > > Best regards,
> > >   Andrey Kuznetsov.
> > > --
> > > View this message in context: http://apache-ignite-
> > > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> > > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> >
> >
> >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>
>
> --
> If you reply to this email, your message will be added to the discussion
> below:
> http://apache-ignite-developers.2346864.n4.nabble.
> com/Non-UTF-8-string-encoding-support-in-BinaryMarshaller-
> IGNITE-5655-tp20024p20039.html
> To unsubscribe from Non-UTF-8 string encoding support in BinaryMarshaller
> (IGNITE-5655), click here
> 
> .
> NAML
> 
>

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Vladimir Ozerov]

Vyacheslav,
When we finish varlen optimization for string lengths, I am afraid we could
end up with very messy protocol, should we mix encoded length and encoding.

Dima,
Encoding must be set on per field basis. This will give us as most flexible
solution at the cost of 1-byte overhead.

вт, 25 июля 2017 г. в 20:23, Dmitriy Setrakyan :

> I don't understand why this encoding is done on per-object and not on
> per-cache level. Shouldn't the column-to-encoding mapping be defined at
> cache level configuration?
>
> On Tue, Jul 25, 2017 at 12:13 PM, Vladimir Ozerov 
> wrote:
>
> > Andrey,
> >
> > You cannot have optional part in the middle as it will break
> compatibility
> > in dangerous way, probably leading to node crash. Also having INT (4
> bytes)
> > looks too much for me.
> >
> > Instead, I would add new type "encoded string":
> > 1 byte - type
> > 1 byte - encoding code, map frequently used encodings to some byte value;
> > also have a special value, meaning that encoding will be written as
> string
> > afterwards, this way we will support any encoding out of the box
> > [optional] encoding name
> > 4 bytes - string length
> > Finally - string bytes
> >
> > Vladimir.
> >
> > вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov :
> >
> > > I apologize for damaged formatting. Below is my message as it should
> be.
> > >
> > >
> > > Hi Igniters,
> > >
> > > I'd like to discuss future changes related to
> https://issues.apache.org/
> > > jira/browse/IGNITE-5655
> > > .
> > >
> > > Is it really good idea to introduce new flag (ENCODED_STRING) for
> > existing
> > > String datatype? It's possible to use existing STRING flag at
> negligible
> > > performance cost.
> > >
> > > Currently, utf-8-encoded string looks like
> > >
> > > byteFlag nonNegativeIntStrLen bytes
> > >
> > > This format can be backward compatibly extended to
> > >
> > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > >
> > > Next, I suggest to add new BinaryConfiguration property for encoding to
> > use
> > > instead of using global property. It seems to be more convenient for
> > user.
> > >
> > > I'll appreciate your feedback.
> > >
> > > 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov :
> > >
> > > > Hi Igniters,I'd like to discuss future changes related to
> IGNITE-5655
> > > >   . Is it really
> > good
> > > > idea to introduce new flag (ENCODED_STRING) for existing String
> > datatype?
> > > > It's possible to use existing STRING flag at negligible performance
> > cost.
> > > > Currently, utf-8-encoded string looks like
> > > > byteFlag nonNegativeIntStrLen bytes
> > > > This format can be backward compatibly extended to
> > > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > > > Next, I suggest to add new BinaryConfiguration property for encoding
> to
> > > use
> > > > instead of using global property. It seems to be more convenient for
> > > > user.I'll appreciate your feedback.
> > > >
> > > >
> > > >
> > > > -
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > > > --
> > > > View this message in context: http://apache-ignite-
> > > > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> > > > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> > > > Sent from the Apache Ignite Developers mailing list archive at
> > > Nabble.com.
> > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >   Andrey Kuznetsov.
> > >
> >
>

[GitHub] ignite pull request #2123: IGNITE-5278: First stage of BLAS (Local onheap st...

[artemmalykh]

Github user artemmalykh closed the pull request at:

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


---
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: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Dmitriy Setrakyan]

I don't understand why this encoding is done on per-object and not on
per-cache level. Shouldn't the column-to-encoding mapping be defined at
cache level configuration?

On Tue, Jul 25, 2017 at 12:13 PM, Vladimir Ozerov 
wrote:

> Andrey,
>
> You cannot have optional part in the middle as it will break compatibility
> in dangerous way, probably leading to node crash. Also having INT (4 bytes)
> looks too much for me.
>
> Instead, I would add new type "encoded string":
> 1 byte - type
> 1 byte - encoding code, map frequently used encodings to some byte value;
> also have a special value, meaning that encoding will be written as string
> afterwards, this way we will support any encoding out of the box
> [optional] encoding name
> 4 bytes - string length
> Finally - string bytes
>
> Vladimir.
>
> вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov :
>
> > I apologize for damaged formatting. Below is my message as it should be.
> >
> >
> > Hi Igniters,
> >
> > I'd like to discuss future changes related to https://issues.apache.org/
> > jira/browse/IGNITE-5655
> > .
> >
> > Is it really good idea to introduce new flag (ENCODED_STRING) for
> existing
> > String datatype? It's possible to use existing STRING flag at negligible
> > performance cost.
> >
> > Currently, utf-8-encoded string looks like
> >
> > byteFlag nonNegativeIntStrLen bytes
> >
> > This format can be backward compatibly extended to
> >
> > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> >
> > Next, I suggest to add new BinaryConfiguration property for encoding to
> use
> > instead of using global property. It seems to be more convenient for
> user.
> >
> > I'll appreciate your feedback.
> >
> > 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov :
> >
> > > Hi Igniters,I'd like to discuss future changes related to  IGNITE-5655
> > >   . Is it really
> good
> > > idea to introduce new flag (ENCODED_STRING) for existing String
> datatype?
> > > It's possible to use existing STRING flag at negligible performance
> cost.
> > > Currently, utf-8-encoded string looks like
> > > byteFlag nonNegativeIntStrLen bytes
> > > This format can be backward compatibly extended to
> > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > > Next, I suggest to add new BinaryConfiguration property for encoding to
> > use
> > > instead of using global property. It seems to be more convenient for
> > > user.I'll appreciate your feedback.
> > >
> > >
> > >
> > > -
> > > Best regards,
> > >   Andrey Kuznetsov.
> > > --
> > > View this message in context: http://apache-ignite-
> > > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> > > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> >
> >
> >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>

Re: .Net client call tx,close in other thread

[Pavel Tupitsyn]

Further investigation shows that platform code performs unnecessary close()
calls for committed & rolled back transactions (sync and async).
Ticket filed: https://issues.apache.org/jira/browse/IGNITE-5834

I'll fix this tomorrow and it should resolve your issue.

Thanks,
Pavel

On Tue, Jul 25, 2017 at 7:56 PM, Pavel Tupitsyn 
wrote:

> Anyway, disallowing close() from another thread would be a breaking
> change, we can't do that.
>
> On Tue, Jul 25, 2017 at 7:36 PM, Pavel Tupitsyn 
> wrote:
>
>> I've reproduced the issue, it happens because in .NET we auto-close the
>> transaction
>> on commit/rollback. This involves two things:
>> * release .NET reference to Java object
>> * call Transaction.close()
>>
>> With sync methods this is trivial, but with commitAsync/rollbackAsync we
>> have to call close()
>> in IgniteFuture listener, which is called in a different thread.
>>
>> I think we need to be able to close() a transaction from any thread.
>> Otherwise I don't see a non-blocking way to deal with
>> commitAsync/rollbackAsync.
>>
>> Thanks,
>> Pavel
>>
>> On Tue, Jul 25, 2017 at 6:10 PM, Николай Ижиков 
>> wrote:
>>
>>> Hi, Pavel
>>>
>>> You can check my pull request.
>>> https://github.com/apache/ignite/pull/2334
>>>
>>> For now I return checks so it has to fail on .Net test suite
>>>
>>>
>>> 2017-07-25 17:16 GMT+03:00 Pavel Tupitsyn :
>>>
>>> > Hi Николай,
>>> >
>>> > .NET test in question (TestTxStateAndExceptions) does not do any
>>> > multithreading,
>>> > everything is called from a single thread.
>>> >
>>> > I see that the latest .NET run of your pull request on TeamCity
>>> finished
>>> > successfully:
>>> > http://ci.ignite.apache.org/viewLog.html?buildId=738277
>>> >
>>> > Do you still have a problem with this? If yes, how can I reproduce it?
>>> > Can you prepare a branch where the test fails, so I can run it locally?
>>> >
>>> > Thanks,
>>> > Pavel
>>> >
>>> > On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков <
>>> nizhikov@gmail.com>
>>> > wrote:
>>> >
>>> > > Hello, Igniters.
>>> > >
>>> > > I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
>>> > > I found that .Net client perform transaction operation(`tx.close()`)
>>> in
>>> > > thread that not owns transaction.
>>> > >
>>> > > So I can't include checks for threadId in my pull request.
>>> > >
>>> > > Is it a bug or a desirable behabiour?
>>> > >
>>> > > With my new check I got following stack trace:
>>> > >
>>> > > Check:
>>> > >
>>> > > `assert (threadId() == Thread.currentThread().getId());`
>>> > >
>>> > > Exception:
>>> > >
>>> > > Test(s) failed. System.AggregateException : One or more errors
>>> occurred.
>>> > > > Apache.Ignite.Core.Common.IgniteException : Java exception
>>> > occurred
>>> > > [class=java.lang.AssertionError, message=] >
>>> > > Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError
>>> at
>>> > > org.apache.ignite.internal.processors.cache.transactions.
>>> > > TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
>>> > > at
>>> > > org.apache.ignite.internal.processors.cache.transactions.
>>> > > TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
>>> > > at
>>> > > org.apache.ignite.internal.processors.cache.transactions.
>>> > > TransactionProxyImpl.close(TransactionProxyImpl.java:317)
>>> > > at
>>> > > org.apache.ignite.internal.processors.platform.transactions.
>>> > > PlatformTransactions.txClose(PlatformTransactions.java:136)
>>> > > at
>>> > > org.apache.ignite.internal.processors.platform.transactions.
>>> > > PlatformTransactions.processInLongOutLong(PlatformTransactio
>>> ns.java:178)
>>> > > at
>>> > > org.apache.ignite.internal.processors.platform.PlatformTarge
>>> tProxyImpl.
>>> > > inLongOutLong(PlatformTargetProxyImpl.java:53)
>>> > > at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
>>> > > includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wa
>>> it(Int32
>>> > > millisecondsTimeout, CancellationToken cancellationToken) at
>>> > > System.Threading.Tasks.Task.Wait() at
>>> > > Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest
>>> > > .TestTxStateAndExceptions()
>>> > > in
>>> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
>>> > > Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
>>> > > 510 --IgniteException at
>>> > > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void*
>>> target,
>>> > > Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
>>> > > errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
>>> > > stackTraceCharsLen, Void* errData, Int32 errDataLen) in
>>> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
>>> > > Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
>>> > > 1066 at
>>> > > Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.
>>> > > TargetInLongOutLong(Void*
>>> > > ctx, Void* target, Int32 

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Vyacheslav Daradur]

Hi Andrey.

Sound very useful.

We can save one byte if will use controlled overflow on
[nonNegativeIntStrLen]:
If [nonNegativeIntStrLen < 0] then [string is encoded]

I have some questions:
Will there any public API, e.g. "Encoder" interace?
Will user have the opportunity to define own encoding format?

2017-07-25 20:13 GMT+03:00 Vladimir Ozerov :

> Andrey,
>
> You cannot have optional part in the middle as it will break compatibility
> in dangerous way, probably leading to node crash. Also having INT (4 bytes)
> looks too much for me.
>
> Instead, I would add new type "encoded string":
> 1 byte - type
> 1 byte - encoding code, map frequently used encodings to some byte value;
> also have a special value, meaning that encoding will be written as string
> afterwards, this way we will support any encoding out of the box
> [optional] encoding name
> 4 bytes - string length
> Finally - string bytes
>
> Vladimir.
>
> вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov :
>
> > I apologize for damaged formatting. Below is my message as it should be.
> >
> >
> > Hi Igniters,
> >
> > I'd like to discuss future changes related to https://issues.apache.org/
> > jira/browse/IGNITE-5655
> > .
> >
> > Is it really good idea to introduce new flag (ENCODED_STRING) for
> existing
> > String datatype? It's possible to use existing STRING flag at negligible
> > performance cost.
> >
> > Currently, utf-8-encoded string looks like
> >
> > byteFlag nonNegativeIntStrLen bytes
> >
> > This format can be backward compatibly extended to
> >
> > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> >
> > Next, I suggest to add new BinaryConfiguration property for encoding to
> use
> > instead of using global property. It seems to be more convenient for
> user.
> >
> > I'll appreciate your feedback.
> >
> > 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov :
> >
> > > Hi Igniters,I'd like to discuss future changes related to  IGNITE-5655
> > >   . Is it really
> good
> > > idea to introduce new flag (ENCODED_STRING) for existing String
> datatype?
> > > It's possible to use existing STRING flag at negligible performance
> cost.
> > > Currently, utf-8-encoded string looks like
> > > byteFlag nonNegativeIntStrLen bytes
> > > This format can be backward compatibly extended to
> > > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > > Next, I suggest to add new BinaryConfiguration property for encoding to
> > use
> > > instead of using global property. It seems to be more convenient for
> > > user.I'll appreciate your feedback.
> > >
> > >
> > >
> > > -
> > > Best regards,
> > >   Andrey Kuznetsov.
> > > --
> > > View this message in context: http://apache-ignite-
> > > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> > > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> > > Sent from the Apache Ignite Developers mailing list archive at
> > Nabble.com.
> >
> >
> >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>



-- 
Best Regards, Vyacheslav D.

[jira] [Created] (IGNITE-5835) Implement highlight item in non-multiple dropdown

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-5835:


 Summary: Implement highlight item in non-multiple dropdown
 Key: IGNITE-5835
 URL: https://issues.apache.org/jira/browse/IGNITE-5835
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Affects Versions: 2.2
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin


1) Hide checkboxes in single dropdown
2) Add highlight to selected item in single dropdown



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5834) .NET: Do not close transaction on async commit/rollback

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5834:
--

 Summary: .NET: Do not close transaction on async commit/rollback
 Key: IGNITE-5834
 URL: https://issues.apache.org/jira/browse/IGNITE-5834
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Priority: Critical
 Fix For: 2.2


Committed / rolled back transactions do not need to be closed. 
{{TransactionImpl.CloseWhenComplete}} and {{PlatformTransactions.txClose}} 
perform unnecessary work. This also causes problems with {{commitAsync}} and 
{{rollbackAsync}} since we close a transaction on another thread.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Vladimir Ozerov]

Andrey,

You cannot have optional part in the middle as it will break compatibility
in dangerous way, probably leading to node crash. Also having INT (4 bytes)
looks too much for me.

Instead, I would add new type "encoded string":
1 byte - type
1 byte - encoding code, map frequently used encodings to some byte value;
also have a special value, meaning that encoding will be written as string
afterwards, this way we will support any encoding out of the box
[optional] encoding name
4 bytes - string length
Finally - string bytes

Vladimir.

вт, 25 июля 2017 г. в 18:24, Andrey Kuznetsov :

> I apologize for damaged formatting. Below is my message as it should be.
>
>
> Hi Igniters,
>
> I'd like to discuss future changes related to https://issues.apache.org/
> jira/browse/IGNITE-5655
> .
>
> Is it really good idea to introduce new flag (ENCODED_STRING) for existing
> String datatype? It's possible to use existing STRING flag at negligible
> performance cost.
>
> Currently, utf-8-encoded string looks like
>
> byteFlag nonNegativeIntStrLen bytes
>
> This format can be backward compatibly extended to
>
> byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
>
> Next, I suggest to add new BinaryConfiguration property for encoding to use
> instead of using global property. It seems to be more convenient for user.
>
> I'll appreciate your feedback.
>
> 2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov :
>
> > Hi Igniters,I'd like to discuss future changes related to  IGNITE-5655
> >   . Is it really good
> > idea to introduce new flag (ENCODED_STRING) for existing String datatype?
> > It's possible to use existing STRING flag at negligible performance cost.
> > Currently, utf-8-encoded string looks like
> > byteFlag nonNegativeIntStrLen bytes
> > This format can be backward compatibly extended to
> > byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> > Next, I suggest to add new BinaryConfiguration property for encoding to
> use
> > instead of using global property. It seems to be more convenient for
> > user.I'll appreciate your feedback.
> >
> >
> >
> > -
> > Best regards,
> >   Andrey Kuznetsov.
> > --
> > View this message in context: http://apache-ignite-
> > developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> > support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> > Sent from the Apache Ignite Developers mailing list archive at
> Nabble.com.
>
>
>
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

Re: .Net client call tx,close in other thread

[Pavel Tupitsyn]

Anyway, disallowing close() from another thread would be a breaking change,
we can't do that.

On Tue, Jul 25, 2017 at 7:36 PM, Pavel Tupitsyn 
wrote:

> I've reproduced the issue, it happens because in .NET we auto-close the
> transaction
> on commit/rollback. This involves two things:
> * release .NET reference to Java object
> * call Transaction.close()
>
> With sync methods this is trivial, but with commitAsync/rollbackAsync we
> have to call close()
> in IgniteFuture listener, which is called in a different thread.
>
> I think we need to be able to close() a transaction from any thread.
> Otherwise I don't see a non-blocking way to deal with
> commitAsync/rollbackAsync.
>
> Thanks,
> Pavel
>
> On Tue, Jul 25, 2017 at 6:10 PM, Николай Ижиков 
> wrote:
>
>> Hi, Pavel
>>
>> You can check my pull request.
>> https://github.com/apache/ignite/pull/2334
>>
>> For now I return checks so it has to fail on .Net test suite
>>
>>
>> 2017-07-25 17:16 GMT+03:00 Pavel Tupitsyn :
>>
>> > Hi Николай,
>> >
>> > .NET test in question (TestTxStateAndExceptions) does not do any
>> > multithreading,
>> > everything is called from a single thread.
>> >
>> > I see that the latest .NET run of your pull request on TeamCity finished
>> > successfully:
>> > http://ci.ignite.apache.org/viewLog.html?buildId=738277
>> >
>> > Do you still have a problem with this? If yes, how can I reproduce it?
>> > Can you prepare a branch where the test fails, so I can run it locally?
>> >
>> > Thanks,
>> > Pavel
>> >
>> > On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков > >
>> > wrote:
>> >
>> > > Hello, Igniters.
>> > >
>> > > I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
>> > > I found that .Net client perform transaction operation(`tx.close()`)
>> in
>> > > thread that not owns transaction.
>> > >
>> > > So I can't include checks for threadId in my pull request.
>> > >
>> > > Is it a bug or a desirable behabiour?
>> > >
>> > > With my new check I got following stack trace:
>> > >
>> > > Check:
>> > >
>> > > `assert (threadId() == Thread.currentThread().getId());`
>> > >
>> > > Exception:
>> > >
>> > > Test(s) failed. System.AggregateException : One or more errors
>> occurred.
>> > > > Apache.Ignite.Core.Common.IgniteException : Java exception
>> > occurred
>> > > [class=java.lang.AssertionError, message=] >
>> > > Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError at
>> > > org.apache.ignite.internal.processors.cache.transactions.
>> > > TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
>> > > at
>> > > org.apache.ignite.internal.processors.cache.transactions.
>> > > TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
>> > > at
>> > > org.apache.ignite.internal.processors.cache.transactions.
>> > > TransactionProxyImpl.close(TransactionProxyImpl.java:317)
>> > > at
>> > > org.apache.ignite.internal.processors.platform.transactions.
>> > > PlatformTransactions.txClose(PlatformTransactions.java:136)
>> > > at
>> > > org.apache.ignite.internal.processors.platform.transactions.
>> > > PlatformTransactions.processInLongOutLong(PlatformTransactio
>> ns.java:178)
>> > > at
>> > > org.apache.ignite.internal.processors.platform.PlatformTarge
>> tProxyImpl.
>> > > inLongOutLong(PlatformTargetProxyImpl.java:53)
>> > > at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
>> > > includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wa
>> it(Int32
>> > > millisecondsTimeout, CancellationToken cancellationToken) at
>> > > System.Threading.Tasks.Task.Wait() at
>> > > Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest
>> > > .TestTxStateAndExceptions()
>> > > in
>> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
>> > > Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
>> > > 510 --IgniteException at
>> > > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void*
>> target,
>> > > Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
>> > > errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
>> > > stackTraceCharsLen, Void* errData, Int32 errDataLen) in
>> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
>> > > Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
>> > > 1066 at
>> > > Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.
>> > > TargetInLongOutLong(Void*
>> > > ctx, Void* target, Int32 opType, Int64 val) at
>> > > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(
>> > > IUnmanagedTarget
>> > > target, Int32 opType, Int64 memPtr) in
>> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
>> > > Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
>> > > 429 at Apache.Ignite.Core.Impl.PlatformTarget.DoOutInOp(Int32 type,
>> > Int64
>> > > val) in
>> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
>> > > 

[GitHub] ignite pull request #2343: Ignite 1.9.5

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite 1.9.5



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

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

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

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


commit eb837c7853ffc68e5a3f690e985407e603e3f955
Author: Andrey Novikov 
Date:   2017-03-22T11:21:03Z

IGNITE-4854 Fixed project structure button on summary page under firefox.

(cherry picked from commit 117e18e)

commit 8d9ade2cc2d71f12a427e3effa3846a928b0681e
Author: dkarachentsev 
Date:   2017-03-22T11:57:24Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.7.10

commit 3aa2a68c02879ec57c46091cd2f22a9ac4b129ad
Author: dkarachentsev 
Date:   2017-03-22T12:22:50Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.8.5

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java

commit 9b9c32502764062f30d99337355ea400b7f29295
Author: dkarachentsev 
Date:   2017-03-22T12:33:33Z

Merge branch 'ignite-1.7.9-p1' into ignite-1.9.2

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/IgniteKernal.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePartitionExchangeManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java

commit ec7b9d848274b229b69dc7b8a20902654f719c44
Author: Andrey Novikov 
Date:   2017-03-23T02:32:38Z

IGNITE-4855 Fixed error on switching between notebooks.

(cherry picked from commit 6a148e2)

commit 36f7621b6eaa710d3b1eba7fddd0dfe92e11133e
Author: Andrey Novikov 
Date:   2017-03-23T03:57:03Z

IGNITE-4830 Fixed error ui.

(cherry picked from commit 48e78a9)

commit 1f3b2fcd003c1f084874d5c421953da0a7cd02cb
Author: Valentin Kulichenko 
Date:   2017-03-28T01:12:17Z

IGNITE-4802 - Separate thread pool for managed services

commit a54b7c6d76974f833e451aff947456ea0013226b
Author: Andrey V. Mashenkov 
Date:   2017-03-28T15:49:03Z

IGNITE-4826: Fix eviction to swap if segmented index is used. This closes 
#1628.

commit 39edcc7890ce497771f532a83a57ecae318d8c88
Author: Andrey V. Mashenkov 
Date:   2017-03-28T15:56:17Z

IGNITE-4815: Fixed confusing javadoc. This closes #1613.

commit e47bf27b5582cd695a7d3de3c39d54b3df4c59cc
Author: Valentin Kulichenko 
Date:   2017-03-28T23:51:44Z

IGNITE-4762 - transactionsAllowed flag for JDBC driver

commit 336672432486830c31cb4b6f8bb1b401c276f3e5
Author: Alexey Kuznetsov 
Date:   2017-03-29T03:53:25Z

IGNITE-4659 Fixed typo.
(cherry picked from commit 6f1e970)

commit 1ddce5517815fc85136e2ead9973c8cf74054f9f
Author: Alexey Kuznetsov 
Date:   2017-03-29T04:11:33Z

Merge branch 'web-console-production' of 
https://github.com/gridgain/apache-ignite into ignite-1.8.5

commit b689624e2984ec3cf42ca5b01966937e236abcdc
Author: Alexander Paschenko 
Date:   2017-03-29T15:15:20Z

IGNITE-4868 Raw Object keys and values indexing fix

commit 357c20ab9593390fb7af25f8638188595c5f6cd4
Author: dkarachentsev 
Date:   2017-03-30T09:50:42Z

IGNITE-4284 - Fix. Failed second client node join with continuous query and 
peer class loading enabled.

commit 45a4cfe7ced27aa9d726b36326bfae8b006e84da
Author: Evgenii Zhuravlev 
Date:   2017-03-29T22:28:20Z

IGNITE-4141 - JDBC driver should always set withKeepBinary flag when 
querying cache. This fixes #1617.

(Backport from master)
(cherry picked from commit 8dd88d8)

commit d4979b87e3301f11f52531645028ecd4e947986b
Author: dkarachentsev 
Date:   2017-03-30T14:35:28Z

IGNITE-4284 - Fix. Failed second client node join with continuous query and 
peer class loading enabled.

commit 2e6bc4416a1f2fa18dad78235b3f71f6fb58a98d
Author: dkarachentsev 
Date:   2017-03-30T14:36:22Z

Cleanup unused imports.

commit e01aee0b1bbdb8ff5583728e539df165029f682d
Author: nikolay_tikhonov 
Date:   2017-03-31T17:19:52Z

Fixed SSL issue.

  

[GitHub] ignite pull request #2342: for-dotNET-tests-ignite-5712

[daradurvs]

GitHub user daradurvs opened a pull request:

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

for-dotNET-tests-ignite-5712



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

$ git pull https://github.com/daradurvs/ignite ignite-5712-test

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

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


commit 5f44aae9e61bca0a8445f6257b7275ac95988e1d
Author: Nikolay Izhikov 
Date:   2017-07-21T14:03:14Z

IGNITE-5712: implementation of context switching for transactions.

commit 7e8d716dff57165241c3ee201f922d19c02e3ce3
Author: Ижиков Николай Владимирович 

Date:   2017-07-24T06:01:09Z

IGNITE-5712: change asserts into IgniteException

commit 8531987d6a1d8f8fea83185bfac48394e28170f7
Author: Ижиков Николай Владимирович 

Date:   2017-07-24T06:02:12Z

IGNITE-5712: remove empty line

commit 67b7d39d649c88550ffc3fa05c79cc0692981af3
Author: Nikolay Izhikov 
Date:   2017-07-24T08:48:32Z

IGNITE-5712: remove threadId check as it leads to existing test fails(.Net 
tests)

commit 63b2fa6a5639990e946f627838498e79e7d42d8b
Author: Nikolay Izhikov 
Date:   2017-07-24T11:27:17Z

IGNITE-5712: Refactor tests to use GridTestUtils API

commit 31379d665851d424f7e8aae03d0bdb9a6ee6a49a
Author: Nikolay Izhikov 
Date:   2017-07-24T15:59:15Z

IGNITE-5712: remove unnecessary checks

commit 75344a01fcfa0a09f2af332d0762bd44937f3259
Author: Nikolay Izhikov 
Date:   2017-07-24T16:24:24Z

IGNITE-425: remote unused constant. fix test

commit b11df10f63f7a5fdfe3064c04b32a3296c31a6bc
Author: Nikolay Izhikov 
Date:   2017-07-24T17:09:58Z

IGNITE-5712: remove unnecessary variable. Setting topologyVersionSnapshot 
on resume

commit addaf7c8d5b361e06884bc836a06d17faef7e704
Author: Nikolay Izhikov 
Date:   2017-07-24T17:29:41Z

IGNITE-5712: remove unseal method. don't seal SUSPENDED tx

commit 1de604eaf0b3e06d16005c83c3f9449458b40fa3
Author: Nikolay Izhikov 
Date:   2017-07-25T11:57:28Z

IGNITE-5712: Fixes after code review

commit 49cf37d6a16e0a9893746630cf521f5904133f73
Author: Nikolay Izhikov 
Date:   2017-07-25T12:01:37Z

IGNITE-5712: Fixes after code review

commit a8fa0b705eb311c8ffcf269ea7d4293f6c0fb73c
Author: Nikolay Izhikov 
Date:   2017-07-25T13:06:01Z

IGNITE-5712: Remove unused import

commit 9a77d3c37edfd91b2e3e6b3cfe0c1b2ea840836f
Author: Nikolay Izhikov 
Date:   2017-07-25T13:32:53Z

IGNITE-5712: Code review fixes

commit 28f46d9f672b17bda1ad0c2b8c23781e1fc9d9d8
Author: Nikolay Izhikov 
Date:   2017-07-25T14:38:19Z

IGNITE-5712: Code review fixes

commit 2eb790544ebf7fe242e296af9cd9c8c019e3913d
Author: Nikolay Izhikov 
Date:   2017-07-25T15:08:27Z

IGNITE-5712: Code review fixes. Return check for a threadId on enter

commit abb9129a1e52b3ad092f8a21bfa430de7da142fe
Author: daradurvs 
Date:   2017-07-25T16:35:06Z

Merge branch 'IGNITE-5712' of https://github.com/nizhikov/ignite into 
ignite-5712-test




---
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: .Net client call tx,close in other thread

[Pavel Tupitsyn]

I've reproduced the issue, it happens because in .NET we auto-close the
transaction
on commit/rollback. This involves two things:
* release .NET reference to Java object
* call Transaction.close()

With sync methods this is trivial, but with commitAsync/rollbackAsync we
have to call close()
in IgniteFuture listener, which is called in a different thread.

I think we need to be able to close() a transaction from any thread.
Otherwise I don't see a non-blocking way to deal with
commitAsync/rollbackAsync.

Thanks,
Pavel

On Tue, Jul 25, 2017 at 6:10 PM, Николай Ижиков 
wrote:

> Hi, Pavel
>
> You can check my pull request.
> https://github.com/apache/ignite/pull/2334
>
> For now I return checks so it has to fail on .Net test suite
>
>
> 2017-07-25 17:16 GMT+03:00 Pavel Tupitsyn :
>
> > Hi Николай,
> >
> > .NET test in question (TestTxStateAndExceptions) does not do any
> > multithreading,
> > everything is called from a single thread.
> >
> > I see that the latest .NET run of your pull request on TeamCity finished
> > successfully:
> > http://ci.ignite.apache.org/viewLog.html?buildId=738277
> >
> > Do you still have a problem with this? If yes, how can I reproduce it?
> > Can you prepare a branch where the test fails, so I can run it locally?
> >
> > Thanks,
> > Pavel
> >
> > On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков 
> > wrote:
> >
> > > Hello, Igniters.
> > >
> > > I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
> > > I found that .Net client perform transaction operation(`tx.close()`) in
> > > thread that not owns transaction.
> > >
> > > So I can't include checks for threadId in my pull request.
> > >
> > > Is it a bug or a desirable behabiour?
> > >
> > > With my new check I got following stack trace:
> > >
> > > Check:
> > >
> > > `assert (threadId() == Thread.currentThread().getId());`
> > >
> > > Exception:
> > >
> > > Test(s) failed. System.AggregateException : One or more errors
> occurred.
> > > > Apache.Ignite.Core.Common.IgniteException : Java exception
> > occurred
> > > [class=java.lang.AssertionError, message=] >
> > > Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError at
> > > org.apache.ignite.internal.processors.cache.transactions.
> > > TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
> > > at
> > > org.apache.ignite.internal.processors.cache.transactions.
> > > TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
> > > at
> > > org.apache.ignite.internal.processors.cache.transactions.
> > > TransactionProxyImpl.close(TransactionProxyImpl.java:317)
> > > at
> > > org.apache.ignite.internal.processors.platform.transactions.
> > > PlatformTransactions.txClose(PlatformTransactions.java:136)
> > > at
> > > org.apache.ignite.internal.processors.platform.transactions.
> > > PlatformTransactions.processInLongOutLong(
> PlatformTransactions.java:178)
> > > at
> > > org.apache.ignite.internal.processors.platform.
> PlatformTargetProxyImpl.
> > > inLongOutLong(PlatformTargetProxyImpl.java:53)
> > > at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> > > includeTaskCanceledExceptions) at System.Threading.Tasks.Task.
> Wait(Int32
> > > millisecondsTimeout, CancellationToken cancellationToken) at
> > > System.Threading.Tasks.Task.Wait() at
> > > Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest
> > > .TestTxStateAndExceptions()
> > > in
> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > > Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
> > > 510 --IgniteException at
> > > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void*
> target,
> > > Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
> > > errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
> > > stackTraceCharsLen, Void* errData, Int32 errDataLen) in
> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > > Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
> > > 1066 at
> > > Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.
> > > TargetInLongOutLong(Void*
> > > ctx, Void* target, Int32 opType, Int64 val) at
> > > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(
> > > IUnmanagedTarget
> > > target, Int32 opType, Int64 memPtr) in
> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > > Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
> > > 429 at Apache.Ignite.Core.Impl.PlatformTarget.DoOutInOp(Int32 type,
> > Int64
> > > val) in
> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > > Ignite.Core\Impl\PlatformTarget.cs:line
> > > 717 at
> > > Apache.Ignite.Core.Impl.Transactions.TransactionsImpl.
> > > TxClose(TransactionImpl
> > > tx) in
> > > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > > Ignite.Core\Impl\Transactions\TransactionsImpl.cs:line
> > > 216 at 

Meetup/Live Streaming: An Intro to Ignite

[Denis Magda]

Igniters,

If you live in London or close to it, stop by the meetup Akmal is giving there 
tomorrow:
https://ignite.apache.org/events.html#Brighton-Java-241395191

Rest of us can grasp an opportunity of the live streaming. Find the link on 
this page:
https://www.meetup.com/Brighton-Java/events/241395191/

Finally, help to spread the message outside of this discussion list:
https://twitter.com/denismagda/status/889880292072202240

—
Denis

Re: Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Andrey Kuznetsov]

I apologize for damaged formatting. Below is my message as it should be.


Hi Igniters,

I'd like to discuss future changes related to https://issues.apache.org/
jira/browse/IGNITE-5655.

Is it really good idea to introduce new flag (ENCODED_STRING) for existing
String datatype? It's possible to use existing STRING flag at negligible
performance cost.

Currently, utf-8-encoded string looks like

byteFlag nonNegativeIntStrLen bytes

This format can be backward compatibly extended to

byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes

Next, I suggest to add new BinaryConfiguration property for encoding to use
instead of using global property. It seems to be more convenient for user.

I'll appreciate your feedback.

2017-07-25 16:13 GMT+03:00 Andrey Kuznetsov :

> Hi Igniters,I'd like to discuss future changes related to  IGNITE-5655
>   . Is it really good
> idea to introduce new flag (ENCODED_STRING) for existing String datatype?
> It's possible to use existing STRING flag at negligible performance cost.
> Currently, utf-8-encoded string looks like
> byteFlag nonNegativeIntStrLen bytes
> This format can be backward compatibly extended to
> byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
> Next, I suggest to add new BinaryConfiguration property for encoding to use
> instead of using global property. It seems to be more convenient for
> user.I'll appreciate your feedback.
>
>
>
> -
> Best regards,
>   Andrey Kuznetsov.
> --
> View this message in context: http://apache-ignite-
> developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-
> support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
> Sent from the Apache Ignite Developers mailing list archive at Nabble.com.




-- 
Best regards,
  Andrey Kuznetsov.

Re: .Net client call tx,close in other thread

[Николай Ижиков]

Hi, Pavel

You can check my pull request.
https://github.com/apache/ignite/pull/2334

For now I return checks so it has to fail on .Net test suite


2017-07-25 17:16 GMT+03:00 Pavel Tupitsyn :

> Hi Николай,
>
> .NET test in question (TestTxStateAndExceptions) does not do any
> multithreading,
> everything is called from a single thread.
>
> I see that the latest .NET run of your pull request on TeamCity finished
> successfully:
> http://ci.ignite.apache.org/viewLog.html?buildId=738277
>
> Do you still have a problem with this? If yes, how can I reproduce it?
> Can you prepare a branch where the test fails, so I can run it locally?
>
> Thanks,
> Pavel
>
> On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков 
> wrote:
>
> > Hello, Igniters.
> >
> > I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
> > I found that .Net client perform transaction operation(`tx.close()`) in
> > thread that not owns transaction.
> >
> > So I can't include checks for threadId in my pull request.
> >
> > Is it a bug or a desirable behabiour?
> >
> > With my new check I got following stack trace:
> >
> > Check:
> >
> > `assert (threadId() == Thread.currentThread().getId());`
> >
> > Exception:
> >
> > Test(s) failed. System.AggregateException : One or more errors occurred.
> > > Apache.Ignite.Core.Common.IgniteException : Java exception
> occurred
> > [class=java.lang.AssertionError, message=] >
> > Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError at
> > org.apache.ignite.internal.processors.cache.transactions.
> > TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
> > at
> > org.apache.ignite.internal.processors.cache.transactions.
> > TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
> > at
> > org.apache.ignite.internal.processors.cache.transactions.
> > TransactionProxyImpl.close(TransactionProxyImpl.java:317)
> > at
> > org.apache.ignite.internal.processors.platform.transactions.
> > PlatformTransactions.txClose(PlatformTransactions.java:136)
> > at
> > org.apache.ignite.internal.processors.platform.transactions.
> > PlatformTransactions.processInLongOutLong(PlatformTransactions.java:178)
> > at
> > org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.
> > inLongOutLong(PlatformTargetProxyImpl.java:53)
> > at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> > includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32
> > millisecondsTimeout, CancellationToken cancellationToken) at
> > System.Threading.Tasks.Task.Wait() at
> > Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest
> > .TestTxStateAndExceptions()
> > in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
> > 510 --IgniteException at
> > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* target,
> > Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
> > errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
> > stackTraceCharsLen, Void* errData, Int32 errDataLen) in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
> > 1066 at
> > Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.
> > TargetInLongOutLong(Void*
> > ctx, Void* target, Int32 opType, Int64 val) at
> > Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(
> > IUnmanagedTarget
> > target, Int32 opType, Int64 memPtr) in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
> > 429 at Apache.Ignite.Core.Impl.PlatformTarget.DoOutInOp(Int32 type,
> Int64
> > val) in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core\Impl\PlatformTarget.cs:line
> > 717 at
> > Apache.Ignite.Core.Impl.Transactions.TransactionsImpl.
> > TxClose(TransactionImpl
> > tx) in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core\Impl\Transactions\TransactionsImpl.cs:line
> > 216 at Apache.Ignite.Core.Impl.Transactions.TransactionImpl.Close() in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core\Impl\Transactions\TransactionImpl.cs:line
> > 442 at
> > Apache.Ignite.Core.Impl.Transactions.TransactionImpl.<
> > CloseWhenComplete>b__d(Task
> > x) in
> > c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> > Ignite.Core\Impl\Transactions\TransactionImpl.cs:line
> > 460 at System.Threading.Tasks.Task.Execute() --JavaException ---
> > Stderr: --- Test started:
> > CacheAbstractTransactionalTest.TestTxStateAndExceptions Test finished:
> > CacheAbstractTransactionalTest.TestTxStateAndExceptions
> > --
> > Nikolay Izhikov
> > nizhikov@gmail.com
> >
>



-- 
Nikolay Izhikov
nizhikov@gmail.com

[jira] [Created] (IGNITE-5833) Changing maven goal from "install" to "package" for building from sources

[Oleg Ostanin (JIRA)]

Oleg Ostanin created IGNITE-5833:


 Summary: Changing maven goal from "install" to "package" for 
building from sources
 Key: IGNITE-5833
 URL: https://issues.apache.org/jira/browse/IGNITE-5833
 Project: Ignite
  Issue Type: Bug
Reporter: Oleg Ostanin
Assignee: Oleg Ostanin


Currently we need to run 'mvn clean install' to build Apache Ignite from 
sources, otherwise we can not perform javadoc generation in the next build step 
in DEVNOTES.txt. We need to fix this issue before next release.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5832) .NET: Support transaction continuation in another thread

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5832:
--

 Summary: .NET: Support transaction continuation in another thread
 Key: IGNITE-5832
 URL: https://issues.apache.org/jira/browse/IGNITE-5832
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn


Update API according to the parent task, add tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5831) .NET: Support TransactionScopeAsyncFlowOption.Enabled in TransactionScope

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5831:
--

 Summary: .NET: Support TransactionScopeAsyncFlowOption.Enabled in 
TransactionScope
 Key: IGNITE-5831
 URL: https://issues.apache.org/jira/browse/IGNITE-5831
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
 Fix For: 2.3


IGNITE-4887 introduces support for async transaction continuations (start tx in 
one thread, perform async cache update, continue transaction in async 
continuation).

This should allow us to support {{TransactionScopeAsyncFlowOption.Enabled}} 
([msdn|https://msdn.microsoft.com/en-us/library/system.transactions.transactionscopeasyncflowoption(v=vs.110).aspx])
 with {{TransactionScope}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: .Net client call tx,close in other thread

[Pavel Tupitsyn]

Hi Николай,

.NET test in question (TestTxStateAndExceptions) does not do any
multithreading,
everything is called from a single thread.

I see that the latest .NET run of your pull request on TeamCity finished
successfully:
http://ci.ignite.apache.org/viewLog.html?buildId=738277

Do you still have a problem with this? If yes, how can I reproduce it?
Can you prepare a branch where the test fails, so I can run it locally?

Thanks,
Pavel

On Tue, Jul 25, 2017 at 4:47 PM, Николай Ижиков 
wrote:

> Hello, Igniters.
>
> I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
> I found that .Net client perform transaction operation(`tx.close()`) in
> thread that not owns transaction.
>
> So I can't include checks for threadId in my pull request.
>
> Is it a bug or a desirable behabiour?
>
> With my new check I got following stack trace:
>
> Check:
>
> `assert (threadId() == Thread.currentThread().getId());`
>
> Exception:
>
> Test(s) failed. System.AggregateException : One or more errors occurred.
> > Apache.Ignite.Core.Common.IgniteException : Java exception occurred
> [class=java.lang.AssertionError, message=] >
> Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError at
> org.apache.ignite.internal.processors.cache.transactions.
> TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
> at
> org.apache.ignite.internal.processors.cache.transactions.
> TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
> at
> org.apache.ignite.internal.processors.cache.transactions.
> TransactionProxyImpl.close(TransactionProxyImpl.java:317)
> at
> org.apache.ignite.internal.processors.platform.transactions.
> PlatformTransactions.txClose(PlatformTransactions.java:136)
> at
> org.apache.ignite.internal.processors.platform.transactions.
> PlatformTransactions.processInLongOutLong(PlatformTransactions.java:178)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.
> inLongOutLong(PlatformTargetProxyImpl.java:53)
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32
> millisecondsTimeout, CancellationToken cancellationToken) at
> System.Threading.Tasks.Task.Wait() at
> Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest
> .TestTxStateAndExceptions()
> in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
> 510 --IgniteException at
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* target,
> Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
> errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
> stackTraceCharsLen, Void* errData, Int32 errDataLen) in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
> 1066 at
> Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.
> TargetInLongOutLong(Void*
> ctx, Void* target, Int32 opType, Int64 val) at
> Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(
> IUnmanagedTarget
> target, Int32 opType, Int64 memPtr) in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
> 429 at Apache.Ignite.Core.Impl.PlatformTarget.DoOutInOp(Int32 type, Int64
> val) in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core\Impl\PlatformTarget.cs:line
> 717 at
> Apache.Ignite.Core.Impl.Transactions.TransactionsImpl.
> TxClose(TransactionImpl
> tx) in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core\Impl\Transactions\TransactionsImpl.cs:line
> 216 at Apache.Ignite.Core.Impl.Transactions.TransactionImpl.Close() in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core\Impl\Transactions\TransactionImpl.cs:line
> 442 at
> Apache.Ignite.Core.Impl.Transactions.TransactionImpl.<
> CloseWhenComplete>b__d(Task
> x) in
> c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.
> Ignite.Core\Impl\Transactions\TransactionImpl.cs:line
> 460 at System.Threading.Tasks.Task.Execute() --JavaException ---
> Stderr: --- Test started:
> CacheAbstractTransactionalTest.TestTxStateAndExceptions Test finished:
> CacheAbstractTransactionalTest.TestTxStateAndExceptions
> --
> Nikolay Izhikov
> nizhikov@gmail.com
>

[jira] [Created] (IGNITE-5830) Introduce cache start & stop order on cluster activation

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-5830:
---

 Summary: Introduce cache start & stop order on cluster activation
 Key: IGNITE-5830
 URL: https://issues.apache.org/jira/browse/IGNITE-5830
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.2


Some of the cache components can rely on system/utility caches during start 
operation, but the order of cache start & stop on cluster activation is not 
determined. So there can be situation that user cache started first than system 
cache and it can lead to unexpected problems.
We should start system & utility caches in first order on cluster activation 
and stop it in last order on cluster deactivation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Cache Metrics

[Andrey Gura]

Den,

doesn't make sense from my point if view. And we create new problem:
how should we aggregate this metrics when user requests metrics for
cluster group.

On Mon, Jul 24, 2017 at 8:48 PM, Denis Magda  wrote:
> Guys,
>
> What if we calculate it on both sides? The client will keep the total time 
> needed to complete an operation including network hoops while a server 
> (primary or backup) will count only local time.
>
> —
> Denis
>
>> On Jul 17, 2017, at 7:07 AM, Andrey Gura  wrote:
>>
>> Hi,
>>
>> I believe that the first solution is better than second because it
>> takes into account network communication time. Average time of
>> communication between nodes doesn't make sense from my point of view.
>>
>> So I vote for #1.
>>
>> On Thu, Jul 13, 2017 at 11:52 PM, Вячеслав Коптилин
>>  wrote:
>>> Hi Experts,
>>>
>>> I am working on https://issues.apache.org/jira/browse/IGNITE-3495
>>>
>>> A few words about this issue:
>>> It is about that the process of gathering/updating of cache metrics is
>>> inconsistent in some cases.
>>> Let's consider the following simple topology which contains only two nodes:
>>> first node is a client node and the second is a server.
>>> And client node starts requests to the server node, for instance
>>> cache.put(), cache.putAll(), cache.get() etc.
>>> In that case, metrics which are related to counters (cache hits, cache
>>> misses, removals and puts) are calculated on the server side,
>>> while time metrics are updated on the client node.
>>>
>>> I think that both metrics (counters and time) should be calculated on the
>>> same node. So, there are two obvious solution:
>>>
>>> #1 Node that starts some operation is responsible for updating the cache
>>> metrics.
>>> Pro:
>>> - it will allow to get more accurate results of metrics.
>>> Contra:
>>> - this approach does not work in particular cases. for example, partitioned
>>> cache with FULL_ASYNC write synchronization mode.
>>> - needs to extend response messages (GridNearAtomicUpdateResponse,
>>> GridNearGetResponse etc)
>>>  in order to provide additional information from remote node: cache hits,
>>> number of removal etc.
>>>  So, it will lead to additional pressure on communication channel.
>>> Perhaps, this impact will be small - 4 bytes per message or something like
>>> that.
>>> - backward incompatibility (this is a consequence of the previous point)
>>>
>>> #2 Primary node (node that actually executes a request)
>>> Pro:
>>> - easy to implement
>>> - backward compatible
>>> Contra:
>>> - time metrics will not include the time of communication between nodes, so
>>> the results will be less accurate.
>>> - perhaps we need to provide additional metric which will allow to get avg
>>> time of communication between nodes.
>>>
>>> Please let me know about your thoughts.
>>> Perhaps, both alternatives are not so good...
>>>
>>> Regards,
>>> Slava.
>

.Net client call tx,close in other thread

[Николай Ижиков]

Hello, Igniters.

I working on issue https://issues.apache.org/jira/browse/IGNITE-5712
I found that .Net client perform transaction operation(`tx.close()`) in
thread that not owns transaction.

So I can't include checks for threadId in my pull request.

Is it a bug or a desirable behabiour?

With my new check I got following stack trace:

Check:

`assert (threadId() == Thread.currentThread().getId());`

Exception:

Test(s) failed. System.AggregateException : One or more errors occurred.
> Apache.Ignite.Core.Common.IgniteException : Java exception occurred
[class=java.lang.AssertionError, message=] >
Apache.Ignite.Core.Common.JavaException : java.lang.AssertionError at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.enter0(TransactionProxyImpl.java:113)
at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.enter(TransactionProxyImpl.java:106)
at
org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.close(TransactionProxyImpl.java:317)
at
org.apache.ignite.internal.processors.platform.transactions.PlatformTransactions.txClose(PlatformTransactions.java:136)
at
org.apache.ignite.internal.processors.platform.transactions.PlatformTransactions.processInLongOutLong(PlatformTransactions.java:178)
at
org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inLongOutLong(PlatformTargetProxyImpl.java:53)
at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
includeTaskCanceledExceptions) at System.Threading.Tasks.Task.Wait(Int32
millisecondsTimeout, CancellationToken cancellationToken) at
System.Threading.Tasks.Task.Wait() at
Apache.Ignite.Core.Tests.Cache.CacheAbstractTransactionalTest.TestTxStateAndExceptions()
in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core.Tests\Cache\CacheAbstractTransactionalTest.cs:line
510 --IgniteException at
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedCallbacks.Error(Void* target,
Int32 errType, SByte* errClsChars, Int32 errClsCharsLen, SByte*
errMsgChars, Int32 errMsgCharsLen, SByte* stackTraceChars, Int32
stackTraceCharsLen, Void* errData, Int32 errDataLen) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Unmanaged\UnmanagedCallbacks.cs:line
1066 at
Apache.Ignite.Core.Impl.Unmanaged.IgniteJniNativeMethods.TargetInLongOutLong(Void*
ctx, Void* target, Int32 opType, Int64 val) at
Apache.Ignite.Core.Impl.Unmanaged.UnmanagedUtils.TargetInLongOutLong(IUnmanagedTarget
target, Int32 opType, Int64 memPtr) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Unmanaged\UnmanagedUtils.cs:line
429 at Apache.Ignite.Core.Impl.PlatformTarget.DoOutInOp(Int32 type, Int64
val) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core\Impl\PlatformTarget.cs:line
717 at
Apache.Ignite.Core.Impl.Transactions.TransactionsImpl.TxClose(TransactionImpl
tx) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Transactions\TransactionsImpl.cs:line
216 at Apache.Ignite.Core.Impl.Transactions.TransactionImpl.Close() in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Transactions\TransactionImpl.cs:line
442 at
Apache.Ignite.Core.Impl.Transactions.TransactionImpl.b__d(Task
x) in
c:\BuildAgent\work\820be461cd64b574\modules\platforms\dotnet\Apache.Ignite.Core\Impl\Transactions\TransactionImpl.cs:line
460 at System.Threading.Tasks.Task.Execute() --JavaException ---
Stderr: --- Test started:
CacheAbstractTransactionalTest.TestTxStateAndExceptions Test finished:
CacheAbstractTransactionalTest.TestTxStateAndExceptions
-- 
Nikolay Izhikov
nizhikov@gmail.com

Non-UTF-8 string encoding support in BinaryMarshaller (IGNITE-5655)

[Andrey Kuznetsov]

Hi Igniters,I'd like to discuss future changes related to  IGNITE-5655
  . Is it really good
idea to introduce new flag (ENCODED_STRING) for existing String datatype?
It's possible to use existing STRING flag at negligible performance cost.
Currently, utf-8-encoded string looks like 
byteFlag nonNegativeIntStrLen bytes
This format can be backward compatibly extended to
byteFlag [negativeIntCharsetCode] nonNegativeIntStrLen bytes
Next, I suggest to add new BinaryConfiguration property for encoding to use
instead of using global property. It seems to be more convenient for
user.I'll appreciate your feedback.



-
Best regards,
  Andrey Kuznetsov.
--
View this message in context: 
http://apache-ignite-developers.2346864.n4.nabble.com/Non-UTF-8-string-encoding-support-in-BinaryMarshaller-IGNITE-5655-tp20024.html
Sent from the Apache Ignite Developers mailing list archive at Nabble.com.

Re: Disabling assertions in tests.

[Dmitriy Setrakyan]

Vitaly,

Assertions are made to ensure that Igntie works correctly internally. It
seems rather strange that you need to break Ignite in order to test this
ticket. It may be an indication that you are not on the right path.

D.

On Tue, Jul 25, 2017 at 6:25 AM, Vitaliy Biryukov <
biryukovvitali...@gmail.com> wrote:

> Hi, Igniters!
>
> I'm working on this issue: IGNITE-5468
> 
> And to completely cover this issue with tests, I need to disable
> assertions.
>
> I see three solutions:
>
>1. Make a separate test suite with disabled assertions (If I correctly
>understood that suites run on different JVMs on TC).
>2. Add the ability to start a remote grid with disabled assertions in
>tests.
>3. Do not test this functionality.
>
> What do you think?
>
> --
> Best Regards,
> Vitaliy Biryukov
>

Re: Hello

[Denis Mekhanikov]

My JIRA ID: dmekhanikov

Thank you!

вт, 25 июл. 2017 г. в 15:09, Dmitry Pavlov :

> Hi Denis,
>
> Welcome to the Ignite community!
>
> If you need contributor access to Apache JIRA, could you please sign up and
> share your JIRA ID.
>
> Looking forward to your contributions!
>
> Sincerely,
> Dmitry Pavlov
>
> вт, 25 июл. 2017 г. в 14:21, Denis Mekhanikov :
>
> > Hi everyone!
> >
> > My name is Denis, I'm from Saint Petersburg.
> > I'd like to contribute to Apache Ignite project. I hope, you'll find my
> > work useful.
> >
> > --
> > Best regards,
> > Denis Mekhanikov
> >
>

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Anton Vinogradov]

Alexei,

> How would task know the partition it is running over ?
Not sure it necessary.
You'll create pair partition-job at task's map phase.

> How can I assign task for each cache partition ?
Just implement map method generates map with size equals to partition count.

> How can I enforce partition reservation if task works with multiple
caches at once ?
This possible only in case caches use safe affinity function.
And it useful only it this case.

On Tue, Jul 25, 2017 at 3:22 PM, Alexei Scherbakov <
alexey.scherbak...@gmail.com> wrote:

> Please read job instead task
>
> 2017-07-25 15:20 GMT+03:00 Alexei Scherbakov  >:
>
> > Main point of the issue is to provide clean API for working with
> > computations requiring data collocation
> >
> > affinityCall/Run provide the ability to run closure near data, but
> > map/reduce API is a way reacher: continuous mapping, task session, etc.
> >
> > As for proposed API, I do not understand fully how it solves the problem.
> >
> > Maxim, please provide detailed javadoc for each method and each argument
> > for presented API, and the answers to the following questions:
> >
> > 1. How would task know the partition it is running over ?
> >
> > 2. How can I assign task for each cache partition ?
> >
> > 3. How can I enforce partition reservation if task works with multiple
> > caches at once ?
> >
> >
> >
> >
> >
> > 2017-07-25 12:30 GMT+03:00 Anton Vinogradov :
> >
> >> Val,
> >>
> >> Sure, we can, but we'd like to use map/reduce without fearing that
> >> topology
> >> can change.
> >>
> >> On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com> wrote:
> >>
> >> > Anton,
> >> >
> >> > You can call affinityCallAsync multiple times and then reduce locally.
> >> >
> >> > -Val
> >> >
> >> > On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov <
> >> > avinogra...@gridgain.com>
> >> > wrote:
> >> >
> >> > > Val,
> >> > >
> >> > > > What is the use case for which current affinityRun/Call API
> doesn't
> >> > work?
> >> > > It does not work for map/reduce.
> >> > >
> >> > > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko <
> >> > > valentin.kuliche...@gmail.com> wrote:
> >> > >
> >> > > > Maxim,
> >> > > >
> >> > > > The issue is that it's currently assumed to support job mapping,
> >> but it
> >> > > > actually doesn't. However, I agree that AffinityKeyMapped
> annotation
> >> > > > doesn't fit the use case well. Let's fix documentation and JavaDoc
> >> > then.
> >> > > >
> >> > > > As for the proposed API, it's overcomplicated, took me 15 minutes
> to
> >> > > > understand what it does :)
> >> > > >
> >> > > > What is the use case for which current affinityRun/Call API
> doesn't
> >> > work?
> >> > > >
> >> > > > -Val
> >> > > >
> >> > > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim <
> dreamx@gmail.com
> >> >
> >> > > > wrote:
> >> > > >
> >> > > > > Valentin,
> >> > > > >
> >> > > > > The author of tiket wants to see to provide some API allows to
> map
> >> > > > > ComputeJobs to partitions or keys. If we use @AffinityKeyMapped
> >> then
> >> > > you
> >> > > > > need to enter the cache name parameter, I think this is not
> >> > convenient
> >> > > > for
> >> > > > > the user. Therefore, I propose to extend the existing API.
> >> > > > > Having consulted with Anton V. decided to make a separate
> >> interface
> >> > > > > ReducibleTask, which will allow us to have different map logic
> at
> >> > each
> >> > > > > inheritor.
> >> > > > >
> >> > > > > Old method, allows to map to node
> >> > > > > public interface ComputeTask extends ReducibleTask {
> >> > > > > @Nullable public Map
> >> > > > > map(List subgrid, @Nullable T arg) throws
> >> > IgniteException;
> >> > > > > }
> >> > > > >
> >> > > > > Brand new method with mapping to partitions, which solves
> topology
> >> > > change
> >> > > > > issues.
> >> > > > > public interface AffinityComputeTask extends
> >> ReducibleTask {
> >> > > > > @Nullable public Map
> >> > > > map(@NotnullString
> >> > > > > cacheName, List partIds, @Nullable T arg) throws
> >> > > > IgniteException;
> >> > > > > }
> >> > > > >
> >> > > > > public interface ReducibleTask extends Serializable {
> >> > > > > public ComputeJobResultPolicy result(ComputeJobResult res,
> >> > > > > List rcvd) throws IgniteException;
> >> > > > >
> >> > > > > @Nullable public R reduce(List results)
> >> throws
> >> > > > > IgniteException;
> >> > > > > }
> >> > > > >
> >> > > > > We also need to implement AffinityComputeTaskAdapter and
> >> > > > > AffinityComputeTaskSplitAdapter, for implementation by default.
> >> It
> >> > is
> >> > > > > right?
> >> > > > >
> >> > > > > In the IgniteCompute add:
> >> > > > >
> >> > > > > @IgniteAsyncSupported
> >> > > > > public  R affinityExecute(Class >> > AffinityComputeTask >> > > > R>>
> >> > > > > taskCls, List partIds, @Nullable T arg) throws
> >> > > IgniteException;
> >> > > > 

[GitHub] ignite pull request #2340: IGNITE-5802: Fix all wrong TODO comments in ML co...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Changing public IgniteCompute API to improve changes in 5037 ticket

[Alexei Scherbakov]

Please read job instead task

2017-07-25 15:20 GMT+03:00 Alexei Scherbakov :

> Main point of the issue is to provide clean API for working with
> computations requiring data collocation
>
> affinityCall/Run provide the ability to run closure near data, but
> map/reduce API is a way reacher: continuous mapping, task session, etc.
>
> As for proposed API, I do not understand fully how it solves the problem.
>
> Maxim, please provide detailed javadoc for each method and each argument
> for presented API, and the answers to the following questions:
>
> 1. How would task know the partition it is running over ?
>
> 2. How can I assign task for each cache partition ?
>
> 3. How can I enforce partition reservation if task works with multiple
> caches at once ?
>
>
>
>
>
> 2017-07-25 12:30 GMT+03:00 Anton Vinogradov :
>
>> Val,
>>
>> Sure, we can, but we'd like to use map/reduce without fearing that
>> topology
>> can change.
>>
>> On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko <
>> valentin.kuliche...@gmail.com> wrote:
>>
>> > Anton,
>> >
>> > You can call affinityCallAsync multiple times and then reduce locally.
>> >
>> > -Val
>> >
>> > On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov <
>> > avinogra...@gridgain.com>
>> > wrote:
>> >
>> > > Val,
>> > >
>> > > > What is the use case for which current affinityRun/Call API doesn't
>> > work?
>> > > It does not work for map/reduce.
>> > >
>> > > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko <
>> > > valentin.kuliche...@gmail.com> wrote:
>> > >
>> > > > Maxim,
>> > > >
>> > > > The issue is that it's currently assumed to support job mapping,
>> but it
>> > > > actually doesn't. However, I agree that AffinityKeyMapped annotation
>> > > > doesn't fit the use case well. Let's fix documentation and JavaDoc
>> > then.
>> > > >
>> > > > As for the proposed API, it's overcomplicated, took me 15 minutes to
>> > > > understand what it does :)
>> > > >
>> > > > What is the use case for which current affinityRun/Call API doesn't
>> > work?
>> > > >
>> > > > -Val
>> > > >
>> > > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim > >
>> > > > wrote:
>> > > >
>> > > > > Valentin,
>> > > > >
>> > > > > The author of tiket wants to see to provide some API allows to map
>> > > > > ComputeJobs to partitions or keys. If we use @AffinityKeyMapped
>> then
>> > > you
>> > > > > need to enter the cache name parameter, I think this is not
>> > convenient
>> > > > for
>> > > > > the user. Therefore, I propose to extend the existing API.
>> > > > > Having consulted with Anton V. decided to make a separate
>> interface
>> > > > > ReducibleTask, which will allow us to have different map logic at
>> > each
>> > > > > inheritor.
>> > > > >
>> > > > > Old method, allows to map to node
>> > > > > public interface ComputeTask extends ReducibleTask {
>> > > > > @Nullable public Map
>> > > > > map(List subgrid, @Nullable T arg) throws
>> > IgniteException;
>> > > > > }
>> > > > >
>> > > > > Brand new method with mapping to partitions, which solves topology
>> > > change
>> > > > > issues.
>> > > > > public interface AffinityComputeTask extends
>> ReducibleTask {
>> > > > > @Nullable public Map
>> > > > map(@NotnullString
>> > > > > cacheName, List partIds, @Nullable T arg) throws
>> > > > IgniteException;
>> > > > > }
>> > > > >
>> > > > > public interface ReducibleTask extends Serializable {
>> > > > > public ComputeJobResultPolicy result(ComputeJobResult res,
>> > > > > List rcvd) throws IgniteException;
>> > > > >
>> > > > > @Nullable public R reduce(List results)
>> throws
>> > > > > IgniteException;
>> > > > > }
>> > > > >
>> > > > > We also need to implement AffinityComputeTaskAdapter and
>> > > > > AffinityComputeTaskSplitAdapter, for implementation by default.
>> It
>> > is
>> > > > > right?
>> > > > >
>> > > > > In the IgniteCompute add:
>> > > > >
>> > > > > @IgniteAsyncSupported
>> > > > > public  R affinityExecute(Class> > AffinityComputeTask> > > > R>>
>> > > > > taskCls, List partIds, @Nullable T arg) throws
>> > > IgniteException;
>> > > > > @IgniteAsyncSupported
>> > > > > public  R affinityExecute(AffinityComputeTask task,
>> > > > > List partIds, @Nullable T arg) throws IgniteException;
>> > > > >
>> > > > > public  ComputeTaskFuture affinityExecuteAsync(Class> > extends
>> > > > > AffinityComputeTask> taskCls, List partIds,
>> @Nullable
>> > T
>> > > > arg)
>> > > > > throws IgniteException;
>> > > > > public  ComputeTaskFuture affinityExecuteAsync(
>> > > > AffinityComputeTask> > > > > R> task, List partIds, @Nullable T arg) throws
>> > > IgniteException;
>> > > > >
>> > > > >
>> > > > > How do you like this idea or do you insist that you need to use
>> > > > > @AffinityKeyMapped to solve the problem?
>> > > > >
>> > > > >
>> > > > > > 13 июля 2017 г., в 6:36, Valentin Kulichenko <
>> > > > > 

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Alexei Scherbakov]

Main point of the issue is to provide clean API for working with
computations requiring data collocation

affinityCall/Run provide the ability to run closure near data, but
map/reduce API is a way reacher: continuous mapping, task session, etc.

As for proposed API, I do not understand fully how it solves the problem.

Maxim, please provide detailed javadoc for each method and each argument
for presented API, and the answers to the following questions:

1. How would task know the partition it is running over ?

2. How can I assign task for each cache partition ?

3. How can I enforce partition reservation if task works with multiple
caches at once ?





2017-07-25 12:30 GMT+03:00 Anton Vinogradov :

> Val,
>
> Sure, we can, but we'd like to use map/reduce without fearing that topology
> can change.
>
> On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Anton,
> >
> > You can call affinityCallAsync multiple times and then reduce locally.
> >
> > -Val
> >
> > On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov <
> > avinogra...@gridgain.com>
> > wrote:
> >
> > > Val,
> > >
> > > > What is the use case for which current affinityRun/Call API doesn't
> > work?
> > > It does not work for map/reduce.
> > >
> > > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com> wrote:
> > >
> > > > Maxim,
> > > >
> > > > The issue is that it's currently assumed to support job mapping, but
> it
> > > > actually doesn't. However, I agree that AffinityKeyMapped annotation
> > > > doesn't fit the use case well. Let's fix documentation and JavaDoc
> > then.
> > > >
> > > > As for the proposed API, it's overcomplicated, took me 15 minutes to
> > > > understand what it does :)
> > > >
> > > > What is the use case for which current affinityRun/Call API doesn't
> > work?
> > > >
> > > > -Val
> > > >
> > > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim 
> > > > wrote:
> > > >
> > > > > Valentin,
> > > > >
> > > > > The author of tiket wants to see to provide some API allows to map
> > > > > ComputeJobs to partitions or keys. If we use @AffinityKeyMapped
> then
> > > you
> > > > > need to enter the cache name parameter, I think this is not
> > convenient
> > > > for
> > > > > the user. Therefore, I propose to extend the existing API.
> > > > > Having consulted with Anton V. decided to make a separate interface
> > > > > ReducibleTask, which will allow us to have different map logic at
> > each
> > > > > inheritor.
> > > > >
> > > > > Old method, allows to map to node
> > > > > public interface ComputeTask extends ReducibleTask {
> > > > > @Nullable public Map
> > > > > map(List subgrid, @Nullable T arg) throws
> > IgniteException;
> > > > > }
> > > > >
> > > > > Brand new method with mapping to partitions, which solves topology
> > > change
> > > > > issues.
> > > > > public interface AffinityComputeTask extends
> ReducibleTask {
> > > > > @Nullable public Map
> > > > map(@NotnullString
> > > > > cacheName, List partIds, @Nullable T arg) throws
> > > > IgniteException;
> > > > > }
> > > > >
> > > > > public interface ReducibleTask extends Serializable {
> > > > > public ComputeJobResultPolicy result(ComputeJobResult res,
> > > > > List rcvd) throws IgniteException;
> > > > >
> > > > > @Nullable public R reduce(List results)
> throws
> > > > > IgniteException;
> > > > > }
> > > > >
> > > > > We also need to implement AffinityComputeTaskAdapter and
> > > > > AffinityComputeTaskSplitAdapter, for implementation by default. It
> > is
> > > > > right?
> > > > >
> > > > > In the IgniteCompute add:
> > > > >
> > > > > @IgniteAsyncSupported
> > > > > public  R affinityExecute(Class > AffinityComputeTask > > > R>>
> > > > > taskCls, List partIds, @Nullable T arg) throws
> > > IgniteException;
> > > > > @IgniteAsyncSupported
> > > > > public  R affinityExecute(AffinityComputeTask task,
> > > > > List partIds, @Nullable T arg) throws IgniteException;
> > > > >
> > > > > public  ComputeTaskFuture affinityExecuteAsync(Class > extends
> > > > > AffinityComputeTask> taskCls, List partIds,
> @Nullable
> > T
> > > > arg)
> > > > > throws IgniteException;
> > > > > public  ComputeTaskFuture affinityExecuteAsync(
> > > > AffinityComputeTask > > > > R> task, List partIds, @Nullable T arg) throws
> > > IgniteException;
> > > > >
> > > > >
> > > > > How do you like this idea or do you insist that you need to use
> > > > > @AffinityKeyMapped to solve the problem?
> > > > >
> > > > >
> > > > > > 13 июля 2017 г., в 6:36, Valentin Kulichenko <
> > > > > valentin.kuliche...@gmail.com> написал(а):
> > > > > >
> > > > > > Hi Max,
> > > > > >
> > > > > > This ticket doesn't assume any API changes, it's about broken
> > > > > > functionality. I would start with checking what tests we have
> > > > > > for @AffinityKeyMapped and creating missing one. From what 

[GitHub] ignite pull request #2336: IGNITE-5770 Refactor PlatformProcessor to Platfor...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: Hello

[Dmitry Pavlov]

Hi Denis,

Welcome to the Ignite community!

If you need contributor access to Apache JIRA, could you please sign up and
share your JIRA ID.

Looking forward to your contributions!

Sincerely,
Dmitry Pavlov

вт, 25 июл. 2017 г. в 14:21, Denis Mekhanikov :

> Hi everyone!
>
> My name is Denis, I'm from Saint Petersburg.
> I'd like to contribute to Apache Ignite project. I hope, you'll find my
> work useful.
>
> --
> Best regards,
> Denis Mekhanikov
>

[jira] [Created] (IGNITE-5829) Writing entry contents only single time

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-5829:
---

 Summary: Writing entry contents only single time
 Key: IGNITE-5829
 URL: https://issues.apache.org/jira/browse/IGNITE-5829
 Project: Ignite
  Issue Type: Improvement
  Components: cache
Affects Versions: 2.1
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.2


Now we write entry contents 2 times: once in logical record and once again when 
we write data page update records. We should do that only once. In data page 
updates we can write only a reference to the logical update record but not the 
whole entry contents.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #2341: IGNITE-5648: SQL: Added support for NOT NULL cons...

[skalashnikov]

GitHub user skalashnikov opened a pull request:

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

IGNITE-5648: SQL: Added support for NOT NULL constraint



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

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

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

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


commit 5942441972c5e549253522b4981cb3bbd62db329
Author: skalashnikov 
Date:   2017-07-13T17:12:06Z

IGNITE-5648: SQL: Added support for NOT NULL constraint

commit 658f5a35d437f8bf38ae61173513b324cbc0f72e
Author: skalashnikov 
Date:   2017-07-25T11:35:47Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-5648




---
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.
---

Disabling assertions in tests.

[Vitaliy Biryukov]

Hi, Igniters!

I'm working on this issue: IGNITE-5468

And to completely cover this issue with tests, I need to disable assertions.

I see three solutions:

   1. Make a separate test suite with disabled assertions (If I correctly
   understood that suites run on different JVMs on TC).
   2. Add the ability to start a remote grid with disabled assertions in
   tests.
   3. Do not test this functionality.

What do you think?

-- 
Best Regards,
Vitaliy Biryukov

Hello

[Denis Mekhanikov]

Hi everyone!

My name is Denis, I'm from Saint Petersburg.
I'd like to contribute to Apache Ignite project. I hope, you'll find my
work useful.

-- 
Best regards,
Denis Mekhanikov

[GitHub] ignite pull request #2340: IGNITE-5802: Fix all wrong TODO comments in ML co...

[ybabak]

GitHub user ybabak opened a pull request:

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

IGNITE-5802: Fix all wrong TODO comments in ML component

- Added related tickets to all TODOs.
- Fixed some inspection problems.

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

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

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

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


commit 7924881e14f62f1f0e49e8018338c4cedac17433
Author: Yury Babak 
Date:   2017-07-25T11:13:39Z

IGNITE-5802: Fix all wrong TODO comments in ML component
- Added related tickets to all TODOs.
- Fixed some inspection problems.




---
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.
---

[jira] [Created] (IGNITE-5828) Decompositions refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5828:
--

 Summary: Decompositions refactoring
 Key: IGNITE-5828
 URL: https://issues.apache.org/jira/browse/IGNITE-5828
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


(?) Externalization for decompositions.
(?) QRDecomposition performance.
(?) EigenDecompositionTest - corner case failure.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5827) Benchmarks refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5827:
--

 Summary: Benchmarks refactoring
 Key: IGNITE-5827
 URL: https://issues.apache.org/jira/browse/IGNITE-5827
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


See MathBenchmark.java and VectorBenchmarkTest.java



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5826) OLS refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5826:
--

 Summary: OLS refactoring
 Key: IGNITE-5826
 URL: https://issues.apache.org/jira/browse/IGNITE-5826
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


(?) Copying.
(?) Incremental formula.
(?) Tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5825) K-Means refactoring

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5825:
--

 Summary: K-Means refactoring
 Key: IGNITE-5825
 URL: https://issues.apache.org/jira/browse/IGNITE-5825
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


Improve performance of points copying.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (IGNITE-5824) Adjust precision in math unit tests.

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5824:
--

 Summary: Adjust precision in math unit tests.
 Key: IGNITE-5824
 URL: https://issues.apache.org/jira/browse/IGNITE-5824
 Project: Ignite
  Issue Type: Bug
  Components: ml
Reporter: Yury Babak


Find which precision is sufficient for math related tests.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] ignite pull request #1867: incorrect construction of swap files directory pa...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: [VOTE] Apache Ignite 2.1.0 RC4

[Yakov Zhdanov]

+1 (binding)

--Yakov

2017-07-24 16:32 GMT+03:00 Anton Vinogradov :

> Igniters,
>
> This vote based on same files as RC3.
> Only one change is that I signed zips with my signature.
> KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS) was
> updated as well.
>
> We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
> This vote will go for 72 hours but may be closed earlier if Konstantin
> Boudnik confirmed security issue solved.
>
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
>
> Git tag name is
> 2.1.0-rc4
>
> This release includes the following changes:
>
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
>
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
>
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
>
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%
> 20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
>
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.1.0-rc4
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
>
> This vote will go for 72 hours.
>

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Alexey Kuznetsov]

+1 (binding)

On Mon, Jul 24, 2017 at 8:32 PM, Anton Vinogradov  wrote:

> Igniters,
>
> This vote based on same files as RC3.
> Only one change is that I signed zips with my signature.
> KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS) was
> updated as well.
>
> We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
> This vote will go for 72 hours but may be closed earlier if Konstantin
> Boudnik confirmed security issue solved.
>
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
>
> Git tag name is
> 2.1.0-rc4
>
> This release includes the following changes:
>
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
>
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
>
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
>
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%
> 20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
>
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.1.0-rc4
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
>
> This vote will go for 72 hours.
>



-- 
Alexey Kuznetsov

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Nikolai Tikhonov]

+1 (binding)

On Tue, Jul 25, 2017 at 10:56 AM, Kozlov Maxim  wrote:

> +1
> > 25 июля 2017 г., в 10:53, Николай Ижиков 
> написал(а):
> >
> > +1
> >
> > 2017-07-25 10:50 GMT+03:00 Vyacheslav Daradur :
> >
> >> +1
> >>
> >> 2017-07-25 2:02 GMT+03:00 Valentin Kulichenko <
> >> valentin.kuliche...@gmail.com
> >>> :
> >>
> >>> +1 (binding)
> >>>
> >>> On Mon, Jul 24, 2017 at 6:39 AM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org>
> >>> wrote:
> >>>
>  Anton,
> 
>  You should treat this vote as a brand new vote. According to Apache
> >>> rules,
>  you need 3 +1 votes and it has to go for 72 hours.
> 
>  D.
> 
>  On Mon, Jul 24, 2017 at 8:32 AM, Anton Vinogradov 
> >> wrote:
> 
> > Igniters,
> >
> > This vote based on same files as RC3.
> > Only one change is that I signed zips with my signature.
> > KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS)
> >>> was
> > updated as well.
> >
> > We already got 5 "+1" at RC3, so, is there any reason to wait 72
> >> hours?
> > This vote will go for 72 hours but may be closed earlier if
> >> Konstantin
> > Boudnik confirmed security issue solved.
> >
> > We have uploaded a 2.1.0 release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
> >
> > Git tag name is
> > 2.1.0-rc4
> >
> > This release includes the following changes:
> >
> > Ignite:
> > * Persistent cache store
> > * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> >>> mehtods
> > * Deprecated IgniteConfiguration.marshaller
> > * Updated Lucene dependency to version 5.5.2
> > * Machine learning: implemented K-means clusterization algorithm
>  optimized
> > for distributed storages
> > * SQL: CREATE TABLE and DROP TABLE commands support
> > * SQL: New thin JDBC driver
> > * SQL: Improved performance of certain queries, when affinity node
> >> can
> >>> be
> > calculated in advance
> > * SQL: Fixed return type of AVG() function
> > * SQL: BLOB type support added to thick JDBC driver
> > * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
> >>> Java 8
> > * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > SqlFieldsQuery
> > * ODBC: Implemented DML statement batching
> > * Massive performance and stability improvements
> >
> > Ignite.NET:
> > * Automatic remote assembly loading
> > * NuGet-based standalone node deployment
> > * Added conditional data removeal via LINQ DeleteAll
> > * Added TimestampAttribute to control DateTime serialization mode
> > * Added local collections joins support to LINQ.
> >
> > Ignite CPP:
> > * Added Compute::Call and Compute::Broadcast methods
> >
> > Web Console:
> > * Implemented support for UNIQUE indexes for key fields on import
> >> model
> > from RDBMS
> > * Added option to show full stack trace on Queries screen
> > * Added PK alias generation on Models screen.
> >
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=project%20%
> >>> 3D%20IGNITE%20AND%
> > 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > 20closed%20or%20status%20%3D%
> > 20resolved)
> >
> > DEVNOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
> >
> > RELEASE NOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
> >
> > Please start voting.
> >
> > +1 - to accept Apache Ignite 2.1.0-rc4
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
> >
> > This vote will go for 72 hours.
> >
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Best Regards, Vyacheslav D.
> >>
> >
> >
> >
> > --
> > Nikolay Izhikov
> > nizhikov@gmail.com
>
> --
> Best Regards,
> Max K.
>
>
>
>
>

Re: Changing public IgniteCompute API to improve changes in 5037 ticket

[Anton Vinogradov]

Val,

Sure, we can, but we'd like to use map/reduce without fearing that topology
can change.

On Mon, Jul 24, 2017 at 11:17 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Anton,
>
> You can call affinityCallAsync multiple times and then reduce locally.
>
> -Val
>
> On Mon, Jul 24, 2017 at 3:05 AM, Anton Vinogradov <
> avinogra...@gridgain.com>
> wrote:
>
> > Val,
> >
> > > What is the use case for which current affinityRun/Call API doesn't
> work?
> > It does not work for map/reduce.
> >
> > On Fri, Jul 21, 2017 at 11:42 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > Maxim,
> > >
> > > The issue is that it's currently assumed to support job mapping, but it
> > > actually doesn't. However, I agree that AffinityKeyMapped annotation
> > > doesn't fit the use case well. Let's fix documentation and JavaDoc
> then.
> > >
> > > As for the proposed API, it's overcomplicated, took me 15 minutes to
> > > understand what it does :)
> > >
> > > What is the use case for which current affinityRun/Call API doesn't
> work?
> > >
> > > -Val
> > >
> > > On Fri, Jul 21, 2017 at 5:57 AM, Kozlov Maxim 
> > > wrote:
> > >
> > > > Valentin,
> > > >
> > > > The author of tiket wants to see to provide some API allows to map
> > > > ComputeJobs to partitions or keys. If we use @AffinityKeyMapped then
> > you
> > > > need to enter the cache name parameter, I think this is not
> convenient
> > > for
> > > > the user. Therefore, I propose to extend the existing API.
> > > > Having consulted with Anton V. decided to make a separate interface
> > > > ReducibleTask, which will allow us to have different map logic at
> each
> > > > inheritor.
> > > >
> > > > Old method, allows to map to node
> > > > public interface ComputeTask extends ReducibleTask {
> > > > @Nullable public Map
> > > > map(List subgrid, @Nullable T arg) throws
> IgniteException;
> > > > }
> > > >
> > > > Brand new method with mapping to partitions, which solves topology
> > change
> > > > issues.
> > > > public interface AffinityComputeTask extends ReducibleTask {
> > > > @Nullable public Map
> > > map(@NotnullString
> > > > cacheName, List partIds, @Nullable T arg) throws
> > > IgniteException;
> > > > }
> > > >
> > > > public interface ReducibleTask extends Serializable {
> > > > public ComputeJobResultPolicy result(ComputeJobResult res,
> > > > List rcvd) throws IgniteException;
> > > >
> > > > @Nullable public R reduce(List results) throws
> > > > IgniteException;
> > > > }
> > > >
> > > > We also need to implement AffinityComputeTaskAdapter and
> > > > AffinityComputeTaskSplitAdapter, for implementation by default. It
> is
> > > > right?
> > > >
> > > > In the IgniteCompute add:
> > > >
> > > > @IgniteAsyncSupported
> > > > public  R affinityExecute(Class AffinityComputeTask > > R>>
> > > > taskCls, List partIds, @Nullable T arg) throws
> > IgniteException;
> > > > @IgniteAsyncSupported
> > > > public  R affinityExecute(AffinityComputeTask task,
> > > > List partIds, @Nullable T arg) throws IgniteException;
> > > >
> > > > public  ComputeTaskFuture affinityExecuteAsync(Class extends
> > > > AffinityComputeTask> taskCls, List partIds, @Nullable
> T
> > > arg)
> > > > throws IgniteException;
> > > > public  ComputeTaskFuture affinityExecuteAsync(
> > > AffinityComputeTask > > > R> task, List partIds, @Nullable T arg) throws
> > IgniteException;
> > > >
> > > >
> > > > How do you like this idea or do you insist that you need to use
> > > > @AffinityKeyMapped to solve the problem?
> > > >
> > > >
> > > > > 13 июля 2017 г., в 6:36, Valentin Kulichenko <
> > > > valentin.kuliche...@gmail.com> написал(а):
> > > > >
> > > > > Hi Max,
> > > > >
> > > > > This ticket doesn't assume any API changes, it's about broken
> > > > > functionality. I would start with checking what tests we have
> > > > > for @AffinityKeyMapped and creating missing one. From what I
> > understand
> > > > > functionality is broken completely or almost completely, so I guess
> > > > testing
> > > > > coverage is very weak there.
> > > > >
> > > > > -Val
> > > > >
> > > > > On Wed, Jul 12, 2017 at 4:27 PM, Kozlov Maxim <
> dreamx@gmail.com>
> > > > wrote:
> > > > >
> > > > >> Igniters,
> > > > >>
> > > > >> jira: https://issues.apache.org/jira/browse/IGNITE-5037 <
> > > > >> https://issues.apache.org/jira/browse/IGNITE-5037>
> > > > >> How do you look to solve this ticket by adding two methods to the
> > > public
> > > > >> IgniteCompute API?
> > > > >>
> > > > >> @IgniteAsyncSupported
> > > > >> public void affinityRun(@NotNull Collection cacheNames,
> > > > >> Collection keys, IgniteRunnable job)
> > > > >>throws IgniteException;
> > > > >>
> > > > >> @IgniteAsyncSupported
> > > > >> public  R affinityCall(@NotNull Collection cacheNames,
> > > > >> Collection keys, IgniteCallable job)
> > > > >>throws IgniteException;
> > > > >>
> > > > >> 

Re: Timeouts in atomic cache

[Yakov Zhdanov]

Guys, I have edited https://issues.apache.org/jira/browse/IGNITE-5811 and
extended it a bit. Comments are welcome!

--Yakov

Re: Timeouts in atomic cache

[Yakov Zhdanov]

Here is the newbie ticket for removing the exception -
https://issues.apache.org/jira/browse/IGNITE-5823.

--Yakov

[jira] [Created] (IGNITE-5823) Need to remove CacheAtomicUpdateTimeoutException

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5823:
-

 Summary: Need to remove CacheAtomicUpdateTimeoutException
 Key: IGNITE-5823
 URL: https://issues.apache.org/jira/browse/IGNITE-5823
 Project: Ignite
  Issue Type: Task
Reporter: Yakov Zhdanov
Priority: Minor


And releated - CacheAtomicUpdateTimeoutCheckedException

These exceptions are not used any more and can be removed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Timeouts in atomic cache

[Yakov Zhdanov]

Val, I think this should be something similar to deadlock detection, but
different condition.

--Yakov

[jira] [Created] (IGNITE-5822) Abstract away Java->.NET calls

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-5822:
--

 Summary: Abstract away Java->.NET calls
 Key: IGNITE-5822
 URL: https://issues.apache.org/jira/browse/IGNITE-5822
 Project: Ignite
  Issue Type: Sub-task
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.2


All calls from Java to platform go through static {{PlatformCallbackUtils}}. 
For thin client we are interested in {{inLongOutLong}} and 
{{inLongLongLongObjectOutLong}} only; these two should be abstracted in some 
way so we can replace JNI with RPC when needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Ignite internal events tracing

[Yakov Zhdanov]

Val, it is used by Ignite internals to report the hangs and output
diagnostic information.

--Yakov

Re: Resurrect FairAffinityFunction

[Semyon Boikov]

Valentin,

As far as I know in 2.0 some changes were made in rendezvous function so
now it can provide better result. Do you have some numbers for 2.0 so that
we can compare rendezvous and fair affinity functions?

Thanks

On Tue, Jul 25, 2017 at 5:13 AM,  wrote:

> Agree with Val, we should bring it back.
>
> ⁣D.​
>
> On Jul 24, 2017, 8:14 PM, at 8:14 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
> >Guys,
> >
> >Some time ago we removed FairAffinityFunction from the project.
> >However, my
> >communication with users clearly shows that is was a rush decision.
> >Distribution showed by Fair AF is much better than default and for some
> >users it's extremely important. Basically, there are cases when
> >rendezvous
> >function is no-go.
> >
> >The reason for removal was that it was possible to get inconsistent
> >results
> >in case multiple caches were created on different topologies. However,
> >I
> >think this is fixable. As far as I understand, the only thing we need
> >to do
> >is to maintain a single AffinityFunctionContext for all the caches with
> >same affinity function. Currently for each cache we have separate
> >context
> >which holds the state used by Fair AF. If the state is different, we
> >have
> >an issue.
> >
> >The only question is how to check whether two functions are the same or
> >not. In case both cache node filter and backup filter are not
> >configured,
> >this is easy - if number of partitions and excludeNeighbors flag are
> >equal
> >for two functions, these functions are also equal.
> >
> >With filters it's a bit more complicated as these are custom
> >implementations and in general case we don't know how to compare them.
> >Although, to solve this problem, we can enforce user to implement
> >equals()
> >method for these implementation if Fair AF is used.
> >
> >I propose to make changes described above and bring Fair AF back.
> >
> >Thoughts?
> >
> >-Val
>

[jira] [Created] (IGNITE-5821) Implement fuzzy checkpoints

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5821:


 Summary: Implement fuzzy checkpoints
 Key: IGNITE-5821
 URL: https://issues.apache.org/jira/browse/IGNITE-5821
 Project: Ignite
  Issue Type: New Feature
  Components: persistence
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.2


Currently, we are able to run only sharp checkpoints (all committed 
transactions are in the checkpoint, all non-committed are not included, all 
data structures are fully consistent).
This has the following disadvantages:

1) All transactions are blocked for the markCheckpointBegin call
2) We have an additional overhead for checkpoint COW buffer
3) If checkpoint buffer is exhausted, we block all transactions and 
synchronously wait for the checkpoint to be finished.

There is a technique called fuzzy checkpoints:
1) We keep a WAL LSN in every dirty page
2) When a page is being flushed to disk, we sync WAL up to the LSN
3) We maintain checkpoint low watermark so that WAL does not grow indefinitely
4) WAL logging is changed in a way that does not allow data structures updates 
to be mixed in WAL
5) The recovery procedure is changed to apply all physical deltas up to the end 
of WAL and have consistent memory state, then logical records revert all 
non-committed transactions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Kozlov Maxim]

+1
> 25 июля 2017 г., в 10:53, Николай Ижиков  написал(а):
> 
> +1
> 
> 2017-07-25 10:50 GMT+03:00 Vyacheslav Daradur :
> 
>> +1
>> 
>> 2017-07-25 2:02 GMT+03:00 Valentin Kulichenko <
>> valentin.kuliche...@gmail.com
>>> :
>> 
>>> +1 (binding)
>>> 
>>> On Mon, Jul 24, 2017 at 6:39 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>>> wrote:
>>> 
 Anton,
 
 You should treat this vote as a brand new vote. According to Apache
>>> rules,
 you need 3 +1 votes and it has to go for 72 hours.
 
 D.
 
 On Mon, Jul 24, 2017 at 8:32 AM, Anton Vinogradov 
>> wrote:
 
> Igniters,
> 
> This vote based on same files as RC3.
> Only one change is that I signed zips with my signature.
> KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS)
>>> was
> updated as well.
> 
> We already got 5 "+1" at RC3, so, is there any reason to wait 72
>> hours?
> This vote will go for 72 hours but may be closed earlier if
>> Konstantin
> Boudnik confirmed security issue solved.
> 
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
> 
> Git tag name is
> 2.1.0-rc4
> 
> This release includes the following changes:
> 
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
>>> mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm
 optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node
>> can
>>> be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
>>> Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
> 
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
> 
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
> 
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import
>> model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%
>>> 3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%
> 20resolved)
> 
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
> 
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
> 
> Please start voting.
> 
> +1 - to accept Apache Ignite 2.1.0-rc4
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
> 
> This vote will go for 72 hours.
> 
 
>>> 
>> 
>> 
>> 
>> --
>> Best Regards, Vyacheslav D.
>> 
> 
> 
> 
> -- 
> Nikolay Izhikov
> nizhikov@gmail.com

--
Best Regards,
Max K.

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Николай Ижиков]

+1

2017-07-25 10:50 GMT+03:00 Vyacheslav Daradur :

> +1
>
> 2017-07-25 2:02 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > +1 (binding)
> >
> > On Mon, Jul 24, 2017 at 6:39 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > Anton,
> > >
> > > You should treat this vote as a brand new vote. According to Apache
> > rules,
> > > you need 3 +1 votes and it has to go for 72 hours.
> > >
> > > D.
> > >
> > > On Mon, Jul 24, 2017 at 8:32 AM, Anton Vinogradov 
> wrote:
> > >
> > > > Igniters,
> > > >
> > > > This vote based on same files as RC3.
> > > > Only one change is that I signed zips with my signature.
> > > > KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS)
> > was
> > > > updated as well.
> > > >
> > > > We already got 5 "+1" at RC3, so, is there any reason to wait 72
> hours?
> > > > This vote will go for 72 hours but may be closed earlier if
> Konstantin
> > > > Boudnik confirmed security issue solved.
> > > >
> > > > We have uploaded a 2.1.0 release candidate to
> > > > https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
> > > >
> > > > Git tag name is
> > > > 2.1.0-rc4
> > > >
> > > > This release includes the following changes:
> > > >
> > > > Ignite:
> > > > * Persistent cache store
> > > > * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> > mehtods
> > > > * Deprecated IgniteConfiguration.marshaller
> > > > * Updated Lucene dependency to version 5.5.2
> > > > * Machine learning: implemented K-means clusterization algorithm
> > > optimized
> > > > for distributed storages
> > > > * SQL: CREATE TABLE and DROP TABLE commands support
> > > > * SQL: New thin JDBC driver
> > > > * SQL: Improved performance of certain queries, when affinity node
> can
> > be
> > > > calculated in advance
> > > > * SQL: Fixed return type of AVG() function
> > > > * SQL: BLOB type support added to thick JDBC driver
> > > > * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
> > Java 8
> > > > * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > > > SqlFieldsQuery
> > > > * ODBC: Implemented DML statement batching
> > > > * Massive performance and stability improvements
> > > >
> > > > Ignite.NET:
> > > > * Automatic remote assembly loading
> > > > * NuGet-based standalone node deployment
> > > > * Added conditional data removeal via LINQ DeleteAll
> > > > * Added TimestampAttribute to control DateTime serialization mode
> > > > * Added local collections joins support to LINQ.
> > > >
> > > > Ignite CPP:
> > > > * Added Compute::Call and Compute::Broadcast methods
> > > >
> > > > Web Console:
> > > > * Implemented support for UNIQUE indexes for key fields on import
> model
> > > > from RDBMS
> > > > * Added option to show full stack trace on Queries screen
> > > > * Added PK alias generation on Models screen.
> > > >
> > > > Complete list of closed issues:
> > > > https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20IGNITE%20AND%
> > > > 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > > > 20closed%20or%20status%20%3D%
> > > > 20resolved)
> > > >
> > > > DEVNOTES
> > > > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
> > > >
> > > > RELEASE NOTES
> > > > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
> > > >
> > > > Please start voting.
> > > >
> > > > +1 - to accept Apache Ignite 2.1.0-rc4
> > > > 0 - don't care either way
> > > > -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
> > > >
> > > > This vote will go for 72 hours.
> > > >
> > >
> >
>
>
>
> --
> Best Regards, Vyacheslav D.
>



-- 
Nikolay Izhikov
nizhikov@gmail.com

[jira] [Created] (IGNITE-5820) Implement ability to set auto adjust height of modal

[Dmitriy Shabalin (JIRA)]

Dmitriy Shabalin created IGNITE-5820:


 Summary: Implement ability to set auto adjust height of modal
 Key: IGNITE-5820
 URL: https://issues.apache.org/jira/browse/IGNITE-5820
 Project: Ignite
  Issue Type: Improvement
  Components: UI, wizards
Reporter: Dmitriy Shabalin
Assignee: Dmitriy Shabalin
 Fix For: 2.2






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [VOTE] Apache Ignite 2.1.0 RC4

[Vyacheslav Daradur]

+1

2017-07-25 2:02 GMT+03:00 Valentin Kulichenko :

> +1 (binding)
>
> On Mon, Jul 24, 2017 at 6:39 AM, Dmitriy Setrakyan 
> wrote:
>
> > Anton,
> >
> > You should treat this vote as a brand new vote. According to Apache
> rules,
> > you need 3 +1 votes and it has to go for 72 hours.
> >
> > D.
> >
> > On Mon, Jul 24, 2017 at 8:32 AM, Anton Vinogradov  wrote:
> >
> > > Igniters,
> > >
> > > This vote based on same files as RC3.
> > > Only one change is that I signed zips with my signature.
> > > KEYS files (https://dist.apache.org/repos/dist/release/ignite/KEYS)
> was
> > > updated as well.
> > >
> > > We already got 5 "+1" at RC3, so, is there any reason to wait 72 hours?
> > > This vote will go for 72 hours but may be closed earlier if Konstantin
> > > Boudnik confirmed security issue solved.
> > >
> > > We have uploaded a 2.1.0 release candidate to
> > > https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc4/
> > >
> > > Git tag name is
> > > 2.1.0-rc4
> > >
> > > This release includes the following changes:
> > >
> > > Ignite:
> > > * Persistent cache store
> > > * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
> mehtods
> > > * Deprecated IgniteConfiguration.marshaller
> > > * Updated Lucene dependency to version 5.5.2
> > > * Machine learning: implemented K-means clusterization algorithm
> > optimized
> > > for distributed storages
> > > * SQL: CREATE TABLE and DROP TABLE commands support
> > > * SQL: New thin JDBC driver
> > > * SQL: Improved performance of certain queries, when affinity node can
> be
> > > calculated in advance
> > > * SQL: Fixed return type of AVG() function
> > > * SQL: BLOB type support added to thick JDBC driver
> > > * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
> Java 8
> > > * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > > SqlFieldsQuery
> > > * ODBC: Implemented DML statement batching
> > > * Massive performance and stability improvements
> > >
> > > Ignite.NET:
> > > * Automatic remote assembly loading
> > > * NuGet-based standalone node deployment
> > > * Added conditional data removeal via LINQ DeleteAll
> > > * Added TimestampAttribute to control DateTime serialization mode
> > > * Added local collections joins support to LINQ.
> > >
> > > Ignite CPP:
> > > * Added Compute::Call and Compute::Broadcast methods
> > >
> > > Web Console:
> > > * Implemented support for UNIQUE indexes for key fields on import model
> > > from RDBMS
> > > * Added option to show full stack trace on Queries screen
> > > * Added PK alias generation on Models screen.
> > >
> > > Complete list of closed issues:
> > > https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20IGNITE%20AND%
> > > 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> > > 20closed%20or%20status%20%3D%
> > > 20resolved)
> > >
> > > DEVNOTES
> > > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc4
> > >
> > > RELEASE NOTES
> > > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc4
> > >
> > > Please start voting.
> > >
> > > +1 - to accept Apache Ignite 2.1.0-rc4
> > > 0 - don't care either way
> > > -1 - DO NOT accept Apache Ignite 2.1.0-rc4 (explain why)
> > >
> > > This vote will go for 72 hours.
> > >
> >
>



-- 
Best Regards, Vyacheslav D.