Re: Binary clients: fallback to the previous versions of the protocol

[Vladimir Ozerov]

Hi Dmitriy,

It is very common practice to keep client protocol compatible with multiple
versions of the server. We constantly face this in practice. I do not see
any reason to drop or complicate this functional: user just connects to the
server and we automatically negotiate on the best feature set possible. No
need to expose it somehow to users. As far as develpoment and testing, we
are not afraid of challenges and difficulties. Yes, it takes more time, but
it worth it.

Vladimir.

On Thu, Feb 14, 2019 at 6:28 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> I am sorry it took me a while to fully understand your reasoning.
>
> “Update user software first, then update the server” approach still
> looks somewhat weird to me (I think of Let's Encrypt client as an
> example of “normal” approach in Python world), but since this approach
> is vivid, I just have to take it into account, so I must agree with
> you.
>
> I just want to reiterate on one downside of such multi-protocol client,
> that was not yet addressed (not in Jira tasks or in docs, at least).
>
> Imagine a coder wrote a program with the latest client, using a feature
> available only in latest binary protocol. When the coder tests his
> program against the latest Ignite cluster, the program works perfectly.
>
> But then the end user runs the program against the previous version of
> the server, which client is still backwards-compatible with, the
> program runs, but at some point it tries to use the latest feature of
> the binary protocol and fails with some cryptic message. The end user
> is clueless, so as the coder.
>
> To avoid such a case, we must include an explicit parameter in our
> client's initialization method, that would set the desired protocol
> version(s) the user application is designed to work with. This
> parameter should be explicit, i.e. not have a default value, since it
> just will be useless the other way. And yes, this parameter renders all
> the software built with previous client versions incompatible with the
> new client.
>
> I think this problem concerns not only the Python client, but all the
> thin clients. What do you think?
>
> On Wed, 2019-02-13 at 13:45 +0300, Igor Sapego wrote:
> > The approach you suggest looks to me pretty much the same as
> > installing a new version of client software in C++ or Java. The issue
> > here that we break existing installed software and require for user
> > to update software in order to have ability to connect to a server.
> > Just imagine that application which made with thin client is not used
> > by a developer that knows how to use pip and all the stuff, but
> > someone with another background. Imagine, you have thousands of such
> > users. And now imagine, you want to update your servers.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Feb 12, 2019 at 8:51 PM Dmitry Melnichuk <
> > dmitry.melnic...@nobitlost.com> wrote:
> >
> > > Igor,
> > >
> > > Thank you for your explanation. I think the matter begins to clear
> > > up
> > > for me now.
> > >
> > > The backward compatibility issue you described can not be applied
> > > to
> > > Python, because Python applications, unlike Java ones, do not have
> > > to
> > > be built. They rely on package manager (pip, conda, et c.) to run
> > > anywhere, including production.
> > >
> > > At the stage of deployment, the package manager collects
> > > dependencies
> > > using a specially crafted response file, often called
> > > `requirements.txt`.
> > >
> > > For example, to ensure that their application will work with the
> > > current _and_ future minor versions of pyignite, the user may
> > > include a
> > > line in their `requirements.txt` file:
> > >
> > > pyignite < x
> > >
> > > where x is a next major version number. In compliance with semantic
> > > versioning, the line is basically says: “Use the latest available
> > > version, that is earlier than x”.
> > >
> > > When upgrading Ignite server, system administrator or devops
> > > engineer
> > > must also update or recreate the app's environment, or update OS-
> > > level
> > > packages, or redeploy the app using Docker − the exact procedure
> > > may
> > > vary, but in any case it should be completely standard − to deliver
> > > the
> > > latest suitable dependencies.
> > >
> > > And then the same app connects to a latest Ignite server.
> > >
> > > Here is more about how pip understands versions:
> > >
> > >
> https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers
> > >
> > > What we really need to do for this to work seamlessly, is to
> > > establish
> > > the clear relation between products' versions. Regretfully, I have
> > > not
> > > done this before; just did not expect for this issue to come up. I
> > > think it would be best for pyignite major and minor to be set
> > > according
> > > to the Ignite binary protocol versions, i.e. pyignite 1.2.z handles
> > > Ignite binary protocol v1.2, and so on. But that is another 

Re: Binary clients: fallback to the previous versions of the protocol

[Dmitry Melnichuk]

Igor,

I am sorry it took me a while to fully understand your reasoning.

“Update user software first, then update the server” approach still
looks somewhat weird to me (I think of Let's Encrypt client as an
example of “normal” approach in Python world), but since this approach
is vivid, I just have to take it into account, so I must agree with
you.

I just want to reiterate on one downside of such multi-protocol client,
that was not yet addressed (not in Jira tasks or in docs, at least).

Imagine a coder wrote a program with the latest client, using a feature
available only in latest binary protocol. When the coder tests his
program against the latest Ignite cluster, the program works perfectly.

But then the end user runs the program against the previous version of
the server, which client is still backwards-compatible with, the
program runs, but at some point it tries to use the latest feature of
the binary protocol and fails with some cryptic message. The end user
is clueless, so as the coder.

To avoid such a case, we must include an explicit parameter in our
client's initialization method, that would set the desired protocol
version(s) the user application is designed to work with. This
parameter should be explicit, i.e. not have a default value, since it
just will be useless the other way. And yes, this parameter renders all
the software built with previous client versions incompatible with the
new client.

I think this problem concerns not only the Python client, but all the
thin clients. What do you think?

On Wed, 2019-02-13 at 13:45 +0300, Igor Sapego wrote:
> The approach you suggest looks to me pretty much the same as
> installing a new version of client software in C++ or Java. The issue
> here that we break existing installed software and require for user
> to update software in order to have ability to connect to a server.
> Just imagine that application which made with thin client is not used
> by a developer that knows how to use pip and all the stuff, but
> someone with another background. Imagine, you have thousands of such
> users. And now imagine, you want to update your servers.
> 
> Best Regards,
> Igor
> 
> 
> On Tue, Feb 12, 2019 at 8:51 PM Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
> 
> > Igor,
> > 
> > Thank you for your explanation. I think the matter begins to clear
> > up
> > for me now.
> > 
> > The backward compatibility issue you described can not be applied
> > to
> > Python, because Python applications, unlike Java ones, do not have
> > to
> > be built. They rely on package manager (pip, conda, et c.) to run
> > anywhere, including production.
> > 
> > At the stage of deployment, the package manager collects
> > dependencies
> > using a specially crafted response file, often called
> > `requirements.txt`.
> > 
> > For example, to ensure that their application will work with the
> > current _and_ future minor versions of pyignite, the user may
> > include a
> > line in their `requirements.txt` file:
> > 
> > pyignite < x
> > 
> > where x is a next major version number. In compliance with semantic
> > versioning, the line is basically says: “Use the latest available
> > version, that is earlier than x”.
> > 
> > When upgrading Ignite server, system administrator or devops
> > engineer
> > must also update or recreate the app's environment, or update OS-
> > level
> > packages, or redeploy the app using Docker − the exact procedure
> > may
> > vary, but in any case it should be completely standard − to deliver
> > the
> > latest suitable dependencies.
> > 
> > And then the same app connects to a latest Ignite server.
> > 
> > Here is more about how pip understands versions:
> > 
> > https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers
> > 
> > What we really need to do for this to work seamlessly, is to
> > establish
> > the clear relation between products' versions. Regretfully, I have
> > not
> > done this before; just did not expect for this issue to come up. I
> > think it would be best for pyignite major and minor to be set
> > according
> > to the Ignite binary protocol versions, i.e. pyignite 1.2.z handles
> > Ignite binary protocol v1.2, and so on. But that is another matter.
> > 
> > On Tue, 2019-02-12 at 13:39 +0300, Igor Sapego wrote:
> > > Hi,
> > > 
> > > Well, this approach was used for quite some time in ODBC and
> > > JDBC,
> > > so thin client has just inherited it, as we have the same port
> > > and
> > > the
> > > same handshake message header. Maybe that's why you could not
> > > find
> > > any mention of versioning in thin client context.
> > > 
> > > 3. Let's start from this point as this is the root of the issue.
> > > Preconditions
> > > are simple - the backward compatibility. We should guarantee that
> > > user
> > > can use any version of thin client with any version of server
> > > while
> > > they
> > > share the same major version. This can be important, if someone
> > > have
> > > user applications 

Re: [DISCUSSION] [IGNITE-11141] The new java method to create a cache from a template

[Eduard Shangareev]

CacheConfiguration cfg = ignite.cacheConfiguration("myTemplate");
cfg.setName("myCacheFromTemplate");
ignite.createCache(cfg);

Ok, I got it. We already have addCacheConfiguration and cacheConfiguration
should be a getter-like counterpart for it.

So, I would suggest deprecating this addCacheConfiguration method and add
new one Ignite.addCacheTemplate and its counterpart getCacheTemplate.
Because cacheConfiguration looks very weird, I would expect that it should
return cache configuration for any given cache name.


Thoughts?


On Thu, Feb 14, 2019 at 12:01 AM Sergey Moldachev 
wrote:

> Hi, Eduard, thank you for your reply!
>
> You can find example and full description in the Jira task
> . Also you can find
> simple implementation in comments.
>
> Thank you,
> Sergey!
>
> + update subject (fixed a typo)
>
> ср, 13 февр. 2019 г. в 19:55, Eduard Shangareev <
> eduard.shangar...@gmail.com
> >:
>
> > Hi, Sergey!
> >
> > Could you give some example of how it is supposed to use?
> >
> > On Wed, Feb 13, 2019 at 6:02 PM Sergey Moldachev <
> > sergeymoldac...@gmail.com>
> > wrote:
> >
> > > Hi, Igniters!
> > >
> > > I want to add the new java method *cacheConfiguration(String
> cacheName)*
> > in
> > > to *Ignite* core interface as part of the task
> > > https://issues.apache.org/jira/browse/IGNITE-11141.
> > >
> > > I'll be glad to see the comments about this feature.
> > >
> > > Thank you,
> > > Sergey
> > >
> >
>

Re: [DISCUSSION] [IGNITE-11141] The new java method to create a cache from a template

[Sergey Moldachev]

Hi, Eduard, thank you for your reply!

You can find example and full description in the Jira task
. Also you can find
simple implementation in comments.

Thank you,
Sergey!

+ update subject (fixed a typo)

ср, 13 февр. 2019 г. в 19:55, Eduard Shangareev :

> Hi, Sergey!
>
> Could you give some example of how it is supposed to use?
>
> On Wed, Feb 13, 2019 at 6:02 PM Sergey Moldachev <
> sergeymoldac...@gmail.com>
> wrote:
>
> > Hi, Igniters!
> >
> > I want to add the new java method *cacheConfiguration(String cacheName)*
> in
> > to *Ignite* core interface as part of the task
> > https://issues.apache.org/jira/browse/IGNITE-11141.
> >
> > I'll be glad to see the comments about this feature.
> >
> > Thank you,
> > Sergey
> >
>

[jira] [Created] (IGNITE-11316) SQL: Support partition pruning for local queries

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-11316:


 Summary: SQL: Support partition pruning for local queries
 Key: IGNITE-11316
 URL: https://issues.apache.org/jira/browse/IGNITE-11316
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov


Currently it is not supported because extraction happens inside splitter. Local 
query eithe: 
# Do not reach splitter at all (no-split case)
# Reach splitter, but skip extraction due to missing infrastructure which is to 
be implemented and tested in the scope of current ticket.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [DISCUSSION] [IGNOTE-11141] The new java method to create a cache from a template

[Eduard Shangareev]

Hi, Sergey!

Could you give some example of how it is supposed to use?

On Wed, Feb 13, 2019 at 6:02 PM Sergey Moldachev 
wrote:

> Hi, Igniters!
>
> I want to add the new java method *cacheConfiguration(String cacheName)* in
> to *Ignite* core interface as part of the task
> https://issues.apache.org/jira/browse/IGNITE-11141.
>
> I'll be glad to see the comments about this feature.
>
> Thank you,
> Sergey
>

[DISCUSSION] [IGNOTE-11141] The new java method to create a cache from a template

[Sergey Moldachev]

Hi, Igniters!

I want to add the new java method *cacheConfiguration(String cacheName)* in
to *Ignite* core interface as part of the task
https://issues.apache.org/jira/browse/IGNITE-11141.

I'll be glad to see the comments about this feature.

Thank you,
Sergey

[jira] [Created] (IGNITE-11315) [ML] Nonlinear SVM

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-11315:
-

 Summary: [ML] Nonlinear SVM
 Key: IGNITE-11315
 URL: https://issues.apache.org/jira/browse/IGNITE-11315
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Artem Malykh
Assignee: Artem Malykh






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11314) JDBC Thin: add transaction-scoped flag to JdbcHandler's responses.

[Alexander Lapin (JIRA)]

Alexander Lapin created IGNITE-11314:


 Summary: JDBC Thin: add transaction-scoped flag to JdbcHandler's 
responses.
 Key: IGNITE-11314
 URL: https://issues.apache.org/jira/browse/IGNITE-11314
 Project: Ignite
  Issue Type: Task
  Components: jdbc
Reporter: Alexander Lapin


Within the context of best effort affinity, and particular, multi-connections, 
it's necessary to use "sticky" connections in case of  "next page" requests, 
transactions, streaming and copy.
In order to implement transaction-based-sticky use case we need to know whether 
we are in transnational scope or not. So JdbcRequestHandler ought to retrieve 
query execution plan, analyse whether transaction exists and propagate 
corresponding flag to the client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Running single test multiple times on TeamCity

[Eduard Shangareev]

Ivan,
We already have IgniteReproducingSuite, and there was a corresponding TC
configuration, but it was removed (maybe by accident).
We could resurrect TC configuration.
+ We can improve Suite to provide test class name by parameter instead of
changing code.

On Mon, Feb 11, 2019 at 11:22 AM Павлухин Иван  wrote:

> Vlad,
>
> Your case is valid as well. And DebugSuite will not help there. But I
> talk about another case. And I have already reproduced several tests
> after repetitive execution of a single test on TC. So, my case also
> seems valid.
>
> пн, 11 февр. 2019 г. в 10:43, Vladislav Pyatkov :
> >
> > Hi,
> >
> > I think more test falling on TC due to context in which running.
> > If you added it in debug suite, it can stop failing anymore like local
> run.
> >
> > On Mon, Feb 11, 2019 at 9:37 AM Павлухин Иван 
> wrote:
> >
> > > Hi,
> > >
> > > During a couple of last weeks I was fixing several flaky tests.
> > > Sometimes it was quite hard to reproduce a test locally. So, one
> > > option was running a particular test on TC several times in a row. To
> > > setup such run I did code modifications in several places.
> > >
> > > I thought about how to simplify the thing. And I came up with some
> > > sort of solution which I would like to share. Basically it is custom
> > > junit runner DebugSuite and a configuration annotation
> > > DebugSuite.Config which allows to choose a method to run and number of
> > > executions. You can see a draft in PR [1].
> > >
> > > As always there are several options to solve a problem. One
> > > alternative way is creating something similar to parameterized build
> > > job Jenkins employs [2] (I have not checked for TC analog yet) and
> > > using maven features to run single test repeatedly (have not checked
> > > as well). But all in all we need to answer following questions:
> > > 1. Do we need such tool? (Or perhaps we already have something and
> > > there is no need to reinvent the wheel.)
> > > 2. What is the best way for us to implement the tool?
> > >
> > > [1] https://github.com/apache/ignite/pull/6076
> > > [2] https://wiki.jenkins.io/display/JENKINS/Parameterized+Build
> > >
> > > --
> > > Best regards,
> > > Ivan Pavlukhin
> > >
> >
> >
> > --
> > Vladislav Pyatkov
>
>
>
> --
> Best regards,
> Ivan Pavlukhin
>

Re: New committer: Andrey Mashenkov

[Вячеслав Коптилин]

Congrats, Andrey! You really deserve it.

Best Regards,
S.


ср, 13 февр. 2019 г. в 15:02, Dmitriy Pavlov :

> Dear Igniters,
>
> The Project Management Committee (PMC) for Apache Ignite has invited Andrey
> Mashenkov to become a committer and we are pleased to announce that he has
> accepted.
>
> Andrey has both code contributions and valuable contribution to community
> development, we appreciate his effort in helping users on user-list,
> efforts in reviewing patches from other members.
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
> Congrats, Andrey, keep your pace! Please join me in welcoming Andrey, and
> congratulating him on the new role in the Apache Ignite Community.
>
> Best Regards,
> Dmitriy Pavlov
>

Re: Code inspection

[Павлухин Иван]

Maxim,

Oh, my poor tabs.. Joke.

I am totally ok with currently enabled checks. But I am mostly
concerned about a general approach. I would like to outline one thing.
Requirements for a prototype code are not the same as for a patch
ready to merge (see a little bit more in the end of that message).

We have a document defining code style which every contributor should
follow [1]. And many points can be checked automatically. Personally,
I do not see much need in writing good javadocs for prototype. Why
should I stub it to be able run any build on TC?

Also, we a have a review process which should be applied to every
patch. Partially it is described in [2]. And due to this process every
patch should not introduce new failures on TC. So, the patch should
not be merged if inspections failed.

P.S. Something more about prototypes and production code. There is a
common bad practice in software engineering. It is turning prototypes
into production code. Often it is much faster to create a prototype by
price of violating some rules of writing "clean code". And often
prototype after successful piloting is turned into production code.
And it is very easy in practice to keep some pieces of initially
"dirty" prototype code. I believe human factor plays a great role
here. How should it be done right then? In my opinion good production
code should be designed as "good production code" from the beginning.
So, only ideas are taken from the prototype and a code is fully
rewritten.

[1] https://cwiki.apache.org/confluence/display/IGNITE/Coding+Guidelines
[2] https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist

ср, 13 февр. 2019 г. в 15:05, Maxim Muzafarov :
>
> Ivan,
>
> As the first implementation of this addition, I'd prefer to make it
> working like _Licenses Headers_ suite check. It will fail when some of
> the code style checks violated. Moreover, these licenses header checks
> can be included in the checkstyle plugin configuration.
>
> In general, I'd prefer to have a compilation fail error with code
> style checks and after we will get a stable checkstyle suite I propose
> to change it in a "compilation error" way. If we are talking about the
> coding style convenient for most of the community members I see no
> difference with coding sketches or production-ready branches equally.
> Indeed, no one will be against unused imports [or spaces instead of
> tabs :-) ] in their PRs or prototypes, right? (for instance, it can be
> automatically removed by IDE at commit phase).
>
> Please, note currently enabled checks are:
>  - list.isEmpty() instead of list.size() == 0
>  - unused imports
>  - missing @Override
>  - sotred modifiers checks (e.g. pulic static final ..)
>  - redundunt suppersion checks
>  - spaces insted of tabs.
>
> Are you really what to violate these checks in your sketches? Hope not :-)
>
> On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov  wrote:
> >
> > Actually, I dont see anything wrong with failing *compilation* task.
> >
> > I think one should use project code style for everyday coding, not only for
> > ready-to-merge PRs.
> >
> > If we cant use code style for everyday coding, we should change the
> > codestyle.
> >
> > What do you think?
> >
> > ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.wei...@gmail.com:
> >
> > > I guess that was about failing build configuration with Checkstype, not
> > > compilation build itself.
> > >
> > > > On 12 Feb 2019, at 18:03, Павлухин Иван  wrote:
> > > >
> > > > Folks,
> > > >
> > > > Are you going to fail job compiling Ignite sources [1] if some
> > > > inspection found a problem? Can we avoid it? It is quite common
> > > > pattern to start some feature implementation with making a sketch and
> > > > running tests against it. I found it convenient to skip some style
> > > > requirements for such sketches (e.g. well formed javadocs).
> > > >
> > > > [1]
> > > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > > >
> > > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov :
> > > >>
> > > >> Petr, we should have 1 configuration for project, may be 1 
> > > >> configuration
> > > >> per programming language.
> > > >>
> > > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.wei...@gmail.com:
> > > >>
> > > >>> I was asking about how many build configuration is intended? One for
> > > all
> > > >>> and multiple per module?
> > > >>>
> > > >>> With IDEA inspections it was going to be build configuration per
> > > module.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > >  On 11 Feb 2019, at 11:24, Nikolay Izhikov 
> > > wrote:
> > > 
> > >  Hello, Petr.
> > > 
> > >  Are you saying that we have not single build task? And each module
> > > builds
> > >  when it required? If yes, then I propose to create a task like
> > > "Licence
> > >  check" which will be run for every patch.
> > > 
> > >  My point is that violation of codestyle should be treated as hard as
> > >  compile error.
> > > 

[jira] [Created] (IGNITE-11313) Cluster hangs on cache invoke with binary objects creation

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-11313:
--

 Summary: Cluster hangs on cache invoke with binary objects creation
 Key: IGNITE-11313
 URL: https://issues.apache.org/jira/browse/IGNITE-11313
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


Creating of binary objects in entry processors in parallel with continuous 
queries may lead to deadlock:
{code:java}
[2019-02-11 18:52:50,129][WARN ][grid-timeout-worker-#39] >>> Possible 
starvation in striped pool.
Thread name: sys-stripe-13-#14
Queue: []
Deadlock: false
Completed: 1
Thread [name="sys-stripe-13-#14", id=33, state=WAITING, blockCnt=3, waitCnt=3]
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at 
o.a.i.i.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
at o.a.i.i.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
at 
o.a.i.i.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:284)
at 
o.a.i.i.binary.BinaryContext.registerUserClassName(BinaryContext.java:1202)
at 
o.a.i.i.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:366)
at 
o.a.i.i.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:189)
at 
o.a.i.scenario.InvokeTask$MyEntryProcessor.process(InvokeTask.java:106)
at 
o.a.i.i.processors.cache.EntryProcessorResourceInjectorProxy.process(EntryProcessorResourceInjectorProxy.java:68)
at 
o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.onEntriesLocked(GridDhtTxPrepareFuture.java:446)
at 
o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1302)
at 
o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:713)
at 
o.a.i.i.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1103)
at 
o.a.i.i.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:405)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:569)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:367)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:171)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:156)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:118)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:198)
at 
o.a.i.i.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:196)
at 
o.a.i.i.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1129)
at 
o.a.i.i.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:594)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
at 
o.a.i.i.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
at 
o.a.i.i.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at 
o.a.i.i.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at 
o.a.i.i.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at 
o.a.i.i.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at 
o.a.i.i.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at 
o.a.i.i.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at o.a.i.i.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{code}
 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: New committer: Andrey Mashenkov

[Павлухин Иван]

Andrey, my congratulations!

ср, 13 февр. 2019 г. в 15:02, Dmitriy Pavlov :
>
> Dear Igniters,
>
> The Project Management Committee (PMC) for Apache Ignite has invited Andrey
> Mashenkov to become a committer and we are pleased to announce that he has
> accepted.
>
> Andrey has both code contributions and valuable contribution to community
> development, we appreciate his effort in helping users on user-list,
> efforts in reviewing patches from other members.
>
> Being a committer enables easier contribution to the project since there is
> no need to go via the patch submission process. This should enable better
> productivity.
>
> Congrats, Andrey, keep your pace! Please join me in welcoming Andrey, and
> congratulating him on the new role in the Apache Ignite Community.
>
> Best Regards,
> Dmitriy Pavlov



-- 
Best regards,
Ivan Pavlukhin

Re: [DISCUSSION] Add reviewer field to Apache Ignite JIRA project

[Dmitriy Pavlov]

Igniters, is it still reasonable to add a reviewer field now?

AFAIK, count of PA tickets (our review dept) is less than it was when the
topic is started. So this proposal can be not actual anymore.

If you agree, please consider picking up this ticket and contact INFRA for
adding the field.
If not, let's close this discussion as not needed

Sincerely,
Dmitriy Pavlov

чт, 27 сент. 2018 г. в 18:39, Dmitriy Pavlov :

> Hi Anton,
>
> Thank you for bringing this significant concern here.
>
> I'm going to use this field in total correspondence with assignee field
> usage. We don't set assignee unless someone agrees to be a developer for
> that feature.
>
> Otherwise, it is better to keep an issue as unassigned. Same implies to
> the reviewer field.
>
> So reviewer is someone, who is ready and going to do the review. Unless we
> not sure who will do a review, mention process continues to work.
>
> Sincerely,
> Dmitriy Pavlov
>
>
> https://lists.apache.org/thread.html/c6013b99940de32aae831a0b76e8fd53febe5040e9e0d67abb4f62a5@%3Cdev.community.apache.org%3E
>
>
>
> чт, 27 сент. 2018 г. в 18:23, Anton Vinogradov :
>
>> Currently, you may ask for a review by mention someone and asking him to
>> review.
>> And this approach looks good to me.
>>
>> In case we'll invent reviewer field who will set the reviewer?
>> It's NOT ok to set somebody as a reviewer!
>> You should ask somebody to be a reviewer first.
>> And in case he agrees he will just make a review. No reason to set a
>> useless field in that case.
>>
>> вт, 25 сент. 2018 г. в 19:39, Dmitriy Setrakyan :
>>
>> > I like the idea.
>> >
>> > On Tue, Sep 25, 2018 at 8:25 AM Dmitriy Pavlov 
>> > wrote:
>> >
>> > > Hi Ignite Enthusiasts,
>> > >
>> > > During the planning of release 2.7, I've faced with the situation
>> when it
>> > > is completely not clear who is going to review ticket.
>> > >
>> > > Usually, we do not reassign tickets to a reviewer, but info about
>> planned
>> > > reviewer can be very useful for all reviewers, who select some
>> > contribution
>> > > to pick up into a review.
>> > >
>> > > Please share your vision about the idea of adding a reviewer field
>> (type:
>> > > user) in addition to the assignee field.
>> > >
>> > > If we agree I will try to ask the Infra team on Friday 28.09.
>> > >
>> > > Sincerely,
>> > > Dmitriy Pavlov
>> > >
>> >
>>
>

Re: Code inspection

[Maxim Muzafarov]

Ivan,

As the first implementation of this addition, I'd prefer to make it
working like _Licenses Headers_ suite check. It will fail when some of
the code style checks violated. Moreover, these licenses header checks
can be included in the checkstyle plugin configuration.

In general, I'd prefer to have a compilation fail error with code
style checks and after we will get a stable checkstyle suite I propose
to change it in a "compilation error" way. If we are talking about the
coding style convenient for most of the community members I see no
difference with coding sketches or production-ready branches equally.
Indeed, no one will be against unused imports [or spaces instead of
tabs :-) ] in their PRs or prototypes, right? (for instance, it can be
automatically removed by IDE at commit phase).

Please, note currently enabled checks are:
 - list.isEmpty() instead of list.size() == 0
 - unused imports
 - missing @Override
 - sotred modifiers checks (e.g. pulic static final ..)
 - redundunt suppersion checks
 - spaces insted of tabs.

Are you really what to violate these checks in your sketches? Hope not :-)

On Wed, 13 Feb 2019 at 10:25, Nikolay Izhikov  wrote:
>
> Actually, I dont see anything wrong with failing *compilation* task.
>
> I think one should use project code style for everyday coding, not only for
> ready-to-merge PRs.
>
> If we cant use code style for everyday coding, we should change the
> codestyle.
>
> What do you think?
>
> ср, 13 февр. 2019 г., 10:11 Petr Ivanov mr.wei...@gmail.com:
>
> > I guess that was about failing build configuration with Checkstype, not
> > compilation build itself.
> >
> > > On 12 Feb 2019, at 18:03, Павлухин Иван  wrote:
> > >
> > > Folks,
> > >
> > > Are you going to fail job compiling Ignite sources [1] if some
> > > inspection found a problem? Can we avoid it? It is quite common
> > > pattern to start some feature implementation with making a sketch and
> > > running tests against it. I found it convenient to skip some style
> > > requirements for such sketches (e.g. well formed javadocs).
> > >
> > > [1]
> > https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_BuildApacheIgnite
> > >
> > > пн, 11 февр. 2019 г. в 11:38, Nikolay Izhikov :
> > >>
> > >> Petr, we should have 1 configuration for project, may be 1 configuration
> > >> per programming language.
> > >>
> > >> пн, 11 февр. 2019 г., 11:33 Petr Ivanov mr.wei...@gmail.com:
> > >>
> > >>> I was asking about how many build configuration is intended? One for
> > all
> > >>> and multiple per module?
> > >>>
> > >>> With IDEA inspections it was going to be build configuration per
> > module.
> > >>>
> > >>>
> > >>>
> > >>>
> >  On 11 Feb 2019, at 11:24, Nikolay Izhikov 
> > wrote:
> > 
> >  Hello, Petr.
> > 
> >  Are you saying that we have not single build task? And each module
> > builds
> >  when it required? If yes, then I propose to create a task like
> > "Licence
> >  check" which will be run for every patch.
> > 
> >  My point is that violation of codestyle should be treated as hard as
> >  compile error.
> > 
> >  пн, 11 февр. 2019 г., 11:16 Petr Ivanov mr.wei...@gmail.com:
> > 
> > > Is build configuration Inspections [Core] meant to transform into
> > single
> > > all-modules check build configuration (without module subdivision)?
> > >
> > >
> > >> On 11 Feb 2019, at 11:02, Nikolay Izhikov 
> > wrote:
> > >>
> > >> Hello, Maxim.
> > >>
> > >> +1 from me for migrating to checkstyle.
> > >>
> > >> Oleg, there is plugin for IDEA with 2mln downloads -
> > >> https://plugins.jetbrains.com/plugin/1065-checkstyle-idea
> > >>
> > >> I propose do the following:
> > >>
> > >> 1. Migrate current checks to checkstyle.
> > >> 2. Apply checks to all Ignite modules. Currently, only core module
> > are
> > >> checked.
> > >> I will review and commit this patch, or do it by my own.
> > >>
> > >> 3. Include code style checks to "Build Apache Ignite" suite. Ignite
> > has
> > > to
> > >> fail to build if patch violates codestyle.
> > >>
> > >> вс, 10 февр. 2019 г. в 07:54, Павлухин Иван :
> > >>
> > >>> Hi,
> > >>>
> > >>> I also think that some warning from IDEA that some code style rule
> > is
> > >>> violated is a must-have.
> > >>>
> > >>> вс, 10 февр. 2019 г. в 01:58, oignatenko  > >:
> > 
> >  Hi Maxim,
> > 
> >  I believe that whatever style checks we establish at Teamcity, we
> > > better
> >  take care of making it easy for developers to find and fix
> > violations
> > > in
> >  their typical dev environment (for Ignite this means, in IDEA). I
> > >>> think
> > >>> it
> >  is important that developers can maintain required style with
> > minimal
> > >>> effort
> >  on their side.
> > 
> >  If above is doable then I 

New committer: Andrey Mashenkov

[Dmitriy Pavlov]

Dear Igniters,

The Project Management Committee (PMC) for Apache Ignite has invited Andrey
Mashenkov to become a committer and we are pleased to announce that he has
accepted.

Andrey has both code contributions and valuable contribution to community
development, we appreciate his effort in helping users on user-list,
efforts in reviewing patches from other members.

Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.

Congrats, Andrey, keep your pace! Please join me in welcoming Andrey, and
congratulating him on the new role in the Apache Ignite Community.

Best Regards,
Dmitriy Pavlov

[jira] [Created] (IGNITE-11311) MVCC: SQL full table scan query can return duplicates.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-11311:
-

 Summary: MVCC: SQL full table scan query can return duplicates.
 Key: IGNITE-11311
 URL: https://issues.apache.org/jira/browse/IGNITE-11311
 Project: Ignite
  Issue Type: Bug
  Components: mvcc, sql
Reporter: Andrew Mashenkov


SQL query like "select * from table" can return duplicate rows.

Possible reasons can be
 *  due to SQL query iterates over data pages directly and can see inconsistent 
state (IGNITE-10561) 
 * Same as IGNITE-10767, query see stale pages.
 * Smth is wrong with mvcc versions visibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11312) JDBC: Thin driver doesn't reports incorrect property names

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-11312:
---

 Summary: JDBC: Thin driver doesn't reports incorrect property names
 Key: IGNITE-11312
 URL: https://issues.apache.org/jira/browse/IGNITE-11312
 Project: Ignite
  Issue Type: Improvement
  Components: jdbc
Reporter: Stanislav Lukyanov


JDBC driver reports the properties it supports via getPropertyInfo method. It 
currently reports the property names as simple strings, like 
"enforceJoinOrder". However, when the properties are processed on connect they 
are looked up with prefix "ignite.jdbc", e.g. "ignite.jdbc.enforceJoinOrder".

Because of this UI tools like DBeaver can't properly pass the properties to 
Ignite. For example, when "enforceJoinOrder" is set to true in "Connection 
settings" -> "Driver properties" menu of DBeaver it has no effect.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Binary clients: fallback to the previous versions of the protocol

[Igor Sapego]

The approach you suggest looks to me pretty much the same as installing
a new version of client software in C++ or Java. The issue here that we
break
existing installed software and require for user to update software in order
to have ability to connect to a server. Just imagine that application which
made
with thin client is not used by a developer that knows how to use pip and
all the
stuff, but someone with another background. Imagine, you have thousands of
such users. And now imagine, you want to update your servers.

Best Regards,
Igor


On Tue, Feb 12, 2019 at 8:51 PM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:

> Igor,
>
> Thank you for your explanation. I think the matter begins to clear up
> for me now.
>
> The backward compatibility issue you described can not be applied to
> Python, because Python applications, unlike Java ones, do not have to
> be built. They rely on package manager (pip, conda, et c.) to run
> anywhere, including production.
>
> At the stage of deployment, the package manager collects dependencies
> using a specially crafted response file, often called
> `requirements.txt`.
>
> For example, to ensure that their application will work with the
> current _and_ future minor versions of pyignite, the user may include a
> line in their `requirements.txt` file:
>
> pyignite < x
>
> where x is a next major version number. In compliance with semantic
> versioning, the line is basically says: “Use the latest available
> version, that is earlier than x”.
>
> When upgrading Ignite server, system administrator or devops engineer
> must also update or recreate the app's environment, or update OS-level
> packages, or redeploy the app using Docker − the exact procedure may
> vary, but in any case it should be completely standard − to deliver the
> latest suitable dependencies.
>
> And then the same app connects to a latest Ignite server.
>
> Here is more about how pip understands versions:
>
> https://pip.pypa.io/en/stable/reference/pip_install/#requirement-specifiers
>
> What we really need to do for this to work seamlessly, is to establish
> the clear relation between products' versions. Regretfully, I have not
> done this before; just did not expect for this issue to come up. I
> think it would be best for pyignite major and minor to be set according
> to the Ignite binary protocol versions, i.e. pyignite 1.2.z handles
> Ignite binary protocol v1.2, and so on. But that is another matter.
>
> On Tue, 2019-02-12 at 13:39 +0300, Igor Sapego wrote:
> > Hi,
> >
> > Well, this approach was used for quite some time in ODBC and JDBC,
> > so thin client has just inherited it, as we have the same port and
> > the
> > same handshake message header. Maybe that's why you could not find
> > any mention of versioning in thin client context.
> >
> > 3. Let's start from this point as this is the root of the issue.
> > Preconditions
> > are simple - the backward compatibility. We should guarantee that
> > user
> > can use any version of thin client with any version of server while
> > they
> > share the same major version. This can be important, if someone have
> > user applications built with thin client and they don't want to break
> > their
> > user applications, when they just want to update servers. What is
> > appropriate here is to give user some kind of warning that they use
> > outdated client or server.
> >
> > Can you explain how your approach is going to work in the example
> > above? I'm not quite sure I understand you correctly.
> >
> > 1. The API for this can be as simple as a set of allowed version in
> > a configuration for both server and client. Maybe we should discuss
> > such
> > kind of API as it can be useful for example in terms of security.
> >
> > 2. Complexity is the price developers have to pay for better user
> > experience.
> > Nothing new here. Software is not designed for developers, it's
> > designed
> > for a user.
> >
> > Best Regards,
> > Igor
> >
> >
> > On Tue, Feb 12, 2019 at 11:56 AM Dmitry Melnichuk <
> > dmitry.melnic...@nobitlost.com> wrote:
> >
> > > Hello fellow igniters!
> > >
> > > I recently started reconnaissance before the
> > > implementation of IEP-23 [1] in Python thin client. I think it is
> > > an
> > > interesting and much promising feature. As I understand, the
> > > changes
> > > associated with this feature will result in a new version of the
> > > binary
> > > protocol.
> > >
> > > What bothers me is not the changes required by the
> > > implementation itself, but the upcoming changes in the way that the
> > > fallback to the previous versions of the protocol is going to be
> > > handled.
> > >
> > > I have not found a open discussion on this topic neither on
> > > this mailing list, nor in Jira. If such a discussion took place,
> > > please
> > > inform me with a link. Based on what I have heard so far, I made
> > > the
> > > following conclusions:
> > >
> > > 1) the client is now expected to handle multiple
> > > binary protocol 

[jira] [Created] (IGNITE-11310) SQL: remove special interaction between query parallelism and distributed joins

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-11310:


 Summary: SQL: remove special interaction between query parallelism 
and distributed joins
 Key: IGNITE-11310
 URL: https://issues.apache.org/jira/browse/IGNITE-11310
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.8


Currently we enable so-called "local distributed joins" when query is executed 
locally with enabled parallelism. This behavior is not needed and needs to be 
removed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11309) JDBC Thin: add flag or property to disable best effort affinity

[Alexander Lapin (JIRA)]

Alexander Lapin created IGNITE-11309:


 Summary: JDBC Thin: add flag or property to disable best effort 
affinity
 Key: IGNITE-11309
 URL: https://issues.apache.org/jira/browse/IGNITE-11309
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.8
Reporter: Alexander Lapin


It's necessary to have an ability to disable best effort affinity among thin 
clients including thin jdbc client.
It's not obvious whether it should be flag in connection string, app properties 
or some other place, so research required.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11308) Add soLinger parameter support in TcpDiscoverySpi .NET configuration.

[Pavel Voronkin (JIRA)]

Pavel Voronkin created IGNITE-11308:
---

 Summary: Add soLinger parameter support in TcpDiscoverySpi .NET 
configuration.
 Key: IGNITE-11308
 URL: https://issues.apache.org/jira/browse/IGNITE-11308
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Voronkin






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11306) NativeSqlJoinQueryRangeBenchmark doesn't work

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-11306:
-

 Summary: NativeSqlJoinQueryRangeBenchmark doesn't work
 Key: IGNITE-11306
 URL: https://issues.apache.org/jira/browse/IGNITE-11306
 Project: Ignite
  Issue Type: Task
  Components: yardstick
Affects Versions: 2.7
Reporter: Ilya Suntsov


Config:

{noformat}

*now0**=*`date +'%H%M%S'`

# JVM options.

*JVM_OPTS**=**${JVM_OPTS}*" -DIGNITE_QUIET*=**false*"

# Uncomment to enable concurrent garbage collection (GC) if you encounter long 
GC pauses.

*JVM_OPTS**=**${JVM_OPTS}*" *\*

-Xms8g *\*

-Xmx8g *\*

-Xloggc:./gc*${now0}*.log *\*

-XX:+PrintGCDetails *\*

-verbose:gc *\*

-XX:+UseParNewGC *\*

-XX:+UseConcMarkSweepGC *\*

-XX:+PrintGCDateStamps *\*

"

#Ignite version

*ver**=*ver-*2*.*8*.*0*-SNAPSHOT-rev-816f435d-

# List of default probes.

# Add DStatProbe or VmStatProbe if your OS supports it (e.g. if running on 
Linux).

*BENCHMARK_DEFAULT_PROBES**=*ThroughputLatencyProbe,PercentileProbe,DStatProbe

# Packages where the specified benchmark is searched by reflection mechanism.

*BENCHMARK_PACKAGES**=*org.yardstickframework,org.apache.ignite.yardstick

# Flag which indicates to restart the servers before every benchmark execution.

*RESTART_SERVERS**=**true*

# Probe point writer class name.

# BENCHMARK_WRITER=

# Comma-separated list of the hosts to run BenchmarkServers on.

*SERVER_HOSTS**=172*.*25*.*1*.*30*,*172*.*25*.*1*.*27*,*172*.*25*.*1*.*28*,*172*.*25*.*1*.*29*

# Comma-separated list of the hosts to run BenchmarkDrivers on.

*DRIVER_HOSTS**=172*.*25*.*1*.*11*

# Remote username.

# REMOTE_USER=

# Number of nodes, used to wait for the specified number of nodes to start.

*nodesNum**=*$((`echo *${SERVER_HOSTS}* | tr ',' '\n' | wc -l` + `echo 
*${DRIVER_HOSTS}* | tr ',' '\n' | wc -l`))

# Backups count.

*b**=1*

# Warmup.

*w**=60*

# Duration.

*d**=180*

# Threads count.

*t**=64*

# Sync mode.

*sm**=*PRIMARY_SYNC

# Jobs.

*j**=10*

# Run configuration which contains all benchmarks.

# Note that each benchmark is set to run for 300 seconds (5 min) with warm-up 
set to 60 seconds (1 minute).

*CONFIGS**=*"*\*

-cfg *${SCRIPT_DIR}*/../config/ignite-config.xml -nn *${nodesNum}* -b *${b}* -w 
*${w}* -d *${d}* -t *${t}* -sm *${sm}* -pc *2* -r *10* *-*-sqlRange *1*  
*-*-client 

 *-dn* NativeSqlJoinQueryRangeBenchmark -sn IgniteNode -ds 
*${ver}*sql-select-native-join-r1-*${b}*-backup,*\*

"

{noformat}

Exception:

{noformat}

<12:50:49> Populate 9

<12:50:50> Populate 10

<12:50:50> Probe writer is not configured (using default CSV 
writer)

<12:50:50> ThroughputLatencyProbe is started.

<12:50:50> PercentileProbe is started.

<12:50:50> DStatProbe is started. Command: 'dstat -m --all 
--noheaders --noupdate 1'

<12:50:50> Starting warmup.

Finishing main test [ts=1550051451762, date=Wed Feb 13 12:50:51 MSK 2019]

ERROR: Shutting down benchmark driver to unexpected exception.

Type '--help' for usage.

java.lang.Exception: Invalid result set size [actual=0, expected=1]

*<-->*at 
org.apache.ignite.yardstick.jdbc.NativeSqlJoinQueryRangeBenchmark.test(NativeSqlJoinQueryRangeBenchmark.java:84)

*<-->*at 
org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)

*<-->*at java.lang.Thread.run(Thread.java:748)

[2019-02-13 12:50:51,810][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=compute]

[2019-02-13 12:50:51,812][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=query]

[2019-02-13 12:50:51,813][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=atomic-index-with-eviction]

[2019-02-13 12:50:51,813][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=atomic-index]

[2019-02-13 12:50:51,813][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=tx]

[2019-02-13 12:50:51,815][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=atomic]

[2019-02-13 12:50:51,815][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=ignite-sys-cache]

[2019-02-13 12:50:51,815][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=SQL_PUBLIC_PERSON]

[2019-02-13 12:50:51,816][INFO ][Thread-8][GridCacheProcessor] Stopped cache 
[cacheName=SQL_PUBLIC_ORGANIZATION]

[2019-02-13 12:50:51,825][INFO ][Thread-8][IgniteKernal]*.*

 

{noformat}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11307) SqlNative benchmarks failed with more than 1 client

[Ilya Suntsov (JIRA)]

Ilya Suntsov created IGNITE-11307:
-

 Summary: SqlNative benchmarks failed with more than 1 client
 Key: IGNITE-11307
 URL: https://issues.apache.org/jira/browse/IGNITE-11307
 Project: Ignite
  Issue Type: Task
  Components: yardstick
Affects Versions: 2.7
Reporter: Ilya Suntsov


I saw the exception below when tried to run NativeSqlInsertDeleteBenchmark, 
NativeSqlQueryRangeBenchmark, NativeSqlUpdateRangeBenchmark with 4 servers and 
8 clients. Looks like we need to use "*create* *table* *if* *not* *exists*" 
instead of "*create* *table*"

{noformat}

<19:55:12> Create table...
<19:55:12> Creating table with schema: CREATE TABLE test_long 
(id LONG PRIMARY KEY, val LONG) WITH "wrap_value=true";
[2019-02-12 19:55:12,876][INFO 
][exchange-worker-#58][GridDhtPartitionsExchangeFuture] Finish exchange future 
[startVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], 
resVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], err=null]
[2019-02-12 19:55:12,881][INFO 
][exchange-worker-#58][GridDhtPartitionsExchangeFuture] Completed partition 
exchange [localNode=f5594085-054c-492f-9112-301b196ff8b3, 
exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion 
[topVer=12, minorTopVer=0],.
evt=NODE_JOINED, evtNode=TcpDiscoveryNode 
[id=0a475055-ad4c-46e4-88e9-ebeba9c846ce, addrs=ArrayList [127.0.0.1, 
172.17.0.1, 172.25.1.26], sockAddrs=HashSet [/172.17.0.1:0, /127.0.0.1:0, 
lab26.gridgain.local/172.25.1.26:0], discPort=0, order=12, intOrder=12, 
lastExchangeTime=1549990512845,
 loc=false, ver=2.8.0#20190211-sha1:e59aa879, isClient=true], done=true], 
topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0]]
[2019-02-12 19:55:12,881][INFO 
][exchange-worker-#58][GridDhtPartitionsExchangeFuture] Exchange timings 
[startVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], 
resVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], stage="Waiting in 
exchange queue" (0 ms),.
stage="Exchange parameters initialization" (0 ms), stage="Determine exchange 
type" (5 ms), stage="Exchange done" (4 ms), stage="Total time" (9 ms)]
[2019-02-12 19:55:12,881][INFO 
][exchange-worker-#58][GridDhtPartitionsExchangeFuture] Exchange longest local 
stages [startVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], 
resVer=AffinityTopologyVersion [topVer=12, minorTopVer=0]]
[2019-02-12 19:55:12,881][INFO ][exchange-worker-#58][time] Finished exchange 
init [topVer=AffinityTopologyVersion [topVer=12, minorTopVer=0], crd=false]
[2019-02-12 19:55:12,882][INFO 
][exchange-worker-#58][GridCachePartitionExchangeManager] Skipping rebalancing 
(no affinity changes) [top=AffinityTopologyVersion [topVer=12, minorTopVer=0], 
rebTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0], evt=NODE_JOINED, e
vtNode=0a475055-ad4c-46e4-88e9-ebeba9c846ce, client=true]
[2019-02-12 19:55:12,972][INFO ][exchange-worker-#58][time] Started exchange 
init [topVer=AffinityTopologyVersion [topVer=12, minorTopVer=1], crd=false, 
evt=DISCOVERY_CUSTOM_EVT, evtNode=da386c99-7b45-4c5b-913b-95eb5b70118f, 
customEvt=DynamicCacheChangeBatch.
[id=5ac22a2e861-fb1a5341-6a6e-4ef8-8a74-072c95cb2e08, reqs=ArrayList 
[DynamicCacheChangeRequest [cacheName=SQL_PUBLIC_TEST_LONG, hasCfg=true, 
nodeId=da386c99-7b45-4c5b-913b-95eb5b70118f, clientStartOnly=false, stop=false, 
destroy=false, disabledAfterStartfalse]], exchangeActions=ExchangeActions
 [startCaches=[SQL_PUBLIC_TEST_LONG], stopCaches=null, 
startGrps=[SQL_PUBLIC_TEST_LONG], stopGrps=[], resetParts=null, 
stateChangeRequest=null], startCaches=false], allowMerge=false]
[2019-02-12 19:55:12,986][INFO ][exchange-worker-#58][time] Finished exchange 
init [topVer=AffinityTopologyVersion [topVer=12, minorTopVer=1], crd=false]
[2019-02-12 19:55:13,063][INFO ][sys-#66][GridDhtPartitionsExchangeFuture] 
Received full message, will finish exchange 
[node=e301e555-2a31-4bdd-a574-9ec412f4c435, resVer=AffinityTopologyVersion 
[topVer=12, minorTopVer=1]]
[2019-02-12 19:55:13,064][INFO ][sys-#66][GridDhtPartitionsExchangeFuture] 
Finish exchange future [startVer=AffinityTopologyVersion [topVer=12, 
minorTopVer=1], resVer=AffinityTopologyVersion [topVer=12, minorTopVer=1], 
err=null]
[2019-02-12 19:55:13,075][INFO ][sys-#66][GridDhtPartitionsExchangeFuture] 
Completed partition exchange [localNode=f5594085-054c-492f-9112-301b196ff8b3, 
exchange=GridDhtPartitionsExchangeFuture [topVer=AffinityTopologyVersion 
[topVer=12, minorTopVer=1], evt=DISCOVERY_CUSTOM_EVT, evtNode=TcpDiscoveryNode.
[id=da386c99-7b45-4c5b-913b-95eb5b70118f, addrs=ArrayList [127.0.0.1, 
172.17.0.1, 172.25.1.13], sockAddrs=HashSet [/172.17.0.1:0, 
lab13.gridgain.local/172.25.1.13:0, /127.0.0.1:0], discPort=0, order=7, 
intOrder=7, lastExchangeTime=1549990507545, loc=false, 
ver=2.8.0#20190211-sha1:e59aa879, isClient=true],
 done=true], topVer=AffinityTopologyVersion [topVer=12, minorTopVer=1]]
[2019-02-12 

[jira] [Created] (IGNITE-11305) Support data page scan for ODBC

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-11305:


 Summary: Support data page scan for ODBC
 Key: IGNITE-11305
 URL: https://issues.apache.org/jira/browse/IGNITE-11305
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Pavel Kuznetsov


Just like IGNITE-10937, we need the same for ODBC.




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-11304) SQL: Common caching of both local and distributed query metadata

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-11304:


 Summary: SQL: Common caching of both local and distributed query 
metadata
 Key: IGNITE-11304
 URL: https://issues.apache.org/jira/browse/IGNITE-11304
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov


Currently query metadata is only cached for distributed queries. For local 
queries it is calculated on every request over and over again. Need to cache it 
always in {{QueryParserResultSelect}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)