Re: Null cache names

[Roman Shtykh]

Shall we add the notes to REST and memcached docs pages that "default" cache 
has to be specified in xml configs? Otherwise it is not created and "cacheName" 
cannot be optional (as REST API docs say) -- no default cache.

https://apacheignite.readme.io/docs/rest-api

-- Roman




On Monday, April 24, 2017 10:43 PM, Dmitriy Setrakyan 
 wrote:
 

 Can we just use the name "default" in such cases?

On Mon, Apr 24, 2017 at 6:33 AM, Seliverstov Igor 
wrote:

> Dear Igniters,
>
> Seems we have almost the same issue with Memcached protocol.
>
> There is an ability to define a cache name via operation extras message
> part (
> https://github.com/memcached/memcached/wiki/BinaryProtocolRevamped#packet-
> structure)
> but it looks a bit complicated from my point of view...
>
> Different client implementations might provide such functionality or not (I
> mean an additional info in an operation extras), so, potential user might
> have some difficultes using Ignite as a Memcached server because of this
> ignite-specific message part becomes mandatory.
>
> An alternative (an the best way, I think) is introducing a configuration
> property to define which cache to use in case it hasn't be defined in a
> message.
>
> I'll appreciate any thoughts on that.
>
> Regards,
> Igor
>
> 2017-04-24 12:43 GMT+03:00 Roman Shtykh :
>
> > Vladimir,
> > Probably we may set the cache name via https://redis.io/commands/
> > client-setname, save it and use until the user specifies another name.
> > #That will be the name for the default cache (mainly for STRING data).
> For
> > other data types, like hashes (https://redis.io/topics/data-types), I am
> > thinking about putting data into caches specified by key.
> > Or use https://redis.io/commands/config-set CONFIG SET DFLT_CACHE
> > cache_name,and save cache name somewhere in Ignite cluster (what is the
> > proper place to store such info?).
> > For that, we have to implement one of the above-mentioned commands.
> > What do you think?
> >
> >
> >
> >    On Monday, April 24, 2017 4:34 PM, Vladimir Ozerov <
> > voze...@gridgain.com> wrote:
> >
> >
> >  Roman,
> > Is it possible to define a kind of property in Redis connection string
> (or
> > property map) for this purpose? IMO ideally we should "externalize" cache
> > name somehow, so that it can be changed with no changes to user's code.
> >
> > Alex,
> > Not sure if this is a good idea as you will end up with PARTITIONED cache
> > without backups with no ability to change that.
> >
> > On Mon, Apr 24, 2017 at 9:35 AM, Alexey Kuznetsov  >
> > wrote:
> >
> > > Roman,
> > >
> > > Just as idea, how about in case of user does not configured
> "REDIS_CACHE"
> > >  then create it via ignite.getOrCreateCache(new
> > > CacheConfiguration("REDIS_CACHE"))
> > > and prin warning to log "REDIS_CACHE not configured, using default
> > > partitioned cache".
> > >
> > > What do you think?
> > >
> > > On Mon, Apr 24, 2017 at 10:26 AM, Roman Shtykh
>  > >
> > > wrote:
> > >
> > > > Denis, Igor,
> > > > What can be done now
> > > > 1. create a default cache name for Redis data, e.g. "REDIS_CACHE"
> that
> > > has
> > > > to be configured explicitly in xml file (as it is done with other
> > caches)
> > > > by a user if he/she needs Redis protocol.
> > > > 2. Force users to specify cache names as prefix to their keys, so
> that
> > we
> > > > can parse and switch between caches.
> > > > The 1st one is a very quick fix I can do today. This can be extended
> in
> > > > future to have a separate cache for each data type.
> > > > Roman
> > > >
> > > >
> > > >    On Monday, April 24, 2017 12:15 AM, Denis Magda <
> > dma...@gridgain.com
> > > >
> > > > wrote:
> > > >
> > > >
> > > >  Roman, would you suggest a quick solution for the redis integration
> or
> > > > even
> > > > implement it in the nearest couple of days? We need to change the
> > defaul
> > > > cache name in 2.0. Otherwise, it can be done only in an year or so in
> > > 3.0.
> > > >
> > > > Denis
> > > >
> > > > On Sunday, April 23, 2017, Seliverstov Igor 
> > > wrote:
> > > >
> > > > > Hi Roman,
> > > > >
> > > > > The ticket number is IGNITE-3488.
> > > > >
> > > > > It's planned not to have null-named or default caches at all. All
> the
> > > > > caches must be defined explicitly or via templates and have names.
> > The
> > > > > current implementation uses a cache with null name, so, we need
> some
> > > > > configuration property to define which cache to use or mapping in
> > case
> > > of
> > > > > using Redis databases.
> > > > >
> > > > > Regards,
> > > > > Igor
> > > > >
> > > > > 22 апр. 2017 г. 8:47 пользователь "Roman Shtykh"
> > > >  > > > > >
> > > > > написал:
> > > > >
> > > > > > Hi Igor,
> > > > > > The current implementation supports only STRING data type of
> Redis.
> > > In
> > > > > > addition, AFAIK, 

Re: Supported and Unsupported SQL

[Dmitriy Setrakyan]

Ticket filed: https://issues.apache.org/jira/browse/IGNITE-5678

On Mon, Jul 3, 2017 at 5:14 PM, Denis Magda  wrote:

> Fully support this idea. That’ll help a lot our users and make things
> clearer for us.
>
> —
> Denis
>
> > On Jul 3, 2017, at 8:41 AM, Dmitriy Setrakyan 
> wrote:
> >
> > Igniters,
> >
> > Vladimir pointed out that PostgreSQL has a very detailed list of
> supported
> > and unsupported features:
> > https://www.postgresql.org/docs/devel/static/features.html
> >
> > I think we can borrow a few things from this format:
> >
> >   1. Have a very detailed documented list of all the
> supported/unsupported
> >   features in Ignite SQL engine.
> >   2. Once the list is created, ensure that we have sufficient test
> >   coverage for all the supported features.
> >
> > Thoughts?
> >
> > D.
>
>

[jira] [Created] (IGNITE-5678) Need to document and test supported and unsupported SQL features

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-5678:
-

 Summary: Need to document and test supported and unsupported SQL 
features
 Key: IGNITE-5678
 URL: https://issues.apache.org/jira/browse/IGNITE-5678
 Project: Ignite
  Issue Type: Task
  Components: documentation, sql
Reporter: Dmitriy Setrakyan
Assignee: Vladimir Ozerov
Priority: Critical
 Fix For: 2.1


We should provide supported and unsupported feature documentation, similar to 
PostgreSQL: https://www.postgresql.org/docs/devel/static/features.html

We can do the following:
* Have a very detailed documented list of all the supported/unsupported 
features in Ignite SQL engine.
* Once the list is created, ensure that we have sufficient test coverage for 
all the supported features.



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

Re: Supported and Unsupported SQL

[Denis Magda]

Fully support this idea. That’ll help a lot our users and make things clearer 
for us.

—
Denis

> On Jul 3, 2017, at 8:41 AM, Dmitriy Setrakyan  wrote:
> 
> Igniters,
> 
> Vladimir pointed out that PostgreSQL has a very detailed list of supported
> and unsupported features:
> https://www.postgresql.org/docs/devel/static/features.html
> 
> I think we can borrow a few things from this format:
> 
>   1. Have a very detailed documented list of all the supported/unsupported
>   features in Ignite SQL engine.
>   2. Once the list is created, ensure that we have sufficient test
>   coverage for all the supported features.
> 
> Thoughts?
> 
> D.

[jira] [Created] (IGNITE-5677) Document affinity-related SQL optimizations

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5677:
---

 Summary: Document affinity-related SQL optimizations
 Key: IGNITE-5677
 URL: https://issues.apache.org/jira/browse/IGNITE-5677
 Project: Ignite
  Issue Type: Sub-task
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.1


Refer to the ticket below for details on what has been done:
https://issues.apache.org/jira/browse/IGNITE-4509



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

Re: Distributed scheduling

[Dmitriy Setrakyan]

Hm... I think we should definitely make our services durable. Everything in
Ignite should be durable now.

As far as scheduling, makes sense as well. Let's make it durable too.

D.

On Mon, Jul 3, 2017 at 3:35 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Dmitry,
>
> Yes, this can be implemented using services in many cases, but:
>
> - It will require user to implement actual scheduling logic. It's quite a
> generic task, so I think it makes sense to have it directly on the API.
> - Most likely it will imply deploying separate service for each scheduled
> task. I don't think it's a very good idea.
> - Current services implementation is not durable. If cluster is restarted,
> all services are lost.
>
> -Val
>
> On Sat, Jul 1, 2017 at 12:34 AM, Dmitriy Setrakyan 
> wrote:
>
> > Val,
> >
> > In this case, we should have a notion of a named scheduler and ensure
> that
> > we don't schedule the same task more than once. This is beginning to look
> > more like a durable cluster singleton service, no?
> >
> > D.
> >
> > On Fri, Jun 30, 2017 at 1:39 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> > > I think this functionality should provide durable way of scheduled task
> > or
> > > closure execution on the cluster. Job descriptors should be persisted
> on
> > > server side and executed there.
> > >
> > > As for API, I believe this should be part of Compute Grid. I suggest to
> > > introduce IgniteCompute#withSchedulingPolicy(SchedulingPolicy policy)
> > > method, where SchedulingPolicy is smth like this:
> > >
> > > public interface SchedulingPolicy {
> > > /**
> > >  * @return Timestamp of next execution.
> > >  */
> > > public Date nextTime();
> > > }
> > >
> > > This will enable scheduling for all compute features (tasks, callables,
> > > closures, etc.) and also very flexible. Policy implementation can
> provide
> > > simple periodic scheduling, scheduling based on Cron or anything else.
> > >
> > > Thoughts?
> > >
> > > -Val
> > >
> > > On Fri, Jun 30, 2017 at 7:55 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > > wrote:
> > >
> > > > On Fri, Jun 30, 2017 at 12:29 AM, Alexey Kuznetsov <
> > > akuznet...@apache.org>
> > > > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > >> Can you provide a simple example of API calls that will make
> this
> > > > > possible?
> > > > > API could be like this:
> > > > > 1) via scheduler:
> > > > > Ignite ignite = Ignition.start();
> > > > >
> > > > > ignite.scheduler().schedulel(job, "0 0 * * *"); // This will
> execute
> > > job
> > > > > every day at 00:00
> > > > >
> > > > > 2) via compute
> > > > >
> > > > > Ignite ignite = Ignition.start();
> > > > >
> > > > > ignite.compute().schedulel(task, "0 0 * * *"); // This will
> execute
> > > > > compute
> > > > > task every day at 00:00
> > > > >
> > > > > Make sense?
> > > > >
> > > > >
> > > > Yes, it does, but I am failing to see how is this a *distributed*
> > > > scheduling. Are we persisting the scheduler somewhere in the cluster
> or
> > > is
> > > > it only triggered on the client side?
> > > >
> > >
> >
>

Re: Distributed scheduling

[Valentin Kulichenko]

Dmitry,

Yes, this can be implemented using services in many cases, but:

- It will require user to implement actual scheduling logic. It's quite a
generic task, so I think it makes sense to have it directly on the API.
- Most likely it will imply deploying separate service for each scheduled
task. I don't think it's a very good idea.
- Current services implementation is not durable. If cluster is restarted,
all services are lost.

-Val

On Sat, Jul 1, 2017 at 12:34 AM, Dmitriy Setrakyan 
wrote:

> Val,
>
> In this case, we should have a notion of a named scheduler and ensure that
> we don't schedule the same task more than once. This is beginning to look
> more like a durable cluster singleton service, no?
>
> D.
>
> On Fri, Jun 30, 2017 at 1:39 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > I think this functionality should provide durable way of scheduled task
> or
> > closure execution on the cluster. Job descriptors should be persisted on
> > server side and executed there.
> >
> > As for API, I believe this should be part of Compute Grid. I suggest to
> > introduce IgniteCompute#withSchedulingPolicy(SchedulingPolicy policy)
> > method, where SchedulingPolicy is smth like this:
> >
> > public interface SchedulingPolicy {
> > /**
> >  * @return Timestamp of next execution.
> >  */
> > public Date nextTime();
> > }
> >
> > This will enable scheduling for all compute features (tasks, callables,
> > closures, etc.) and also very flexible. Policy implementation can provide
> > simple periodic scheduling, scheduling based on Cron or anything else.
> >
> > Thoughts?
> >
> > -Val
> >
> > On Fri, Jun 30, 2017 at 7:55 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >
> > > On Fri, Jun 30, 2017 at 12:29 AM, Alexey Kuznetsov <
> > akuznet...@apache.org>
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > >> Can you provide a simple example of API calls that will make this
> > > > possible?
> > > > API could be like this:
> > > > 1) via scheduler:
> > > > Ignite ignite = Ignition.start();
> > > >
> > > > ignite.scheduler().schedulel(job, "0 0 * * *"); // This will execute
> > job
> > > > every day at 00:00
> > > >
> > > > 2) via compute
> > > >
> > > > Ignite ignite = Ignition.start();
> > > >
> > > > ignite.compute().schedulel(task, "0 0 * * *"); // This will execute
> > > > compute
> > > > task every day at 00:00
> > > >
> > > > Make sense?
> > > >
> > > >
> > > Yes, it does, but I am failing to see how is this a *distributed*
> > > scheduling. Are we persisting the scheduler somewhere in the cluster or
> > is
> > > it only triggered on the client side?
> > >
> >
>

Re: Zookeeper Discovery SPI & external IP address in AWS

[Valentin Kulichenko]

To my knowledge it's the case, there should be any issues with that.

-Val

On Mon, Jul 3, 2017 at 3:55 AM, Yakov Zhdanov  wrote:

> My point is that communication SPI should put both address types to its
> attributes to share - private and addresses processed by a resolver.
>
> --Yakov
>

Re: Custom string encoding

[Valentin Kulichenko]

Yes, this needs to be tested and confirmed. I will work on it.

Would be great to get more details about indexes. I'm not sure I understand
the limitation there.

-Val

On Mon, Jul 3, 2017 at 7:21 AM, Dmitriy Setrakyan 
wrote:

> Agree with Valya on the system-wide default. We need to have it.
>
> Also, are we certain that the encoding will provide 1-byte length for UTF-8
> for different languages? Would be nice to test it to confirm, as it has a
> potential to decrease the Ignite storage space by 2x in certain cases.
>
> D.
>
> On Sun, Jul 2, 2017 at 12:26 PM, Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Vova,
> >
> > That's actually a good point. Probably that would be enough and there is
> no
> > need to introduce absract encoder. However, I still think it makes sense
> to
> > specify default encoding in BinaryConfiguration and
> > BinaryTypeConfiguration.
> >
> > -Val
> >
> > On Sun, Jul 2, 2017 at 10:31 AM Vladimir Ozerov 
> > wrote:
> >
> > > Yes, this is exactly what non-UTF8 encodings do.
> > >
> > > вс, 2 июля 2017 г. в 20:08, Dmitriy Setrakyan :
> > >
> > > > On Sun, Jul 2, 2017 at 9:50 AM, Vladimir Ozerov <
> voze...@gridgain.com>
> > > > wrote:
> > > >
> > > > > There is no need for custom encoders, as they are already built-in
> to
> > > > Java.
> > > > >
> > > >
> > > > Will non-ASCII encodings fit into 1 byte? The whole point here is to
> > save
> > > > space.
> > > >
> > > >
> > > > >
> > > > > вс, 2 июля 2017 г. в 19:16, Dmitriy Setrakyan <
> dsetrak...@apache.org
> > >:
> > > > >
> > > > > > Vladimir, how would you plugin custom encoders in your design?
> > > > > >
> > > > > > On Sat, Jul 1, 2017 at 11:53 PM, Vladimir Ozerov <
> > > voze...@gridgain.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Valya,
> > > > > > >
> > > > > > > Personally I vote against this feature. BinaryConfiguration is
> > > proven
> > > > > to
> > > > > > be
> > > > > > > inconvenient, since it has to be configured before node start,
> it
> > > > > cannot
> > > > > > be
> > > > > > > changed in runtime, and it requires classes on the server.
> > > Moreover,
> > > > if
> > > > > > you
> > > > > > > decide to change encoding at some point, it would be
> impossible.
> > > > > > >
> > > > > > > I think, we should add this feature on API level instead. If
> > string
> > > > is
> > > > > > > written in non-UTF8 form, we will write in different format:
> > > > > > > [encoding_code][string]
> > > > > > >
> > > > > > > BInaryWriter.writeString(String fieldName, String val);
> > > > > > > BInaryWriter.writeString(String fieldName, String val, *String
> > > > > > encoding*);
> > > > > > >
> > > > > > > BinaryReader.readString(String fieldName);
> > > > > > > BinaryReader.readString(String fieldName, *String encoding*);
> > > > > > >
> > > > > > > BinaryObjectBuilder.writeString(String fieldName, String val,
> > > *String
> > > > > > > encoding*);
> > > > > > >
> > > > > > > class MyClass {
> > > > > > > *@BinaryString(encoding = "Cp1251")*
> > > > > > > private String myCyrillicString;
> > > > > > > }
> > > > > > >
> > > > > > > Vladimir.
> > > > > > >
> > > > > > > On Sat, Jul 1, 2017 at 7:26 PM, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Sat, Jul 1, 2017 at 2:24 AM, Sergi Vladykin <
> > > > > > sergi.vlady...@gmail.com
> > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > In SQL indexes we may store partial strings and assume them
> > to
> > > be
> > > > > in
> > > > > > > > UTF-8,
> > > > > > > > > I don't think this can be abstracted away. But may be this
> is
> > > > not a
> > > > > > big
> > > > > > > > > deal if in indexes we still will use UTF-8.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Sergi, why does it matter if it is UTF8 or custom encoding?
> Why
> > > > can't
> > > > > > we
> > > > > > > > use our own compact encoding in indexes?
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > 2017-07-01 10:13 GMT+03:00 Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > Val, do you know how we compare strings in SQL queries?
> > Will
> > > we
> > > > > be
> > > > > > > able
> > > > > > > > > to
> > > > > > > > > > use this encoder?
> > > > > > > > > >
> > > > > > > > > > Additionally, I think that the encoder is a bit too
> > abstract.
> > > > Why
> > > > > > not
> > > > > > > > go
> > > > > > > > > > even further and allow users create their own ASCII table
> > for
> > > > > > > encoding?
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Fri, Jun 30, 2017 at 6:49 PM, Valentin Kulichenko <
> > > > > > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Andrey,
> > > > > > > > > > >
> > > > > > > > > > > Can you elaborate more on this? What is your concern?
> > > > > > > > 

Re: Ready for review IGNITE-5532 .NET: Clean up and refactor CacheLinqTest

[Guru Stron]

Hi, Anton

Thank you for suggestion, done.

On 3 July 2017 at 20:22, Anton Vinogradov  wrote:

> Hi,
>
> Thanks for interest to Apache Ignite development.
>
> I'd like to propose you to make direct "review request".
> This should help to speedup review process, you can find tips here:
> https://cwiki.apache.org/confluence/display/IGNITE/How+
> to+Contribute#HowtoContribute-SubmittingforReview
>
> On Mon, Jul 3, 2017 at 7:53 PM, Guru Stron 
> wrote:
>
> > Hi,
> >
> > IGNITE-5532 is ready for review, can someone take a look please?
> >
> > https://github.com/apache/ignite/pull/2226
> >
> > Builds:
> >
> > Ignite Platform .NET
> > http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_
> > IgnitePlatformNet_Ignite20Tests=pull%2F2226%
> > 2Fmerge=buildTypeStatusDiv
> >
> > Ignite Platform .NET Inspections
> > http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_
> > IgnitePlatformNetInspections_Ignite20Tests=pull%
> 2F2226%2Fmerge=
> > buildTypeStatusDiv
> >
>

[GitHub] ignite pull request #2228: IGNITE-5153 CPP: Introduced "varint" encoding in ...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-5153 CPP: Introduced "varint" encoding in C++



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

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

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

https://github.com/apache/ignite/pull/2228.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2228


commit 1e1e8432dc936df7c62557575a57c4a159b4bca6
Author: Vyacheslav Daradur 
Date:   2017-05-31T08:41:56Z

ignite-5097: writing arrays length in varint encoding was implemented

commit d162d3e3d9036cddb275b4a3d86b8f5de9795185
Author: daradurvs 
Date:   2017-06-01T18:35:13Z

ignite-5097: doUnsafeWriteUnsignedVarint method was added

commit bfe381b3a7498eb5bebeb25026a43d36656c6041
Author: daradurvs 
Date:   2017-06-04T21:25:48Z

ignite-5097: dotNET - writing arrays length in varint encoding was 
implemented

commit 516fcf41e4e973abf41cdd19acd2c9ea1bfb9445
Author: daradurvs 
Date:   2017-06-04T21:26:00Z

ignite-5097: dotNET - hardcoded hashcode values in the tests were changed 
according to new conditions

commit 51fd311c5775fb7c5801c9588cafbcd842be2a4f
Author: Igor Sapego 
Date:   2017-05-31T14:58:03Z

IGNITE-5153: Initial commit

commit a6dbd043de5d2aa08195ff67cad768fa3337e05e
Author: Igor Sapego 
Date:   2017-05-31T15:32:43Z

IGNITE-5153: Fix for Decimals

commit 302d68d4b8313a9f0e593d711ac22d3ab1534cf8
Author: Igor Sapego 
Date:   2017-07-03T17:53:58Z

IGNITE-5153: Fix for the test configuration




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Ready for review IGNITE-5532 .NET: Clean up and refactor CacheLinqTest

[Anton Vinogradov]

Hi,

Thanks for interest to Apache Ignite development.

I'd like to propose you to make direct "review request".
This should help to speedup review process, you can find tips here:
https://cwiki.apache.org/confluence/display/IGNITE/How+
to+Contribute#HowtoContribute-SubmittingforReview

On Mon, Jul 3, 2017 at 7:53 PM, Guru Stron 
wrote:

> Hi,
>
> IGNITE-5532 is ready for review, can someone take a look please?
>
> https://github.com/apache/ignite/pull/2226
>
> Builds:
>
> Ignite Platform .NET
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_
> IgnitePlatformNet_Ignite20Tests=pull%2F2226%
> 2Fmerge=buildTypeStatusDiv
>
> Ignite Platform .NET Inspections
> http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_
> IgnitePlatformNetInspections_Ignite20Tests=pull%2F2226%2Fmerge=
> buildTypeStatusDiv
>

[GitHub] ignite pull request #2227: IGNITE-5159 DDL example.

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-5159 DDL example.



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

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

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

https://github.com/apache/ignite/pull/2227.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2227


commit 75769a64059bef43b8d7ed103563896f96eabe84
Author: Alexander Paschenko 
Date:   2017-07-03T17:08:05Z

IGNITE-5159 DDL example.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Ready for review IGNITE-5532 .NET: Clean up and refactor CacheLinqTest

[Guru Stron]

Hi,

IGNITE-5532 is ready for review, can someone take a look please?

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

Builds:

Ignite Platform .NET
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNet_Ignite20Tests=pull%2F2226%2Fmerge=buildTypeStatusDiv

Ignite Platform .NET Inspections
http://ci.ignite.apache.org/viewType.html?buildTypeId=Ignite20Tests_IgnitePlatformNetInspections_Ignite20Tests=pull%2F2226%2Fmerge=buildTypeStatusDiv

[GitHub] ignite pull request #2226: IGNITE-5532 .NET: Clean up and refactor CacheLinq...

[gurustron]

GitHub user gurustron opened a pull request:

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

IGNITE-5532 .NET: Clean up and refactor CacheLinqTest



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

$ git pull https://github.com/gurustron/ignite feature/IGNITE-5532

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

https://github.com/apache/ignite/pull/2226.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2226


commit 89ca713cfc1c130958a038a0a3869bd65ecca991
Author: gurustron 
Date:   2017-07-02T18:10:47Z

break up CacheLinqTests class into partial




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (IGNITE-5675) Add ability to detect and report anomalities

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5675:
-

 Summary: Add ability to detect and report anomalities
 Key: IGNITE-5675
 URL: https://issues.apache.org/jira/browse/IGNITE-5675
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# growing (or decreasing) response times
# changes to result sets of queries
# changes to serialized sizes of the objects
# anything else?
# 
Probably, we will need to add automatic reaction on these changes



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

[GitHub] ignite pull request #2225: Ignite gg 12390

[dspavlov]

GitHub user dspavlov opened a pull request:

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

Ignite gg 12390

PR for tests run on TC

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

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

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

https://github.com/apache/ignite/pull/2225.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2225


commit 5f5c5f1ba07cccd1ee072f4b1f95d32459d9507b
Author: dpavlov 
Date:   2017-06-14T10:58:21Z

Merge remote-tracking branch 'apache-gridgain-fork/ignite-2.1.1' into 
ignite-2.1.1

commit 40db31ef76303215db1703166c94b795cd2eb2b2
Author: Dmitriy Govorukhin 
Date:   2017-06-14T11:16:08Z

ignite-2.1.1 do not create database shared manger on client + cosmetic 
changes

commit 4e973551a4264395aa7fe167aba61736a0d259e6
Author: Dmitriy Govorukhin 
Date:   2017-06-14T11:49:13Z

ignite-2.1.1 invoke activate/deactivate for snapshot manager.

commit 69aa299c9f9f864086266d618d28b78ca407b8ac
Author: devozerov 
Date:   2017-06-14T11:55:48Z

Fixed missing Apache header in HttpIgniteUpdatesChecker.

commit 4eb8c5e4c687edb1c695d2d38ad93cca09cd024a
Author: Dmitriy Govorukhin 
Date:   2017-06-14T12:08:01Z

ignite-2.1.1 validate operation change global state if snapshot operation 
in progress

commit 752dd65f82221fdc7570c50ae4c0d41652541422
Author: Dmitriy Govorukhin 
Date:   2017-06-14T12:08:29Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into ignite-2.1.1

commit 3d269d7d5094acb9b8ac86de16fc16c8c80ec5e6
Author: Ilya Lantukh 
Date:   2017-06-14T12:20:20Z

Minors.

commit 73df0354241bff62c854847c4c98abac8a5b4c24
Author: Ilya Lantukh 
Date:   2017-06-14T12:39:17Z

Minors.

commit 8b85477eabd6e9059d3849a277b9494845b67293
Author: Ilya Lantukh 
Date:   2017-06-14T12:47:29Z

Cache type validation.

commit 51e6aed7c82e4c7885b85c57a7235f0d5872b7e7
Author: dpavlov 
Date:   2017-06-14T13:00:46Z

GG-12283: disabled handing tests to run others

commit 0292110a0427ecce0b10f9b3393d0c1b94b254f6
Author: dpavlov 
Date:   2017-06-14T13:37:15Z

IGNITE-5487: disabled handing tests to run others

commit d285f82b2540f84a88d4c655d6e3a74680b0f766
Author: oleg-ostanin 
Date:   2017-06-14T13:47:46Z

IGNITE-5488 Build failure: maven-remote-resources-plugin

commit e7a7751a9d60c541c57f570779a6301abdb696b5
Author: Dmitriy Govorukhin 
Date:   2017-06-14T13:53:22Z

ignite-gg-12290 fix npe in cluster processor if got exception on start in 
plugin processor.

commit c5882ba94a21859dd5fac7f50b792512492c7018
Author: Dmitriy Govorukhin 
Date:   2017-06-14T13:53:42Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into ignite-2.1.1

commit 59dace5a3883596d7edb661e6f8a328cca4a059e
Author: Ilya Lantukh 
Date:   2017-06-14T15:11:23Z

Fixed assertion error when tried to aquire affinity assignment for NONE 
topology version.

commit b1d8a4975585dddc6256496c3c797362eddac0ed
Author: devozerov 
Date:   2017-06-14T15:29:17Z

IGNITE-5458: Added CacheConfiguration.keyConfiguration property and fixed 
affinity calculation in some cases. This closes #2113. This closes #2125.

commit 86125baf871d2a686fa1e8fb9af19ec44e013b40
Author: Pavel Kovalenko 
Date:   2017-06-14T15:35:30Z

Fail with known issue

commit c4447bbbabcd47649349af2c1d7129f6148133d0
Author: mcherkasov 
Date:   2017-06-14T16:01:17Z

classnames.properties is updated.

commit aef982c1953aa9eacd8aa9e2fe2b6db3b7be463b
Author: EdShangGG 
Date:   2017-06-14T16:27:41Z

GG-12289 Snapshot functionality works incorrect after activation

commit f36ab7ce5e32a98e6bcc6c913a38552d481f47a9
Author: Dmitriy Govorukhin 
Date:   2017-06-14T16:34:38Z

ignite-gg-12289 deactivate components if accept inactive state from 
cluster. Mute test fail get file lock.

commit e651aeaad3d0d40859145df8e810f29ed9dc1d48
Author: Dmitriy Govorukhin 
Date:   2017-06-14T16:43:14Z

ignite-gg-12289 move deactivate code on join from discovery thread to start 
node thread.

commit 6aad7b2b8921c47c6bddc7293bb1be8679156438
Author: Dmitriy Govorukhin 
Date:   2017-06-14T16:45:29Z

Merge remote-tracking branch 'professional/ignite-2.1.1' into 
ignite-gg-12289

commit 19333f8b61597617ac16593edd8c7344c02f21fd
Author: Dmitriy Govorukhin 

[jira] [Created] (IGNITE-5672) Report contended cache keys if any

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5672:
-

 Summary: Report contended cache keys if any
 Key: IGNITE-5672
 URL: https://issues.apache.org/jira/browse/IGNITE-5672
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov






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

[jira] [Created] (IGNITE-5671) Collect cache SQL query stats

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5671:
-

 Summary: Collect cache SQL query stats
 Key: IGNITE-5671
 URL: https://issues.apache.org/jira/browse/IGNITE-5671
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# requests processed
# plans on demand
# timings
# result set sizes



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

Supported and Unsupported SQL

[Dmitriy Setrakyan]

Igniters,

Vladimir pointed out that PostgreSQL has a very detailed list of supported
and unsupported features:
https://www.postgresql.org/docs/devel/static/features.html

I think we can borrow a few things from this format:

   1. Have a very detailed documented list of all the supported/unsupported
   features in Ignite SQL engine.
   2. Once the list is created, ensure that we have sufficient test
   coverage for all the supported features.

Thoughts?

D.

[GitHub] ignite pull request #2224: Ignite 1.7

[ntikhonov]

GitHub user ntikhonov opened a pull request:

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

Ignite 1.7



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

$ git pull https://github.com/gridgain/apache-ignite ignite-1.7.9-p1.b1

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

https://github.com/apache/ignite/pull/2224.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2224


commit b1ec58f716ece3a5866dd654ebc707bef67caf57
Author: Alexey Kuznetsov 
Date:   2016-10-13T05:58:22Z

IGNITE-4066 Fixed NPE.

commit 447e07c0bb5af75bce6a14612606904e4e3d9705
Author: Anton Vinogradov 
Date:   2016-10-14T08:40:41Z

IGNITE-1924 Incomplete marshaller cache rebalancing causes Grid hangs under 
SSL

commit 7adfbcf1ee7bbe0beb95fa82749a2e04449de8fa
Author: tledkov-gridgain 
Date:   2016-10-14T14:48:14Z

IGNITE-4060: Fixed a bug in RoundRobinLoadBalancing API causing exception 
when running closures after client node reconnect. This closes #1157.

commit 80abd1b72e4fc7b0b95212e7f53c700c0fe21156
Author: Aleksei Scherbakov 
Date:   2016-10-14T16:33:07Z

GG-11360 - Implement SQL queries cancellation (#18)

* GG-11360 Merged IGNITE-2680 to ignite-1.6.3.

* GG-11360 Test cleanup.

* GG-11360 Fixing broken tests.

* GG-11360 Fixing test.

* GG-11360 Fixing test.

* GG-11360 Fixing broken tests.

* GG-11360 Added test for forever-running query cancellation on node 
restart.

* GG-11360 Fixing race.

* GG-11360 Added test for forever-running query cancellation on node stop.

* GG-11360 Cleanup.

* GG-11360 Support for local query cancellation/timeout.

* GG-11360 Increase test duration.

* GG-11360 Remove redundant catch block.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Fix formatting.

* GG-11360 Simplify test.

* GG-11360 Simplify test.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* GG-11360 Fixing issues.

* Merge remote-tracking branch 'remotes/gg/ignite-1.6.10' into 
ignite-gg-11360

Conflicts:

modules/core/src/main/java/org/apache/ignite/internal/processors/query/GridQueryProcessor.java

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

* GG-11360 Review fixes.

commit 43ac3f5d5e8ab664e07f26d99be34f284f7941dd
Author: vozerov-gridgain 
Date:   2016-10-17T08:26:12Z

IGNITE-4054: Hadoop: added map-reduce plan debug output.

commit d3f042b9ba6c605500ab7155c40a41850babefdb
Author: sboikov 
Date:   2016-10-17T09:28:31Z

Fixed indexing test in according to changes from #80abd1b.

commit 59de231c0d0dce56b0cf5c386b19a2880d9c0603
Author: sboikov 
Date:   2016-10-17T13:31:35Z

Re-generated GridQueryFailResponse.

commit 717e91fed944082df35ecdc2e647de2ad3fca2c7
Author: ascherbakoff 
Date:   2016-10-17T19:30:38Z

GG-11360 Fix java8 compilation.

commit 44eff48f72d2a4c5c6a9a2ba6ed903834bcb63f9
Author: Igor Sapego 
Date:   2016-10-18T08:53:46Z

IGNITE-4090: CPP: Fixed compilation for GCC 4.4.7. This closes #1165.

commit 4edcf126baf75840e3816a3e0876200c7e9c0d45
Author: vozerov-gridgain 
Date:   2016-10-18T09:25:56Z

Revert "IGNITE-3875: Added separate thread pool for data streamer. This 
closes #1067."

This reverts commit f597aff1bdf65d3d430cf85c9932391a72c2d7dc.

commit ccae52cc1af3fa2077ece6f6a9c4146e3ba72cb4
Author: tledkov-gridgain 
Date:   2016-10-18T10:01:03Z

IGNITE-2355 Fixed the test HadoopClientProtocolMultipleServersSelfTest. 
Close FileSystem after each test to prevent using the one Client delegate for 
all tests.

commit e6430bdf14e457e7497bf6e84013747f06f71fc3
Author: tledkov-gridgain 
Date:   2016-10-18T10:01:41Z

Merge remote-tracking branch 'community/ignite-1.6.10' 

[jira] [Created] (IGNITE-5670) Collect high level API calls stats

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5670:
-

 Summary: Collect high level API calls stats
 Key: IGNITE-5670
 URL: https://issues.apache.org/jira/browse/IGNITE-5670
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


# tasks sent
# jobs sent
# cahce updates sent
# queries sent
# result set size
# timings



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

[jira] [Created] (IGNITE-5669) Gather stats for communication queues sizes per node

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5669:
-

 Summary: Gather stats for communication queues sizes per node
 Key: IGNITE-5669
 URL: https://issues.apache.org/jira/browse/IGNITE-5669
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov






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

[jira] [Created] (IGNITE-5668) Gather stats for communication messages

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5668:
-

 Summary: Gather stats for communication messages
 Key: IGNITE-5668
 URL: https://issues.apache.org/jira/browse/IGNITE-5668
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


Stats should be collected for "to" and "from" messages.

# message type
# message size
# direct (de)serialization times
# processing times




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

[jira] [Created] (IGNITE-5666) Gather time statistics for user objects (de)serialization

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5666:
-

 Summary: Gather time statistics for user objects (de)serialization
 Key: IGNITE-5666
 URL: https://issues.apache.org/jira/browse/IGNITE-5666
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov






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

[jira] [Created] (IGNITE-5665) Implement histogram-like functionality to gather time stats on different operations

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5665:
-

 Summary: Implement histogram-like functionality to gather time 
stats on different operations
 Key: IGNITE-5665
 URL: https://issues.apache.org/jira/browse/IGNITE-5665
 Project: Ignite
  Issue Type: Sub-task
Reporter: Yakov Zhdanov


Idea and examples - https://github.com/HdrHistogram/HdrHistogram





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

Re: Support for starting transaction in another thread IGNITE-4887

[ALEKSEY KUZNETSOV]

So, desired behavior is the following: when some thread evaluates tx
operation's secured scope, other threads should be locked and then released
with return after first thread has finished evaluating
secured scope ?

пн, 3 июл. 2017 г. в 17:12, Yakov Zhdanov :

> Yes, feel free to file a sub-ticket.
>
> --Yakov
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-5664) Implement self-check facilities for Ignite

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5664:
-

 Summary: Implement self-check facilities for Ignite
 Key: IGNITE-5664
 URL: https://issues.apache.org/jira/browse/IGNITE-5664
 Project: Ignite
  Issue Type: Task
Reporter: Yakov Zhdanov






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

Re: JIRA Access - Ignite

[Denis Magda]

Welcome! Added you to the list.

—
Denis

> On Jul 2, 2017, at 11:11 PM, Ankur Kumar  wrote:
> 
> ankurkuma...@gmail.com is my JIRA Id. Please grant the permission.
> 
> On Tue, Jun 27, 2017 at 2:16 PM, Alexey Kuznetsov 
> wrote:
> 
>> Hi Ankur,
>> 
>> What is your JIRA ID?
>> 
>> On Tue, Jun 27, 2017 at 3:42 PM, Ankur Kumar 
>> wrote:
>> 
>>> I can access Apache Ignite but can not assign any defect to myself. Can I
>>> get permission to assign issues to myself to work on these items?
>>> 
>>> Regards,
>>> 
>>> Ankur Kumar
>>> 
>> 
>> 
>> 
>> --
>> Alexey Kuznetsov
>> 

[jira] [Created] (IGNITE-5663) ODBC: Few consecutive inserts lead to exception

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5663:
-

 Summary: ODBC: Few consecutive inserts lead to exception
 Key: IGNITE-5663
 URL: https://issues.apache.org/jira/browse/IGNITE-5663
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 1.8
Reporter: Evgenii Zhuravlev
Assignee: Igor Sapego


Exception: ('HY010', '[HY010] Query is not prepared. (0) (SQLExecDirectW)')

Reproducer in python:


{code:java}
import pyodbc
cnxn = pyodbc.connect(DRIVER='{Apache Ignite}', 
ADDRESS='localhost:10800',CACHE="Person", autocommit=True)
cursor = cnxn.cursor()
select_string= "INSERT INTO Person(_key, id, firstName, lastName, salary) 
VALUES (?, ? , 'abcd', 'dhsagd', 1000)"
id_list = (1,1)
id_list2 = (2,2)
cursor.execute(select_string, id_list) 
cursor.execute(select_string, id_list2) 
{code}

Also, the same behavior with executemany.




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

Re: Ignite Teamcity email notifications

[Denis Magda]

Dmitriy P.,

The list has been created. Here is a response from ASF:

As requested by you, the following mailing list has been created:
c...@ignite.apache.org 
Moderators: dma...@apache.org 
,dsetrak...@apache.org 
This list is private.



---

The list will start accepting mail in 60 minutes from now.  If it's a public
list, it will appear on https://lists.apache.org/  
within a few minutes of
the first post to it.

—
Denis

> On Jun 29, 2017, at 4:10 PM, Denis Magda  wrote:
> 
> Trigged the alias creation. Will let you know once it’s ready for usage.
> 
> —
> Denis
> 
>> On Jun 29, 2017, at 3:51 PM, Dmitriy Setrakyan  wrote:
>> 
>> I like this alias.
>> 
>> On Thu, Jun 29, 2017 at 3:43 PM, Denis Magda  wrote:
>> 
>>> What’s about c...@ignite.apache.org ? If 
>>> there
>>> are no objections I’ll create the alias.
>>> 
>>> —
>>> Denis
>>> 
 On Jun 29, 2017, at 11:53 AM, Dmitry Pavlov 
>>> wrote:
 
 Hi Dmitriy,
 
 At the first step we need some email address to send notifications from
 behalf of TeamCity. We need to set up SMTP server, username and password.
 Later users may set up personal notification rules ( see the link
 http://ci.ignite.apache.org/profile.html?item=userNotifications).
 
 Teamcity takes into account last commits in branch and sends
>>> notifications
 separately and only to users which may break the build (option name
>>> 'builds
 containing my changes').
 
 Best Regards,
 Dmitriy Pavlov
 
 
 чт, 29 июн. 2017 г. в 21:21, Dmitriy Setrakyan :
 
> Dmitry, I don't think ign...@apache.org is a valid email address. Why
> creating a mailing list for TC is not a good option?
> 
> On Thu, Jun 29, 2017 at 8:17 AM, Dmitry Pavlov 
> wrote:
> 
>> Hi Igniters,
>> 
>> I want to set up a email notifications from the public Teamcity about
>> broken builds. But there is no configured address and email account. To
> set
>> up notifications we need some mail box (account) to send messages from.
>> 
>> I asked the apache infrastructure team in
>> https://issues.apache.org/jira/browse/INFRA-14455
>> However, they recommended through PMC to create a mailing list. I doubt
> it
>> can solve the problem.
>> 
>> I also found out that there are e-mails from the address Ignite
>>> Teamcity
> <
>> ign...@apache.org>.
>> 
>> Can we use it? Do we know the password for this account?
>> Any thought how to solve it?
>> 
>> Best Regards,
>> Dmitriy Pavlov
>> 
> 
>>> 
>>> 
> 

[jira] [Created] (IGNITE-5662) Primary index name should contain type ID or name

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5662:


 Summary: Primary index name should contain type ID or name
 Key: IGNITE-5662
 URL: https://issues.apache.org/jira/browse/IGNITE-5662
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexey Goncharuk
 Fix For: 2.1


Currently, the primary index name contains neither type ID nor type name. Since 
metadata storage allocates tree root based on the index name, two different 
indexes will be using the same index tree.

Attached test reproduces this issue.

A correct fix would be to include type ID or type name (depends on the current 
SQL internals) to the index name.



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

Re: Custom string encoding

[Dmitriy Setrakyan]

Agree with Valya on the system-wide default. We need to have it.

Also, are we certain that the encoding will provide 1-byte length for UTF-8
for different languages? Would be nice to test it to confirm, as it has a
potential to decrease the Ignite storage space by 2x in certain cases.

D.

On Sun, Jul 2, 2017 at 12:26 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Vova,
>
> That's actually a good point. Probably that would be enough and there is no
> need to introduce absract encoder. However, I still think it makes sense to
> specify default encoding in BinaryConfiguration and
> BinaryTypeConfiguration.
>
> -Val
>
> On Sun, Jul 2, 2017 at 10:31 AM Vladimir Ozerov 
> wrote:
>
> > Yes, this is exactly what non-UTF8 encodings do.
> >
> > вс, 2 июля 2017 г. в 20:08, Dmitriy Setrakyan :
> >
> > > On Sun, Jul 2, 2017 at 9:50 AM, Vladimir Ozerov 
> > > wrote:
> > >
> > > > There is no need for custom encoders, as they are already built-in to
> > > Java.
> > > >
> > >
> > > Will non-ASCII encodings fit into 1 byte? The whole point here is to
> save
> > > space.
> > >
> > >
> > > >
> > > > вс, 2 июля 2017 г. в 19:16, Dmitriy Setrakyan  >:
> > > >
> > > > > Vladimir, how would you plugin custom encoders in your design?
> > > > >
> > > > > On Sat, Jul 1, 2017 at 11:53 PM, Vladimir Ozerov <
> > voze...@gridgain.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Valya,
> > > > > >
> > > > > > Personally I vote against this feature. BinaryConfiguration is
> > proven
> > > > to
> > > > > be
> > > > > > inconvenient, since it has to be configured before node start, it
> > > > cannot
> > > > > be
> > > > > > changed in runtime, and it requires classes on the server.
> > Moreover,
> > > if
> > > > > you
> > > > > > decide to change encoding at some point, it would be impossible.
> > > > > >
> > > > > > I think, we should add this feature on API level instead. If
> string
> > > is
> > > > > > written in non-UTF8 form, we will write in different format:
> > > > > > [encoding_code][string]
> > > > > >
> > > > > > BInaryWriter.writeString(String fieldName, String val);
> > > > > > BInaryWriter.writeString(String fieldName, String val, *String
> > > > > encoding*);
> > > > > >
> > > > > > BinaryReader.readString(String fieldName);
> > > > > > BinaryReader.readString(String fieldName, *String encoding*);
> > > > > >
> > > > > > BinaryObjectBuilder.writeString(String fieldName, String val,
> > *String
> > > > > > encoding*);
> > > > > >
> > > > > > class MyClass {
> > > > > > *@BinaryString(encoding = "Cp1251")*
> > > > > > private String myCyrillicString;
> > > > > > }
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > > > On Sat, Jul 1, 2017 at 7:26 PM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > On Sat, Jul 1, 2017 at 2:24 AM, Sergi Vladykin <
> > > > > sergi.vlady...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > In SQL indexes we may store partial strings and assume them
> to
> > be
> > > > in
> > > > > > > UTF-8,
> > > > > > > > I don't think this can be abstracted away. But may be this is
> > > not a
> > > > > big
> > > > > > > > deal if in indexes we still will use UTF-8.
> > > > > > > >
> > > > > > >
> > > > > > > Sergi, why does it matter if it is UTF8 or custom encoding? Why
> > > can't
> > > > > we
> > > > > > > use our own compact encoding in indexes?
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > 2017-07-01 10:13 GMT+03:00 Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >:
> > > > > > > >
> > > > > > > > > Val, do you know how we compare strings in SQL queries?
> Will
> > we
> > > > be
> > > > > > able
> > > > > > > > to
> > > > > > > > > use this encoder?
> > > > > > > > >
> > > > > > > > > Additionally, I think that the encoder is a bit too
> abstract.
> > > Why
> > > > > not
> > > > > > > go
> > > > > > > > > even further and allow users create their own ASCII table
> for
> > > > > > encoding?
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Fri, Jun 30, 2017 at 6:49 PM, Valentin Kulichenko <
> > > > > > > > > valentin.kuliche...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > > Andrey,
> > > > > > > > > >
> > > > > > > > > > Can you elaborate more on this? What is your concern?
> > > > > > > > > >
> > > > > > > > > > -Val
> > > > > > > > > >
> > > > > > > > > > On Fri, Jun 30, 2017 at 6:17 PM Andrey Mashenkov <
> > > > > > > > > > andrey.mashen...@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Val,
> > > > > > > > > > >
> > > > > > > > > > > Looks like make sense.
> > > > > > > > > > >
> > > > > > > > > > > This will not affect FullText index, as Lucene has own
> > > format
> > > > > for
> > > > > > > > > storing
> > > > > > > > > > > data.
> > > > > > > > > > >
> > > > > > > > > > > But.. would it be 

[jira] [Created] (IGNITE-5661) ignite.NET serialization failed when entity has property with IList and equals to null

[Chris Wang (JIRA)]

Chris Wang created IGNITE-5661:
--

 Summary: ignite.NET serialization failed when entity has property 
with IList and equals to null
 Key: IGNITE-5661
 URL: https://issues.apache.org/jira/browse/IGNITE-5661
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
 Environment: windows server 2012 x64
Reporter: Chris Wang


when using datastreamer or cache.put, insert entities into a cache, if there 
are some properties with IList type and value is null, serialization might 
failed, and no cache exists in H2 database even queryentities has been 
configured. but cache.count() return the count that inserted.
like codes below generates an empty cache in ignite h2 db:

{code:c#}

using (var dc = GetDbContext(branchId)) //dc is DbContext
{
var infoList = 
dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
&& cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property IList 
Subsidaries and value is null.

foreach (var item in infoList)
{
ds.AddData(item.PK, item);
count++;
if (count % 1000 == 0)

Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
}
ds.Flush();
}

{code}



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

[jira] [Created] (IGNITE-5660) ignite.NET serialization failed when entity has property with IList and equals to null

[Chris Wang (JIRA)]

Chris Wang created IGNITE-5660:
--

 Summary: ignite.NET serialization failed when entity has property 
with IList and equals to null
 Key: IGNITE-5660
 URL: https://issues.apache.org/jira/browse/IGNITE-5660
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
 Environment: windows server 2012 x64
Reporter: Chris Wang


when using datastreamer or cache.put, insert entities into a cache, if there 
are some properties with IList type and value is null, serialization might 
failed, and no cache exists in H2 database even queryentities has been 
configured. but cache.count() return the count that inserted.
like codes below generates an empty cache in ignite h2 db:

{code:c#}

using (var dc = GetDbContext(branchId)) //dc is DbContext
{
var infoList = 
dc.Set().AsNoTracking().Where(cust => cust.BranchID == branchId 
&& cust.DeleteFlag == 0).ToList(); //CustMainInfo has a property IList 
Subsidaries and value is null.

foreach (var item in infoList)
{
ds.AddData(item.PK, item);
count++;
if (count % 1000 == 0)

Console.WriteLine(string.Format("CustMainInfoLoader：{0}", count));
}
ds.Flush();
}

{code}



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

Re: Support for starting transaction in another thread IGNITE-4887

[ALEKSEY KUZNETSOV]

So i need to put new lock mechanism to* all* transaction operations ? If
so, don't we need additional ticket for this ?(for example sub ticket for
my original one)

пн, 3 июл. 2017 г. в 16:59, Yakov Zhdanov :

> Disagree. Currently transaction is bound to a thread and if user tries to
> pass it over to another thread this would be a contract violation.
>
> Your ticket will make inter-thread transitions allowed.
>
> --Yakov
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Support for starting transaction in another thread IGNITE-4887

[Yakov Zhdanov]

Disagree. Currently transaction is bound to a thread and if user tries to
pass it over to another thread this would be a contract violation.

Your ticket will make inter-thread transitions allowed.

--Yakov

Re: Support for starting transaction in another thread IGNITE-4887

[ALEKSEY KUZNETSOV]

It is a global scope) Now multiple threads can commit transaction and it
will lead to exception. It doesn't refer to my ticket only, but for a
current transaction implementation.

пн, 3 июл. 2017 г. в 16:53, Yakov Zhdanov :

> What separate ticket do you mean here? I think this is the scope of the
> original one.
>
> --Yakov
>
> 2017-07-03 16:39 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > I've go a test, which illustrates transaction commit fail when multiple
> > threads try to commit. As i said, it happenes in mvcc stage.
> >
> > So we should create a special lock mechanism for all transaction methods.
> > In a separate ticket.
> >
> > пн, 3 июл. 2017 г. в 16:26, Yakov Zhdanov :
> >
> >> >Consider thread *Th1* started transaction *Tx1*, done some actions, and
> >> is
> >> >calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And
> >> >concurrently thread *Th2 *is calling the same commit on* Tx1*.
> >>
> >> Alexey, this looks weird to me. IMO, if we talk about proper
> >> implementation
> >> you should detect all cases of illegal access (e.g. commit from thread
> not
> >> owning the transaction).
> >>
> >> --Yakov
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-5659) BinaryMarshaller loads class with local classloader even if it excluded in Configuration

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-5659:
---

 Summary: BinaryMarshaller loads class with local classloader even 
if it excluded in Configuration
 Key: IGNITE-5659
 URL: https://issues.apache.org/jira/browse/IGNITE-5659
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Nikolay Izhikov
Priority: Critical


Run Ignite with configuration:

Two nodes: server and client

# BinaryMarshaller
# PeerClassLoadingEnabled = true
# PeerClassLoadingLocalClassPathExclude = org.apache.ignite.test.*

Do following actions:

# put some Employee data to the server node
# run ScanQuery from client node

Error on step 2:

{noformat}
Caused by: java.lang.ClassCastException: 
org.apache.ignite.test.ignite2190.Employee cannot be cast to 
org.apache.ignite.test.ignite2190.Employee
at 
org.apache.ignite.test.ignite2190.EmployeePredicate.apply(EmployeePredicate.java:8)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.advance(GridCacheQueryManager.java:3000)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$PeekValueExpiryAwareIterator.onHasNext(GridCacheQueryManager.java:2923)
at 
org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
at 
org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.runQuery(GridCacheQueryManager.java:1188)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager.processQueryRequest(GridCacheDistributedQueryManager.java:231)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:109)
at 
org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$2.apply(GridCacheDistributedQueryManager.java:107)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1020)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:541)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:359)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:296)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:104)
at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:286)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1097)
... 3 more
{noformat}



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

Re: Support for starting transaction in another thread IGNITE-4887

[Yakov Zhdanov]

What separate ticket do you mean here? I think this is the scope of the
original one.

--Yakov

2017-07-03 16:39 GMT+03:00 ALEKSEY KUZNETSOV :

> I've go a test, which illustrates transaction commit fail when multiple
> threads try to commit. As i said, it happenes in mvcc stage.
>
> So we should create a special lock mechanism for all transaction methods.
> In a separate ticket.
>
> пн, 3 июл. 2017 г. в 16:26, Yakov Zhdanov :
>
>> >Consider thread *Th1* started transaction *Tx1*, done some actions, and
>> is
>> >calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And
>> >concurrently thread *Th2 *is calling the same commit on* Tx1*.
>>
>> Alexey, this looks weird to me. IMO, if we talk about proper
>> implementation
>> you should detect all cases of illegal access (e.g. commit from thread not
>> owning the transaction).
>>
>> --Yakov
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>

Re: Support for starting transaction in another thread IGNITE-4887

[ALEKSEY KUZNETSOV]

I've go a test, which illustrates transaction commit fail when multiple
threads try to commit. As i said, it happenes in mvcc stage.

So we should create a special lock mechanism for all transaction methods.
In a separate ticket.

пн, 3 июл. 2017 г. в 16:26, Yakov Zhdanov :

> >Consider thread *Th1* started transaction *Tx1*, done some actions, and is
> >calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And
> >concurrently thread *Th2 *is calling the same commit on* Tx1*.
>
> Alexey, this looks weird to me. IMO, if we talk about proper implementation
> you should detect all cases of illegal access (e.g. commit from thread not
> owning the transaction).
>
> --Yakov
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Support for starting transaction in another thread IGNITE-4887

[Yakov Zhdanov]

>Consider thread *Th1* started transaction *Tx1*, done some actions, and is
>calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And
>concurrently thread *Th2 *is calling the same commit on* Tx1*.

Alexey, this looks weird to me. IMO, if we talk about proper implementation
you should detect all cases of illegal access (e.g. commit from thread not
owning the transaction).

--Yakov

Re: Support for starting transaction in another thread IGNITE-4887

[ALEKSEY KUZNETSOV]

Lock is put by cache adapter. Now its clear

пн, 3 июл. 2017 г. в 15:14, ALEKSEY KUZNETSOV :

> Consider thread *Th1* started transaction *Tx1*, done some actions, and
> is calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And
> concurrently thread *Th2 *is calling the same commit on* Tx1*. Now, if
> you look into code :
>
> public IgniteInternalFuture commitNearTxLocalAsync() {
> if (log.isDebugEnabled())
> log.debug("Committing near local tx: " + this);
>
> if (fastFinish()) {
> state(PREPARING);
> state(PREPARED);
> state(COMMITTING);
>
> cctx.tm().fastFinishTx(this, true);
>
> state(COMMITTED);
>
> return new GridFinishedFuture<>((IgniteInternalTx)this);
> }
>
> final IgniteInternalFuture prepareFut = prepareNearTxLocal();//1
>
> GridNearTxFinishFuture fut = commitFut;
>
> if (fut == null &&
> !COMMIT_FUT_UPD.compareAndSet(this, null, fut = new 
> GridNearTxFinishFuture<>(cctx, this, true)))
> return commitFut;//2
>
> cctx.mvcc().addFuture(fut, fut.futureId());//3
>
> Both threads would end up on //1 .Then.
> *Th1 *would create *commitFut* in //2 and add it to mvcc //3
> *Th2 *concurrently would evaluate //2 into true(it sees fut not null now)
> and put fut into mvcc //3 which would lead to exception.
>
> So, there is no locking sections (mutex) here
>
> -- Forwarded message -
> From: Yakov Zhdanov 
> Date: пн, 3 июл. 2017 г. в 14:16
> Subject: Re: Support for starting transaction in another thread IGNITE-4887
> To: ALEKSEY KUZNETSOV 
>
>
> Alex, what do you mean by "multiple threads committing?". Transaction
> should be committed only by one thread and only once.
>
> Can you please provide a test or a code snippet to demonstrate the issue
> you mentioned.
>
>
> --Yakov
>
>
>
>
> Im looking into current implementation of commitNearTxLocalAsync() , and
> in case of multiple concurrent threads committing there would be exception
> thrown by
>
> cctx.mvcc().addFuture(fut, fut.futureId());
>
> Is it correct behavior ?
>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

abbrevation rules plugin

[ALEKSEY KUZNETSOV]

Igntrs!
There is a plugin , mentioned  in Abbreviation Rules
 page
that performs on-the-fly check.Is somebody going to add it some day?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: distributed transaction of non-single coordinator

[ALEKSEY KUZNETSOV]

Yakov, I have couple of questions regarding tests proposal.Thx

пт, 30 июн. 2017 г. в 19:17, ALEKSEY KUZNETSOV :

> Thanks! Do you think all test scenarios results, presented in table(in
> ticket comments) , are acceptable ?
>
> пт, 30 июн. 2017 г., 18:28 Yakov Zhdanov :
>
>> Alex, I have commented in the ticket. Please take a look.
>>
>> Thanks!
>> --
>> Yakov Zhdanov, Director R
>> *GridGain Systems*
>> www.gridgain.com
>>
>> 2017-06-29 17:27 GMT+03:00 ALEKSEY KUZNETSOV :
>>
>> > I've attached HangTest. I suppose it should not hang, am i right ?
>> >
>> > чт, 29 июн. 2017 г. в 14:54, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>:
>> >
>> > > Igntrs.
>> > > Im rewieving all usages of threadId of
>> > > transaction.(IgniteTxAdapter#threadID). What is the point of usage
>> > threadId
>> > > in mvcc entry ?
>> > >
>> > > пн, 3 апр. 2017 г. в 9:47, ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>:
>> > >
>> > >> so what do u think on my idea?
>> > >>
>> > >> пт, 31 Мар 2017 г., 11:05 ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com>:
>> > >>
>> > >>> sorry for misleading you. We planned to support multi-node
>> > transactions,
>> > >>> but failed.
>> > >>>
>> > >>> пт, 31 мар. 2017 г. в 10:51, Alexey Goncharuk <
>> > >>> alexey.goncha...@gmail.com>:
>> > >>>
>> > >>> Well, now the scenario is more clear, but it has nothing to do with
>> > >>> multiple coordinators :) Let me think a little bit about it.
>> > >>>
>> > >>> 2017-03-31 9:53 GMT+03:00 ALEKSEY KUZNETSOV <
>> alkuznetsov...@gmail.com
>> > >:
>> > >>>
>> > >>> > so what do u think on the issue ?
>> > >>> >
>> > >>> > чт, 30 Мар 2017 г., 17:49 ALEKSEY KUZNETSOV <
>> > alkuznetsov...@gmail.com
>> > >>> >:
>> > >>> >
>> > >>> > > Hi ! Thanks for help. I've created ticket :
>> > >>> > > https://issues.apache.org/jira/browse/IGNITE-4887
>> > >>> > > and a commit :
>> > >>> > >
>> > >>>
>> https://github.com/voipp/ignite/commit/aa3487bd9c203394f534c605f84e06
>> > >>> > 436b638e5c
>> > >>> > > We really need this feature
>> > >>> > >
>> > >>> > > чт, 30 мар. 2017 г. в 11:31, Alexey Goncharuk <
>> > >>> > alexey.goncha...@gmail.com
>> > >>> > > >:
>> > >>> > >
>> > >>> > > Aleksey,
>> > >>> > >
>> > >>> > > I doubt your approach works as expected. Current transaction
>> > recovery
>> > >>> > > protocol heavily relies on the originating node ID in its
>> internal
>> > >>> logic.
>> > >>> > > For example, currently a transaction will be rolled back if you
>> > want
>> > >>> to
>> > >>> > > transfer a transaction ownership to another node and original tx
>> > >>> owner
>> > >>> > > fails. An attempt to commit such a transaction on another node
>> may
>> > >>> fail
>> > >>> > > with all sorts of assertions. After transaction ownership
>> changed,
>> > >>> you
>> > >>> > need
>> > >>> > > to notify all current transaction participants about this
>> change,
>> > >>> and it
>> > >>> > > should also be done failover-safe, let alone that you did not
>> add
>> > any
>> > >>> > tests
>> > >>> > > for these cases.
>> > >>> > >
>> > >>> > > I back Denis here. Please create a ticket first and come up with
>> > >>> clear
>> > >>> > > use-cases, API and protocol changes design. It is hard to reason
>> > >>> about
>> > >>> > the
>> > >>> > > changes you've made when we do not even understand why you are
>> > making
>> > >>> > these
>> > >>> > > changes and how they are supposed to work.
>> > >>> > >
>> > >>> > > --AG
>> > >>> > >
>> > >>> > > 2017-03-30 10:43 GMT+03:00 ALEKSEY KUZNETSOV <
>> > >>> alkuznetsov...@gmail.com>:
>> > >>> > >
>> > >>> > > > So, what do u think on my idea ?
>> > >>> > > >
>> > >>> > > > ср, 29 мар. 2017 г. в 10:35, ALEKSEY KUZNETSOV <
>> > >>> > alkuznetsov...@gmail.com
>> > >>> > > >:
>> > >>> > > >
>> > >>> > > > > Hi! No, i dont have ticket for this.
>> > >>> > > > > In the ticket i have implemented methods that change
>> > transaction
>> > >>> > status
>> > >>> > > > to
>> > >>> > > > > STOP, thus letting it to commit transaction in another
>> thread.
>> > In
>> > >>> > > another
>> > >>> > > > > thread you r going to restart transaction in order to commit
>> > it.
>> > >>> > > > > The mechanism behind it is obvious : we change thread id to
>> > >>> newer one
>> > >>> > > in
>> > >>> > > > > ThreadMap, and make use of serialization of txState,
>> > transactions
>> > >>> > > itself
>> > >>> > > > to
>> > >>> > > > > transfer them into another thread.
>> > >>> > > > >
>> > >>> > > > >
>> > >>> > > > > вт, 28 мар. 2017 г. в 20:15, Denis Magda > >:
>> > >>> > > > >
>> > >>> > > > > Aleksey,
>> > >>> > > > >
>> > >>> > > > > Do you have a ticket for this? Could you briefly list what
>> > >>> exactly
>> > >>> > was
>> > >>> > > > > done and how the things work.
>> > >>> > > > >
>> > >>> > > > > —
>> > >>> > > > > Denis
>> > >>> > > > >
>> > >>> > > > > > On Mar 28, 2017, at 8:32 AM, ALEKSEY KUZNETSOV <
>> > >>> > > > alkuznetsov...@gmail.com>
>> > >>> > > 

Support for starting transaction in another thread IGNITE-4887

[ALEKSEY KUZNETSOV]

Consider thread *Th1* started transaction *Tx1*, done some actions, and is
calling commit (GridNearTxLocal#commit -> commitNearTxLocalAsync). And
concurrently thread *Th2 *is calling the same commit on* Tx1*. Now, if you
look into code :

public IgniteInternalFuture commitNearTxLocalAsync() {
if (log.isDebugEnabled())
log.debug("Committing near local tx: " + this);

if (fastFinish()) {
state(PREPARING);
state(PREPARED);
state(COMMITTING);

cctx.tm().fastFinishTx(this, true);

state(COMMITTED);

return new GridFinishedFuture<>((IgniteInternalTx)this);
}

final IgniteInternalFuture prepareFut = prepareNearTxLocal();//1

GridNearTxFinishFuture fut = commitFut;

if (fut == null &&
!COMMIT_FUT_UPD.compareAndSet(this, null, fut = new
GridNearTxFinishFuture<>(cctx, this, true)))
return commitFut;//2

cctx.mvcc().addFuture(fut, fut.futureId());//3

Both threads would end up on //1 .Then.
*Th1 *would create *commitFut* in //2 and add it to mvcc //3
*Th2 *concurrently would evaluate //2 into true(it sees fut not null now)
and put fut into mvcc //3 which would lead to exception.

So, there is no locking sections (mutex) here

-- Forwarded message -
From: Yakov Zhdanov 
Date: пн, 3 июл. 2017 г. в 14:16
Subject: Re: Support for starting transaction in another thread IGNITE-4887
To: ALEKSEY KUZNETSOV 


Alex, what do you mean by "multiple threads committing?". Transaction
should be committed only by one thread and only once.

Can you please provide a test or a code snippet to demonstrate the issue
you mentioned.


--Yakov




Im looking into current implementation of commitNearTxLocalAsync() , and in
case of multiple concurrent threads committing there would be exception
thrown by

cctx.mvcc().addFuture(fut, fut.futureId());

Is it correct behavior ?

-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-5658) Optimizations for data streamer

[Yakov Zhdanov (JIRA)]

Yakov Zhdanov created IGNITE-5658:
-

 Summary: Optimizations for data streamer
 Key: IGNITE-5658
 URL: https://issues.apache.org/jira/browse/IGNITE-5658
 Project: Ignite
  Issue Type: Improvement
Reporter: Yakov Zhdanov


Data streamer can be improved with this:
-batch on per-partition basis and send batches to striped pool
-New default - perNodeParallelOps should be twice CPU count of a remote node 
(if not set by user, if set then parallelOps for every node is the value 
provided by user)
-wait stable topology error should be output as warn




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

[jira] [Created] (IGNITE-5657) Web Console: add apropriate placeholder in case if no columns are selected in table

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-5657:
--

 Summary: Web Console: add apropriate placeholder in case if no 
columns are selected in table
 Key: IGNITE-5657
 URL: https://issues.apache.org/jira/browse/IGNITE-5657
 Project: Ignite
  Issue Type: Bug
  Components: UI
Reporter: Pavel Konstantinov






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

Re: Zookeeper Discovery SPI & external IP address in AWS

[Yakov Zhdanov]

My point is that communication SPI should put both address types to its
attributes to share - private and addresses processed by a resolver.

--Yakov

Re: IGNITE-4901 (Decrease logging level for DataStremer retry)

[Yakov Zhdanov]

Alexey,

To be more exact Ignite should fail the update only if affinity mapping
changes and only for the case when allowOverwrite is false. Please share
the PR and we will review it.

--Yakov

[GitHub] ignite pull request #2223: Ignite gg 4901

[kukushal]

GitHub user kukushal opened a pull request:

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

Ignite gg 4901



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

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

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

https://github.com/apache/ignite/pull/2223.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #2223


commit a2b4751f5eefd70a5a1aa26652c9671240125f78
Author: dkarachentsev 
Date:   2017-03-17T11:57:48Z

IGNITE-4473 - Client should re-try connection attempt in case of concurrent 
network failure.

(cherry picked from commit d124004)

commit c4de164392ddc114c88d5a6eba0ff0b13d32542f
Author: AMRepo 
Date:   2017-03-20T13:31:15Z

IGNITE-518: Unmuted tests that was fixed in ignite-4036. This closes #1636.

commit e0c012d977b6db13dfdf2fb8347677998287c1e4
Author: Igor Sapego 
Date:   2017-03-21T14:50:06Z

IGNITE-4200: Added copying of the C++ binaries.

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

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

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

Fixed SSL issue.

Signed-off-by: nikolay_tikhonov 

commit ead9f2a595b91821b1b16627dd8d752897c24c03
Author: dkarachentsev 
Date:   2017-04-03T11:46:54Z

Merge branch 'ignite-1.8.4-p1' into ignite-1.8.6

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 925ee11c2002729b1264148ee5db5700ded5a7b7
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:06:01Z

Fixed typo.
(cherry picked from commit 3b84f34)

commit ce4b078c1c97cae4136c318ae38b27a50fe383cc
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:14:56Z

master Updated version.
(cherry picked from commit 5469626)

commit b7ab27301b59bf93fc73b52fdf8e0bcf124fec1d
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

commit b214211eb3461746b6931c0623e086bb208e5dda
Author: Anton Vinogradov 
Date:   2017-04-06T12:00:12Z

IGNITE-4644 Value from IgniteQueue in atomic mode could be lost

commit 014161427fb603b6df7c8ecc3c0904f5df47a21d
Author: Denis Magda 
Date:   2017-02-14T01:33:32Z

IGNITE-4159: Kubernetes IP finder.
(cherry picked from commit 37c0a22)

commit 1db238402f11c67d2b28bfb7ff47955415f00c25
Author: Denis Magda 
Date:   2017-02-16T04:37:26Z

IGNITE-4159: fixing logging
(cherry picked from commit 06908d2)
(cherry picked from commit fa27ee3)

commit 5dfe16f7e91374008b9f6dfbb899364f5b2e1164
Author: Denis Magda 
Date:   2017-02-14T06:03:30Z

IGNITE-4159: using logger instead of system.out.println
(cherry picked from commit b9bf77c)

commit 6e596d1ef426b66abd866d011a8f5cf5c5c25124
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

(cherry picked from commit b7ab273)

commit 443ac9a7aa82af1359a03bcfc8f9212b108300e4
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

commit 05f3c747921aed6838804d2f5f2c8d2bd7985337
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

(cherry picked from commit 443ac9a)

commit 3d616799efb472227b3b313516e6b40729654631
Author: dkarachentsev 
Date:   2017-04-10T07:36:11Z

IGNITE-2466 - Use current NIO back pressure mechanism to limit received 
messages. Mark them process only when backups acknowledged.

(backport from 1.9.2)

(cherry picked from commit 220db882b466c03eadd148b3a19a0bf70d82d4a6)

commit 2a88a7a7581465ff0a6f8733550e6d42d7f71a6c
Author: dkarachentsev 
Date:   2017-04-10T07:54:37Z

IGNITE-4667 - Throw exception on starting client cache when indexed types 
cannot be loaded

commit ba6227be49c8a395a5632e9841a6acb65ae340b6
Author: dkarachentsev 
Date:   

[GitHub] ignite pull request #2204: IGNITE-5279

[alexpaschenko]

Github user alexpaschenko closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [Review] IGNITE-4648: IgniteInternalTx.prepare() does not wait for async operations to complete

[Дмитрий Рябов]

I added test as Yakov said, here is CI
only test method added, without bugfix:
http://ci.ignite.apache.org/viewLog.html?buildId=694784=Ignite20Tests_RunAll=buildResultsDiv
and with bugfix:
http://ci.ignite.apache.org/viewLog.html?buildId=695030=Ignite20Tests_RunAll=buildResultsDiv

2017-05-03 13:04 GMT+03:00 Дмитрий Рябов :

> Hello, igniters, please review.
>
> JIRA: https://issues.apache.org/jira/browse/IGNITE-4648
>
> PR: https://github.com/apache/ignite/pull/1876/files
>
> CI: http://ci.ignite.apache.org/viewLog.html?buildId=
> 590583=buildResultsDiv=IgniteTests_RunAllTemp
>

[GitHub] ignite pull request #2222: Ignite gg 4901

[kukushal]

Github user kukushal closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request #2222: Ignite gg 4901

[kukushal]

GitHub user kukushal opened a pull request:

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

Ignite gg 4901



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

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

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

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

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #


commit a2b4751f5eefd70a5a1aa26652c9671240125f78
Author: dkarachentsev 
Date:   2017-03-17T11:57:48Z

IGNITE-4473 - Client should re-try connection attempt in case of concurrent 
network failure.

(cherry picked from commit d124004)

commit c4de164392ddc114c88d5a6eba0ff0b13d32542f
Author: AMRepo 
Date:   2017-03-20T13:31:15Z

IGNITE-518: Unmuted tests that was fixed in ignite-4036. This closes #1636.

commit e0c012d977b6db13dfdf2fb8347677998287c1e4
Author: Igor Sapego 
Date:   2017-03-21T14:50:06Z

IGNITE-4200: Added copying of the C++ binaries.

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

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

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

Fixed SSL issue.

Signed-off-by: nikolay_tikhonov 

commit ead9f2a595b91821b1b16627dd8d752897c24c03
Author: dkarachentsev 
Date:   2017-04-03T11:46:54Z

Merge branch 'ignite-1.8.4-p1' into ignite-1.8.6

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java

commit 925ee11c2002729b1264148ee5db5700ded5a7b7
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:06:01Z

Fixed typo.
(cherry picked from commit 3b84f34)

commit ce4b078c1c97cae4136c318ae38b27a50fe383cc
Author: Alexey Kuznetsov 
Date:   2017-04-04T09:14:56Z

master Updated version.
(cherry picked from commit 5469626)

commit b7ab27301b59bf93fc73b52fdf8e0bcf124fec1d
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

commit b214211eb3461746b6931c0623e086bb208e5dda
Author: Anton Vinogradov 
Date:   2017-04-06T12:00:12Z

IGNITE-4644 Value from IgniteQueue in atomic mode could be lost

commit 014161427fb603b6df7c8ecc3c0904f5df47a21d
Author: Denis Magda 
Date:   2017-02-14T01:33:32Z

IGNITE-4159: Kubernetes IP finder.
(cherry picked from commit 37c0a22)

commit 1db238402f11c67d2b28bfb7ff47955415f00c25
Author: Denis Magda 
Date:   2017-02-16T04:37:26Z

IGNITE-4159: fixing logging
(cherry picked from commit 06908d2)
(cherry picked from commit fa27ee3)

commit 5dfe16f7e91374008b9f6dfbb899364f5b2e1164
Author: Denis Magda 
Date:   2017-02-14T06:03:30Z

IGNITE-4159: using logger instead of system.out.println
(cherry picked from commit b9bf77c)

commit 6e596d1ef426b66abd866d011a8f5cf5c5c25124
Author: Andrey V. Mashenkov 
Date:   2017-04-06T11:43:50Z

IGNITE-4832: Prevent service deployment on client by default when 
configuration is provided on startup. This closes #1748.

(cherry picked from commit b7ab273)

commit 443ac9a7aa82af1359a03bcfc8f9212b108300e4
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

commit 05f3c747921aed6838804d2f5f2c8d2bd7985337
Author: Andrey V. Mashenkov 
Date:   2017-04-05T12:01:02Z

IGNITE-4917: Fixed failure when accessing BinaryObjectBuilder field value 
serialized with OptimizedMarshaller . This closes #1736.

(cherry picked from commit 443ac9a)

commit 3d616799efb472227b3b313516e6b40729654631
Author: dkarachentsev 
Date:   2017-04-10T07:36:11Z

IGNITE-2466 - Use current NIO back pressure mechanism to limit received 
messages. Mark them process only when backups acknowledged.

(backport from 1.9.2)

(cherry picked from commit 220db882b466c03eadd148b3a19a0bf70d82d4a6)

commit 2a88a7a7581465ff0a6f8733550e6d42d7f71a6c
Author: dkarachentsev 
Date:   2017-04-10T07:54:37Z

IGNITE-4667 - Throw exception on starting client cache when indexed types 
cannot be loaded

commit ba6227be49c8a395a5632e9841a6acb65ae340b6
Author: dkarachentsev 
Date:   

Re: JIRA Access - Ignite

[Ankur Kumar]

ankurkuma...@gmail.com is my JIRA Id. Please grant the permission.

On Tue, Jun 27, 2017 at 2:16 PM, Alexey Kuznetsov 
wrote:

> Hi Ankur,
>
> What is your JIRA ID?
>
> On Tue, Jun 27, 2017 at 3:42 PM, Ankur Kumar 
> wrote:
>
> > I can access Apache Ignite but can not assign any defect to myself. Can I
> > get permission to assign issues to myself to work on these items?
> >
> > Regards,
> >
> > Ankur Kumar
> >
>
>
>
> --
> Alexey Kuznetsov
>