Re: Converting TreeMap to BinaryObject causes ClassCastException (IGNITE-2852)

Well, in my view we should have that discussion or close this ticket. What are the challenges there? Is there a dev thread I can review? On Thu, Jul 21, 2016 at 5:41 AM, Denis Magda wrote: > Dmitriy, > > Presently even the guys who spent bunch the time developing and

[GitHub] ignite pull request #881: IGNITE-3390: Added system DSN support for Windows.

GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/881 IGNITE-3390: Added system DSN support for Windows. You can merge this pull request into a Git repository by running: $ git pull https://github.com/isapego/ignite ignite-3390 Alternatively

[GitHub] ignite pull request #880: Ignite 3513

GitHub user agura opened a pull request: https://github.com/apache/ignite/pull/880 Ignite 3513 You can merge this pull request into a Git repository by running: $ git pull https://github.com/agura/incubator-ignite ignite-3513 Alternatively you can review and apply these

Re: Ignite message ping metric

To my knowledge, the GridGain Web Console [1] already does have the PING button, which does exactly what you are asking. It’s not part of Ignite per se, but it is still free for everyone to use. [1] - https://console.gridgain.com/ On Thu, Jul 21, 2016 at 11:11 AM, AndreyVel

Re: IGNITE-2294 implementation details

OK, then using your analogy, the current behavior in Ignite is MERGE for the most part. My preference is that Ignite SQL should work no different from traditional databases, which means: - INSERT is translated into *putIfAbsent()* call in Ignite - UPDATE is translated into *replace()* call in

Ignite message ping metric

Hi everyone, What do you think if to add ignite message ping metric between nodes and display it in monitoring tools? This metric can be displayed as matrix [All nodes] * [All nodes] Sometime to hard find, why cluster has bad performance, one of reason can be bad network performance between

Re: IGNITE-2294 implementation details

I agree. It looks like we first of all need some algorithm of key generation for new objects, and it does not necessarily have to be involved with DDL. The first suggestion that comes to my mind on that matter is, obviously, marking some method of the class persisted with magical annotation - so

Re: Apache Ignite - New Release

Sorry, I missed the typo: To support the point, I would add that PosgreSQL has demonstrated the similar behavior (inspired by unix .dot files and ls): - they have "hidden" column: xmin and xmax in any table - they do not appear in select * list unless they are specified explicitly Take care,

Re: Apache Ignite - New Release

To support the point, I would add that PosgreSQL has demonstrated the similar behavior (inspired by unix .dot files and ls): - they have "hidden" column: xmin and xmax in any table - they appear in select * list unless they are specified explicitly I'll add some notices to the ticket Take care,

[GitHub] ignite pull request #879: IGNITE-3512 .NET: IBinaryObject.ToBuilder loses ty...

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/879 IGNITE-3512 .NET: IBinaryObject.ToBuilder loses type name You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptupitsyn/ignite ignite-3512

IGNITE-3399 ready for review

Thanks Jens

Re: IGNITE-2294 implementation details

Suppose I have a PersonKey {int id;} class and Person {@SqlQueryField int id; @SqlQueryField String name; @SqlQueryField int age;} class. How would an insert statement look like? INSERT INTO Person (_key, _val) values (...) INSERT INTO Person (_key, _val, id, name, age) values (...) -> Obviously

[jira] [Created] (IGNITE-3535) Hadoop: make IgniteHadoopWeightedMapReducePlanner default one.

Vladimir Ozerov created IGNITE-3535: --- Summary: Hadoop: make IgniteHadoopWeightedMapReducePlanner default one. Key: IGNITE-3535 URL: https://issues.apache.org/jira/browse/IGNITE-3535 Project: Ignite

[jira] [Created] (IGNITE-3534) Hadoop: create factory for UserNameMapper.

Vladimir Ozerov created IGNITE-3534: --- Summary: Hadoop: create factory for UserNameMapper. Key: IGNITE-3534 URL: https://issues.apache.org/jira/browse/IGNITE-3534 Project: Ignite Issue

[jira] [Created] (IGNITE-3533) Hadoop: create factory for map-reduce planner.

Vladimir Ozerov created IGNITE-3533: --- Summary: Hadoop: create factory for map-reduce planner. Key: IGNITE-3533 URL: https://issues.apache.org/jira/browse/IGNITE-3533 Project: Ignite Issue

[jira] [Created] (IGNITE-3532) Hadoop: Move HadoopMapReducePlanner interface to public space.

Vladimir Ozerov created IGNITE-3532: --- Summary: Hadoop: Move HadoopMapReducePlanner interface to public space. Key: IGNITE-3532 URL: https://issues.apache.org/jira/browse/IGNITE-3532 Project: Ignite

Re: IGNITE-2294 implementation details

I don't see why we need to start with DDL. We have table definitions with key and value definitions in them, so what is the problem? Sergi On Thu, Jul 21, 2016 at 2:14 PM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > For me the main question here is how we define Key and Value for a

[jira] [Created] (IGNITE-3531) IGFS: Rename format() to clear().

Vladimir Ozerov created IGNITE-3531: --- Summary: IGFS: Rename format() to clear(). Key: IGNITE-3531 URL: https://issues.apache.org/jira/browse/IGNITE-3531 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-3530) IGFS: "setTimes" method is missing from IgfsSecondaryFileSystem interface.

Vladimir Ozerov created IGNITE-3530: --- Summary: IGFS: "setTimes" method is missing from IgfsSecondaryFileSystem interface. Key: IGNITE-3530 URL: https://issues.apache.org/jira/browse/IGNITE-3530

[jira] [Created] (IGNITE-3529) IGFS: Simplify meta and data cache configuration.

Vladimir Ozerov created IGNITE-3529: --- Summary: IGFS: Simplify meta and data cache configuration. Key: IGNITE-3529 URL: https://issues.apache.org/jira/browse/IGNITE-3529 Project: Ignite

[jira] [Created] (IGNITE-3528) IGFS: Review IgfsSecondaryFileSystem.open() method return type.

Vladimir Ozerov created IGNITE-3528: --- Summary: IGFS: Review IgfsSecondaryFileSystem.open() method return type. Key: IGNITE-3528 URL: https://issues.apache.org/jira/browse/IGNITE-3528 Project:

[jira] [Created] (IGNITE-3527) IGFS: Review "rename", "delete" and "mkdirs" return types in IgniteFileSystem and IgfsSecondaryFileSystem:

Vladimir Ozerov created IGNITE-3527: --- Summary: IGFS: Review "rename", "delete" and "mkdirs" return types in IgniteFileSystem and IgfsSecondaryFileSystem: Key: IGNITE-3527 URL:

[jira] [Created] (IGNITE-3526) IGFS: Review "perNodeBatchSize" and "perNodeParallelBatchCount" properties.

Vladimir Ozerov created IGNITE-3526: --- Summary: IGFS: Review "perNodeBatchSize" and "perNodeParallelBatchCount" properties. Key: IGNITE-3526 URL: https://issues.apache.org/jira/browse/IGNITE-3526

[jira] [Created] (IGNITE-3525) IGFS: Move fragmentizer-related properties into a separate class.

Vladimir Ozerov created IGNITE-3525: --- Summary: IGFS: Move fragmentizer-related properties into a separate class. Key: IGNITE-3525 URL: https://issues.apache.org/jira/browse/IGNITE-3525 Project:

[jira] [Created] (IGNITE-3524) IGFS: Do not allow nulls for FileSystemConfiguration.name.

Vladimir Ozerov created IGNITE-3524: --- Summary: IGFS: Do not allow nulls for FileSystemConfiguration.name. Key: IGNITE-3524 URL: https://issues.apache.org/jira/browse/IGNITE-3524 Project: Ignite

[jira] [Created] (IGNITE-3523) Remove "initialize default path modes" feature.

Vladimir Ozerov created IGNITE-3523: --- Summary: Remove "initialize default path modes" feature. Key: IGNITE-3523 URL: https://issues.apache.org/jira/browse/IGNITE-3523 Project: Ignite Issue

[jira] [Created] (IGNITE-3522) IGFS: Rename "streamBufferSize" to "bufferSize" in FileSystemConfiguration.

Vladimir Ozerov created IGNITE-3522: --- Summary: IGFS: Rename "streamBufferSize" to "bufferSize" in FileSystemConfiguration. Key: IGNITE-3522 URL: https://issues.apache.org/jira/browse/IGNITE-3522

[jira] [Created] (IGNITE-3521) IGFS: Remove "max space" notion.

Vladimir Ozerov created IGNITE-3521: --- Summary: IGFS: Remove "max space" notion. Key: IGNITE-3521 URL: https://issues.apache.org/jira/browse/IGNITE-3521 Project: Ignite Issue Type: Task

[jira] [Created] (IGNITE-3520) IGFS: Remove task execution methods.

Vladimir Ozerov created IGNITE-3520: --- Summary: IGFS: Remove task execution methods. Key: IGNITE-3520 URL: https://issues.apache.org/jira/browse/IGNITE-3520 Project: Ignite Issue Type: Task

Re: Converting TreeMap to BinaryObject causes ClassCastException (IGNITE-2852)

Dmitriy, Presently even the guys who spent bunch the time developing and improving binary marshaller don’t have a view on how to implement this feature. So initially we should discuss how to implement it in general and after that decide if the ticket can be taken over by new contributors. —

Re: New contributor: Support primitive type names in QueryEntity (IGNITE-3399)

Thanks Semyon. I created a pull request a short while ago, however I am not quite sure what I need to do in TeamCity. Do I need to register and run the test suite that I changed, or can I move the ticket to ready for review? Thanks Jens On Thu, Jul 21, 2016 at 1:07 PM, Semyon Boikov

[GitHub] ignite pull request #878: IGNITE-3399 Add support for primitive type names i...

GitHub user jayho opened a pull request: https://github.com/apache/ignite/pull/878 IGNITE-3399 Add support for primitive type names in QueryEntity - add optional primitive type mapping to class resolution - add test to IgniteCacheQuerySelfTestSuite You can merge this pull

Re: NullPointerException when stopping IgniteSemaphore

Sure, I'll do the review. It is lazy initialized, same as latch and other datastructures. Regards, Vladisav On Thu, Jul 21, 2016 at 10:24 AM, Yakov Zhdanov wrote: > Vladislav, can you please review and merge to master the fix and test case > suggested by Krome? > > Vlad,

Re: IGNITE-2294 implementation details

For me the main question here is how we define Key and Value for a cache when using SQL interface. Unless we are going to re-architect the whole Ignite, it will still be a key-value storage in the first place, so whenever we do an INSERT, we must generate Key and Value. Given that values in INSERT

Re: New contributor: Support primitive type names in QueryEntity (IGNITE-3399)

Hi, I added you in the contributors list. On Thu, Jul 21, 2016 at 1:54 PM, NoTrueScotsman wrote: > Hi all, > > I'd like to attempt a fix for IGNITE-3399 (currently unclaimed in > Jira) as my newbie contribution. > > Could you add me to the list of Ignite

Re: IGNITE-2294 implementation details

No, this does not make sense. There is no upsert mode in databases. There are operations: INSERT, UPDATE, DELETE, MERGE. I want to have clear understanding of how they have to behave in SQL databases and how they will actually behave in Ignite in different scenarios. Also I want to have clear

New contributor: Support primitive type names in QueryEntity (IGNITE-3399)

Hi all, I'd like to attempt a fix for IGNITE-3399 (currently unclaimed in Jira) as my newbie contribution. Could you add me to the list of Ignite contributors? Jira username: thehoff Cheers Jens

Re: Converting TreeMap to BinaryObject causes ClassCastException (IGNITE-2852)

On Wed, Jul 20, 2016 at 2:45 PM, Denis Magda wrote: > Hi Jens, > > This is not the best candidate for the first contribution and presently I > don’t think that this feature should be supported at all. > Denis, why not? > > I would recommend you picking up one of the

Re: Rework "withAsync" in Apache 2.0

+1 "Async" suffix. From: Vladimir Ozerov Sent: Thursday, July 21, 2016 2:41 AM To: dev@ignite.apache.org Subject: Re: Rework "withAsync" in Apache 2.0 Moreover, have a look at *CompletableFuture *interface: handle handle*Async* thenApply

Re: Rework "withAsync" in Apache 2.0

My opinion is that if we do away with current “withAsync()” paradigm, then we should simply add the *async* methods directly to the original interface. At least this way it will be easier to tell which methods support async execution, and which don’t. I don’t think it makes sense to have 2

Re: Rework "withAsync" in Apache 2.0

Totally agree with this particular suggestion. On more than just a few occasions I've been greatly confused by Ignite's "asynchronous" operations that in reality are blocking under some circumstances and non-blocking under others... Go figure! The reason I was given for such design was

Re: ReadWriteUpdateLock

I hardly can image where we can get concrete numbers of method usages. RWU lock is just a base .NET primitive. There are no plain RW lock there, only RWU. Users are just used to it. But again, my point is - let's implement standard RW lock first and then think about such extensions. On Wed, Jul

Re: Rework "withAsync" in Apache 2.0

Moreover, have a look at *CompletableFuture *interface: handle handle*Async* thenApply thenApply*Async* And so on. One more argument to return methods with "Async" suffix from good old GridGain days. On Thu, Jul 21, 2016 at 12:38 PM, Vladimir Ozerov wrote: > It is a

Re: Rework "withAsync" in Apache 2.0

It is a matter of taste. In .NET we have "Async" methods near synchronous methods because it is common practice in .NET world: V Get(K key); Task GetAsync(K key); For Java we can go the same way, or introduce separate interface. It will not be identical to synchronous, because it will have

Re: Rework "withAsync" in Apache 2.0

Do I understand correctly that the community is proposing to have 2 identical interfaces, one for sync operations and another for async operations? On Thu, Jul 21, 2016 at 12:15 PM, Sergi Vladykin wrote: > +1 > > Finally it is time to drop this "cool feature" from

Re: Ignite monitoring

On Wed, Jul 20, 2016 at 7:35 PM, Igor Rudyak wrote: > Andrey, > > Is Web Console you are talking about the same thing as GridGain Web Console > (http://ignite.apache.org/addons.html#web-console)? If yes it has > monitoring tab which allows to monitor some JVM and cache metrics

Re: Rework "withAsync" in Apache 2.0

+1 Finally it is time to drop this "cool feature" from Ignite! Sergi On Thu, Jul 21, 2016 at 11:13 AM, Vladimir Ozerov wrote: > Alex. > > Of course, some distributed operations will involve some kind of asynchrony > even in synchronous mode. My point is that we should

NullPointerException when stopping IgniteSemaphore

Vladislav, can you please review and merge to master the fix and test case suggested by Krome? Vlad, btw, why don't we init semaphore during construction time? https://issues.apache.org/jira/browse/IGNITE-3515 Thanks! --Yakov

[GitHub] ignite pull request #877: Ignite 1525

GitHub user avinogradovgg opened a pull request: https://github.com/apache/ignite/pull/877 Ignite 1525 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-1525 Alternatively you can review and apply

Re: Rework "withAsync" in Apache 2.0

Alex. Of course, some distributed operations will involve some kind of asynchrony even in synchronous mode. My point is that we should not blindly do things like that: V get(K key) { return getAsync(key),get(); } Instead, get() has it's own path, getAsync() another path. But of course they

Re: Rework "withAsync" in Apache 2.0

Another issue which usually confuses users is Ignite 'implementation details' of asynchronous execution: it operation is local it can be executed from calling thread (for example, if 'async put' is executed in atomic cache from primary node then cache store will be updated from calling thread).

Re: Rework "withAsync" in Apache 2.0

Agree with Alex. Vova, please go on with issues taking Alex's comments into consideration. Thanks! --Yakov 2016-07-21 10:43 GMT+03:00 Alexey Goncharuk : > Big +1 on this in general. > > I would also relax our guarantees on operations submitted from the same >

Re: Rework "withAsync" in Apache 2.0

Big +1 on this in general. I would also relax our guarantees on operations submitted from the same thread. Currently we guarantee that sequential invocations of async operations happen in the same order. I think that if a user wants such guarantees, he must define these dependencies explicitly by

[jira] [Created] (IGNITE-3519) Web console: add ability to specify a node filter in start caches configuration

Pavel Konstantinov created IGNITE-3519: -- Summary: Web console: add ability to specify a node filter in start caches configuration Key: IGNITE-3519 URL: https://issues.apache.org/jira/browse/IGNITE-3519

Rework "withAsync" in Apache 2.0

Hi folks, There was a discussion about not very good "withAsync()" API design [1]. As we are approaching Ignite 2.0 it is a good time to rework it. My considerations on how good API should look like and how should it be implemented: 1) Sync and async must be *different interfaces*. 2) All async