Re: [CANCEL] [VOTE] Apache Ignite 2.1.0 RC1

[Konstantin Boudnik]

Won't the release manager be the "who"?
--
  With regards,
Konstantin (Cos) Boudnik
2CAC 8312 4870 D885 8616  6115 220F 6980 1F27 E622

Disclaimer: Opinions expressed in this email are those of the author,
and do not necessarily represent the views of any company the author
might be affiliated with at the moment of writing.


On Mon, Jul 17, 2017 at 4:25 PM, Denis Magda  wrote:
> Guys, what’s the status? Who and when is going to send the next build for 
> vote?
>
> —
> Denis
>
>> On Jul 17, 2017, at 5:50 AM, Vladimir Ozerov  wrote:
>>
>> Officially cancelling the vote.
>>
>> -- Forwarded message --
>> From: Denis Magda 
>> Date: Sat, Jul 15, 2017 at 4:48 PM
>> Subject: Re: [VOTE] Apache Ignite 2.1.0 RC1
>> To: "dev@ignite.apache.org" 
>>
>>
>> -1
>>
>> Because of the lgpl libraries issue. Please fix the bug and restart the
>> vote.
>>
>> Denis
>>
>> On Saturday, July 15, 2017, Ilya Suntsov  wrote:
>>
>>> Lgpl binaries should not to be in svn. This build will be removed.
>>>
>>> 15 июля 2017 г. 1:52 PM пользователь "Sergey Kozlov" >> >
>>> написал:
>>>
 Igniters

 Could someone explain why we include LGPL binary fabric [1] in the
>>> release?
 Either it was a mistake or we should upload also SHA1/MD5/ASC checksums
>>> as
 well


 [1]
 https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc1/
 apache-ignite-fabric-lgpl-2.1.0-bin.zip

 On Fri, Jul 14, 2017 at 8:45 PM, Vladimir Ozerov >> >
 wrote:

> gniters!
>
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc1/
>
> Git tag name is
> 2.1.0-rc1
>
> This release includes the following changes:
>
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync()
>>> mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm
 optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can
>>> be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for
>>> Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
>
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
>
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
>
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import
>> model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%
>>> 3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc1
>
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc1
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.1.0-rc1
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc1 (explain why)
>
> This vote will go for 72 hours.
>
> Vladimir.
>



 --
 Sergey Kozlov
 GridGain Systems
 www.gridgain.com

>>>
>

Pages metric report

[Sergey Puchnin]

Hi All,

I have just started learning and working with Ignite and I'm about to rise
IGNITE JIRAs for next requirements.
Could you please check maybe there are already exists.
Would it be significant overhead for a cluster?

#1 For tuning system performance it'd be great to get detail information
about memory and IO that using for cache and partition level.
For example, it's possible to save (or share via bean ?) every 15-30-60
minutes "metric report" with main checkpoints:
>  * How many DataPages and IndexesPages are exist in memory and LFS?
>  * How many pages were evicted, loaded since last report (cluster start)?
>  * How many pages were presented in every free list?
>  * How many MIN, AVG, MAX direct, indirect counters are in pages?
>  * How many entities are in the cache, partition and what size they are?
>  * How many get, put, update operations were executed?

#2 With information from "metric report" it'd be possible to analyse memory
consuming and estimating system limits.
For example, WebConsole can show information for every cache:
>  how fast has it grown?
>  how long it'd be possible to keep all data in memory?
>  when should be added new hard disks?

Thanks a lot,
Sergey

Re: usage analytics

[dsetrakyan]

I would try to ping legal again and see if they respond. If not, I think we 
will need to come up with a simpler approach, that does not require legal 
approval.

⁣D.​

On Jul 18, 2017, 2:23 PM, at 2:23 PM, Nikita Ivanov  wrote:
>Igniters,
>Just a quick update. I haven't gotten response from ASF Legal on this
>thread and I frankly don't know how to proceed here. What's the process
>to
>arrive to a decision point here?
>
>Thanks!
>--
>Nikita Ivanov
>
>
>On Mon, Jul 10, 2017 at 3:11 PM, Konstantin Boudnik 
>wrote:
>
>> On Sat, Jul 08, 2017 at 11:04AM, Nikita Ivanov wrote:
>> > Cos,
>> > Based on my experience having it off by default negates the entire
>> > purpose... We need statistically meaningful data set to make any
>> inferences
>> > from it. Moreover, if we are going to ask folks to turn it on it
>will
>> > significantly skew the resulting data set anyways and show full
>picture.
>> I
>> > think "on" by default is the better option if we are to collect
>usage
>> stats
>> > to begin with.
>>
>> yes, sure. But having this "on" by default is likely to expose us to
>> another
>> shit-storm down the road. An interesting dilemma to have indeed. In
>my
>> experience, whenever I install something like a browser or an
>operating
>> system, it would ask if I want to make the particular piece of
>software
>> better
>> by sending back some anonymized stats. Basically, I am given a way to
>> explicitly opt-out if I wish.
>>
>> By turning the feature "on" by default is like saying: "we'll be
>collecting
>> some stats, but if you don't want to you can go here and there and
>disable
>> the
>> collection. Oh, and by the way - you need to go and figure out the
>exact
>> steps
>> to disable it."
>>
>> > Also, I want to re-iterate it again to avoid misunderstanding:
>there is
>> no
>> > proposal nor will there be a technical way to attribute collected
>data
>> back
>> > to a certain company. That's not what this is all about. We should
>only
>> be
>> > interested in aggregated stats (community size, geo information,
>language
>> > information, components usage).
>>
>> Yes, I think it is clear, but never hurts to re-iterate.
>>
>> Cos
>>
>> > Thoughts?
>> >
>> > --
>> > Nikita Ivanov
>> > Founder & CTO
>> > GridGain Systems
>> >
>> > On Fri, Jul 7, 2017 at 8:17 PM, Konstantin Boudnik 
>> wrote:
>> >
>> > > Actually, that should be OFF by default. It sounds like this
>reduce the
>> > > amount
>> > > of the data collected, but this would address the concerns of
>companies
>> > > like
>> > > Roman's. I know for sure that a few of my clients would sue my
>ass out
>> of
>> > > existence if I gave them the platform collecting their
>data-centers
>> info.
>> > >
>> > > Let's have it, set if off by default and document and easy way to
>turn
>> it
>> > > off.
>> > > Then start making rounds asking our user base to share _some_ of
>the
>> stats
>> > > with the community, so we can track the growth of the install
>base,
>> etc.
>> > >
>> > > Cos
>> > >
>> > > On Thu, Jul 06, 2017 at 08:20AM, Nikita Ivanov wrote:
>> > > > The idea so far is to have a single system property in
>configuration
>> that
>> > > > turns this off completely. I envision that this will be
>prominently
>> > > > featured on Ignite website so that everyone who would like to
>> disable it
>> > > -
>> > > > can do it in seconds.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > --
>> > > > Nikita Ivanov
>> > > > Founder & CTO
>> > > > GridGain Systems
>> > > >
>> > > > On Wed, Jul 5, 2017 at 9:27 PM, Roman Shtykh
>
>> wrote:
>> > > >
>> > > > > Nikita,
>> > > > >
>> > > > > Sending and storing (somewhere the company cannot securely
>handle)
>> any
>> > > > > information (OS version, IP addresses, etc.) that can be used
>to
>> > > compromise
>> > > > > the services would be unacceptable.
>> > > > > Turning it off might be ok (possibly through the cluster
>settings,
>> not
>> > > via
>> > > > > globally-accessible site), but the thing that there's a risk
>some
>> > > > > information can leak outside (for any reason, starting from a
>human
>> > > > > mistake) is scary.
>> > > > >
>> > > > > -- Roman
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thursday, July 6, 2017 12:38 PM, Nikita Ivanov <
>> > > niva...@gridgain.com>
>> > > > > wrote:
>> > > > >
>> > > > >
>> > > > > Roman,
>> > > > > Thanks for the feedback. What are those questions
>specifically?
>> Are IP
>> > > > > addresses and OS is what causing it?
>> > > > >
>> > > > > Thanks!
>> > > > >
>> > > > > --
>> > > > > Nikita Ivanov
>> > > > > Founder & CTO
>> > > > > GridGain Systems
>> > > > >
>> > > > > On Wed, Jul 5, 2017 at 6:15 PM, Roman Shtykh
>> > > > >
>> > > > > wrote:
>> > > > >
>> > > > > NIkita,
>> > > > >
>> > > > > While this will help improve Ignite, it will prevent its
>adoption
>> by
>> > > many
>> > > > > projects -- sending and retaining IP adresses, OS versions,
>etc.
>> raises
>> > 

[jira] [Created] (IGNITE-5780) DDL: support custom schema creation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-5780:
---

 Summary: DDL: support custom schema creation
 Key: IGNITE-5780
 URL: https://issues.apache.org/jira/browse/IGNITE-5780
 Project: Ignite
  Issue Type: New Feature
Reporter: Denis Magda
 Fix For: 2.3


Presently if the one creates a SQL table using DDL "CREATE TABLE" command then 
the table will be bound to the default "PUBLIC" schema. All the tables created 
this way will fall under this rule.

Ignite has to support the following:
* custom schema creation with "CREATE SCHEMA" command.
* provide an ability to assign any table created with "CREATE TABLE" name to a 
custom schema.
* schema and table configured this way has to survive restarts meaning that 
Ignite Persistent Store has to preserve the configuration parameters.




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

Re: usage analytics

[Nikita Ivanov]

Igniters,
Just a quick update. I haven't gotten response from ASF Legal on this
thread and I frankly don't know how to proceed here. What's the process to
arrive to a decision point here?

Thanks!
--
Nikita Ivanov


On Mon, Jul 10, 2017 at 3:11 PM, Konstantin Boudnik  wrote:

> On Sat, Jul 08, 2017 at 11:04AM, Nikita Ivanov wrote:
> > Cos,
> > Based on my experience having it off by default negates the entire
> > purpose... We need statistically meaningful data set to make any
> inferences
> > from it. Moreover, if we are going to ask folks to turn it on it will
> > significantly skew the resulting data set anyways and show full picture.
> I
> > think "on" by default is the better option if we are to collect usage
> stats
> > to begin with.
>
> yes, sure. But having this "on" by default is likely to expose us to
> another
> shit-storm down the road. An interesting dilemma to have indeed. In my
> experience, whenever I install something like a browser or an operating
> system, it would ask if I want to make the particular piece of software
> better
> by sending back some anonymized stats. Basically, I am given a way to
> explicitly opt-out if I wish.
>
> By turning the feature "on" by default is like saying: "we'll be collecting
> some stats, but if you don't want to you can go here and there and disable
> the
> collection. Oh, and by the way - you need to go and figure out the exact
> steps
> to disable it."
>
> > Also, I want to re-iterate it again to avoid misunderstanding: there is
> no
> > proposal nor will there be a technical way to attribute collected data
> back
> > to a certain company. That's not what this is all about. We should only
> be
> > interested in aggregated stats (community size, geo information, language
> > information, components usage).
>
> Yes, I think it is clear, but never hurts to re-iterate.
>
> Cos
>
> > Thoughts?
> >
> > --
> > Nikita Ivanov
> > Founder & CTO
> > GridGain Systems
> >
> > On Fri, Jul 7, 2017 at 8:17 PM, Konstantin Boudnik 
> wrote:
> >
> > > Actually, that should be OFF by default. It sounds like this reduce the
> > > amount
> > > of the data collected, but this would address the concerns of companies
> > > like
> > > Roman's. I know for sure that a few of my clients would sue my ass out
> of
> > > existence if I gave them the platform collecting their data-centers
> info.
> > >
> > > Let's have it, set if off by default and document and easy way to turn
> it
> > > off.
> > > Then start making rounds asking our user base to share _some_ of the
> stats
> > > with the community, so we can track the growth of the install base,
> etc.
> > >
> > > Cos
> > >
> > > On Thu, Jul 06, 2017 at 08:20AM, Nikita Ivanov wrote:
> > > > The idea so far is to have a single system property in configuration
> that
> > > > turns this off completely. I envision that this will be prominently
> > > > featured on Ignite website so that everyone who would like to
> disable it
> > > -
> > > > can do it in seconds.
> > > >
> > > > Thoughts?
> > > >
> > > > --
> > > > Nikita Ivanov
> > > > Founder & CTO
> > > > GridGain Systems
> > > >
> > > > On Wed, Jul 5, 2017 at 9:27 PM, Roman Shtykh 
> wrote:
> > > >
> > > > > Nikita,
> > > > >
> > > > > Sending and storing (somewhere the company cannot securely handle)
> any
> > > > > information (OS version, IP addresses, etc.) that can be used to
> > > compromise
> > > > > the services would be unacceptable.
> > > > > Turning it off might be ok (possibly through the cluster settings,
> not
> > > via
> > > > > globally-accessible site), but the thing that there's a risk some
> > > > > information can leak outside (for any reason, starting from a human
> > > > > mistake) is scary.
> > > > >
> > > > > -- Roman
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thursday, July 6, 2017 12:38 PM, Nikita Ivanov <
> > > niva...@gridgain.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > Roman,
> > > > > Thanks for the feedback. What are those questions specifically?
> Are IP
> > > > > addresses and OS is what causing it?
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --
> > > > > Nikita Ivanov
> > > > > Founder & CTO
> > > > > GridGain Systems
> > > > >
> > > > > On Wed, Jul 5, 2017 at 6:15 PM, Roman Shtykh
>  > > >
> > > > > wrote:
> > > > >
> > > > > NIkita,
> > > > >
> > > > > While this will help improve Ignite, it will prevent its adoption
> by
> > > many
> > > > > projects -- sending and retaining IP adresses, OS versions, etc.
> raises
> > > > > tons of questions when considering to use Ignite. Even if it can be
> > > opted
> > > > > out.
> > > > > -- Roman
> > > > >
> > > > >
> > > > > On Thursday, July 6, 2017 5:38 AM, Nikita Ivanov <
> > > nivano...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > >  Igniters,
> > > > > I would like to kick off the discussion on the idea of collecting
> > > Ignite
> > > > > usage statistics. The basic idea behind this 

Re: [VOTE] Apache Ignite 2.1.0 RC2

[Valentin Kulichenko]

+1 (binding)

On Tue, Jul 18, 2017 at 11:40 AM, Denis Magda  wrote:

> +1 (binding)
>
> —
> Denis
>
> > On Jul 17, 2017, at 9:42 PM, Vladimir Ozerov 
> wrote:
> >
> > Igniters!
> >
> > We have uploaded a 2.1.0 release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc2/
> >
> > Git tag name is
> > 2.1.0-rc2
> >
> > This release includes the following changes:
> >
> > Ignite:
> > * Persistent cache store
> > * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> > * Deprecated IgniteConfiguration.marshaller
> > * Updated Lucene dependency to version 5.5.2
> > * Machine learning: implemented K-means clusterization algorithm
> optimized
> > for distributed storages
> > * SQL: CREATE TABLE and DROP TABLE commands support
> > * SQL: New thin JDBC driver
> > * SQL: Improved performance of certain queries, when affinity node can be
> > calculated in advance
> > * SQL: Fixed return type of AVG() function
> > * SQL: BLOB type support added to thick JDBC driver
> > * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> > * SQL: Added FieldsQueryCursor interface to get fields metadata for
> > SqlFieldsQuery
> > * ODBC: Implemented DML statement batching
> > * Massive performance and stability improvements
> >
> > Ignite.NET:
> > * Automatic remote assembly loading
> > * NuGet-based standalone node deployment
> > * Added conditional data removeal via LINQ DeleteAll
> > * Added TimestampAttribute to control DateTime serialization mode
> > * Added local collections joins support to LINQ.
> >
> > Ignite CPP:
> > * Added Compute::Call and Compute::Broadcast methods
> >
> > Web Console:
> > * Implemented support for UNIQUE indexes for key fields on import model
> > from RDBMS
> > * Added option to show full stack trace on Queries screen
> > * Added PK alias generation on Models screen.
> >
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> > 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%
> > 20resolved)
> >
> > DEVNOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc2
> >
> > RELEASE NOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc2
> >
> > Please start voting.
> >
> > +1 - to accept Apache Ignite 2.1.0-rc2
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 2.1.0-rc2 (explain why)
> >
> > This vote will go for 72 hours.
>
>

Re: [VOTE] Apache Ignite 2.1.0 RC2

[Denis Magda]

+1 (binding)

—
Denis

> On Jul 17, 2017, at 9:42 PM, Vladimir Ozerov  wrote:
> 
> Igniters!
> 
> We have uploaded a 2.1.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.1.0-rc2/
> 
> Git tag name is
> 2.1.0-rc2
> 
> This release includes the following changes:
> 
> Ignite:
> * Persistent cache store
> * Added IgniteFuture.listenAsync() and IgniteFuture.chainAsync() mehtods
> * Deprecated IgniteConfiguration.marshaller
> * Updated Lucene dependency to version 5.5.2
> * Machine learning: implemented K-means clusterization algorithm optimized
> for distributed storages
> * SQL: CREATE TABLE and DROP TABLE commands support
> * SQL: New thin JDBC driver
> * SQL: Improved performance of certain queries, when affinity node can be
> calculated in advance
> * SQL: Fixed return type of AVG() function
> * SQL: BLOB type support added to thick JDBC driver
> * SQL: Improved LocalDate, LocalTime and LocalDateTime support for Java 8
> * SQL: Added FieldsQueryCursor interface to get fields metadata for
> SqlFieldsQuery
> * ODBC: Implemented DML statement batching
> * Massive performance and stability improvements
> 
> Ignite.NET:
> * Automatic remote assembly loading
> * NuGet-based standalone node deployment
> * Added conditional data removeal via LINQ DeleteAll
> * Added TimestampAttribute to control DateTime serialization mode
> * Added local collections joins support to LINQ.
> 
> Ignite CPP:
> * Added Compute::Call and Compute::Broadcast methods
> 
> Web Console:
> * Implemented support for UNIQUE indexes for key fields on import model
> from RDBMS
> * Added option to show full stack trace on Queries screen
> * Added PK alias generation on Models screen.
> 
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.1%20AND%20(status%20%3D%20closed%20or%20status%20%3D%
> 20resolved)
> 
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.1.0-rc2
> 
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.1.0-rc2
> 
> Please start voting.
> 
> +1 - to accept Apache Ignite 2.1.0-rc2
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.1.0-rc2 (explain why)
> 
> This vote will go for 72 hours.

Fwd: July 19 webinar: Distributed ACID transactions in Apache® Ignite™

[Denis Magda]

Cross-posting to the dev list

> Begin forwarded message:
> 
> From: Dieds 
> Subject: July 19 webinar: Distributed ACID transactions in Apache® Ignite™
> Date: July 18, 2017 at 9:50:52 AM PDT
> To: u...@ignite.apache.org
> Reply-To: u...@ignite.apache.org
> 
> Igniters, Akmal B. Chaudhri will host a webinar tomorrow (July 19 at 11 a.m.
> Pacific time) during which he'll take attendees on a deep-dive into the
> Apache Ignite architecture's ACID-compliant transactional subsystem.
> Register here: http://bit.ly/2tCWvlL 
> 
> It will be recorded and that link above will allow you to view the
> presentation afterward. 
> 
> At the end of this session, you will have a better understanding of why
> companies in many industries, including large banks and financial
> institutions, trust Apache Ignite and make it their platform of choice. 
> 
> 
> 
> --
> View this message in context: 
> http://apache-ignite-users.70518.x6.nabble.com/July-19-webinar-Distributed-ACID-transactions-in-Apache-Ignite-tp15073.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.

[GitHub] ignite pull request #2319: IGNITE-5775 JobsProcessor: Remove job from active...

[ezhuravl]

GitHub user ezhuravl opened a pull request:

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

IGNITE-5775 JobsProcessor: Remove job from activeJobs before invoke o…

…nCollision

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

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

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

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


commit 23cb1312faa172d7dd1a0cee088b39a69568dec5
Author: Evgenii Zhuravlev 
Date:   2017-07-18T16:46:36Z

IGNITE-5775 JobsProcessor: Remove job from activeJobs before invoke 
onCollision




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

Re: New method for MemoryMetrics: segment fill variance

[Dmitriy Setrakyan]

Ivan,

How about renaming it to hashFunctionScore? This will be more digestable to
users. "segmentFillVariance" sounds too scientific even to me.

D.

On Tue, Jul 18, 2017 at 10:39 AM, Ivan Rakov  wrote:

> Hello Igniters,
>
> I want to propose one more method for memory metrics -
> segmentFillVariance, float value from 0.0 to 1.0.
>
> Motivation: when persistence is enabled, we split memory policy into K
> equal segments (K = concurrency level). We calculate hash of pageId to
> determine segment where page will be stored.
> Pages eviction to disk starts when segment is full. If hash function is
> bad enough, one segment can overflow when there are lots of free space, and
> evictions can start too early. We want to be able to distinguish such
> situations.
>
> I propose to calculate segmentFillVariance as difference between maximum
> and minimum percentage of segment fill. Greater variance signals about
> worse hash function.
>
> Thoughts?
>
> --
> Best Regards,
> Ivan Rakov
>
>

[jira] [Created] (IGNITE-5779) Incorrect mapping of smallint cassandra type.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-5779:


 Summary: Incorrect mapping of smallint cassandra type.
 Key: IGNITE-5779
 URL: https://issues.apache.org/jira/browse/IGNITE-5779
 Project: Ignite
  Issue Type: Bug
  Components: cassandra
Reporter: Andrew Mashenkov


Looks like we map Java SHORT types to Cassandra INT type.
This causes an exception if user uses Cassandra SMALLINT type:
CodecNotFoundException: [smallint <-> java.lang.Integer] with Cassandra

See discussion on userlist for details.
 
[1] 
http://apache-ignite-users.70518.x6.nabble.com/CodecNotFoundException-smallint-lt-gt-java-lang-Integer-with-Cassandra-td14938.html



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

[GitHub] ignite pull request #2318: checkpoint marker guaranteed read

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

checkpoint marker guaranteed read



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

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

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

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


commit 18bdfe96a1e579371108c661e3374183c58a296d
Author: Alexey Goncharuk 
Date:   2017-07-13T12:42:30Z

Fixed NPE in tests

commit d9ed07c67e4a4ff3a9de543cbe039ac2a48f03a0
Author: Sergey Chugunov 
Date:   2017-07-13T14:32:06Z

Functionality of muted test is debated now

commit 871d9260f3b32bed5273852dbdb74c758f73d383
Author: Sergey Chugunov 
Date:   2017-07-13T15:34:01Z

Functionality of GridVersionSelfTest is debated now

commit 2788a740c9aec88d14808d5927a346d121ad42b1
Author: Alexey Goncharuk 
Date:   2017-07-14T09:23:42Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-2.1.3

commit 1e7e692bd4ce0fe2e092117190b59382840317a7
Author: Alexey Goncharuk 
Date:   2017-07-14T09:25:08Z

Merge branch 'ignite-2.1.3' of https://github.com/gridgain/apache-ignite 
into ignite-2.1.3

commit 9fa78849c1ecc45fa56f518ad229e76725c27790
Author: Andrey V. Mashenkov 
Date:   2017-07-14T11:12:29Z

IGNITE-4831: Add an option to disable MBeans. This closes #2265.

(cherry picked from commit 7283edb)

commit d5cc82cb09cf37da783c9bcfbf6743b8910ceb30
Author: Sergey Chugunov 
Date:   2017-07-14T11:52:09Z

GridCacheAbstractNodeRestartSelfTest stopping all grids after each test to 
prevent subsequent test failures when one test fails or hangs

commit 8f1d732fc8065e59a29bb538456194d7f4edd3e9
Author: Sergey Chugunov 
Date:   2017-07-14T11:52:17Z

Merge branch 'ignite-2.1.3' of https://github.com/gridgain/apache-ignite 
into ignite-2.1.3

commit 1d75560f9f418628da7d212207267482a1ea16aa
Author: devozerov 
Date:   2017-07-14T13:07:49Z

Merge branch 'master' into ignite-2.1.3

commit e7ed26b6d305485d3a48ffcca0b9f4069e1fad30
Author: Sergey Chugunov 
Date:   2017-07-14T14:04:51Z

Test configuration fix to pass validation.

commit b32800a0ec573fb60b77bd00cb04578c5114233b
Author: Alexey Goncharuk 
Date:   2017-07-14T17:17:15Z

Corrected benchmark output

commit 2b50486983fcda8d4b599d9af33e08673e87668e
Author: dpavlov 
Date:   2017-07-14T18:10:06Z

IGNITE-5515: Tests were enabled to get hangup on TC

commit 310d903a3ae23a2761c5c8339e5cd53ea6a7eb03
Author: Alexey Goncharuk 
Date:   2017-07-17T09:45:20Z

Minor (comments)

commit 0d6b73081725d006947a11bfe787bf01f0e869f4
Author: Ivan Rakov 
Date:   2017-07-17T10:25:58Z

GG-12495 SaveStoreMetadata doesn't work for local cache. Got NPE.

commit a71691ae22e30eea775324363d13e8875be8c4d9
Author: Alexey Goncharuk 
Date:   2017-07-18T09:37:14Z

IGNITE-5774 - Added more information about long-running partition release 
future

commit 4a37d712d6234066102f6d0677d90d45fb3f415d
Author: Sergey Chugunov 
Date:   2017-07-18T11:03:49Z

GG-12505 assertion for checkpoint marker length, guaranteed full read of 
checkpoint marker file




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

New method for MemoryMetrics: segment fill variance

[Ivan Rakov]

Hello Igniters,

I want to propose one more method for memory metrics - 
segmentFillVariance, float value from 0.0 to 1.0.


Motivation: when persistence is enabled, we split memory policy into K 
equal segments (K = concurrency level). We calculate hash of pageId to 
determine segment where page will be stored.
Pages eviction to disk starts when segment is full. If hash function is 
bad enough, one segment can overflow when there are lots of free space, 
and evictions can start too early. We want to be able to distinguish 
such situations.


I propose to calculate segmentFillVariance as difference between maximum 
and minimum percentage of segment fill. Greater variance signals about 
worse hash function.


Thoughts?

--
Best Regards,
Ivan Rakov

[jira] [Created] (IGNITE-5778) Update JobMetrics on each job add/start/finish methods and add possibility to turn out JobMetrics and

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5778:
-

 Summary: Update JobMetrics on each job add/start/finish methods 
and add possibility to turn out JobMetrics and 
 Key: IGNITE-5778
 URL: https://issues.apache.org/jira/browse/IGNITE-5778
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 1.9
Reporter: Evgenii Zhuravlev
 Fix For: 2.2






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

[GitHub] ignite pull request #2317: IGNITE-5776 Add option to turn on filter reachabl...

[ezhuravl]

GitHub user ezhuravl opened a pull request:

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

IGNITE-5776 Add option to turn on filter reachable addresses in TcpCo…

…mmunicationSpi

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

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

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

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






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

[GitHub] ignite pull request #2316: IGNITE-5776 Add option to turn on filter reachabl...

[ezhuravl]

Github user ezhuravl closed the pull request at:

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


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

[jira] [Created] (IGNITE-5777) BLAS integration

[Yury Babak (JIRA)]

Yury Babak created IGNITE-5777:
--

 Summary: BLAS integration
 Key: IGNITE-5777
 URL: https://issues.apache.org/jira/browse/IGNITE-5777
 Project: Ignite
  Issue Type: Task
  Components: ml
Reporter: Yury Babak


Replace all naive computations by BLAS from 5278



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

[GitHub] ignite pull request #2316: IGNITE-5776 Add option to turn on filter reachabl...

[ezhuravl]

GitHub user ezhuravl opened a pull request:

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

IGNITE-5776 Add option to turn on filter reachable addresses in 
TcpCommunicationSpi



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

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

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

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


commit 4cd0a328c5b8d344ac2bce2f081d3d76d8fcefda
Author: Evgenii Zhuravlev 
Date:   2017-07-18T14:51:28Z

IGNITE-5776 Add option to turn on filter reachable addresses in 
TcpCommunicationSpi




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

[jira] [Created] (IGNITE-5776) Add option to turn out filter reachable addresses in TcpCommunicationSpi

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5776:
-

 Summary: Add option to turn out filter reachable addresses in 
TcpCommunicationSpi
 Key: IGNITE-5776
 URL: https://issues.apache.org/jira/browse/IGNITE-5776
 Project: Ignite
  Issue Type: Improvement
Reporter: Evgenii Zhuravlev
Assignee: Evgenii Zhuravlev
 Fix For: 2.2






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

[GitHub] ignite pull request #2315: IGNITE-4800: Lucene query may fails with NPE.

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

IGNITE-4800: Lucene query may fails with NPE.



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

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

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

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


commit 18bdfe96a1e579371108c661e3374183c58a296d
Author: Alexey Goncharuk 
Date:   2017-07-13T12:42:30Z

Fixed NPE in tests

commit d9ed07c67e4a4ff3a9de543cbe039ac2a48f03a0
Author: Sergey Chugunov 
Date:   2017-07-13T14:32:06Z

Functionality of muted test is debated now

commit 871d9260f3b32bed5273852dbdb74c758f73d383
Author: Sergey Chugunov 
Date:   2017-07-13T15:34:01Z

Functionality of GridVersionSelfTest is debated now

commit 2788a740c9aec88d14808d5927a346d121ad42b1
Author: Alexey Goncharuk 
Date:   2017-07-14T09:23:42Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-2.1.3

commit 1e7e692bd4ce0fe2e092117190b59382840317a7
Author: Alexey Goncharuk 
Date:   2017-07-14T09:25:08Z

Merge branch 'ignite-2.1.3' of https://github.com/gridgain/apache-ignite 
into ignite-2.1.3

commit 9fa78849c1ecc45fa56f518ad229e76725c27790
Author: Andrey V. Mashenkov 
Date:   2017-07-14T11:12:29Z

IGNITE-4831: Add an option to disable MBeans. This closes #2265.

(cherry picked from commit 7283edb)

commit d5cc82cb09cf37da783c9bcfbf6743b8910ceb30
Author: Sergey Chugunov 
Date:   2017-07-14T11:52:09Z

GridCacheAbstractNodeRestartSelfTest stopping all grids after each test to 
prevent subsequent test failures when one test fails or hangs

commit 8f1d732fc8065e59a29bb538456194d7f4edd3e9
Author: Sergey Chugunov 
Date:   2017-07-14T11:52:17Z

Merge branch 'ignite-2.1.3' of https://github.com/gridgain/apache-ignite 
into ignite-2.1.3

commit 1d75560f9f418628da7d212207267482a1ea16aa
Author: devozerov 
Date:   2017-07-14T13:07:49Z

Merge branch 'master' into ignite-2.1.3

commit e7ed26b6d305485d3a48ffcca0b9f4069e1fad30
Author: Sergey Chugunov 
Date:   2017-07-14T14:04:51Z

Test configuration fix to pass validation.

commit b32800a0ec573fb60b77bd00cb04578c5114233b
Author: Alexey Goncharuk 
Date:   2017-07-14T17:17:15Z

Corrected benchmark output

commit 2b50486983fcda8d4b599d9af33e08673e87668e
Author: dpavlov 
Date:   2017-07-14T18:10:06Z

IGNITE-5515: Tests were enabled to get hangup on TC

commit 310d903a3ae23a2761c5c8339e5cd53ea6a7eb03
Author: Alexey Goncharuk 
Date:   2017-07-17T09:45:20Z

Minor (comments)

commit 0d6b73081725d006947a11bfe787bf01f0e869f4
Author: Ivan Rakov 
Date:   2017-07-17T10:25:58Z

GG-12495 SaveStoreMetadata doesn't work for local cache. Got NPE.

commit a71691ae22e30eea775324363d13e8875be8c4d9
Author: Alexey Goncharuk 
Date:   2017-07-18T09:37:14Z

IGNITE-5774 - Added more information about long-running partition release 
future

commit e46cf9582bb05c22a45b868c2c78ea7ed4818d62
Author: Andrey V. Mashenkov 
Date:   2017-07-18T12:49:00Z

Forcible node drop makes cluster unstable in some cases. Disable forcible 
node drop by default.

commit cf345b81820fbbcb82e5fcb2283b43ea286a40b4
Author: Andrey V. Mashenkov 
Date:   2017-07-18T12:50:03Z

Partial fix of IGNITE-5473: Introduce troubleshooting logger

commit 3497531849ebecaa1368f70a6ac9535a007305d2
Author: Andrey V. Mashenkov 
Date:   2017-07-18T13:53:53Z

IGNITE-4800: Fix possible NPE in GridLuceneInputStream.




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

[GitHub] ignite pull request #2314: IGNITE-5551 Optimize service deployment assignmen...

[kukushal]

GitHub user kukushal opened a pull request:

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

IGNITE-5551 Optimize service deployment assignments object



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

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

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

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


commit 52b6f7d6402cb23f2f5565e98b4a924dc7e82ee4
Author: Alexey Kukushkin 
Date:   2017-07-11T16:38:28Z

a test for IGNITE-5551

commit c7825365fd70d4b5fc80bc53dd734109b8f6a50f
Author: Alexey Kukushkin 
Date:   2017-07-12T16:30:42Z

some progress on IGNITE-5551

commit 93530d259bae76ed2106d8cccad82c1377c92636
Author: Alexey Kukushkin 
Date:   2017-07-13T10:29:12Z

some progress

commit a35381cf8cec743c750499156d1f89b559d68859
Author: Alexey Kukushkin 
Date:   2017-07-13T17:02:43Z

new design for IGNITE-5551 solution

commit 356fef37c09c899b6be240ff5eb3c42f71693e8e
Author: Alexey Kukushkin 
Date:   2017-07-13T21:06:20Z

small progress

commit 5c3839c50001ee4612f7e477a95ac5dc1095cbe0
Author: Alexey Kukushkin 
Date:   2017-07-14T13:34:11Z

Java changes complete

commit 219f28948d22a36f9292ae34b02e18171486d3cc
Author: oleg-ostanin 
Date:   2017-07-17T13:29:16Z

removed excluding ML sources from assembly file - Fixes #2310.

Signed-off-by: Alexey Goncharuk 

commit e88fcd8d228e2f15187ff05218f3afb242c65fed
Author: devozerov 
Date:   2017-07-17T14:13:16Z

Revert "removed excluding ML sources from assembly file - Fixes #2310."

This reverts commit 219f28948d22a36f9292ae34b02e18171486d3cc.

commit 757a301a08942b14a0efeb29837b09a424ffe2a9
Author: Alexey Kukushkin 
Date:   2017-07-17T17:14:33Z

Merge remote-tracking branch 'gridgain/ignite-2.1.2' into ignite-gg-5551




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

[jira] [Created] (IGNITE-5775) Compute runs one job in MetricsUpdateFrequency per thread after all jobs was submitted(as onCollision is not invokes)

[Evgenii Zhuravlev (JIRA)]

Evgenii Zhuravlev created IGNITE-5775:
-

 Summary: Compute runs one job in MetricsUpdateFrequency per thread 
after all jobs was submitted(as onCollision is not invokes)
 Key: IGNITE-5775
 URL: https://issues.apache.org/jira/browse/IGNITE-5775
 Project: Ignite
  Issue Type: Bug
Reporter: Evgenii Zhuravlev






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

[GitHub] ignite pull request #2313: IGNITE-5772

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-5772



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

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

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

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


commit b12ffd16a18150fadf85442b443d576edc205f10
Author: Ilya Lantukh 
Date:   2017-07-18T12:16:29Z

ignite-5772: WAL redesign - stop flag in FakeRecord.

commit 63451b67b4763ea93e650785d6fefa289d5571eb
Author: Ilya Lantukh 
Date:   2017-07-18T12:43:41Z

ignite-5772: WAL redesign - stop flag in FakeRecord.




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

[jira] [Created] (IGNITE-5774) Print more information about long partition release future

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5774:


 Summary: Print more information about long partition release future
 Key: IGNITE-5774
 URL: https://issues.apache.org/jira/browse/IGNITE-5774
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.0
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.2






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

[GitHub] ignite pull request #2312: IGNITE-5174, list only server nodes for specified...

[zstan]

GitHub user zstan opened a pull request:

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

IGNITE-5174, list only server nodes for specified topology version



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

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

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

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


commit 4a89684f9b73d6b3130dc28fc617c02181315f2e
Author: Evgeny Stanilovskiy 
Date:   2017-07-18T09:13:20Z

IGNITE-5174: list only server nodes for specified topology version




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

[jira] [Created] (IGNITE-5773) Scheduler throwing NullPointerException

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-5773:
-

 Summary: Scheduler throwing NullPointerException
 Key: IGNITE-5773
 URL: https://issues.apache.org/jira/browse/IGNITE-5773
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.0
 Environment: Oracle Hotspot 1.8_121
Ignite 2.0.0
Springmix 4.3.7

Reporter: Mikhail Cherkasov
Assignee: Alexey Goncharuk
Priority: Critical
 Fix For: 2.1


NPE occurs during deploying a service as cluster singleton. Ignite scheduler is 
used as a cron for this purpose, however NPE occurs for ignite version 2.0.0.

Below is the log information for the exception:

2017-06-06 13:21:08 ERROR GridServiceProcessor:495 - Failed to initialize 
service (service will not be deployed): AVxezSbWNphcxa1CYjfP
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.schedule(ScheduleFutureImpl.java:299)
at 
org.apache.ignite.internal.processors.schedule.IgniteScheduleProcessor.schedule(IgniteScheduleProcessor.java:56)
at 
org.apache.ignite.internal.IgniteSchedulerImpl.scheduleLocal(IgniteSchedulerImpl.java:109)
at 
com.mypackage.state.services.MyService.startScheduler(MyService.scala:172)
at com.mypackage.state.services.MyService.init(MyService.scala:149)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.redeploy(GridServiceProcessor.java:1097)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.processAssignment(GridServiceProcessor.java:1698)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.onSystemCacheUpdated(GridServiceProcessor.java:1372)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor.access$300(GridServiceProcessor.java:117)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$ServiceEntriesListener$1.run0(GridServiceProcessor.java:1339)
at 
org.apache.ignite.internal.processors.service.GridServiceProcessor$DepRunnable.run(GridServiceProcessor.java:1753)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
2017-06-06 13:21:08:868 ERROR application - Unable to initialise GRID:
class org.apache.ignite.IgniteException: null
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:949)
at 
org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:122)
at 
com.mypackage.state.mypackage1.InitialiseGrid$$anonfun$apply$1.apply(InitialiseGrid.scala:22)
at 
com.mypackage.state.mypackage1.InitialiseGrid$$anonfun$apply$1.apply(InitialiseGrid.scala:19)
at 
scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:48)
at 
com.mypackage.state.mypackage1.InitialiseGrid$.apply(InitialiseGrid.scala:19)
at com.mypackage.state.Application$.main(Application.scala:54)
at com.mypackage.state.Application.main(Application.scala)
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 sbt.Run.invokeMain(Run.scala:67)
at sbt.Run.run0(Run.scala:61)
at sbt.Run.sbt$Run$$execute$1(Run.scala:51)
at sbt.Run$$anonfun$run$1.apply$mcV$sp(Run.scala:55)
at sbt.Run$$anonfun$run$1.apply(Run.scala:55)
at sbt.Run$$anonfun$run$1.apply(Run.scala:55)
at sbt.Logger$$anon$4.apply(Logger.scala:85)
at sbt.TrapExit$App.run(TrapExit.scala:248)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: null
at 
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7242)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:258)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:189)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:139)
at 
org.apache.ignite.internal.AsyncSupportAdapter.saveOrGet(AsyncSupportAdapter.java:112)
at 
org.apache.ignite.internal.IgniteServicesImpl.deployClusterSingleton(IgniteServicesImpl.java:119)
... 20 more
Caused by: java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.schedule.ScheduleFutureImpl.schedule(ScheduleFutureImpl.java:299)
at 

[jira] [Created] (IGNITE-5772) Race between WAL segment rollover and concurrent log

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-5772:


 Summary: Race between WAL segment rollover and concurrent log
 Key: IGNITE-5772
 URL: https://issues.apache.org/jira/browse/IGNITE-5772
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.1
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.2


The WAL log() and close() are synch-ed as follows:
log: read head, check stop flag, cas head
close: set stop flag, cas head to fake record.
This guarantees that after close() is called, there will be no other records 
appended to the closed segment.
Now consider three threads doing the following operations:
T1: flush(); T2: rollOver(); T3: log();
The sequence of events:
1) T1 does a CAS of head to FakeRecord
2) T3 reads head as FakeRecord, reads stop flag as false
3) T2 attempts to rollOver: CAS stop to true; call flushOrWait(null); call 
flush(null); Since the head is an instance of FakeRecord, the flush(null) 
immediately returns false. This thread waits for written bytes and proceeds
4) T3 successfully does a CAS of head to non-fake record
5) T2 proceeds with rollOver, signals next available and asserts on head.
The invariant above is broken when T2 does not CAS fake record during rollover, 
which allows T3 to append an entry to the closed segment. The solution is to 
change the code so the CAS is always attempted on close even if the current 
head is already a FakeRecord.
Alternatively, we can introduce another type of fake record that will seal the 
WAL segment queue.



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

[GitHub] ignite pull request #1910: IGNITE-5174 client nodes filter func

[zstan]

Github user zstan closed the pull request at:

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


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

Re: New blog post: Implementing Ignite.NET Plugin, interacting with Java

[Pavel Tupitsyn]

Good point, done.

On Tue, Jul 18, 2017 at 2:35 AM, Denis Magda  wrote:

> Pavel, the blog post is well deserved to be mentioned on this
> documentation page!
> https://apacheignite-net.readme.io/docs/plugins  readme.io/docs/plugins>
>
> Please add it using a “callout” block of readme.
>
> —
> Denis
>
> > On Jul 17, 2017, at 3:31 AM, Pavel Tupitsyn 
> wrote:
> >
> > Subj: https://ptupitsyn.github.io/Ignite-Plugin/
> >
> > Pavel
>
>