Re: binary output from cache

thanks for explanation пт, 10 Фев 2017 г., 20:12 Alexey Goncharuk : > Aleksey, > > It can give a performance benefit for example if you access only a subset > of the fields of a large object. In this case, deserializing only required > fields is much faster than

Re: IGNITE-13

On Thu, Feb 9, 2017 at 11:26 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Hi Vadim, > > I don't think it makes much sense to invest into OptimizedMarshaller. > However, I would check if this optimization is applicable to > BinaryMarshaller, and if yes, implement it. > Val,

Re: Rethink native SQL API in Apache Ignite 2.0

I think the proper process here is to create a JIRA ticket and propose the design there. D. On Fri, Feb 10, 2017 at 1:37 AM, Sergi Vladykin wrote: > I agree with Vladimir that we have to improve our API with respect to the > latest changes in our SQL capabilities. > >

Re: jdbc vs jdbc2 packages

I generally like the idea of supporting thin JDBC clients. Often it is not feasible to start a client node on JDBC side. On Fri, Feb 10, 2017 at 1:04 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Yakov, > > There are two separate aspects that we can improve: > > 1. Message

Re: DML data streaming

On Fri, Feb 10, 2017 at 3:36 AM, Vladimir Ozerov wrote: > I propose to ship streaming with INSERT support only for now. This is > enough for multitude cases and will add value to Ignite 1.9 immediately. We > can think about correct streaming UPDATE/DELETE architecture

Re: DML data streaming

On Fri, Feb 10, 2017 at 12:55 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > And to avoid further confusion: UPDATE and DELETE are simply > impossible in streaming mode when the key is not completely defined as > long as data streamer operates with key-value pairs and not

Re: DML data streaming

On Fri, Feb 10, 2017 at 12:49 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > Dima, > > > > There are several ways to handle it. I would check how other databases > > handle it, maybe we can borrow something. To the least, we should log > such > > errors in the log for now. >

Re: IGNITE-817: [Test] Disabled tests of GridCacheOffHeapTest

Yakov, Sam? Please join and share your thoughts. — Denis > On Feb 10, 2017, at 7:08 AM, Александр Меньшиков wrote: > > Denis, thank you for information. I see JMH in pom file in benchmarks > module. So this must be removed or it's okay for micro-benchmarks? > >

Re: DML data streaming

In general, the data streamer approach should be mostly used for data loading scenarios. The data is usually loaded with INSERTS which means that the scenario is already supported and we’re free to merge the changes to 1.9. If you UPDATE or DELETE data in the streaming mode then you are

Re: DML & Transactions

Hello, Yes, MVCC has already been being designed and developed by multiple community members including Sergi. If you prefer to take a big feature for dev then I would suggest considering these tasks: https://ignite.apache.org/community/contribute.html#pick-ticket

[GitHub] ignite pull request #1519: Ignite 4633

GitHub user alexpaschenko opened a pull request: https://github.com/apache/ignite/pull/1519 Ignite 4633 DDL base stuff You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4633 Alternatively you can

Re: jdbc vs jdbc2 packages

Yakov, There are two separate aspects that we can improve: 1. Message routing as you described. I agree it can be useful in some scenarios and I definitely not against this feature, but honestly I haven't seen a lot of requests for this so far. 2. Server can initiate connection with client. This

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Oleg, Thanks a lot, we’re almost done. Please address the latest comments from my side. https://issues.apache.org/jira/browse/IGNITE-4212 Sergey K., please take over from this point trying to use the feature created by Oleg for Ignite 1.9

Re: binary output from cache

Aleksey, It can give a performance benefit for example if you access only a subset of the fields of a large object. In this case, deserializing only required fields is much faster than deserializing the whole object. --AG 2017-02-10 10:26 GMT+03:00 ALEKSEY KUZNETSOV :

general question

Guys, i have a question.Why do we store fields position information in FieldAccessor before hashcode evaluation? Test example is in : org.apache.ignite.internal.binary.BinaryFieldIdentityResolverSelfTest#testHashCode -- *Best Regards,* *Kuznetsov Aleksey*

[GitHub] ignite pull request #1473: IGNITE-3196

Github user daradurvs closed the pull request at: https://github.com/apache/ignite/pull/1473 --- 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

[jira] [Created] (IGNITE-4685) Propagate platform plugin configuration to Java

Pavel Tupitsyn created IGNITE-4685: -- Summary: Propagate platform plugin configuration to Java Key: IGNITE-4685 URL: https://issues.apache.org/jira/browse/IGNITE-4685 Project: Ignite Issue

Re: IGNITE-3196 - ready for review

Thanks for your explanation. 2017-02-10 18:18 GMT+03:00 Pavel Tupitsyn : > You can close it. > > On Fri, Feb 10, 2017 at 6:16 PM, Vyacheslav Daradur > wrote: > > > I meant what I need to do with opened PR? > > I need to close it or to leave it open for

Re: IGNITE-3196 - ready for review

You can close it. On Fri, Feb 10, 2017 at 6:16 PM, Vyacheslav Daradur wrote: > I meant what I need to do with opened PR? > I need to close it or to leave it open for future merge? > > 2017-02-10 17:42 GMT+03:00 Pavel Tupitsyn : > > > The ticket is

Re: IGNITE-3196 - ready for review

I meant what I need to do with opened PR? I need to close it or to leave it open for future merge? 2017-02-10 17:42 GMT+03:00 Pavel Tupitsyn : > The ticket is targeted for 2.0 because this change may affect existing > code. > 1.9 is planned in the near future, and minor

Re: IGNITE-817: [Test] Disabled tests of GridCacheOffHeapTest

Denis, thank you for information. I see JMH in pom file in benchmarks module. So this must be removed or it's okay for micro-benchmarks? 2017-02-10 0:04 GMT+03:00 Denis Magda : > Alexander, > > We use Yardstick benchmarks for performance measurements of Ignite: >

Re: IGNITE-3196 - ready for review

The ticket is targeted for 2.0 because this change may affect existing code. 1.9 is planned in the near future, and minor versions should not break existing code. Pavel On Fri, Feb 10, 2017 at 5:24 PM, Vyacheslav Daradur wrote: > Pavel, thanks. > > What about PR to

[jira] [Created] (IGNITE-4684) Local cache.get(K) should not block

Yakov Zhdanov created IGNITE-4684: - Summary: Local cache.get(K) should not block Key: IGNITE-4684 URL: https://issues.apache.org/jira/browse/IGNITE-4684 Project: Ignite Issue Type:

Re: IGNITE-3196 - ready for review

Pavel, thanks. What about PR to master-branch? 2017-02-10 16:55 GMT+03:00 Pavel Tupitsyn : > Merged to ignite-2.0. > > Thank you for the contribution, Vyacheslav! > > On Tue, Feb 7, 2017 at 10:15 PM, Denis Magda wrote: > > > + Vladimir Ozerov > > > > It

[jira] [Created] (IGNITE-4683) Need to avoid extra-copy to byte array when marhsalling to cache object

Yakov Zhdanov created IGNITE-4683: - Summary: Need to avoid extra-copy to byte array when marhsalling to cache object Key: IGNITE-4683 URL: https://issues.apache.org/jira/browse/IGNITE-4683 Project:

[jira] [Created] (IGNITE-4682) Need to finish transition to thread-per-partition model

Yakov Zhdanov created IGNITE-4682: - Summary: Need to finish transition to thread-per-partition model Key: IGNITE-4682 URL: https://issues.apache.org/jira/browse/IGNITE-4682 Project: Ignite

[jira] [Created] (IGNITE-4681) Apply new future adapter

Yakov Zhdanov created IGNITE-4681: - Summary: Apply new future adapter Key: IGNITE-4681 URL: https://issues.apache.org/jira/browse/IGNITE-4681 Project: Ignite Issue Type: Improvement

Re: IGNITE-3196 - ready for review

Merged to ignite-2.0. Thank you for the contribution, Vyacheslav! On Tue, Feb 7, 2017 at 10:15 PM, Denis Magda wrote: > + Vladimir Ozerov > > It would be better if Vladimir Ozerov does the final review considering > all the changes in .NET, C++ and Java. > > Vladimir, could

Re: Apache Ignite 1.9

Anton, Here is the status for IGNITE-4523. The work is completed, tests are OK. Most of the changes were made by Alexey and were reviewed. I only authored few last commits for which I would appreciate a review. The PR is https://github.com/apache/ignite/pull/1508 Thank you -- Sergey

[jira] [Created] (IGNITE-4680) Properly split batch atomic cache operations between stripes (putAll, removeAll, etc)

Yakov Zhdanov created IGNITE-4680: - Summary: Properly split batch atomic cache operations between stripes (putAll, removeAll, etc) Key: IGNITE-4680 URL: https://issues.apache.org/jira/browse/IGNITE-4680

Re: Contributing to Ignite.NET

Hi, Pavel Great, thank you. Was thinking about taking IGNITE-4636 too) On 10 February 2017 at 15:44, Pavel Tupitsyn wrote: > Sergey, looks good! Merged to master branch. > > Thank you for the contribution. > > Would be

Re: Contributing to Ignite.NET

Sergey, looks good! Merged to master branch. Thank you for the contribution. Would be great if you pick up https://issues.apache.org/jira/browse/IGNITE-4636 so that we'll have comprehensive collection support. Pavel On Fri, Feb 10, 2017 at 2:41 PM, Guru Stron wrote:

[GitHub] ignite pull request #1502: IGNITE-4425 .NET: Support "ICollection.Contains" ...

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1502 --- 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

[GitHub] ignite pull request #1496: IGNITE-3994

Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/1496 --- 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

[GitHub] ignite pull request #1518: IGNITE-2703 .NET: Dynamic type registration

GitHub user ptupitsyn opened a pull request: https://github.com/apache/ignite/pull/1518 IGNITE-2703 .NET: Dynamic type registration You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-2703

IGNITE-4158 - ready for review

Hello. I did it. Please, review. https://issues.apache.org/jira/browse/IGNITE-4158 - Implement Time type for binary protocol. latest ci.tests

Re: Contributing to Ignite.NET

Hi Pavel, I've fixed the issues you've pointed out and committed changes. The inspections build is passing, also I've queued the platform build

Re: DML data streaming

I propose to ship streaming with INSERT support only for now. This is enough for multitude cases and will add value to Ignite 1.9 immediately. We can think about correct streaming UPDATE/DELETE architecture separately .It is much more difficult thing, we cannot support it in a clean way right now

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

I'm sorry, there wasn't any problem with the build, it was local problem on my machine. On Fri, Feb 10, 2017 at 11:54 AM, Oleg Ostanin wrote: > Hi. > > I just discovered that some functionality does not work correctly. I will > present fixed version later. > > On Fri, Feb

[jira] [Created] (IGNITE-4679) Consistency checks and error tracking during node joining process

Sergey Chugunov created IGNITE-4679: --- Summary: Consistency checks and error tracking during node joining process Key: IGNITE-4679 URL: https://issues.apache.org/jira/browse/IGNITE-4679 Project:

[GitHub] ignite pull request #1516: IGNITE-3429: org.hibernate.cache.spi.CacheKey not...

GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1516 IGNITE-3429: org.hibernate.cache.spi.CacheKey not properly serialized by binary marshaller Sample comfigurations for CacheKey added. You can merge this pull request into a Git repository by

Re: jdbc vs jdbc2 packages

Val, can you please explain your statement. You suggest users have port forwarding for dozens of nodes in their topologies so client can initiate connect to any of them? I don't think this is possible and routing seems to be the only possible option. --Yakov 2017-02-10 0:04 GMT+03:00 Valentin

Re: Rethink native SQL API in Apache Ignite 2.0

I agree with Vladimir that we have to improve our API with respect to the latest changes in our SQL capabilities. As for the given API proposal, it is a bit harsh right now, but it is ok for the first draft, overall direction looks good. Also IMO we should not drop the existing API, thus adding

Re: DML data streaming

And to avoid further confusion: UPDATE and DELETE are simply impossible in streaming mode when the key is not completely defined as long as data streamer operates with key-value pairs and not just tuples of named values. That's why we can't do DELETE from Person WHERE id1 = 5 from prev example

Re: IGNITE-4212 (Ignite Benchmarking Simplification and Automation)

Hi. I just discovered that some functionality does not work correctly. I will present fixed version later. On Fri, Feb 10, 2017 at 12:43 AM, Oleg Ostanin wrote: > https://drive.google.com/open?id=0B9teTzJ9iIvHckl6eVQ3N0R4a3c > > On Fri, Feb 10, 2017 at 12:43 AM, Oleg

[jira] [Created] (IGNITE-4678) Web Console: Implement demo load as service

Andrey Novikov created IGNITE-4678: -- Summary: Web Console: Implement demo load as service Key: IGNITE-4678 URL: https://issues.apache.org/jira/browse/IGNITE-4678 Project: Ignite Issue Type:

Re: DML data streaming

Dima, > > There are several ways to handle it. I would check how other databases > handle it, maybe we can borrow something. To the least, we should log such > errors in the log for now. > Logging errors would mean introducing some kind of stream receiver to do that and thus that would be really

Re: IGNITE-1948 ClusterTopologyCheckedException can return null for retryReadyFuture()

Alexander, I do not see why you would need to overwrite the cause field. What I meant in the previous email is that instead of setting a retry ready future in the checked exception, you would set a correct affinity topology version here. Then, during a construction of CacheException (unchecked,