Re: DiscoverySpi based on Apache ZooKeeper

[Semyon Boikov]

Dmitriy, no problem, I'll rename it.

Semyon

On Tue, Jan 9, 2018 at 11:20 PM, Dmitriy Setrakyan 
wrote:

> Thanks Semyon!
>
> I have a naming nitpick. Can we rename Problem to Failure, e.g.
> CommunicationProblemResolver to CommunicationFailureResolver?
>
> D.
>
> On Tue, Jan 9, 2018 at 3:39 AM, Semyon Boikov  wrote:
>
> > Hi all,
> >
> > Currently I'm working on implementation of DiscoverySpi based on Apache
> > ZooKeeper (ZookeeperDiscoverySpi) and want to share results of this work.
> >
> > In very large clusters (>1000 nodes) current default implementation of
> > DiscoverySpi - TcpDiscoverySpi - has some significant drawbacks:
> > - TcpDiscoverySpi organizes nodes in ring, and all messages are passed
> > sequentially via ring. More nodes there are in ring, more time it takes
> to
> > pass message. In very large clusters such architecture can cause slowdown
> > of important operations (node join, node stop, cache start, etc).
> > - in TcpDiscoverySpi's protocol each node in ring is able to fail next
> one
> > in case of network issues, and it is possible that two nodes can 'kill'
> > each other (it is possible in complex scenarios when network is broken
> and
> > then restored back after some time, such problems were observed in real
> > environments), and with current TcpDiscoverySpi protocol there is no easy
> > way to completely fix such problems.
> > - when some node in ring fails, then previous node tries to restore ring
> > and sequentially tries to connect to next nodes. If large part of ring
> > fails then it takes long time to sequentially detect failure of all
> nodes.
> > - with TcpDiscoverySpi split brain is possible (one ring can split into
> two
> > independent parts), separate mechanism is needed to protect from split
> > brain when TcpDiscoverySpi is used
> >
> > Even though most probably some of these problems can be somehow fixed in
> > TcpDiscoverySpi, it seems more robust and fast DiscoverySpi can be
> > implemented on top of some existing coordination service.
> >
> > Apache ZooKeeper is known reliable service and it provides all mechanisms
> > and consistency guarantees required for Ignite's DiscoverySpi. Some
> > technical details of ZookeeperDiscoverySpi implementation can be found in
> > description prepared by Sergey Puchnin:
> > https://cwiki.apache.org/confluence/display/IGNITE/
> > Discovery+SPI+by+ZooKeeper
> > .
> >
> > In our preliminary tests we were able to successfully start 4000+ nodes
> > with ZookeeperDiscoverySpi. New implementation works faster than
> > TcpDiscoverySpi and does not have mentioned TcpDiscoverySpi's drawbacks:
> > - nodes alive status is controlled by ZooKeeper, so nodes never can kill
> > each other
> > - ZooKeeper has protection from split brain
> > - with ZooKeeper it is possible to detect nodes join/failures in batches
> so
> > time to detect join/failure of 1 vs 100+ nodes is almost the same
> >
> > I'm going to finalize implementation of ZookeeperDiscoverySpi in next few
> > days. But in Ignite there is one more issue caused by the fact that
> > DiscoverySpi and CommunicationSpi are two independent component: it is
> > possible that DiscoverySpi considers some node as alive, but at the same
> > time CommunicationSpi is not able to send message to this node (this
> issue
> > exists not only for ZookeeperDiscoverySpi for but for TcpDiscoverySpi
> too).
> > Such case is very critical since all internal Ignite's code assumes that
> if
> > node is alive then CommunicationSpi is able to send/receive messages
> > to/from this node. If it is not the case, then any Ignite operation can
> > hang (with ZooKeeper such situation is possible when due to network
> > failures nodes have connection with ZooKeeper, but can not establish TCP
> > connection to each other).
> >
> > If such case arises, then Ignite should have some mechanism to forcibly
> > kill faulty nodes to keep cluster operational. But note that in case of
> > 'split brain' scenarios each independent part of cluster will consider
> > others as 'failed' and there should be some way to choose which part
> should
> > be killed. It would be good to provide generic solution for this problem
> as
> > part of work on new DiscoverySpi.
> >
> > We discussed this with Yakov Zhdanov and suggest following: in case when
> > communication fails to send message to some node and this node is
> > considered as alive, then Ignite should trigger global 'communication
> error
> > resolve' process (obviously, this process should use for messaging
> internal
> > discovery mechanisms). As part of this process CommunicationSpi on each
> > node should try to establish connection to all others alive nodes
> > (TcpCommunicationSpi can do this efficiently using async NIO) and send
> > results of this connection test to some coordinator node (e.g. oldest
> > cluster node). When coordinator receives results of connection test from
> > all nodes it calls user-defined CommunicationProblemResolver to choose
> > which nodes s

Re: DiscoverySpi based on Apache ZooKeeper

[Vladimir Ozerov]

Hi Andrey,

Could you please share detail of this API mismatch? AFAIK, the main
guarantee we need for disco SPI is total message ordering. Zookeeper
provides this guarantee. Moreover, Zookeeper is proven to be correct and
reliable coordinator service by many users and Jepsen tests, as opposed to
various in-house implementations (e.g. Zen of Elasticsearch).

вт, 9 янв. 2018 г. в 21:53, Andrey Kornev :

> Semyon,
>
> Not to discourage you or anything, just a interesting fact from recent
> history.
>
> I vaguely remember already trying to implement DiscoverySpi on top of
> Zookeeper back in 2012. After a few failed attempts and a lot of help from
> Zookeeper's original developers (Flavio Junqueira and Ben Reed) we (Dmitriy
> S. and I) concluded that its not possible to  implement DiscoverySpi on top
> of Zookeeper due to strict(er) semantics of DiscoverySpi. Unfortunately I
> do not remember details, but essentially, in some cases it was not possible
> to establish total ordering of watcher events and under certain
> circumstances loss of such events was possible.
>
> It's not to say that Zookeeper can't be used to implement the cluster
> membership tracking in general. The problem is rather with DiscoverySpi
> semantics that require a different set of APIs than what Zookeeper provides.
>
> Regards
> Andrey
>
> 
> From: Semyon Boikov 
> Sent: Tuesday, January 9, 2018 3:39 AM
> To: dev@ignite.apache.org
> Subject: DiscoverySpi based on Apache ZooKeeper
>
> Hi all,
>
> Currently I'm working on implementation of DiscoverySpi based on Apache
> ZooKeeper (ZookeeperDiscoverySpi) and want to share results of this work.
>
> In very large clusters (>1000 nodes) current default implementation of
> DiscoverySpi - TcpDiscoverySpi - has some significant drawbacks:
> - TcpDiscoverySpi organizes nodes in ring, and all messages are passed
> sequentially via ring. More nodes there are in ring, more time it takes to
> pass message. In very large clusters such architecture can cause slowdown
> of important operations (node join, node stop, cache start, etc).
> - in TcpDiscoverySpi's protocol each node in ring is able to fail next one
> in case of network issues, and it is possible that two nodes can 'kill'
> each other (it is possible in complex scenarios when network is broken and
> then restored back after some time, such problems were observed in real
> environments), and with current TcpDiscoverySpi protocol there is no easy
> way to completely fix such problems.
> - when some node in ring fails, then previous node tries to restore ring
> and sequentially tries to connect to next nodes. If large part of ring
> fails then it takes long time to sequentially detect failure of all nodes.
> - with TcpDiscoverySpi split brain is possible (one ring can split into two
> independent parts), separate mechanism is needed to protect from split
> brain when TcpDiscoverySpi is used
>
> Even though most probably some of these problems can be somehow fixed in
> TcpDiscoverySpi, it seems more robust and fast DiscoverySpi can be
> implemented on top of some existing coordination service.
>
> Apache ZooKeeper is known reliable service and it provides all mechanisms
> and consistency guarantees required for Ignite's DiscoverySpi. Some
> technical details of ZookeeperDiscoverySpi implementation can be found in
> description prepared by Sergey Puchnin:
>
> https://cwiki.apache.org/confluence/display/IGNITE/Discovery+SPI+by+ZooKeeper
> .
>
> In our preliminary tests we were able to successfully start 4000+ nodes
> with ZookeeperDiscoverySpi. New implementation works faster than
> TcpDiscoverySpi and does not have mentioned TcpDiscoverySpi's drawbacks:
> - nodes alive status is controlled by ZooKeeper, so nodes never can kill
> each other
> - ZooKeeper has protection from split brain
> - with ZooKeeper it is possible to detect nodes join/failures in batches so
> time to detect join/failure of 1 vs 100+ nodes is almost the same
>
> I'm going to finalize implementation of ZookeeperDiscoverySpi in next few
> days. But in Ignite there is one more issue caused by the fact that
> DiscoverySpi and CommunicationSpi are two independent component: it is
> possible that DiscoverySpi considers some node as alive, but at the same
> time CommunicationSpi is not able to send message to this node (this issue
> exists not only for ZookeeperDiscoverySpi for but for TcpDiscoverySpi too).
> Such case is very critical since all internal Ignite's code assumes that if
> node is alive then CommunicationSpi is able to send/receive messages
> to/from this node. If it is not the case, then any Ignite operation can
> hang (with ZooKeeper such situation is possible when due to network
> failures nodes have connection with ZooKeeper, but can not establish TCP
> connection to each other).
>
> If such case arises, then Ignite should have some mechanism to forcibly
> kill faulty nodes to keep cluster operational. But note that in case of
> 'split b

RE: IGNITE-6853: Cassandra cache store does not clean prepared statements cache when remove old cassandra session

[Jason Man, CLSA]

Hi Ignor,

Would you please help review my patch to see if it is ok.  I'm hoping to 
include this in 2.4.

Thanks
Jason

-Original Message-
From: Denis Magda [mailto:dma...@apache.org] 
Sent: Thursday, December 21, 2017 2:15 PM
To: dev@ignite.apache.org; Igor Rudyak
Subject: Re: IGNITE-6853: Cassandra cache store does not clean prepared 
statements cache when remove old cassandra session

Hi Jason,

Thanks for fixing the bug! Please assign the ticket on yourself, move it to 
“PATCH AVAILABLE” state and run Cassandra specific tests on TeamCity. More on 
this can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-SubmittingforReview
 


Igor Rudyak (copied) is a main maintainer. Igor, would you mind checking the 
patch and explain how to test the integration on TeamCity (if needed)?

—
Denis

> On Dec 20, 2017, at 10:08 PM, Jason Man, CLSA  wrote:
> 
> Hi Igniters,
> 
> I've got a PR to resolve this JIRA available:
> 
> https://issues.apache.org/jira/browse/IGNITE-6853
> https://github.com/apache/ignite/pull/3088
> 
> The JIRA was tagged previously with fix version = 2.4
> 
> May I know what is the process to move things forward?  (The PR has been 
> created 3 weeks ago).  I'm hoping this fix would be included in 2.4 release. 
> 
> Thanks.
> Jason  
> The content of this communication is intended for the recipient and is 
> subject to CLSA Legal and Regulatory Notices.
> These can be viewed at https://www.clsa.com/disclaimer.html or sent to you 
> upon request.
> CLSA is ISO14001 certified and committed to reducing environmental impact.

The content of this communication is intended for the recipient and is subject 
to CLSA Legal and Regulatory Notices.
These can be viewed at https://www.clsa.com/disclaimer.html or sent to you upon 
request.
Please consider before printing. CLSA is ISO14001 certified and committed to 
reducing its impact on the environment.

Re: Ignite logs adoption for enterprise grade monitoring tools

[Vladimir Ozerov]

Single Number is easier to manage than prefix + number

ср, 10 янв. 2018 г. в 10:13, Sergey Kosarev :

> Hi,
> Why Event ID should be a number?
> Maybe better to  split main subsystems by prefixes?
> something like
> Networking: IGN-NET
> Persistence: IGN-PERS
> etc.
>
> Sergey Kosarev
>
> > On 10 Jan 2018, at 03:49, Denis Magda  wrote:
> >
> > Igniters,
> >
> > As a preface, Alexey Kukushkin laid out an insightful and profound
> explanation on what’s wrong with Ignite logs from a DevOps perspective, how
> the community can easily tackle the gaps and how our efforts will be payed
> off if we take his advice in consideration:
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-not-friendly-for-Monitoring-td20802.html
> >
> > In short, Ignite log events (errors, warnings and non-severe messages)
> are not assigned unique identifiers.
> > Why a mature project like Ignite needs it?
> >
> > First, to have a human-friendly glossary of error messages or warnings
> (see MySQL [1] and MongoDB [2] examples) that simplify troubleshooting and
> debugging on the dev side. Actually we planned to do it back in 2016! [3]
> >
> > Second, turns out to be that popular DevOps monitoring tools such as
> DynaTrace [4] and Nagios [5] can easily analyze IDs of log events and help
> automate their processing or trigger notifications. For instance, if “node
> left” log message was labeled with an ID then DynaTrace could detect that
> event and by looking at overall memory usage (JMX) decide what to do next -
> just send an email to an admin or add a new node to the cluster.
> >
> > My proposal is to start putting the glossary together making Ignite
> ready for enterprise grade monitoring systems and DevOps!
> >
> > As a first step, let’s define subsystems of Ignite spreading out IDs
> ranges among them:
> > - networking (discovery, communication) - 1000 - 3000
> > - memory and persistence - 4000 - 6000
> > - key-value, caching - 7000 - 9000
> > - SQL - 1 - 11000
> > - etc.
> >
> > Is everyone with this format and overall endeavor?
> >
> > [1] https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
> > [2]
> https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.err
> > [3] https://issues.apache.org/jira/browse/IGNITE-3690
> > [4] https://www.dynatrace.com/capabilities/log-analytics/
> > [5] https://www.nagios.com/solutions/log-monitoring/
>
>

Re: Ignite logs adoption for enterprise grade monitoring tools

[Sergey Kosarev]

Hi,
Why Event ID should be a number?
Maybe better to  split main subsystems by prefixes?  
something like 
Networking: IGN-NET
Persistence: IGN-PERS
etc.

Sergey Kosarev

> On 10 Jan 2018, at 03:49, Denis Magda  wrote:
> 
> Igniters,
> 
> As a preface, Alexey Kukushkin laid out an insightful and profound 
> explanation on what’s wrong with Ignite logs from a DevOps perspective, how 
> the community can easily tackle the gaps and how our efforts will be payed 
> off if we take his advice in consideration: 
> http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-not-friendly-for-Monitoring-td20802.html
> 
> In short, Ignite log events (errors, warnings and non-severe messages) are 
> not assigned unique identifiers. 
> Why a mature project like Ignite needs it?
> 
> First, to have a human-friendly glossary of error messages or warnings (see 
> MySQL [1] and MongoDB [2] examples) that simplify troubleshooting and 
> debugging on the dev side. Actually we planned to do it back in 2016! [3]
> 
> Second, turns out to be that popular DevOps monitoring tools such as 
> DynaTrace [4] and Nagios [5] can easily analyze IDs of log events and help 
> automate their processing or trigger notifications. For instance, if “node 
> left” log message was labeled with an ID then DynaTrace could detect that 
> event and by looking at overall memory usage (JMX) decide what to do next - 
> just send an email to an admin or add a new node to the cluster.
> 
> My proposal is to start putting the glossary together making Ignite ready for 
> enterprise grade monitoring systems and DevOps! 
> 
> As a first step, let’s define subsystems of Ignite spreading out IDs ranges 
> among them:
> - networking (discovery, communication) - 1000 - 3000
> - memory and persistence - 4000 - 6000
> - key-value, caching - 7000 - 9000
> - SQL - 1 - 11000
> - etc.
> 
> Is everyone with this format and overall endeavor? 
> 
> [1] https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
> [2] 
> https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.err
> [3] https://issues.apache.org/jira/browse/IGNITE-3690
> [4] https://www.dynatrace.com/capabilities/log-analytics/
> [5] https://www.nagios.com/solutions/log-monitoring/

Re: Java 9 support

[Petr Ivanov]

Andrey — double checked your solution and it works now. Guess there was some 
merge error first time.
Sorry for misleading.

So, there is working solution for Java 9 build and I’d like to save this 
configuration in ignite-6730 (making IGNITE-7144 and IGNITE-6736 to become 
subtasks in the process).
What do you think?


> On 9 Jan 2018, at 20:49, Andrey Kuznetsov  wrote:
> 
> Hi Petr!
> 
> Could you please clarify what is wrong with fix proposed in IGNITE-6736,
> and what is supposed to be a replacement for monitorEnter/monitorExit now?
> 
> 2018-01-09 19:08 GMT+03:00 Petr Ivanov :
> 
>> Hi all.
>> 
>> 
>> After some thorough research and with help of fellow igniters, I’ve
>> managed to prepare more or less stable Java 9 build configuration of Apache
>> Ignite.
>> 
>> Here are changes to make it work:
>> - Java 8 profiles and build process revision, made in IGNITE-7203;
>> - Java 9 maven profile prepared in IGNITE-7144 (will be moved to
>> IGNITE-6730 as subtask);
>> - specific maven-compiler-plugin configuration with JVM args for Java 9
>> profile (as was proposed by Vladimir Ozerov);
>> - maven-bundle-plugin version is updated to 3.5.0;
>> - maven-compiler-plugin version synchronised to 3.7.0 (in Cassandra
>> modules);
>> - scala version updated to 2.12.4;
>> - disabled scalar-2.10, spark-2.10 and visor-console-2.10 modules (due to
>> dependency in scala 2.10 which is unsupported by Java 9);
>> - sun.misc.JavaNioAccess import changed to jdk.internal.misc.JavaNioAccess
>> in GridUnsafe.java and PageMemoryImpl.java;
>> - sun.misc.SharedSecrets import changed to jdk.internal.misc.SharedSecrets
>> in GridUnsafe.java and PageMemoryImpl.java;
>> - methods monitorEnter and monitorExit bodies commented out (fix from
>> IGNITE-6736 did not work).
>> 
>> I’d like to put these changes into ignite-6730 to have working compiling
>> under Java 9 branch — so that we can continue work on improving Apache
>> Ignite’s Java 9 support.
> 
> 
> 
> 
> -- 
> Best regards,
>  Andrey Kuznetsov.

Re: Ignite logs adoption for enterprise grade monitoring tools

[Vladimir Ozerov]

+1, better t I think we need more ch bigger ranges for subsystems. E.g.,
10K reserved for SQL would be enough. Not because there are so many real
errors, but because we would need subgroups.

ср, 10 янв. 2018 г. в 6:49, Alexey Kuznetsov :

> Denis,
>
> I think it will be very useful.
>
> P.S. Minor note, I think ranges should be _000 - _999?
>
>
>
> On Wed, Jan 10, 2018 at 7:49 AM, Denis Magda  wrote:
>
> > Igniters,
> >
> > As a preface, Alexey Kukushkin laid out an insightful and profound
> > explanation on what’s wrong with Ignite logs from a DevOps perspective,
> how
> > the community can easily tackle the gaps and how our efforts will be
> payed
> > off if we take his advice in consideration:
> > http://apache-ignite-developers.2346864.n4.nabble.
> > com/Ignite-not-friendly-for-Monitoring-td20802.html
> >
> > In short, Ignite log events (errors, warnings and non-severe messages)
> are
> > not assigned unique identifiers.
> > Why a mature project like Ignite needs it?
> >
> > First, to have a human-friendly glossary of error messages or warnings
> > (see MySQL [1] and MongoDB [2] examples) that simplify troubleshooting
> and
> > debugging on the dev side. Actually we planned to do it back in 2016! [3]
> >
> > Second, turns out to be that popular DevOps monitoring tools such as
> > DynaTrace [4] and Nagios [5] can easily analyze IDs of log events and
> help
> > automate their processing or trigger notifications. For instance, if
> “node
> > left” log message was labeled with an ID then DynaTrace could detect that
> > event and by looking at overall memory usage (JMX) decide what to do
> next -
> > just send an email to an admin or add a new node to the cluster.
> >
> > My proposal is to start putting the glossary together making Ignite ready
> > for enterprise grade monitoring systems and DevOps!
> >
> > As a first step, let’s define subsystems of Ignite spreading out IDs
> > ranges among them:
> > - networking (discovery, communication) - 1000 - 3000
> > - memory and persistence - 4000 - 6000
> > - key-value, caching - 7000 - 9000
> > - SQL - 1 - 11000
> > - etc.
> >
> > Is everyone with this format and overall endeavor?
> >
> > [1] https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
> > [2] https://github.com/mongodb/mongo/blob/master/src/mongo/
> > base/error_codes.err
> > [3] https://issues.apache.org/jira/browse/IGNITE-3690
> > [4] https://www.dynatrace.com/capabilities/log-analytics/
> > [5] https://www.nagios.com/solutions/log-monitoring/
>
>
>
>
> --
> Alexey Kuznetsov
>

Re: Ignite logs adoption for enterprise grade monitoring tools

[Alexey Kuznetsov]

Denis,

I think it will be very useful.

P.S. Minor note, I think ranges should be _000 - _999?



On Wed, Jan 10, 2018 at 7:49 AM, Denis Magda  wrote:

> Igniters,
>
> As a preface, Alexey Kukushkin laid out an insightful and profound
> explanation on what’s wrong with Ignite logs from a DevOps perspective, how
> the community can easily tackle the gaps and how our efforts will be payed
> off if we take his advice in consideration:
> http://apache-ignite-developers.2346864.n4.nabble.
> com/Ignite-not-friendly-for-Monitoring-td20802.html
>
> In short, Ignite log events (errors, warnings and non-severe messages) are
> not assigned unique identifiers.
> Why a mature project like Ignite needs it?
>
> First, to have a human-friendly glossary of error messages or warnings
> (see MySQL [1] and MongoDB [2] examples) that simplify troubleshooting and
> debugging on the dev side. Actually we planned to do it back in 2016! [3]
>
> Second, turns out to be that popular DevOps monitoring tools such as
> DynaTrace [4] and Nagios [5] can easily analyze IDs of log events and help
> automate their processing or trigger notifications. For instance, if “node
> left” log message was labeled with an ID then DynaTrace could detect that
> event and by looking at overall memory usage (JMX) decide what to do next -
> just send an email to an admin or add a new node to the cluster.
>
> My proposal is to start putting the glossary together making Ignite ready
> for enterprise grade monitoring systems and DevOps!
>
> As a first step, let’s define subsystems of Ignite spreading out IDs
> ranges among them:
> - networking (discovery, communication) - 1000 - 3000
> - memory and persistence - 4000 - 6000
> - key-value, caching - 7000 - 9000
> - SQL - 1 - 11000
> - etc.
>
> Is everyone with this format and overall endeavor?
>
> [1] https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
> [2] https://github.com/mongodb/mongo/blob/master/src/mongo/
> base/error_codes.err
> [3] https://issues.apache.org/jira/browse/IGNITE-3690
> [4] https://www.dynatrace.com/capabilities/log-analytics/
> [5] https://www.nagios.com/solutions/log-monitoring/




-- 
Alexey Kuznetsov

Ignite logs adoption for enterprise grade monitoring tools

[Denis Magda]

Igniters,

As a preface, Alexey Kukushkin laid out an insightful and profound explanation 
on what’s wrong with Ignite logs from a DevOps perspective, how the community 
can easily tackle the gaps and how our efforts will be payed off if we take his 
advice in consideration: 
http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-not-friendly-for-Monitoring-td20802.html

In short, Ignite log events (errors, warnings and non-severe messages) are not 
assigned unique identifiers. 
Why a mature project like Ignite needs it?

First, to have a human-friendly glossary of error messages or warnings (see 
MySQL [1] and MongoDB [2] examples) that simplify troubleshooting and debugging 
on the dev side. Actually we planned to do it back in 2016! [3]

Second, turns out to be that popular DevOps monitoring tools such as DynaTrace 
[4] and Nagios [5] can easily analyze IDs of log events and help automate their 
processing or trigger notifications. For instance, if “node left” log message 
was labeled with an ID then DynaTrace could detect that event and by looking at 
overall memory usage (JMX) decide what to do next - just send an email to an 
admin or add a new node to the cluster.

My proposal is to start putting the glossary together making Ignite ready for 
enterprise grade monitoring systems and DevOps! 

As a first step, let’s define subsystems of Ignite spreading out IDs ranges 
among them:
- networking (discovery, communication) - 1000 - 3000
- memory and persistence - 4000 - 6000
- key-value, caching - 7000 - 9000
- SQL - 1 - 11000
- etc.

Is everyone with this format and overall endeavor? 

[1] https://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
[2] https://github.com/mongodb/mongo/blob/master/src/mongo/base/error_codes.err
[3] https://issues.apache.org/jira/browse/IGNITE-3690
[4] https://www.dynatrace.com/capabilities/log-analytics/
[5] https://www.nagios.com/solutions/log-monitoring/

[jira] [Created] (IGNITE-7368) IgniteCache.getAll() throws high volume of GridDhtInvalidPartitionException if on-heap is enabled

[Andrey Kornev (JIRA)]

Andrey Kornev created IGNITE-7368:
-

 Summary: IgniteCache.getAll() throws high volume of 
GridDhtInvalidPartitionException if on-heap is enabled
 Key: IGNITE-7368
 URL: https://issues.apache.org/jira/browse/IGNITE-7368
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.3
Reporter: Andrey Kornev
 Attachments: Screen Shot 2018-01-09 at 3.37.53 PM.png

With on-heap option enabled, {{IgniteCache.getAll()}} throws a 
GridDhtInvalidPartitionException if the input set of keys contains at least one 
non-local key (a key for which the node executing {{getAll}} is not the 
primary). In general case, the input set always contains such keys which, given 
sufficiently high request rate, results in thousands of exceptions thrown per 
second. Attached is a screenshot of a JFR recording showing the exceptions and 
their stack traces.



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

[GitHub] ignite pull request #3347: IGNITE-6899: Adding GA Grid to Apache Ignite ML m...

[techbysample]

GitHub user techbysample opened a pull request:

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

IGNITE-6899: Adding GA Grid to Apache Ignite ML module

IGNITE-6899: Adding GA Grid to Apache Ignite ML module

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

$ git pull https://github.com/techbysample/ignite ignite-6899

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

https://github.com/apache/ignite/pull/3347.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 #3347


commit 5c204d7b433f043fdce25be0330d7793767ea99f
Author: Turik Campbell 
Date:   2018-01-09T22:06:18Z

IGNITE-6899: Adding GA Grid to Apache Ignite ML module




---

Re: Transaction operations using the Ignite Thin Client Protocol

[Denis Magda]

+ dev list

Igniters, Pavel,

I think we need to bring support for key-value transactions to one of the 
future versions. As far as I understand, a server node, a thin client will be 
connected to, will be the transaction coordinator and the client will simply 
offloading everything to it. What do you think?

—
Denis

> On Jan 8, 2018, at 1:12 AM, kotamrajuyashasvi  
> wrote:
> 
> Hi
> 
> I would like to perform Ignite Transaction operations from a C++ program
> using the Ignite Thin Client Protocol. Is it possible to do so ? If this
> feature is not available now, will it be added in future ? 
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Re: DiscoverySpi based on Apache ZooKeeper

[Dmitriy Setrakyan]

Thanks Semyon!

I have a naming nitpick. Can we rename Problem to Failure, e.g.
CommunicationProblemResolver to CommunicationFailureResolver?

D.

On Tue, Jan 9, 2018 at 3:39 AM, Semyon Boikov  wrote:

> Hi all,
>
> Currently I'm working on implementation of DiscoverySpi based on Apache
> ZooKeeper (ZookeeperDiscoverySpi) and want to share results of this work.
>
> In very large clusters (>1000 nodes) current default implementation of
> DiscoverySpi - TcpDiscoverySpi - has some significant drawbacks:
> - TcpDiscoverySpi organizes nodes in ring, and all messages are passed
> sequentially via ring. More nodes there are in ring, more time it takes to
> pass message. In very large clusters such architecture can cause slowdown
> of important operations (node join, node stop, cache start, etc).
> - in TcpDiscoverySpi's protocol each node in ring is able to fail next one
> in case of network issues, and it is possible that two nodes can 'kill'
> each other (it is possible in complex scenarios when network is broken and
> then restored back after some time, such problems were observed in real
> environments), and with current TcpDiscoverySpi protocol there is no easy
> way to completely fix such problems.
> - when some node in ring fails, then previous node tries to restore ring
> and sequentially tries to connect to next nodes. If large part of ring
> fails then it takes long time to sequentially detect failure of all nodes.
> - with TcpDiscoverySpi split brain is possible (one ring can split into two
> independent parts), separate mechanism is needed to protect from split
> brain when TcpDiscoverySpi is used
>
> Even though most probably some of these problems can be somehow fixed in
> TcpDiscoverySpi, it seems more robust and fast DiscoverySpi can be
> implemented on top of some existing coordination service.
>
> Apache ZooKeeper is known reliable service and it provides all mechanisms
> and consistency guarantees required for Ignite's DiscoverySpi. Some
> technical details of ZookeeperDiscoverySpi implementation can be found in
> description prepared by Sergey Puchnin:
> https://cwiki.apache.org/confluence/display/IGNITE/
> Discovery+SPI+by+ZooKeeper
> .
>
> In our preliminary tests we were able to successfully start 4000+ nodes
> with ZookeeperDiscoverySpi. New implementation works faster than
> TcpDiscoverySpi and does not have mentioned TcpDiscoverySpi's drawbacks:
> - nodes alive status is controlled by ZooKeeper, so nodes never can kill
> each other
> - ZooKeeper has protection from split brain
> - with ZooKeeper it is possible to detect nodes join/failures in batches so
> time to detect join/failure of 1 vs 100+ nodes is almost the same
>
> I'm going to finalize implementation of ZookeeperDiscoverySpi in next few
> days. But in Ignite there is one more issue caused by the fact that
> DiscoverySpi and CommunicationSpi are two independent component: it is
> possible that DiscoverySpi considers some node as alive, but at the same
> time CommunicationSpi is not able to send message to this node (this issue
> exists not only for ZookeeperDiscoverySpi for but for TcpDiscoverySpi too).
> Such case is very critical since all internal Ignite's code assumes that if
> node is alive then CommunicationSpi is able to send/receive messages
> to/from this node. If it is not the case, then any Ignite operation can
> hang (with ZooKeeper such situation is possible when due to network
> failures nodes have connection with ZooKeeper, but can not establish TCP
> connection to each other).
>
> If such case arises, then Ignite should have some mechanism to forcibly
> kill faulty nodes to keep cluster operational. But note that in case of
> 'split brain' scenarios each independent part of cluster will consider
> others as 'failed' and there should be some way to choose which part should
> be killed. It would be good to provide generic solution for this problem as
> part of work on new DiscoverySpi.
>
> We discussed this with Yakov Zhdanov and suggest following: in case when
> communication fails to send message to some node and this node is
> considered as alive, then Ignite should trigger global 'communication error
> resolve' process (obviously, this process should use for messaging internal
> discovery mechanisms). As part of this process CommunicationSpi on each
> node should try to establish connection to all others alive nodes
> (TcpCommunicationSpi can do this efficiently using async NIO) and send
> results of this connection test to some coordinator node (e.g. oldest
> cluster node). When coordinator receives results of connection test from
> all nodes it calls user-defined CommunicationProblemResolver to choose
> which nodes should be killed (CommunicationProblemResolver should be set in
> IgniteConfiguration):
>
> public interface CommunicationProblemResolver {
> public void resolve(CommunicationProblemContext ctx);
> }
>
> CommunicationProblemResolver  receives CommunicationProblemContext which
> provides results

[GitHub] ignite pull request #3345: Ignite return auth 7322 6783 step 22

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3331: ignite-6814: added detailed memory consumption

[sk0x50]

Github user sk0x50 closed the pull request at:

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


---

Re: DiscoverySpi based on Apache ZooKeeper

[Andrey Kornev]

Semyon,

Not to discourage you or anything, just a interesting fact from recent history.

I vaguely remember already trying to implement DiscoverySpi on top of Zookeeper 
back in 2012. After a few failed attempts and a lot of help from Zookeeper's 
original developers (Flavio Junqueira and Ben Reed) we (Dmitriy S. and I) 
concluded that its not possible to  implement DiscoverySpi on top of Zookeeper 
due to strict(er) semantics of DiscoverySpi. Unfortunately I do not remember 
details, but essentially, in some cases it was not possible to establish total 
ordering of watcher events and under certain circumstances loss of such events 
was possible.

It's not to say that Zookeeper can't be used to implement the cluster 
membership tracking in general. The problem is rather with DiscoverySpi 
semantics that require a different set of APIs than what Zookeeper provides.

Regards
Andrey


From: Semyon Boikov 
Sent: Tuesday, January 9, 2018 3:39 AM
To: dev@ignite.apache.org
Subject: DiscoverySpi based on Apache ZooKeeper

Hi all,

Currently I'm working on implementation of DiscoverySpi based on Apache
ZooKeeper (ZookeeperDiscoverySpi) and want to share results of this work.

In very large clusters (>1000 nodes) current default implementation of
DiscoverySpi - TcpDiscoverySpi - has some significant drawbacks:
- TcpDiscoverySpi organizes nodes in ring, and all messages are passed
sequentially via ring. More nodes there are in ring, more time it takes to
pass message. In very large clusters such architecture can cause slowdown
of important operations (node join, node stop, cache start, etc).
- in TcpDiscoverySpi's protocol each node in ring is able to fail next one
in case of network issues, and it is possible that two nodes can 'kill'
each other (it is possible in complex scenarios when network is broken and
then restored back after some time, such problems were observed in real
environments), and with current TcpDiscoverySpi protocol there is no easy
way to completely fix such problems.
- when some node in ring fails, then previous node tries to restore ring
and sequentially tries to connect to next nodes. If large part of ring
fails then it takes long time to sequentially detect failure of all nodes.
- with TcpDiscoverySpi split brain is possible (one ring can split into two
independent parts), separate mechanism is needed to protect from split
brain when TcpDiscoverySpi is used

Even though most probably some of these problems can be somehow fixed in
TcpDiscoverySpi, it seems more robust and fast DiscoverySpi can be
implemented on top of some existing coordination service.

Apache ZooKeeper is known reliable service and it provides all mechanisms
and consistency guarantees required for Ignite's DiscoverySpi. Some
technical details of ZookeeperDiscoverySpi implementation can be found in
description prepared by Sergey Puchnin:
https://cwiki.apache.org/confluence/display/IGNITE/Discovery+SPI+by+ZooKeeper
.

In our preliminary tests we were able to successfully start 4000+ nodes
with ZookeeperDiscoverySpi. New implementation works faster than
TcpDiscoverySpi and does not have mentioned TcpDiscoverySpi's drawbacks:
- nodes alive status is controlled by ZooKeeper, so nodes never can kill
each other
- ZooKeeper has protection from split brain
- with ZooKeeper it is possible to detect nodes join/failures in batches so
time to detect join/failure of 1 vs 100+ nodes is almost the same

I'm going to finalize implementation of ZookeeperDiscoverySpi in next few
days. But in Ignite there is one more issue caused by the fact that
DiscoverySpi and CommunicationSpi are two independent component: it is
possible that DiscoverySpi considers some node as alive, but at the same
time CommunicationSpi is not able to send message to this node (this issue
exists not only for ZookeeperDiscoverySpi for but for TcpDiscoverySpi too).
Such case is very critical since all internal Ignite's code assumes that if
node is alive then CommunicationSpi is able to send/receive messages
to/from this node. If it is not the case, then any Ignite operation can
hang (with ZooKeeper such situation is possible when due to network
failures nodes have connection with ZooKeeper, but can not establish TCP
connection to each other).

If such case arises, then Ignite should have some mechanism to forcibly
kill faulty nodes to keep cluster operational. But note that in case of
'split brain' scenarios each independent part of cluster will consider
others as 'failed' and there should be some way to choose which part should
be killed. It would be good to provide generic solution for this problem as
part of work on new DiscoverySpi.

We discussed this with Yakov Zhdanov and suggest following: in case when
communication fails to send message to some node and this node is
considered as alive, then Ignite should trigger global 'communication error
resolve' process (obviously, this process should use for messaging internal
discovery mechanis

Re: Java 9 support

[Andrey Kuznetsov]

Hi Petr!

Could you please clarify what is wrong with fix proposed in IGNITE-6736,
and what is supposed to be a replacement for monitorEnter/monitorExit now?

2018-01-09 19:08 GMT+03:00 Petr Ivanov :

> Hi all.
>
>
> After some thorough research and with help of fellow igniters, I’ve
> managed to prepare more or less stable Java 9 build configuration of Apache
> Ignite.
>
> Here are changes to make it work:
>  - Java 8 profiles and build process revision, made in IGNITE-7203;
>  - Java 9 maven profile prepared in IGNITE-7144 (will be moved to
> IGNITE-6730 as subtask);
>  - specific maven-compiler-plugin configuration with JVM args for Java 9
> profile (as was proposed by Vladimir Ozerov);
>  - maven-bundle-plugin version is updated to 3.5.0;
>  - maven-compiler-plugin version synchronised to 3.7.0 (in Cassandra
> modules);
>  - scala version updated to 2.12.4;
>  - disabled scalar-2.10, spark-2.10 and visor-console-2.10 modules (due to
> dependency in scala 2.10 which is unsupported by Java 9);
>  - sun.misc.JavaNioAccess import changed to jdk.internal.misc.JavaNioAccess
> in GridUnsafe.java and PageMemoryImpl.java;
>  - sun.misc.SharedSecrets import changed to jdk.internal.misc.SharedSecrets
> in GridUnsafe.java and PageMemoryImpl.java;
>  - methods monitorEnter and monitorExit bodies commented out (fix from
> IGNITE-6736 did not work).
>
> I’d like to put these changes into ignite-6730 to have working compiling
> under Java 9 branch — so that we can continue work on improving Apache
> Ignite’s Java 9 support.




-- 
Best regards,
  Andrey Kuznetsov.

[jira] [Created] (IGNITE-7367) Flickering minMax test in SparseDistributedMatrixTest

[Artem Malykh (JIRA)]

Artem Malykh created IGNITE-7367:


 Summary: Flickering minMax test in SparseDistributedMatrixTest
 Key: IGNITE-7367
 URL: https://issues.apache.org/jira/browse/IGNITE-7367
 Project: Ignite
  Issue Type: Bug
Reporter: Artem Malykh


java.lang.NullPointerException: null
at java.util.Collections.min(Collections.java:600)
at 
org.apache.ignite.ml.math.distributed.CacheUtils.sparseMin(CacheUtils.java:241)
at 
org.apache.ignite.ml.math.impls.matrix.SparseBlockDistributedMatrix.minValue(SparseBlockDistributedMatrix.java:271)
at 
org.apache.ignite.ml.math.impls.matrix.SparseDistributedBlockMatrixTest.testMinMax(SparseDistributedBlockMatrixTest.java:178)
--- Stdout: ---
[2018-01-09 17:21:46,029][INFO ][main][root] >>> Starting test: 
SparseDistributedBlockMatrixTest#testMinMax <<<
[2018-01-09 17:21:58,436][INFO ][main][root] >>> Stopping test: 
SparseDistributedBlockMatrixTest#testMinMax in 12407 ms <<<
--- Stderr: ---
[2018-01-09 17:21:58,432][ERROR][main][root] Test failed.
java.lang.NullPointerException
at java.util.Collections.min(Collections.java:600)
at 
org.apache.ignite.ml.math.distributed.CacheUtils.sparseMin(CacheUtils.java:241)
at 
org.apache.ignite.ml.math.impls.matrix.SparseBlockDistributedMatrix.minValue(SparseBlockDistributedMatrix.java:271)
at 
org.apache.ignite.ml.math.impls.matrix.SparseDistributedBlockMatrixTest.testMinMax(SparseDistributedBlockMatrixTest.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2001)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:133)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1916)
at java.lang.Thread.run(Thread.java:745)



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

[GitHub] ignite pull request #3346: IGNITE-7284: Introduce DEV_ONLY marker to IgniteL...

[slukyano]

GitHub user slukyano opened a pull request:

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

IGNITE-7284: Introduce DEV_ONLY marker to IgniteLogger



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

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

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

https://github.com/apache/ignite/pull/3346.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 #3346


commit fd43e44b7be7746f496502147711246bd8555024
Author: Stanislav Lukyanov 
Date:   2018-01-09T13:37:52Z

IGNITE-7284: change loggers to use default methods for overloads

commit 102bf58bafae44e9872fa3e395f9566d84703993
Author: Stanislav Lukyanov 
Date:   2018-01-09T17:32:50Z

IGNITE-7284: added handling of markers in slf4j and log4j2




---

[GitHub] ignite pull request #3345: Ignite return auth 7322 6783 step 22

[artemmalykh]

GitHub user artemmalykh opened a pull request:

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

Ignite return auth 7322 6783 step 22



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-return-auth-7322-6783-step-22

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

https://github.com/apache/ignite/pull/3345.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 #3345


commit b567851796b20ce1dd5e064ac71a26871ddc4910
Author: Artem Malykh 
Date:   2018-01-09T17:02:47Z

Step1

commit 9f0099bf143b30123116b72df79f6fb27b89cdc2
Author: Artem Malykh 
Date:   2018-01-09T17:03:12Z

Step2




---

[GitHub] ignite pull request #3344: ignite-7365 Switch segment rollover hanging is fi...

[agura]

GitHub user agura opened a pull request:

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

ignite-7365 Switch segment rollover hanging is fixed



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

$ git pull https://github.com/agura/incubator-ignite ignite-7365

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

https://github.com/apache/ignite/pull/3344.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 #3344






---

[GitHub] ignite pull request #3336: IGNITE-7322: Return authorship of 7322 and 6783

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3343: IGNITE-7322: Return authorship step 2

[artemmalykh]

GitHub user artemmalykh opened a pull request:

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

IGNITE-7322: Return authorship step 2



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-return-auth-7322-6783-step2

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

https://github.com/apache/ignite/pull/3343.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 #3343






---

[jira] [Created] (IGNITE-7366) Affinity assignment exception in service processor during multiple nodes join

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7366:
---

 Summary: Affinity assignment exception in service processor during 
multiple nodes join
 Key: IGNITE-7366
 URL: https://issues.apache.org/jira/browse/IGNITE-7366
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: 2.3
Reporter: Ilya Kasnacheev


When two nodes which are deploying services join at the same time, and 
exception is observed:
{code}
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.cachedAffinity(GridAffinityAssignmentCache.java:514)
at 
org.apache.ignite.internal.processors.affinity.GridAffinityAssignmentCache.nodes(GridAffinityAssignmentCache.java:419)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.nodesByPartition(GridCacheAffinityManager.java:220)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByPartition(GridCacheAffinityManager.java:256)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:247)
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.primaryByKey(GridCacheAffinityManager.java:271)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$TopologyListener$1.run0(GridServiceProcessor.java:1771)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1958)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
{code}

This may be caused by exchange merges. There are 4 nodes joining topology. When 
nodes 3 and 4 join at the same time, exchanges for [3, 0] and [4, 0] are 
merged. But, TopologyListener in service processor is notified about topVer [3, 
0], for which there is no affinity because exchange has already moved forward 
to [4, 0].



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

[GitHub] ignite pull request #3342: IGNITE-6772: SQL exception messages made more inf...

[dolphin1414]

GitHub user dolphin1414 opened a pull request:

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

IGNITE-6772: SQL exception messages made more informative.

SQL exception messages made more informative.

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

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

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

https://github.com/apache/ignite/pull/3342.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 #3342


commit 2d3a681632e972ec647f41e9c5940a394cad3817
Author: rkondakov 
Date:   2018-01-09T16:14:39Z

IGNITE-6772: SQL exception messages became more informative.




---

[jira] [Created] (IGNITE-7365) File channel associated with WAL can be closed by interruption

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-7365:
---

 Summary: File channel associated with WAL can be closed by 
interruption
 Key: IGNITE-7365
 URL: https://issues.apache.org/jira/browse/IGNITE-7365
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura
Assignee: Andrey Gura
Priority: Critical
 Fix For: 2.4


File channel associated with WAL can be closed by user thread interruption on 
segment rollover.



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

Java 9 support

[Petr Ivanov]

Hi all.


After some thorough research and with help of fellow igniters, I’ve managed to 
prepare more or less stable Java 9 build configuration of Apache Ignite.

Here are changes to make it work:
 - Java 8 profiles and build process revision, made in IGNITE-7203;
 - Java 9 maven profile prepared in IGNITE-7144 (will be moved to IGNITE-6730 
as subtask);
 - specific maven-compiler-plugin configuration with JVM args for Java 9 
profile (as was proposed by Vladimir Ozerov);
 - maven-bundle-plugin version is updated to 3.5.0;
 - maven-compiler-plugin version synchronised to 3.7.0 (in Cassandra modules);
 - scala version updated to 2.12.4;
 - disabled scalar-2.10, spark-2.10 and visor-console-2.10 modules (due to 
dependency in scala 2.10 which is unsupported by Java 9);
 - sun.misc.JavaNioAccess import changed to jdk.internal.misc.JavaNioAccess in 
GridUnsafe.java and PageMemoryImpl.java;
 - sun.misc.SharedSecrets import changed to jdk.internal.misc.SharedSecrets in 
GridUnsafe.java and PageMemoryImpl.java;
 - methods monitorEnter and monitorExit bodies commented out (fix from 
IGNITE-6736 did not work).

I’d like to put these changes into ignite-6730 to have working compiling under 
Java 9 branch — so that we can continue work on improving Apache Ignite’s Java 
9 support.

[jira] [Created] (IGNITE-7364) [Test failed] IgnitePdsThreadInterruptionTest.testInterruptsOnWALWrite fails or hangs

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-7364:
---

 Summary: [Test failed] 
IgnitePdsThreadInterruptionTest.testInterruptsOnWALWrite fails or hangs
 Key: IGNITE-7364
 URL: https://issues.apache.org/jira/browse/IGNITE-7364
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura
Assignee: Andrey Gura
Priority: Critical
 Fix For: 2.4


Test {{IgnitePdsThreadInterruptionTest.testInterruptsOnWALWrite}} fails or 
hangs.



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

[GitHub] ignite pull request #3341: IGNITE-7277: override equals() & hashCode() metho...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-7277: override equals() & hashCode() methods for JdbcTableMeta…

… to prevent tables duplication at the tables metadata result set.

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

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

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

https://github.com/apache/ignite/pull/3341.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 #3341


commit ab93df250dcbe3b15c65d757e9d8746aa6ce9c8a
Author: tledkov-gridgain 
Date:   2018-01-09T15:41:36Z

IGNITE-7277: override equals() & hashCode() methods for JdbcTableMeta to 
prevent tables duplication at the tables metadata result set.




---

[jira] [Created] (IGNITE-7363) Inconsistent millis in java.util.Date when retrieved in SELECT query

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-7363:
---

 Summary: Inconsistent millis in java.util.Date when retrieved in 
SELECT query
 Key: IGNITE-7363
 URL: https://issues.apache.org/jira/browse/IGNITE-7363
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.3
Reporter: Ilya Kasnacheev
 Attachments: 19222.zip

~ when querying for java.util.Date field in SELECT query it returns a 
java.sql.Timestamp, and when getTime() on that Timestamp is called it returns 
different milliseconds value than in original java.util.Date, in case Time Zone 
is different on client and on server. Using get() the correct java.util.Date is 
obtained. Please see reproducer, kudos 
http://apache-ignite-users.70518.x6.nabble.com/Date-type-field-in-select-query-is-returning-wrong-value-when-Time-zones-of-Ignite-Client-and-Servert-tc19222.html



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

[jira] [Created] (IGNITE-7362) ODBC: Third party libraries truncate any inserted varlen data to ColumnSize

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-7362:
---

 Summary: ODBC: Third party libraries truncate any inserted varlen 
data to ColumnSize
 Key: IGNITE-7362
 URL: https://issues.apache.org/jira/browse/IGNITE-7362
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.3
Reporter: Igor Sapego
 Fix For: 2.5


Third-party frameworks and ODBC bindings for different languages use metadata 
requests results for columns (such as {{SQL_COLUMN_PRECISION}}) to truncate 
varlen data, inserted by the user, which is only 64 by default. 

{code}
setAttribute(PDO::ATTR_ERRMODE, 
PDO::ERRMODE_EXCEPTION);

$sql = 'CREATE TABLE IF NOT EXISTS test_md5 (id int PRIMARY 
KEY, userkey
LONGVARCHAR, server LONGVARCHAR, tsession LONGVARCHAR, tpost LONGVARCHAR,
tget LONGVARCHAR, adddate int) WITH
"atomicity=transactional,cachegroup=somegroup"';
$ignite->exec($sql);

for($i=0; $i <= 10; $i++){
$dbs = $ignite->prepare("INSERT INTO test_md5 (id, 
userkey, server,
tsession, tpost, tget, adddate) VALUES ($i, 'Lorem ipsum dolor sit amet,
consectetur adipiscing elit, sed do elit, sed', 'b', 'c', 'd', 'e', 1)");
$dbs->execute();
}


} catch (PDOException $e) {
print "Error!: " . $e->getMessage() . "\n";
die();
}

?>
{code}



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

[GitHub] ignite pull request #3340: ignite-2.4.1 reconnect fix

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

ignite-2.4.1 reconnect fix



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-2.4.1-merge-master-recFix

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

https://github.com/apache/ignite/pull/3340.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 #3340


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

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

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578
Author: Ilya Lantukh 
Date:   2017-11-18T12:39:19Z

Fixed Ignite.active(true) returning control too early.

commit 1bcdd76aae78665e2bbd49034fb46a1b91ef8389
Author: Ilya Lantukh 
Date:   2017-11-18T13:33:01Z

Fixed baseline topology changes from client/daemon nodes.

commit e3bbecd9f133251818a4b43afa44f46e66dd0325
Author: Alexey Goncharuk 
Date:   2017-11-18T14:16:39Z

Fixed licenses

commit b0d73fe45a8bb89ef82fce561f702

[GitHub] ignite pull request #3339: IGNITE-7335: add test

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-7335: add test



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

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

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

https://github.com/apache/ignite/pull/3339.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 #3339


commit e5dcb1e86d5bd4263880cdaa288bb03137eeed8a
Author: tledkov-gridgain 
Date:   2018-01-09T13:44:39Z

IGNITE-7335: add test




---

[GitHub] ignite pull request #3338: IGNITE-7335 DatabaseMetaData getTables error

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #3338: IGNITE-7335 DatabaseMetaData getTables error

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-7335  DatabaseMetaData getTables error



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

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

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

https://github.com/apache/ignite/pull/3338.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 #3338


commit 95421658e348e7db8bb764af3737dee2f776cc49
Author: tledkov-gridgain 
Date:   2018-01-09T13:44:39Z

IGNITE-7335: add test

commit 23b1f44d5d004cf89c81958678cae91520cebe14
Author: tledkov-gridgain 
Date:   2018-01-09T14:14:52Z

IGNITE-7335: add test




---

[GitHub] ignite pull request #3312: Ignite-2.4-java8

[agura]

Github user agura closed the pull request at:

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


---

[GitHub] ignite pull request #3322: IGNITE-7343: add multi-tread guard

[tledkov-gridgain]

Github user tledkov-gridgain closed the pull request at:

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


---

[GitHub] ignite pull request #3337: IGNITE-7343 Add guard to prevent concurrent usage...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-7343  Add guard to prevent concurrent usage the JDBC thin connection



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

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

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

https://github.com/apache/ignite/pull/3337.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 #3337


commit 2fe1ca63a08ef3c12f239abfb5549b5a57096447
Author: tledkov-gridgain 
Date:   2017-12-29T12:43:26Z

IGNITE-7335: add multi-tread guard

commit 227841f0f7bb5169d5e995705ac4dcf98e9dde86
Author: tledkov-gridgain 
Date:   2018-01-09T12:44:43Z

Merge branch '_master' into ignite-7335




---

[jira] [Created] (IGNITE-7361) HA: NPE in HadoopJobTracker.jobMetaCache

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-7361:
-

 Summary: HA: NPE in HadoopJobTracker.jobMetaCache
 Key: IGNITE-7361
 URL: https://issues.apache.org/jira/browse/IGNITE-7361
 Project: Ignite
  Issue Type: Bug
Reporter: Evgenii Zhuravlev


java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.jobMetaCache(HadoopJobTracker.java:206)
 
at 
org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.finishFuture(HadoopJobTracker.java:478)
 
at 
org.apache.ignite.internal.processors.hadoop.HadoopProcessor.finishFuture(HadoopProcessor.java:192)
 
at 
org.apache.ignite.internal.processors.hadoop.HadoopImpl.finishFuture(HadoopImpl.java:111)
 
at 
org.apache.ignite.internal.processors.hadoop.proto.HadoopProtocolJobStatusTask.run(HadoopProtocolJobStatusTask.java:59)
at 
org.apache.ignite.internal.processors.hadoop.proto.HadoopProtocolJobStatusTask.run(HadoopProtocolJobStatusTask.java:33)
 
at 
org.apache.ignite.internal.processors.hadoop.proto.HadoopProtocolTaskAdapter$Job.execute(HadoopProtocolTaskAdapter.java:101)
at 
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:566)
 
at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6629)
 
at 
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:560)
 
at 
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:489)
 
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1181)
at 
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1908)
at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1562)
 
at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1190)
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)
 [
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1152) 
[?:1.7.0_151]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:622) 
[?:1.7.0_151]



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

[GitHub] ignite pull request #3336: IGNITE-7322: Return authorship of 7322 and 6783

[artemmalykh]

GitHub user artemmalykh opened a pull request:

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

IGNITE-7322: Return authorship of 7322 and 6783



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-return-auth-7322-6783

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

https://github.com/apache/ignite/pull/3336.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 #3336


commit ffee7d02bc92006dbcea03c36c229d25b68f7c4e
Author: Artem Malykh 
Date:   2018-01-09T11:46:29Z

Revert "Compilation fixed"

This reverts commit dd2fe1bcefcabc05ab5a09139d6be5ff5f7348d3.

commit 25fec3e9304c62e23d2af63b76dcb5114ece26d0
Author: Artem Malykh 
Date:   2018-01-09T11:46:49Z

Revert "IGNITE-5623 Fix .NET QueryEntity parity check"

This reverts commit daf70d24a109419aa578735429717b535359e090.

commit f3f03b27facea8a594fbcac268136625d5940a31
Author: Artem Malykh 
Date:   2018-01-09T11:47:10Z

Revert "IGNITE-7304: AWS ELB-based ip finder."

This reverts commit 7d64100c193d264072d62273faa37bbe315b6241.

commit ade3660d0cba54ae994f4ba6bc6bb31042d2513e
Author: Artem Malykh 
Date:   2018-01-09T11:47:35Z

Revert "IGNITE-7331: Create MLP examples"

This reverts commit 826108f15f92e57a299b497bae1d39aa490cdd8d.

commit 52dcac9998738798d311ab40491b82a4b9ce184d
Author: Artem Malykh 
Date:   2018-01-09T11:48:02Z

Revert "IGNITE-5623: SQL: default column values support for CREATE TABLE. 
This closes #3256."

This reverts commit 78e79e011f1bb017653e628587faf606cfd37510.

commit 3c9d8eaa74c3db9cc162be3c2cf67c902c801009
Author: Artem Malykh 
Date:   2018-01-09T11:48:25Z

Revert "IGNITE-7322: Distributed MLP training."

This reverts commit 2f2fa8b345c9705d0bf3109f3a2478fa616559ca.

commit 4efe4a2ce60423d2789c1781692ad42e47d477b9
Author: Artem Malykh 
Date:   2018-01-09T11:48:38Z

Revert "IGNITE-6783: Create common mechanism for group training."

This reverts commit b0c5ef1ea273530f48a8014c004ed073be9c6d6e.

commit 34e810964e8efc5b1a741f595530172e48b328f4
Author: Artem Malykh 
Date:   2018-01-09T11:56:31Z

5623 recommit

commit 8f728da5246a9646923391063fb67d9d0186dfe1
Author: Artem Malykh 
Date:   2018-01-09T11:57:27Z

7304 recommit

commit b09561ff1c8996cde17ed3488c7b43e06ee583d9
Author: Artem Malykh 
Date:   2018-01-09T11:58:00Z

5623-2 recommit

commit e3694d799b9ff5e3ddf1ef6220b8d6a2d8ac7141
Author: Artem Malykh 
Date:   2018-01-09T11:58:28Z

Compilation fixed recommit




---

[jira] [Created] (IGNITE-7360) SQL: incorrect date/time values could be inserted

[Alex Volkov (JIRA)]

Alex Volkov created IGNITE-7360:
---

 Summary: SQL: incorrect date/time values could be inserted
 Key: IGNITE-7360
 URL: https://issues.apache.org/jira/browse/IGNITE-7360
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Alex Volkov
Priority: Minor


According to ansi 99 spec.:

||Keyword||Valid values of datetime fields||
|YEAR|0001 to |
|MONTH|01 to 12|
|DAY|Within the range 1 (one) to 31, but further constrained by the value of
MONTH and YEAR fields, according to the rules for well-formed dates in
the Gregorian calendar.|
|HOUR|00 to 23|

and so on.

But these values could be inserted:

*For DATE data type:*

{code:java}
0: jdbc:ignite:thin://127.0.0.1:10800/> create table tmp_table_date_and_time 
(key_field INT PRIMARY KEY,field1 DATE,field2 TIME);
SQL: create table tmp_table_date_and_time (key_field INT PRIMARY KEY,field1 
DATE,field2 TIME)
No rows affected (0.028 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> insert into tmp_table_date_and_time 
(key_field,field1,field2) values (2, '1-12-09','13:44:56');
SQL: insert into tmp_table_date_and_time (key_field,field1,field2) values (2, 
'1-12-09','13:44:56')
1 row affected (0.009 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> select * from tmp_table_date_and_time;
SQL: select * from tmp_table_date_and_time
IN IncrementalRows 3
++++
|   KEY_FIELD| FIELD1 | 
FIELD2 |
++++
| 2  | Sat Dec 09 00:00:00 MSK 1  | 13:44:56
   |
++++
1 row selected (0.007 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> insert into tmp_table_date_and_time 
(key_field,field1,field2) values (6, '-2017-12-09','13:44:56');
SQL: insert into tmp_table_date_and_time (key_field,field1,field2) values (6, 
'-2017-12-09','13:44:56')
1 row affected (0.011 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> select * from tmp_table_date_and_time;
SQL: select * from tmp_table_date_and_time
IN IncrementalRows 3
++++
|   KEY_FIELD| FIELD1 | 
FIELD2 |
++++
| 2  | Sat Dec 09 00:00:00 MSK 1  | 13:44:56
   |
| 6  | Tue Dec 09 00:00:00 MSK 2018   | 13:44:56
   |
++++
2 rows selected (0.016 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> 
{code}

For TIME data type:


{code:java}
0: jdbc:ignite:thin://127.0.0.1:10800/> create table tmp_table_date_and_time 
(key_field INT PRIMARY KEY,field1 DATE,field2 TIME);
SQL: create table tmp_table_date_and_time (key_field INT PRIMARY KEY,field1 
DATE,field2 TIME)
No rows affected (0.131 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> insert into tmp_table_date_and_time 
(key_field,field1,field2) values (3, '2017-12-09','25:44:56');
SQL: insert into tmp_table_date_and_time (key_field,field1,field2) values (3, 
'2017-12-09','25:44:56')
1 row affected (0.097 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> select * from tmp_table_date_and_time;
SQL: select * from tmp_table_date_and_time
IN IncrementalRows 3
++++
|   KEY_FIELD| FIELD1 | 
FIELD2 |
++++
| 3  | Sat Dec 09 00:00:00 MSK 2017   | 01:44:56
   |
++++
1 row selected (0.017 seconds)
0: jdbc:ignite:thin://127.0.0.1:10800/> 
{code}





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

DiscoverySpi based on Apache ZooKeeper

[Semyon Boikov]

Hi all,

Currently I'm working on implementation of DiscoverySpi based on Apache
ZooKeeper (ZookeeperDiscoverySpi) and want to share results of this work.

In very large clusters (>1000 nodes) current default implementation of
DiscoverySpi - TcpDiscoverySpi - has some significant drawbacks:
- TcpDiscoverySpi organizes nodes in ring, and all messages are passed
sequentially via ring. More nodes there are in ring, more time it takes to
pass message. In very large clusters such architecture can cause slowdown
of important operations (node join, node stop, cache start, etc).
- in TcpDiscoverySpi's protocol each node in ring is able to fail next one
in case of network issues, and it is possible that two nodes can 'kill'
each other (it is possible in complex scenarios when network is broken and
then restored back after some time, such problems were observed in real
environments), and with current TcpDiscoverySpi protocol there is no easy
way to completely fix such problems.
- when some node in ring fails, then previous node tries to restore ring
and sequentially tries to connect to next nodes. If large part of ring
fails then it takes long time to sequentially detect failure of all nodes.
- with TcpDiscoverySpi split brain is possible (one ring can split into two
independent parts), separate mechanism is needed to protect from split
brain when TcpDiscoverySpi is used

Even though most probably some of these problems can be somehow fixed in
TcpDiscoverySpi, it seems more robust and fast DiscoverySpi can be
implemented on top of some existing coordination service.

Apache ZooKeeper is known reliable service and it provides all mechanisms
and consistency guarantees required for Ignite's DiscoverySpi. Some
technical details of ZookeeperDiscoverySpi implementation can be found in
description prepared by Sergey Puchnin:
https://cwiki.apache.org/confluence/display/IGNITE/Discovery+SPI+by+ZooKeeper
.

In our preliminary tests we were able to successfully start 4000+ nodes
with ZookeeperDiscoverySpi. New implementation works faster than
TcpDiscoverySpi and does not have mentioned TcpDiscoverySpi's drawbacks:
- nodes alive status is controlled by ZooKeeper, so nodes never can kill
each other
- ZooKeeper has protection from split brain
- with ZooKeeper it is possible to detect nodes join/failures in batches so
time to detect join/failure of 1 vs 100+ nodes is almost the same

I'm going to finalize implementation of ZookeeperDiscoverySpi in next few
days. But in Ignite there is one more issue caused by the fact that
DiscoverySpi and CommunicationSpi are two independent component: it is
possible that DiscoverySpi considers some node as alive, but at the same
time CommunicationSpi is not able to send message to this node (this issue
exists not only for ZookeeperDiscoverySpi for but for TcpDiscoverySpi too).
Such case is very critical since all internal Ignite's code assumes that if
node is alive then CommunicationSpi is able to send/receive messages
to/from this node. If it is not the case, then any Ignite operation can
hang (with ZooKeeper such situation is possible when due to network
failures nodes have connection with ZooKeeper, but can not establish TCP
connection to each other).

If such case arises, then Ignite should have some mechanism to forcibly
kill faulty nodes to keep cluster operational. But note that in case of
'split brain' scenarios each independent part of cluster will consider
others as 'failed' and there should be some way to choose which part should
be killed. It would be good to provide generic solution for this problem as
part of work on new DiscoverySpi.

We discussed this with Yakov Zhdanov and suggest following: in case when
communication fails to send message to some node and this node is
considered as alive, then Ignite should trigger global 'communication error
resolve' process (obviously, this process should use for messaging internal
discovery mechanisms). As part of this process CommunicationSpi on each
node should try to establish connection to all others alive nodes
(TcpCommunicationSpi can do this efficiently using async NIO) and send
results of this connection test to some coordinator node (e.g. oldest
cluster node). When coordinator receives results of connection test from
all nodes it calls user-defined CommunicationProblemResolver to choose
which nodes should be killed (CommunicationProblemResolver should be set in
IgniteConfiguration):

public interface CommunicationProblemResolver {
public void resolve(CommunicationProblemContext ctx);
}

CommunicationProblemResolver  receives CommunicationProblemContext which
provides results of CommunicationSpi connection test. Also it can be useful
to have information about started caches and current cache data
distribution to decide which part of cluster should be killed:

public interface CommunicationProblemContext {
/**
 * @return Current topology snapshot.
 */
public List topologySnapshot();

/**
 * @param node1 Fir

[jira] [Created] (IGNITE-7359) SQL: DDL synchronization with query and cache API operations

[Sergey Kalashnikov (JIRA)]

Sergey Kalashnikov created IGNITE-7359:
--

 Summary: SQL: DDL synchronization with query and cache API 
operations
 Key: IGNITE-7359
 URL: https://issues.apache.org/jira/browse/IGNITE-7359
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Sergey Kalashnikov
Assignee: Sergey Kalashnikov
 Fix For: 2.5


We need to add a means to synchronize DDL operations with queries and cache 
operations. This is required to facilitate future DDL improvements that would 
require to modify user data and/or some cache metadata atomically. Basically it 
is a sort of a global table lock.

One way to achieve this is to re-use a mechanism used by the exchange 
procedure. 
An exchange is waiting for all already started cache operations to end before 
proceeding itself.
Likewise, the new cache operations won't start until exchange procedure has 
completed.

However, for DDL we only need to selectively defer operations that are made on 
the same cache as DDL operation.



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

[GitHub] ignite pull request #3335: Ignite 7003 1

[anton-vinogradov]

GitHub user anton-vinogradov opened a pull request:

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

Ignite 7003 1



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

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

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

https://github.com/apache/ignite/pull/3335.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 #3335


commit ec58473bfce5ec28b8710b98e733a23ef38bbfaa
Author: Anton Vinogradov 
Date:   2017-12-04T19:45:31Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit e83410430e3a03c47e30a41ae57fb11bfc817e72
Author: Anton Vinogradov 
Date:   2017-12-05T14:31:16Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 8cdf8ed5492dd8dd517f97d3911b52425b97539e
Author: Anton Vinogradov 
Date:   2017-12-05T16:33:13Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit f0d4ffe5be5e6ba6b7707757cb92004e4bbe8a37
Author: Anton Vinogradov 
Date:   2017-12-06T11:56:13Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 80bde0ec75450ed95a0e6c5046daaec239699ac7
Author: Anton Vinogradov 
Date:   2017-12-08T19:07:00Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 3baa64a014f2b40ec2fd52c0ad779cf801924d77
Author: Anton Vinogradov 
Date:   2017-12-11T12:39:42Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-7003

commit 4c39c3b8964eb979d8991167593c5ccb0f7e9c36
Author: Anton Vinogradov 
Date:   2017-12-11T13:33:26Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 3b6ea4085cfcf8cc1931f4f5edef3d8ea66ba369
Author: devozerov 
Date:   2017-12-13T13:19:34Z

Merge branch 'master' into ignite-7003

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java

commit d3b99a76eb8ad215ea70ac7efe958bee1739af75
Author: Anton Vinogradov 
Date:   2017-12-16T17:43:57Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit afd34b023d4d480c3fb4ae50addf504c44f1c823
Author: Anton Vinogradov 
Date:   2017-12-17T16:23:37Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit d17600ddc50891562d82e10d2e3aecb5a9ba3a86
Author: Anton Vinogradov 
Date:   2017-12-17T16:48:07Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 26f352d29a463e7ff66dd20df757ded19b04e037
Author: Anton Vinogradov 
Date:   2017-12-17T18:15:49Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 0362d9deb884be223dad1ffe4a5459ed5ef7b3ca
Author: Anton Vinogradov 
Date:   2017-12-17T19:05:06Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 0f97bd4aee47376812d2bdfcea0b25390b807729
Author: Anton Vinogradov 
Date:   2017-12-17T20:51:10Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 68678aab1981ef6173846e720e8b22fced99b888
Author: Anton Vinogradov 
Date:   2017-12-17T21:05:47Z

Merge remote-tracking branch 'remotes/origin/master' into ignite-7003

Signed-off-by: Anton Vinogradov 

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/CacheAffinitySharedManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionsExchangeFuture.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/pagemem/PageMemoryImpl.java

commit a8f356ab0b08ed4b17653a5bde6df9e165d980d3
Author: Anton Vinogradov 
Date:   2017-12-18T17:29:46Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit e43dfdbdc2cca2422c77229154495a49fd7f38fd
Author: Anton Vinogradov 
Date:   2017-12-18T22:17:41Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit eb7db2856c4d8fac066177c48b2bf41c74cf
Author: Anton Vinogradov 
Date:   2017-12-19T12:53:45Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit ca421254d0a7e35a05a643099459a445722d1dda
Author: Anton Vinogradov 
Date:   2017-12-19T16:21:51Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 0fa2d9fa091f22a69959c574fab54d25ee43b7cd
Author: Anton Vinogradov 
Date:   2017-12-19T16:40:32Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 0af10c32fe88c86421d603190d2635489c7e8c21
Author: Anton Vinogradov 
Date:   2017-12-19T16:40:49Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 413324ecf5a4d578a32995bf3358d7f57beb3d86
Author: Anton Vinogradov 
Date:   2017-12-19T16:53:13Z

IGNITE-6411 WIP

Signed-off-by: Anton Vinogradov 

commit 7b76f2f239df0043a806bceb628d8d0e207d263c
Author: Anton Vin

[GitHub] ignite pull request #3320: Gg 13139

[slukyano]

Github user slukyano closed the pull request at:

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


---

[GitHub] ignite pull request #3334: Ignite 7217 2.1

[slukyano]

GitHub user slukyano opened a pull request:

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

Ignite 7217 2.1



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

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

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

https://github.com/apache/ignite/pull/3334.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 #3334


commit 433879963db63103ba597e67e703f6ab7d3c64e1
Author: vsisko 
Date:   2017-09-19T17:10:46Z

IGNITE-6431 Web console: Fixed duplicate "Partition loss policy" field.
(cherry picked from commit 2299589)

commit 6318c1a15f05e952c22e42e6e238816d7ffdb0ca
Author: vsisko 
Date:   2017-09-20T10:19:58Z

IGNITE-6376 Web console: Enable task and job events in demo mode by default.
(cherry picked from commit ff17783)

commit 668e29fa2766ad5f0fda829e027b777407d9ca4f
Author: vsisko 
Date:   2017-09-20T10:27:14Z

IGNITE-6304 Fixed script execution after throttling interval.
(cherry picked from commit d1f178f)

commit 4e38b792517ff182391b78821937db57353a7388
Author: Dmitriy Shabalin 
Date:   2017-09-20T12:00:09Z

IGNITE-6435 Web Console: Added version to footer.
(cherry picked from commit 3c75184)

commit 1a6461582eac95e1e51faf8acd9b8bd10394dd47
Author: vsisko 
Date:   2017-09-20T12:07:55Z

IGNITE-6449 Added missing cache configuration properties.
(cherry picked from commit 9b2bca7)

commit bd60ab1fa6aaf433849e8a052af41a2a333c7904
Author: Pavel Tupitsyn 
Date:   2017-09-20T13:49:49Z

IGNITE-6250 .NET: Thin client: Basic exception handling

This closes #2698

commit 58ba0d229476b502241940e474c25f0d895c
Author: Ilya Borisov 
Date:   2017-09-21T03:25:19Z

IGNITE-6446 Fix permission transition hook and permissions for basic 
configuration screen.
(cherry picked from commit 0f8a2bf)

commit 3847b47752db7d83c85a76e09964fd154e2f0cc4
Author: Alexey Kuznetsov 
Date:   2017-09-21T07:36:08Z

IGNITE-6461 Web Console: Sanitize user on save.
(cherry picked from commit 1b6873c)

commit 931320f6ded6f927931c6dca2b9ed6795632365c
Author: tledkov-gridgain 
Date:   2017-09-21T11:40:13Z

IGNITE-6457: JDBC thin driver: now schema in URL string is case-insensitive 
by default. This closes #2712.

commit b6d570fb0d5cc5638f857a5aa463600a942fbba0
Author: Alexey Goncharuk 
Date:   2017-09-21T13:37:42Z

IGNITE-6342 Fixed exchange hanging on eviction when partition is lost

commit f5ff60eb72cf6bf55511b2c73f841eb50af59526
Author: Alexey Kuznetsov 
Date:   2017-09-21T14:13:59Z

Web Console: minor refactoring.
(cherry picked from commit abe4ee8)

commit 099d33ceaee8bb8b3edbd1bee91a580572537e45
Author: tledkov-gridgain 
Date:   2017-09-21T14:46:47Z

IGNITE-6448: Fixed a bug causing stale SQL statement to reside in cache 
after ALTER TABLE command. This closes #2702.

commit be8afd4f39599b7e26ad148331c5aa6ba4faf513
Author: tledkov-gridgain 
Date:   2017-09-21T14:51:26Z

IGNITE-6465: JDBC thin driver: added SQLSTATE propagation for 
BatchUpdateException. This closes #2719.

commit 111d8abbe6ec7710c7f0e7ebe6d43f3ccb904dcb
Author: Alexei Scherbakov 
Date:   2017-09-21T14:40:16Z

IGNITE-6228 Avoid closing page store by thread interruption. Fixes #2715

commit aeb4aeaef44ff7abc152f3942dee9e40086bc69c
Author: EdShangGG 
Date:   2017-09-21T15:36:37Z

ignite-6470 Fixed wrong casting og long value to int

Signed-off-by: Andrey Gura 

(cherry picked from commit b98ffab)

commit 21d7fed8a43ba4606eaf850438fc39fcc3223d1c
Author: Alexander Paschenko 
Date:   2017-09-21T15:51:18Z

IGNITE-6316: SQL: fixed CacheConfiguration persistence logic for DDL 
operations. This closes #2701.

commit e82f077df78972a58fdd06917839445711432705
Author: Dmitriy Govorukhin 
Date:   2017-09-21T15:56:40Z

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

commit 49a3631937b09c2fa795d29411635b3b5f82f15a
Author: Eduard Shangareev 
Date:   2017-09-21T15:55:00Z

IGNITE-6460 Fixed consistentId used in lightweight ClusterNode. Fixes #2707

commit fc34091c750cdaf759a54a989a84c76f8d9f9f7f
Author: Igor Sapego 
Date:   2017-09-21T17:02:33Z

IGNITE-6294: ODBC: implemented SQLSTATE management. This closes #2716.

commit ccc8c9b40d09e1d3314a519f1e9417e79c150d9d
Author: Alexey Kuznetsov 
Date:   2017-09-15T16:19:16Z

IGNITE-6120 Fixed version check for ignite-2.2.0.
(cherry picked from commit f4ead8b)

commit cd4e25ecb4912beb85a571b33e0f1096a24bbb7c
Author: Alexey Kuznetsov 
Date:   2017-09-22T03:10:52Z

Versions updated.

commit f08127d50357c4ea24217c096f00942189ed
Author: Alexey Kuznetsov 
Date:   2017-09-22T04:30:12Z

IGNITE-6476 Fixed "No suitable driver found" in demo mode.
(cherry picked from commit 27295f2)

commit 73e1578370c35f3428b097f2f185adf34dace881
Author: Dmitriy Govorukhin 
D

[GitHub] ignite pull request #3333: IGNITE-7318 .NET: Move SQL examples to Sql namesp...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-7318 .NET: Move SQL examples to Sql namespace



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

$ git pull https://github.com/ptupitsyn/ignite ignite-7318

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 c3037d40b4938221bd2b92b82dd5c7c8701b
Author: Pavel Tupitsyn 
Date:   2018-01-09T10:02:41Z

IGNITE-7318 .NET Move all SQL examples out of "data grid" package

commit 382e0857ff8942b836464cdaf1395b2cedb30ca3
Author: Pavel Tupitsyn 
Date:   2018-01-09T10:15:20Z

Rename examples




---

[GitHub] ignite pull request #3332: Ignite 7217 2.3

[slukyano]

GitHub user slukyano opened a pull request:

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

Ignite 7217 2.3



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

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

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

https://github.com/apache/ignite/pull/3332.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 #3332


commit be91bbf8bcb7e9c71fe6d3bea0f79763f9606558
Author: Krzysztof Chmielewski 
Date:   2017-10-10T14:50:59Z

Fixed "IGNITE-6234 Initialize schemaIds to empty set if schemas field is 
null during the deserialization".

Signed-off-by: nikolay_tikhonov 

commit 08389601728512dc4e7fa5b953f5afe34ae4506f
Author: AMRepo 
Date:   2017-10-10T08:57:20Z

IGNITE-6545: Failure during Ignite Service.cancel() can break normal 
shutdown process. This closes #2807.

(cherry picked from commit 8ffa109)

commit 57547b5afae059a0a6dfa13c08b2e0b6c0e96ebd
Author: devozerov 
Date:   2017-10-13T09:34:35Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit 08798f8e47bdfdd68a557385ed2ce98b4bb1609a
Author: devozerov 
Date:   2017-10-13T11:12:44Z

IGNITE-6605: SQL: common backup filter. This closes #2836.

commit 2b59a241de3935a338842b8fc3221aedc8e11e1d
Author: devozerov 
Date:   2017-10-16T07:33:36Z

IGNITE-6631: Minor improvements to GridH2KeyValueRowOnheap. This closes 
#2855.

commit 98438c954c5f9a08634cf3132361268456397864
Author: devozerov 
Date:   2017-10-16T09:38:54Z

IGNITE-6632: SQL: simplified GridH2Row inheritance tree. This closes #2856.

commit 95b7ab518dd3c3db6fcc5142c2ee85da2516c2b6
Author: devozerov 
Date:   2017-10-16T10:37:11Z

IGNITE-6634: Removed IgniteDistributedJoinTestSuite. It's tests are 
distributed between "Query" and "Query 2" suites. This closes #2857.

commit 9c91deff877ebc0eed84559d4abca71408e3cb0a
Author: devozerov 
Date:   2017-10-16T13:46:13Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit 911ab7ab7a8a6968d219b053adb2338477738506
Author: Alexey Popov 
Date:   2017-10-17T11:45:42Z

IGNITE-6627 .NET: Fix serialization of enums within generic collections

* Fix EnumEqualityComparer serialization
* Fix enum arrays serialization
* Fix empty objects missing metadata

This closes #2864

commit 3ba374c319ac7048a05871692060e2f143d6acdf
Author: Alexey Kuznetsov 
Date:   2017-10-06T17:11:37Z

IGNITE-6463 Web Console: Fixed output of big numbers in SQL query results.
(cherry picked from commit 35589a7)

commit b67feb0f175bfbd6ffbefe82a8d693c8ab7d4213
Author: Vasiliy Sisko 
Date:   2017-10-09T10:55:23Z

IGNITE-5767 Web console: Use byte array type instead of java.lang.Object 
for binary JDBC types.
(cherry picked from commit 3184437)

commit 8e1560322b87d79b3d3250832a3969ac4032d6fc
Author: Alexey Kuznetsov 
Date:   2017-10-06T18:10:08Z

IGNITE-6574 Remove pending requests in case STATUS_AUTH_FAILURE && 
credentials == null.
(cherry picked from commit 85261a3)

commit 7a0300ae35894c389b126e95615f720a99a3d360
Author: devozerov 
Date:   2017-10-18T11:18:08Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

commit ad01f9b099d0bf92537378859ad6d5a52de57748
Author: Alexey Kuznetsov 
Date:   2017-10-19T02:43:20Z

IGNITE-6647 Web Console: Implemented support of schema migration scripts.
(cherry picked from commit c65399c)

commit 0c66344bc752dac98b256dd140fcab95d1662862
Author: Pavel Tupitsyn 
Date:   2017-10-19T09:36:39Z

IGNITE-6627 .NET: Fix repeated known metadata updates

This closes #2876

commit 1b8abd214ed2afcd3fd1f6a4c71a19d6fe1a4b01
Author: Alexey Kuznetsov 
Date:   2017-10-20T04:23:23Z

IGNITE-6647 Added missing Mongo injector.
(cherry picked from commit 173ecef)

commit a221066b3d029afc392be704a810c0e830fc0c49
Author: Alexey Kuznetsov 
Date:   2017-10-20T14:15:02Z

IGNITE-6647 Web Console: Added folder for modules migrations.
(cherry picked from commit 3700717)

commit da8a9d5a968ba071697a28adb01bc59f80d1893c
Author: Pavel Tupitsyn 
Date:   2017-10-23T08:55:33Z

Merge branch 'ignite-2.3.1' into ignite-2.3.2

# Conflicts:
#   
modules/platforms/dotnet/Apache.Ignite.Core.Tests/Apache.Ignite.Core.Tests.csproj

commit 69fdac3acf768ecb9df80d4412c4de5ffd5bc4f5
Author: Dmitriy Shabalin 
Date:   2017-10-23T09:09:47Z

IGNITE-5909 Added list editable component.
(cherry picked from commit 01daee6)

commit 4a2c38333c112d4956d6394667672c1470503435
Author: apopov 
Date:   2017-10-24T08:56:33Z

IGNITE-6362 NPE in Log4J2Logger

commit 089ebecb3e5962c7a38afd01bd18c77feb23d155
Author: vsisko 
Date:   2017-10-25T04:23:11Z

IGNITE-6671 Web Agent: Fixed data type conversion for Oracle NUMBER(N) data 
types.
(cherry picked from commit 93be8ea)

commit 1e56de86525a79c895eba2d839b7887b61979b07
Author: Denis Mekhanikov 
Da

[GitHub] ignite pull request #3301: IGNITE-7217: Add abilities to monitor custom thre...

[slukyano]

Github user slukyano closed the pull request at:

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


---