[GitHub] ignite pull request #1499: ignite-4646

2017-02-06 Thread gvvinblade
GitHub user gvvinblade opened a pull request: https://github.com/apache/ignite/pull/1499 ignite-4646 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-4646 Alternatively you can review and apply these

Re: IGNITE-3244

2017-02-06 Thread Vladimir Ozerov
Denis, We need to ensure that type IDs are attached for both arrays and collections/maps. May be we have it for arrays already, but I doubt it is so for generic containers. On Fri, Feb 3, 2017 at 8:59 PM, Denis Magda wrote: > If a value can be serialized to BinaryObject then it will be serializ

Re: Ignite-2.0 - Make near readers update async by default

2017-02-06 Thread Vladimir Ozerov
Yakov, I think forcing reads in TX or from primary is not what users expect by default. So i would have this mode disabled by default. On Mon, Feb 6, 2017 at 10:40 AM, Yakov Zhdanov wrote: > >It still seems that outdated reads will be *more* outdated with async > mode. > >Also, is there a guara

Re: Ensure that builder approach is used for all setters in public API

2017-02-06 Thread Vladimir Ozerov
Val, Good catch! Can we try leaving SPIs and base methods untouched? Will it API be consistent in this case? On Fri, Feb 3, 2017 at 10:22 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > I tend to think that the problem is that we try to apply 'builder approach' > to

Re: IGNITE-3196 - ready for review

2017-02-06 Thread Vyacheslav Daradur
Pavel, Igor Please, review it again. https://github.com/apache/ignite/pull/1473/files All tests .NET tests

Re: Do not use H2 parser for DDL

2017-02-06 Thread Vladimir Ozerov
Sergi, Cache creation function will be too complex without named parameters. As I understand we have two options at the moment: - Invest into H2 and add named parameters there, then use custom functions in Ignite; - Invest into Ignite and add custom "CREATE CACHE" parsing. CREATE CACHE doesn't ap

Re: Ignite-2.0 - Make near readers update async by default

2017-02-06 Thread Yakov Zhdanov
What users do not expect is that partitioned cache suddenly turns to replicated with replicas on client machines running in virtual environment on higher latency network. I am a bit surprised nobody sees it. I predict we will soon start getting questions from our largest deployments =) --Yakov 20

Re: Do not use H2 parser for DDL

2017-02-06 Thread Sergi Vladykin
IMO the right thing is not to divide between "us" and "them". We use H2 anyways and if we improve usability in H2, we automatically improve usability in Ignite. Sergi 2017-02-06 11:27 GMT+03:00 Vladimir Ozerov : > Sergi, > > Cache creation function will be too complex without named parameters. A

jdbc vs jdbc2 packages

2017-02-06 Thread Sergi Vladykin
Guys, We have 2 different packages: jdbc and jdbc2. Everything in jdbc is deprecated. Because of that new features like DML support were not added there. This seems to cause some problems to our users. Can someone clarify, did we deprecated these classes wrongly and we have to continue developing

Re: IGNITE-3196 - ready for review

2017-02-06 Thread Igor Sapego
Vyacheslav, I can see two ODBC tests fail in C++ test suits that should not: - TestEscConvertFunctionFloat - TestEscConvertFunctionDouble

Re: IGNITE-3196 - ready for review

2017-02-06 Thread Pavel Tupitsyn
.NET changes look good to me. Pavel On Mon, Feb 6, 2017 at 1:10 PM, Igor Sapego wrote: > Vyacheslav, I can see two ODBC tests fail in C++ test suits that should > not: > - TestEscConvertFunctionFloat >

[jira] [Created] (IGNITE-4656) Use dynamic caches for yardstick

2017-02-06 Thread Sergey Kozlov (JIRA)
Sergey Kozlov created IGNITE-4656: - Summary: Use dynamic caches for yardstick Key: IGNITE-4656 URL: https://issues.apache.org/jira/browse/IGNITE-4656 Project: Ignite Issue Type: Task

Please, review IGNITE-3994

2017-02-06 Thread Vladislav Pyatkov
Hi, IGNITE-3994 Client buffer CacheContinuousQueryEntry on pendingEvts after reconnect to alive cluster PR: http://195.239.208.174/project.html?projectId=IgniteTests&tab=projectOverview&branch_IgniteTests=pull/1496/head -- Vladislav Pyatkov

[GitHub] ignite pull request #1500: ignite-3477-idx2

2017-02-06 Thread kdudkov
GitHub user kdudkov opened a pull request: https://github.com/apache/ignite/pull/1500 ignite-3477-idx2 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3477-idx2 Alternatively you can review and appl

[GitHub] ignite pull request #1501: IGNITE-3579 Change lenght of the message type fro...

2017-02-06 Thread tledkov-gridgain
GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/1501 IGNITE-3579 Change lenght of the message type from byte to short type You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-

Re: IGNITE-3244

2017-02-06 Thread ALEKSEY KUZNETSOV
type IDs correctly attached to class descriptors. The issue comes from BinaryUtils#doReadObjectArray() . Presently, unmarshalled array's elements stored in Object[], one need to write the following : Object[] arr = (Object[])Array.newInstance(compType, len); instead of Object[] arr = deserialize ?

Re: IGNITE-3244

2017-02-06 Thread ALEKSEY KUZNETSOV
Moreover, in CacheObjectBinaryProcessorImpl#marshalToBinary() we explicitly marshal objects array into Object[] and then write it further. I wonder why we dont just marshal -> unmarshal it ? пн, 6 февр. 2017 г. в 15:58, ALEKSEY KUZNETSOV : > type IDs correctly attached to class descriptors. The i

Re: IGNITE-3196 - ready for review

2017-02-06 Thread Vyacheslav Daradur
Igor, I didn't change the CPP code before approval approach. I shall write directly, sorry. But I made CPP changes already. > TestEscConvertFunctionFloat > TestEscConvertFunctionDouble. These tests were passed 2017-02-06 13:20 GMT+03

[jira] [Created] (IGNITE-4657) Cache entry eviction can be broken if store throws exception

2017-02-06 Thread Semen Boikov (JIRA)
Semen Boikov created IGNITE-4657: Summary: Cache entry eviction can be broken if store throws exception Key: IGNITE-4657 URL: https://issues.apache.org/jira/browse/IGNITE-4657 Project: Ignite

Re: IGNITE-3196 - ready for review

2017-02-06 Thread Igor Sapego
Vyacheslav, Overall looks good. But why do you use -0x80 instead of 0x80? Best Regards, Igor On Mon, Feb 6, 2017 at 5:36 PM, Vyacheslav Daradur wrote: > Igor, > > I didn't change the CPP code before approval approach. > I shall write directly, sorry. > > But I made CPP changes already. > > > T

Re: Ignite-2.0 - Make near readers update async by default

2017-02-06 Thread Dmitriy Setrakyan
On Mon, Feb 6, 2017 at 12:29 AM, Yakov Zhdanov wrote: > What users do not expect is that partitioned cache suddenly turns to > replicated with replicas on client machines running in virtual environment > on higher latency network. I am a bit surprised nobody sees it. I predict > we will soon star

Re: IGNITE-3196 - ready for review

2017-02-06 Thread Vyacheslav Daradur
Byte.MIN_VALUE = -128 = -0x80 Byte.MAX_VALUE = 127 = 0x7F It is just more evident for me. Maybe, I just have the Java programming style. In Java: byte a = 100 | -0x80; // compiled byte b = 100 | 0x80; // doesn't compile, explicit type casting is neccessary (byte)(100 | 0x80) System.out.println

Re: Ensure that builder approach is used for all setters in public API

2017-02-06 Thread Andrey Mashenkov
Folks, Changing MBeans setters signature is bad idea. AOP tests failed on TC with this change. On Mon, Feb 6, 2017 at 11:21 AM, Vladimir Ozerov wrote: > Val, > > Good catch! Can we try leaving SPIs and base methods untouched? Will it API > be consistent in this case? > > On Fri, Feb 3, 2017 at

Re: Ensure that builder approach is used for all setters in public API

2017-02-06 Thread Valentin Kulichenko
Andrey, Can you list all setters that we have on MBeans? -Val On Mon, Feb 6, 2017 at 2:21 PM, Andrey Mashenkov wrote: > Folks, > > Changing MBeans setters signature is bad idea. AOP tests failed on TC with > this change. > > On Mon, Feb 6, 2017 at 11:21 AM, Vladimir Ozerov > wrote: > > > Val,

Re: jdbc vs jdbc2 packages

2017-02-06 Thread Valentin Kulichenko
There are two implementations of JDBC driver - based on legacy thin client (jdbc package) and on client node (jdbc2). The first one was deprecated when we introduced the latter, but now I tend to think that this was not a right decision. Thin client driver provides worse performance, but it's much

[jira] [Created] (IGNITE-4658) GridCacheProcessor.createMissingCaches() should be called in a separate thread

2017-02-06 Thread Valentin Kulichenko (JIRA)
Valentin Kulichenko created IGNITE-4658: --- Summary: GridCacheProcessor.createMissingCaches() should be called in a separate thread Key: IGNITE-4658 URL: https://issues.apache.org/jira/browse/IGNITE-4658

[jira] [Created] (IGNITE-4659) Migrate to webpack@2

2017-02-06 Thread Dmitriy Shabalin (JIRA)
Dmitriy Shabalin created IGNITE-4659: Summary: Migrate to webpack@2 Key: IGNITE-4659 URL: https://issues.apache.org/jira/browse/IGNITE-4659 Project: Ignite Issue Type: Task Re

Re: jdbc vs jdbc2 packages

2017-02-06 Thread Vladimir Ozerov
Big +1 to Val, not only about JDBC, but about our overall approach to clients. Starting a node with "client=true" is: + Very reach feature set, which is cool - Tons of dependencies - Tons of threads It would be very cool if we have a true thin client with small single JAR. It should have: - Failov