[jira] [Created] (IGNITE-6305) Need to add update checker to Ignite

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-6305:
-

 Summary: Need to add update checker to Ignite
 Key: IGNITE-6305
 URL: https://issues.apache.org/jira/browse/IGNITE-6305
 Project: Ignite
  Issue Type: Improvement
  Components: general
Reporter: Dmitriy Setrakyan
Priority: Critical
 Fix For: 2.3


# Ignite should provide an update check on node startup, which will report to 
users if there is a new version available. 
# We can also use the update-checker to count Ignite starts, which will allow 
the community to monitor the health of the project.

The design is specified in this dev@ thread (make sure to read all the way to 
the end):
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSS-Ignite-Update-Checker-td21150.html





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

Re: [DISCUSS] Ignite Update Checker

[Dmitriy Setrakyan]

I think it is safe to assume at this point that everyone is in general
agreement, since there are no active objections.

I have filed a ticket for the 2.3 release. Let's try to make it happen:
https://issues.apache.org/jira/browse/IGNITE-6305

D.

On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan 
wrote:

>
>
> On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani 
> wrote:
>
>> Yeah, I guess that's doable as well and requires less management effort
>> than my suggestion. We could use events [1] to store payload data (e.g.
>> IP,
>> version, etc.)
>
>
> Yes, we could use events or some other similar API provided by GA.
>
>
>> What the download page CGI developed in? PHP?
>>
>
> To be honest, no clue. I guess someone in the community can figure it out:
> https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
>
>
>> However, I'm not sure whether storing this data in a 3rd party (Google) is
>> compliant with the ASF policy. I guess it's no biggie, but if there's
>> doubt
>> in the PMC, it's better to ask legal@.
>
>
> I am not sure there is anything to ask about. The whole Ignite website is
> GA enabled, and all we are doing is accessing a standard web page from the
> Ignite web site. The information gathered from GA is available only to the
> Ignite PMC. Frankly, I think legal@ will be very confused by this
> question.
>
> Even ASF website itself uses GA: https://www.apache.org/
> foundation/policies/privacy.html
>
>
>> I think Cos said it's OK; maybe Roman can pitch in.
>>
>
>  Sure, would be nice to hear from Roman as well.
>
>
>> Cheers.
>>
>> [1]
>> https://developers.google.com/analytics/devguides/collection
>> /analyticsjs/events
>>
>> On Sat, Aug 26, 2017 at 12:23 AM, Dmitriy Setrakyan <
>> dsetrak...@apache.org>
>> wrote:
>>
>> > Raul,
>> >
>> > Could point about Javascript, it will not work because it executes in
>> the
>> > browser. This means we need a server-side script, like CGI we are using
>> on
>> > our download page.
>> >
>> > How about this approach. We create something like ignite-version.cgi
>> script
>> > which will invoke a call to GA and then return the latest version.
>> >
>> > This should work, right?
>> >
>> > D.
>> >
>> > On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani 
>> > wrote:
>> >
>> > > Hey Dmitriy and all
>> > >
>> > > Also, since we have GA enabled for the website, we can track how many
>> > times
>> > > > this page was accessed, which will be equal to the number of starts.
>> > This
>> > > > way, the counter information is tracked and monitored by the Ignite
>> > PMC.
>> > >
>> > >
>> > > Unfortunately this won't work because GA is loaded via Javascript on
>> the
>> > > browser, so Google will never receive the page hit.
>> > >
>> > > Given the constraints, the most viable solution is an HTTPS endpoint
>> > > running on ASF infra that Ignite invokes via a GET or POST request.
>> The
>> > > simplest thing is to write each request in a log file, along with the
>> > > timestamp, the version reported by the client, maybe the IP (not sure
>> > about
>> > > the ASF rules about this concerning privacy, I guess it's OK if you
>> make
>> > it
>> > > an opt-in) and a unique node identifier, i.e. a UUID the node creates
>> on
>> > > first startup or something.
>> > >
>> > > This endpoint would need some basic DDoS protection and blacklisting
>> to
>> > > prevent data spoofing.
>> > >
>> > > If we'll be implementing this endpoint anyway, then there's no point
>> > > placing another file on Git or elsewhere for reporting the latest
>> > versions:
>> > > the endpoint itself can return them.
>> > >
>> > > WDYT?
>> > >
>> > > Cheers.
>> > >
>> > > On Fri, Aug 25, 2017 at 9:56 PM, Dmitriy Setrakyan <
>> > dsetrak...@apache.org>
>> > > wrote:
>> > >
>> > > > Cos, Raul,
>> > > >
>> > > > Thanks for the feedback. I completely agree about Maven Central
>> being a
>> > > 3rd
>> > > > party repo (did not think about that initially). All your
>> suggestions
>> > > make
>> > > > sense, but I would like to keep it as simple as possible, and so far
>> > > > everything suggested required GIT dependencies and extra work.
>> > > >
>> > > > How about Yakov's suggestion. We simply add a page to the Ignite
>> > website
>> > > > which will have only the latest version. Every time a node starts,
>> it
>> > > > receives the latest version from the page and suggests that users
>> > upgrade
>> > > > if needed.
>> > > >
>> > > > Also, since we have GA enabled for the website, we can track how
>> many
>> > > times
>> > > > this page was accessed, which will be equal to the number of starts.
>> > This
>> > > > way, the counter information is tracked and monitored by the Ignite
>> > PMC.
>> > > >
>> > > > This approach looks pretty innocent to me and everything is kept and
>> > > > managed within Apache.
>> > > >
>> > > > Thoughts?
>> > > >
>> > > > D.
>> > > >
>> > > >
>> > > > On Fri, Aug 25, 2017 at 11:29 AM, Konstantin Boudnik <
>> 

Re: Annoying extra steps for enabling metrics

[Valentin Kulichenko]

First of all, these are events, not metrics, and to my knowledge Ignite
itself does not expose any metrics that depend on events. The fact that Web
Console (or any other tool) uses events to track and show something is a
different story.

Events API has two parts: listening (one simply registers a listener which
is invoked every time an event is fired) and querying (all events are
stored somewhere and one can query events that happened in the past).

All events are disabled by default for performance reasons, so to listen
for an event you need to enable it via includeEventTypes property. Event
storage is also disabled by default, because if you only listen but never
query, the storage would be a waste memory.

I believe the default behavior is correct. But on the other hand, usability
of Web Console obviously suffers. I think we should do the following to
solve this:
  - Add an ability to enable event storage dynamically. BTW, ability to
enable/disable events in runtime already exists.
  - Use the above in Web Console. I.e., it would dynamically enable
required events and event storage on first connect to the cluster.

This way Web Console will work seamlessly without requiring additional
explicit config changes.

-Val

On Thu, Sep 7, 2017 at 7:34 PM Dmitriy Setrakyan 
wrote:

> On Thu, Sep 7, 2017 at 7:30 PM, Denis Magda  wrote:
>
> > My point is different. Before I had to do this only assuming that “Ignite
> > will spend 99%” sending events:
> >
> >
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > Now the platform forces me to do that (probably thinking that I’m crazy
> if
> > I want to waste resources for metrics and giving one more change to
> > contemplate the decision):
> >
> > 
> >
> >
> >
> > Does the issue make sense to you know?
> >
>
> I understand now. Why did we change this behavior? Can someone comment?
>

[jira] [Created] (IGNITE-6304) Visor CMD: Failed script execution after throttling interval

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-6304:
-

 Summary: Visor CMD: Failed script execution after throttling 
interval
 Key: IGNITE-6304
 URL: https://issues.apache.org/jira/browse/IGNITE-6304
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Affects Versions: 2.1
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
 Fix For: 2.3






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

Fwd: 2.1.4 visor console - activate/deactivate command?

[Dmitriy Setrakyan]

Cross-sending to dev@

Igniters, can we try to include the fixes to the cluster activation command
into 2.3 release, including the renaming suggestion?

https://issues.apache.org/jira/browse/IGNITE-6064

D.
-- Forwarded message --
From: Denis Magda 
Date: Thu, Sep 7, 2017 at 7:49 PM
Subject: Re: 2.1.4 visor console - activate/deactivate command?
To: u...@ignite.apache.org


Hello,

You need to use {ignite}/bin/control.sh script to activate/deactivate the
cluster. Hope this feature will be migrated to the Visor CMD soon.

—
Denis

On Sep 7, 2017, at 9:30 AM, Michael Cherkasov 
wrote:

Hi,
there's no such version like 2.1.4, the latest one is 2.1.

Thanks,
Mike.

2017-09-07 19:00 GMT+03:00 mzingman :

> I've downloaded latest ignite-fabric (2.1.4), and running ignitevisorcmd,
> but
> having trouble finding activate/deactivate grid command (promised in
> Release
> Notes). Please help, thank you.
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
>

Re: Annoying extra steps for enabling metrics

[Dmitriy Setrakyan]

On Thu, Sep 7, 2017 at 7:30 PM, Denis Magda  wrote:

> My point is different. Before I had to do this only assuming that “Ignite
> will spend 99%” sending events:
>
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> Now the platform forces me to do that (probably thinking that I’m crazy if
> I want to waste resources for metrics and giving one more change to
> contemplate the decision):
>
> 
>
>
>
> Does the issue make sense to you know?
>

I understand now. Why did we change this behavior? Can someone comment?

Re: Annoying extra steps for enabling metrics

[Denis Magda]

My point is different. Before I had to do this only assuming that “Ignite will 
spend 99%” sending events:












Now the platform forces me to do that (probably thinking that I’m crazy if I 
want to waste resources for metrics and giving one more change to contemplate 
the decision):


   
   

Does the issue make sense to you know?

—
Denis

> On Sep 7, 2017, at 7:25 PM, Dmitriy Setrakyan  wrote:
> 
> On Thu, Sep 7, 2017 at 7:19 PM, Denis Magda  wrote:
> 
>> Any metric from of org.apache.ignite.events.EventType (cache operations,
>> compute, etc.)
>> 
> 
> If you enable them all, Ignite will spend 99% of its time doing event
> notifications.
> 
> 
>> 
>> —
>> Denis
>> 
>>> On Sep 7, 2017, at 7:15 PM, Dmitriy Setrakyan 
>> wrote:
>>> 
>>> Denis, which metrics are you talking about?
>>> 
>>> On Thu, Sep 7, 2017 at 7:12 PM, Denis Magda  wrote:
>>> 
 Igniters,
 
 It was a surprise for me to reveal that even if the default config is
>> used
 [1] I still will not see the metrics in Web Console or in a custom app.
 However, the config was left unchanged for a while and from the first
>> look
 encompassed everything we need to start getting metrics.
 
 But, after looking into the issue, it was determined that this bean has
>> to
 added explicitly:
 
   
   
   
 
 So, my question, what do we do next? It’s ridiculous to force setting
>> this
 parameter. The NoopEventStorageSpi (default) simply ignores all the
>> events.
 Why doesn’t it accept them, send to the subscribers and skips? Then
>> it’s up
 to a subscriber to decide what to do next.
 
 [1] https://github.com/apache/ignite/blob/master/examples/
 config/example-default.xml 
 
 —
 Denis
>> 
>> 

Re: Annoying extra steps for enabling metrics

[Dmitriy Setrakyan]

On Thu, Sep 7, 2017 at 7:19 PM, Denis Magda  wrote:

> Any metric from of org.apache.ignite.events.EventType (cache operations,
> compute, etc.)
>

If you enable them all, Ignite will spend 99% of its time doing event
notifications.


>
> —
> Denis
>
> > On Sep 7, 2017, at 7:15 PM, Dmitriy Setrakyan 
> wrote:
> >
> > Denis, which metrics are you talking about?
> >
> > On Thu, Sep 7, 2017 at 7:12 PM, Denis Magda  wrote:
> >
> >> Igniters,
> >>
> >> It was a surprise for me to reveal that even if the default config is
> used
> >> [1] I still will not see the metrics in Web Console or in a custom app.
> >> However, the config was left unchanged for a while and from the first
> look
> >> encompassed everything we need to start getting metrics.
> >>
> >> But, after looking into the issue, it was determined that this bean has
> to
> >> added explicitly:
> >>
> >>
> >>
> >>
> >>
> >> So, my question, what do we do next? It’s ridiculous to force setting
> this
> >> parameter. The NoopEventStorageSpi (default) simply ignores all the
> events.
> >> Why doesn’t it accept them, send to the subscribers and skips? Then
> it’s up
> >> to a subscriber to decide what to do next.
> >>
> >> [1] https://github.com/apache/ignite/blob/master/examples/
> >> config/example-default.xml  >> ignite/blob/master/examples/config/example-default.xml>
> >>
> >> —
> >> Denis
>
>

Re: Hello

[Denis Magda]

Hello Maxim,

Granted and welcome to the Ignite community!

Please subscribe to both dev and user lists:
https://ignite.apache.org/community/resources.html#mail-lists

Get familiar with Ignite development process described here:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Instructions on how to contribute can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Project setup in Intellij IDEA:
https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup

Once you got familiar and were able to run a few examples, you should pick
a Jira ticket you would like to start on. Send an email to the dev list sharing 
your JIRA id, so we can add you as a contributor in Jira.

These are the easy tickets to start with:
https://issues.apache.org/jira/browse/IGNITE-4549?jql=project%20%3D%20IGNITE%20AND%20labels%20in%20(newbie)%20and%20status%20%3D%20OPEN

While those are more advanced but appealing:
https://ignite.apache.org/community/contribute.html#pick-ticket

Looking forward to your contributions!

—
Denis

> On Sep 7, 2017, at 10:27 AM, Maxim Neverov  wrote:
> 
> Hello Igniters!
> 
> Could you please grant me the permissions so I can contribute to this
> project?
> My jira account: Maxim Neverov
> 
> 
> 
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Annoying extra steps for enabling metrics

[Denis Magda]

Any metric from of org.apache.ignite.events.EventType (cache operations, 
compute, etc.)

—
Denis

> On Sep 7, 2017, at 7:15 PM, Dmitriy Setrakyan  wrote:
> 
> Denis, which metrics are you talking about?
> 
> On Thu, Sep 7, 2017 at 7:12 PM, Denis Magda  wrote:
> 
>> Igniters,
>> 
>> It was a surprise for me to reveal that even if the default config is used
>> [1] I still will not see the metrics in Web Console or in a custom app.
>> However, the config was left unchanged for a while and from the first look
>> encompassed everything we need to start getting metrics.
>> 
>> But, after looking into the issue, it was determined that this bean has to
>> added explicitly:
>> 
>>
>>
>>
>> 
>> So, my question, what do we do next? It’s ridiculous to force setting this
>> parameter. The NoopEventStorageSpi (default) simply ignores all the events.
>> Why doesn’t it accept them, send to the subscribers and skips? Then it’s up
>> to a subscriber to decide what to do next.
>> 
>> [1] https://github.com/apache/ignite/blob/master/examples/
>> config/example-default.xml > ignite/blob/master/examples/config/example-default.xml>
>> 
>> —
>> Denis

Re: [Meetup] Apache Spark and Ignite for IoT scenarious

[Denis Magda]

Hello Anjaneya, Marco,

Honestly, I’m not aware if the video broadcasting or recording is planned. 
Could you go to the meetup page [1] and raise the question there?

Just in case, here is you can find a list of all upcoming Ignite related events 
[2]. Probably some of them will be in close proximity to you:

[1] https://www.meetup.com/datariders/events/242523245/?a=socialmedia 

[2] https://ignite.apache.org/events.html 


—
Denis

> On Sep 7, 2017, at 12:31 PM, Marco Mistroni  wrote:
> 
> Hi
>  Will there be a podcast to view afterwards for remote EMEA users?
> Kr
> 
> On Sep 7, 2017 12:15 AM, "Denis Magda"  > wrote:
> Folks, 
> 
> Those who are craving for mind food this weekend come over the meetup  - 
> Santa Clara, Sept 9, 9.30 AM:
> https://www.meetup.com/datariders/events/242523245/?a=socialmedia 
> 
> 
> —
> Denis

Re: Annoying extra steps for enabling metrics

[Dmitriy Setrakyan]

Denis, which metrics are you talking about?

On Thu, Sep 7, 2017 at 7:12 PM, Denis Magda  wrote:

> Igniters,
>
> It was a surprise for me to reveal that even if the default config is used
> [1] I still will not see the metrics in Web Console or in a custom app.
> However, the config was left unchanged for a while and from the first look
> encompassed everything we need to start getting metrics.
>
> But, after looking into the issue, it was determined that this bean has to
> added explicitly:
>
> 
> 
> 
>
> So, my question, what do we do next? It’s ridiculous to force setting this
> parameter. The NoopEventStorageSpi (default) simply ignores all the events.
> Why doesn’t it accept them, send to the subscribers and skips? Then it’s up
> to a subscriber to decide what to do next.
>
> [1] https://github.com/apache/ignite/blob/master/examples/
> config/example-default.xml  ignite/blob/master/examples/config/example-default.xml>
>
> —
> Denis

Annoying extra steps for enabling metrics

[Denis Magda]

Igniters,

It was a surprise for me to reveal that even if the default config is used [1] 
I still will not see the metrics in Web Console or in a custom app. However, 
the config was left unchanged for a while and from the first look encompassed 
everything we need to start getting metrics.

But, after looking into the issue, it was determined that this bean has to 
added explicitly:





So, my question, what do we do next? It’s ridiculous to force setting this 
parameter. The NoopEventStorageSpi (default) simply ignores all the events. Why 
doesn’t it accept them, send to the subscribers and skips? Then it’s up to a 
subscriber to decide what to do next.

[1] 
https://github.com/apache/ignite/blob/master/examples/config/example-default.xml
 


—
Denis

RE: Massive commit sizes for processes with local Ignite Grid servers

[Raymond Wilson]

Hi Alexey,



The server itself is pretty simple, it runs up and waits for requests
without preloading aything.



Once the process has initialized everything (except for activating the
Ignite server node), the Commit Size is around 750Mb in size. It then
stalls waiting for Active to become true, at which point it creates four
caches on the server. Once this has completed, Commit Size grows to around
3Gb.



The odd thing here is that there shouldn’t really be anything else loaded
in terms of libraries as it should all be there by the time the node is
activated.



I don’t have any memory constraints on the caches as this should be managed
under the umbrella memory policy provided for the server node as a whole.



I see the same behaviour if I run the server with no persistent data
compared to running it again after processing some 250Mb of data across the
four caches. The commit size itself doesn’t change during operations (as
these are really just the Ignite server node reacting to cache requests
made by another totally separate Ignite client node in another process.



Perhaps 3Gb commit is the minimum amount the Ignite JVM requests?



Thanks,

Raymond.





*From:* Alexey Kukushkin [mailto:kukushkinale...@gmail.com]
*Sent:* Thursday, September 7, 2017 11:45 PM
*To:* u...@ignite.apache.org
*Cc:* dev@ignite.apache.org
*Subject:* Re: Massive commit sizes for processes with local Ignite Grid
servers



Raymond,



So you see 3 "extra" GB that your server app takes. Is it possible your app
really loads additional 3GB of referenced libraries and data besides
Ignite? Did you try temporarily changing the code to NOT start Ignite and
see how much memory such an app takes?



On Thu, Sep 7, 2017 at 1:49 PM, Raymond Wilson 
wrote:

Hi Dmitry,



Thanks for the pointer to the MemoryPolicy.



I added the following:



cfg.MemoryConfiguration = new MemoryConfiguration()

{

SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024,

DefaultMemoryPolicyName = "defaultPolicy",

MemoryPolicies = new[]

{

new MemoryPolicyConfiguration

{

Name = "defaultPolicy",

InitialSize = 128 * 1024 * 1024,  // 128 MB

MaxSize = 1L * 1024 * 1024 * 1024  // 1 GB

}

}

};



After running both servers the commit size peaked at 4Gb for both processes
(with ~430Mb actual allocated memory) which is s significant improvement,
though still seems higher than might be expected.



Thanks,

Raymond.







*From:* Dmitry Pavlov [mailto:dpavlov@gmail.com]
*Sent:* Thursday, September 7, 2017 10:22 PM
*To:* u...@ignite.apache.org; dev@ignite.apache.org
*Subject:* Re: Massive commit sizes for processes with local Ignite Grid
servers



Hi Raymond,



Total memory usage since 2.0 version is determined as sum of heap size and
memory policies MaxSizes (overall segment sizes). If it is not configured
there is 80% of physical RAM is used for each node (before 2.2). In 2.2
this behaviour will be changed.



To run several nodes at one PC it may be required to manually setup Memory
Configuration and Memory Policy(ies).





Hi Igniters, esp. Pavel T.



please share your thoughts. To which Java property value of
SystemCacheMaxSize is now mapped?



Sincerely,

Dmitriy Pavlov



P.S. Please see example of configuration

https://apacheignite-net.readme.io/docs/durable-memory



MemoryPolicies = new[]

{

  new MemoryPolicyConfiguration

  {

Name = "defaultPolicy",

MaxSize = 4L * 1024 * 1024 * 1025  // 4 GB

  }

}



чт, 7 сент. 2017 г. в 12:44, Raymond Wilson :

I tried an experiment where I ran only two instances of the server locally,
this is the result in the Task Manager:





*From:* Raymond Wilson [mailto:raymond_wil...@trimble.com]
*Sent:* Thursday, September 7, 2017 9:21 PM
*To:* u...@ignite.apache.org; 'dev@ignite.apache.org' 
*Subject:* Massive commit sizes for processes with local Ignite Grid servers



I’m running a set of four server applications on a local system to simulate
a cluster.



Each of the servers has the following memory configurations set:



public override void ConfigureRaptorGrid(IgniteConfiguration cfg)

{

cfg.JvmInitialMemoryMb = 512; // Set to minimum advised memory
for Ignite grid JVM of 512Mb

cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb



// Don't permit the Ignite node to use more than 1Gb RAM (handy
when running locally...)

cfg.MemoryConfiguration = new MemoryConfiguration()

{

SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024

};

}



The snap below is from the Windows 10 Task Manager where I have included
the Commit Size value. As can 

Re: [Meetup] Apache Spark and Ignite for IoT scenarious

[Marco Mistroni]

Hi
 Will there be a podcast to view afterwards for remote EMEA users?
Kr

On Sep 7, 2017 12:15 AM, "Denis Magda"  wrote:

> Folks,
>
> Those who are craving for mind food this weekend come over the meetup  -
> Santa Clara, Sept 9, 9.30 AM:
> https://www.meetup.com/datariders/events/242523245/?a=socialmedia
>
> —
> Denis
>

Re: Ignite Benchmarking page on readme.io

[Dmitriy Setrakyan]

Actually, it can be contributed directly to readme.io. Alexey, I just sent
you an invite.

You can create a new page for benchmarking and make it invisible for now,
while you are working on it. If you need us to review it, please send a
direct link to it here.

D.

On Thu, Sep 7, 2017 at 8:26 AM, Anton Vinogradov 
wrote:

> Aleksei,
>
> Good idea.
> Could you please prepare page in MD format and attach link to branch
> containing it to the issue to review before publication?
>
>
>
> On Thu, Sep 7, 2017 at 1:45 PM, Aleksei Zaitsev 
> wrote:
>
> > Hi, guys.
> >
> > Issue[1] stated that we have not any information about Apache Ignite
> > benchmarking on our site https://apacheignite.readme.io. I want to add
> > such a page, but I can’t find appropriate section for it. I suggest to
> make
> > new section named ‘Tests and Benchmarking’ and put all information about
> > benchmaring in section page ‘Perfomance Tests’
> >
> > Thoughts?
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-6278
> >
>

Re: Disable compute job results cache by default

[Dmitriy Setrakyan]

On Thu, Sep 7, 2017 at 8:52 AM, Yakov Zhdanov  wrote:

> Guys, according to this -
> http://apache-ignite-users.70518.x6.nabble.com/Task-manageme
> nt-MapReduce-amp-ForkJoin-performance-penalty-td16542.html
> - I would think that we need to disable result caching by default.0


> Or at least find out why it is so costly.
>

Yakov, I was not aware that we have compute job result caching. Can you
please describe what is being cached?

[GitHub] ignite pull request #2620: Ignite 6235: Add ability to handle CacheObject fr...

[dspavlov]

GitHub user dspavlov opened a pull request:

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

Ignite 6235: Add ability to handle CacheObject from DataRecord in 
standalone WAL iterator

 

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

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

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

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


commit e9e967c5cf2bfc4022ba0fe43db862c8364f63e8
Author: dpavlov 
Date:   2017-09-06T15:47:18Z

IGNITE-6235: Add ability to handle CacheObject from DataRecord in 
standalone WAL iterator
IGNITE-6225: Improve tests of WAL iterator with checking DataRecord entries 
and TxRecords

commit afd3f976989d48e8696f0117a94c10f81224b373
Author: EdShangGG 
Date:   2017-09-06T16:40:49Z

IGNITE-6277 Convert WAL to human readable form
-adding cacheId to toString

Fixes #2605

commit 1aa0bdd174770172a81ddef09981216ec0323351
Author: dpavlov 
Date:   2017-09-07T17:51:48Z

IGNITE-6235: Add ability to handle CacheObject from DataRecord in 
standalone WAL iterator

commit 82b0c764d70f4589ace1c8b0f48ad16a12f01832
Author: dpavlov 
Date:   2017-09-07T17:58:40Z

IGNITE-6235: Add ability to handle CacheObject from DataRecord in 
standalone WAL iterator




---

[GitHub] ignite pull request #2619: IGNITE-2092 Switched to the up-to-date java image...

[max-neverov]

GitHub user max-neverov opened a pull request:

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

IGNITE-2092 Switched to the up-to-date java image which has build-in …

…functionality to detect container CPU limitation

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

$ git pull https://github.com/max-neverov/ignite IGNITE-2092

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

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


commit 48b38c147e5c32b9feb693426be6d27ea6191ab6
Author: Maxim Neverov 
Date:   2017-09-07T17:43:41Z

IGNITE-2092 Switched to the up-to-date java image which has build-in 
functionality to detect container CPU limitation




---

Hello

[Maxim Neverov]

Hello Igniters!

Could you please grant me the permissions so I can contribute to this
project?
My jira account: Maxim Neverov



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: IGNITE-2092: upgrade java

[Nikolai Tikhonov]

Hello,

It sounds common sense. Can you create pull request for this ticket?

On Thu, Sep 7, 2017 at 8:03 AM, Maxim Neverov  wrote:

> Hi Igniters!
>
> I've investigated  the ticket
>    and found out that
> it
> can be fixed by updating java from 8u111 to 8u141 (current). Moreover, the
> image that is used in Dockerfile (FROM java:8) is  deprecated
>    and has no recent java updates.
> As I understand there will be a release soon, so can the java image be
> updated to openjdk:8?
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[GitHub] ignite pull request #2618: IGNITE-6046 Multiple SQL statements in one JDBC c...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-6046  Multiple SQL statements in one JDBC command do not work



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

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

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

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


commit f4c6603799c8752c6ee1ef13c697348fa36f9761
Author: tledkov-gridgain 
Date:   2017-09-04T08:31:28Z

IGNITE-6046: prototype of execution SQL query with multiple SQL statements

commit fc579cb0cb97c52adeb163ab2a719ccf4039e2c6
Author: devozerov 
Date:   2017-09-04T09:26:01Z

Merge branch 'master' into ignite-6046

commit 23509bd2f63fc83ee4aa7556317b3f9d05ae370e
Author: tledkov-gridgain 
Date:   2017-09-04T12:04:50Z

Merge branch '_master' into ignite-6046

commit f43bb01dee136f4e59b6b17ccd6877555aaedab9
Author: tledkov-gridgain 
Date:   2017-09-04T13:03:53Z

IGNITE-6046: prototype of execution SQL query with multiple SQL statements

commit c9670c3ce27ad98574467e0e418be1b1271916fc
Author: tledkov-gridgain 
Date:   2017-09-04T15:26:46Z

IGNITE-6046: save the progress

commit 5cef75bcab5d8f31712b0ad5dcbe53ebca110dc4
Author: tledkov-gridgain 
Date:   2017-09-05T06:53:32Z

IGNITE-6046: save the progress

commit 4c49d4f8489be223627f03c3de1c5a4e45d92e38
Author: tledkov-gridgain 
Date:   2017-09-05T06:54:16Z

Merge branch '_master' into ignite-6046

commit 1c7173a8979f8ef876d522bb1b017287f139f9bc
Author: tledkov-gridgain 
Date:   2017-09-05T08:53:41Z

IGNITE-6046: save the progress

commit 23e7cd395618406e1159d52b1b7c30603bd83a48
Author: tledkov-gridgain 
Date:   2017-09-07T09:39:06Z

Merge branch 'master' into ignite-6046

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/jdbc/thin/JdbcThinStatement.java

commit 44295708f0d46f430680954c9bdb20ae4843d783
Author: tledkov-gridgain 
Date:   2017-09-07T09:39:35Z

IGNITE-6046: add jdbc test

commit 96e22b6cb72a09ef04b78693f2957322e48a1c56
Author: tledkov-gridgain 
Date:   2017-09-07T09:44:34Z

IGNITE-6046: minors

commit 00fc06c5f0ee9a4ee83fee1f734ac5aa6151915b
Author: devozerov 
Date:   2017-09-07T09:46:34Z

Merge remote-tracking branch 'upstream/ignite-6046' into ignite-6046

commit 1d4de2f43c15527df21bf94e0b909d1fb34c3cea
Author: tledkov-gridgain 
Date:   2017-09-07T11:47:35Z

IGNITE-6046: refactoring

commit dbf9a97e1b286c56387ac65864aa2d1b7b829552
Author: tledkov-gridgain 
Date:   2017-09-07T11:50:37Z

Merge remote-tracking branch 'community/ignite-6046' into ignite-6046

commit df43b69b2c88fe7788cbe09865e62cf1ba4f3464
Author: tledkov-gridgain 
Date:   2017-09-07T12:48:43Z

IGNITE-6046: cosmetic

commit 0442727cea44e3287f7aee19f9322e0fda1a5c64
Author: tledkov-gridgain 
Date:   2017-09-07T14:00:08Z

IGNITE-6046: saver progress

commit df05d6387c828347a07b4d8e272c170c16a19b27
Author: tledkov-gridgain 
Date:   2017-09-07T15:45:14Z

IGNITE-6046: fix query cache usage, add tests




---

[GitHub] ignite pull request #2617: IGNITE-6288 NPE on SQL query with parameters on c...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-6288  NPE on SQL query with parameters on custom schema name



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

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

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

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


commit 3dc820a3512fec65058a4a179b9f3756a2a88b38
Author: tledkov-gridgain 
Date:   2017-09-07T08:55:24Z

IGNITE-6288: add test to reproduce

commit 6271e557f4fb352ccc05b7de67e1c1a540d471e9
Author: tledkov-gridgain 
Date:   2017-09-07T16:30:09Z

IGNITE-6288: use schema name instead on cache name on table search




---

[GitHub] ignite pull request #2616: Ignite-gg-12707

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite-gg-12707



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

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

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

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


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

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

(cherry picked from commit d124004)

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

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

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

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

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

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

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

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

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

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

commit 4a1415ad01ff9fde30d5c7c02e6d938f1515178d
Author: Andrey V. Mashenkov 
Date:   2017-04-12T10:01:25Z

IGNITE-4907: Fixed excessive service instances can be started with dynamic 
deployment. This closes #1766.

(cherry picked from commit 0f7ef74)

commit bf1049741f7a64728bd433f78262ba273f969848
Author: Andrey V. Mashenkov 
Date:   2017-04-17T16:00:30Z

IGNITE-4954 - Configurable expiration timeout for Cassandra session. This 
closes #1785.

commit f9ecacc625b458539775e6550bd9b7613ed38f21
Author: dkarachentsev 
Date:   2017-04-28T08:46:23Z

IGNITE-5077 - Support service security permissions

backport from master
(cherry picked from commit 6236b5f)

commit 91c899b909383c78b78b9bf0c8f233b8c75ef29e
Author: Valentin Kulichenko 
Date:   2017-04-28T12:48:57Z

IGNITE-5081 - Removed redundant duplication of permissions in 
SecurityPermissionSetBuilder

commit b48a26b9b1e97fb8eb52c2a2f36005770922ac3d
Author: Valentin Kulichenko 
Date:   2017-04-28T12:53:33Z

IGNITE-5080 - Fixes in SecurityBasicPermissionSet

commit f66c23cbb9a6f2c923ebf75c58f00afaf1c0b5f3
Author: Evgenii Zhuravlev 
Date:   2017-05-03T14:47:45Z

IGNITE-4939 Receive event before cache initialized fix

commit 45b4d6316145d0b4b46713409f5e8fbe55ff4c41
Author: Evgenii Zhuravlev 
Date:   2017-05-04T09:11:37Z

IGNITE-4939 Receive event before cache initialized fix

commit 075bcfca0ea22633be13cd02647e359ad6fdca16
Author: Andrey V. Mashenkov 
Date:   2017-05-04T09:21:04Z

Fix flacky service deployment tests.

commit 25c06b50d46937cb39534cdf4147b862217289a2
Author: rfqu 
Date:   2017-05-02T16:46:44Z

ignite-4220 Support statements for JDBC and Cassandra store

commit 987c182686962673e70398395cb27e94f894713b
Author: nikolay_tikhonov 
Date:   2017-05-15T08:54:16Z

Fixed "IGNITE-5214 ConcurrentModificationException with enable DEBUG log 
level"

Signed-off-by: nikolay_tikhonov 

commit ebc4a1648a80fbbd485e4c351fce9bee163318f9
Author: sboikov 
Date:   2017-05-16T08:30:29Z

DirectByteBufferStreamImpl: converted asserts into exceptions.

(cherry picked from commit 560ef60)

commit 9cd7e0f8d132f9b7c496fe64f75f271ef60da5eb
Author: Alexey Kuznetsov 
Date:   2017-02-09T09:44:41Z

IGNITE-4676 Fixed hang if closure executed nested internal task with 
continuation. Added test.
(cherry picked from commit e7a5307)

commit 43bcc15127bd3fd7ac4e277da6da9e5fb6a855c0
Author: Vasiliy Sisko 
Date:   2017-03-30T04:08:10Z

IGNITE-4838 Fixed internal task detection logic. Added tests.
(cherry picked from commit ba68c6c)

commit 2a818d36395dd1af23acf444adf396b2e2edbede
Author: Konstantin Dudkov 
Date:   2017-05-22T13:28:07Z

Fixed "IGNITE-4205 

Disable compute job results cache by default

[Yakov Zhdanov]

Guys, according to this -
http://apache-ignite-users.70518.x6.nabble.com/Task-management-MapReduce-amp-ForkJoin-performance-penalty-td16542.html
- I would think that we need to disable result caching by default.

Or at least find out why it is so costly.

--Yakov

[jira] [Created] (IGNITE-6303) .NET: GetAll should close query cursor

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6303:
--

 Summary: .NET: GetAll should close query cursor
 Key: IGNITE-6303
 URL: https://issues.apache.org/jira/browse/IGNITE-6303
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


{{QueryCursor}} in Java is closed automatically on {{getAll}} call, we should 
do the same in Ignite.NET.



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

[GitHub] ignite pull request #2593: Ignite-gg-12699

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---

[GitHub] ignite pull request #2615: Ignite-gg-12695

[AMashenkov]

GitHub user AMashenkov opened a pull request:

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

Ignite-gg-12695

fix test

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

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

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

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


commit 3d19bfc2b66574e3945ce17c7a4dfe77d0070b8d
Author: dkarachentsev 
Date:   2016-11-08T11:04:36Z

Merge remote-tracking branch 'origin/ignite-1.6.11' into ignite-1.6.11

commit 1612b6d66fed032182a41e90da71e6b986ae087b
Author: Pavel Tupitsyn 
Date:   2016-11-08T11:07:54Z

.NET: Fix minor analysis warnings

commit e821dc0083003bc81058b1cb223d8a8a2ee44daf
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:09:21Z

IGNITE-2079 (revert commit) GridCacheIoManager eats exception trail if it 
falls into the directed case

commit c2c82ca44befe4570325dd6cf2ba885e0d90596c
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:10:10Z

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

commit 865bbcf0f41a0c4944e0928f1758d43a0eae82c5
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:18:29Z

Revert "Merge remote-tracking branch 'professional/ignite-1.6.11' into 
ignite-1.6.11"

This reverts commit c2c82ca44befe4570325dd6cf2ba885e0d90596c, reversing
changes made to e821dc0083003bc81058b1cb223d8a8a2ee44daf.

commit 9726421ff9efb2b19813b2fd6ad27a3728b5ab1a
Author: Dmitriy Govorukhin 
Date:   2016-11-08T12:59:00Z

  Revert  Revert  Merge remote-tracking branch 'professional/ignite-1.6.11'

commit 5a3a1960fff1dcf32961c45c0ba5149d6748d2fc
Author: Igor Sapego 
Date:   2016-11-08T14:36:35Z

Added license header.

commit f697fb5786fb4ce15f581c465ff0dcb3d2bb7b14
Author: Pavel Tupitsyn 
Date:   2016-11-08T16:13:48Z

IGNITE-4185 .NET: Fix NullReferenceException in IgniteOutputCacheProvider 
when igniteConfiguration is missing

commit 69487f2c375010737311af65750a519b403fc17f
Author: Pavel Tupitsyn 
Date:   2016-11-08T16:38:28Z

.NET: Fix error messages when IgniteConfigurationSection content is missing

commit d88f422aeb02738d676d86ce416551b805ad154e
Author: Andrey Novikov 
Date:   2016-11-09T07:25:38Z

GG-11028 Fixed resolving of host name.

commit ac660dcaa5bf8eb20e7dd4e442e97c1cf548a827
Author: Igor Sapego 
Date:   2016-11-09T12:29:06Z

IGNITE-4183: ODBC Fixed null-values fetching issue.

commit cdae2ab76d403aef9a0bd209fc7497dc6cfdfc08
Author: Igor Sapego 
Date:   2016-11-09T13:25:30Z

IGNITE-3873: Added WiX script to generate ODBC installer.

commit 1093819ac0f3e7a0faacde59919117b8977e6d5b
Author: Igor Sapego 
Date:   2016-11-09T15:19:01Z

IGNITE-4201: Fixed version fix maven step.

commit bac0cba7fddd412dfbff98163afbc15d81d5e0d4
Author: Dmitriy Govorukhin 
Date:   2016-11-10T06:02:41Z

ignite-4044  always authenticate local node

commit 26daa57ca82254d68ac04a7b33223c6eb5ade0e4
Author: sboikov 
Date:   2016-11-10T08:17:29Z

Fixed javadoc.

commit 8b59f4e76138e08e80aa219c1a9cf0c3df6fdb4b
Author: Andrey V. Mashenkov 
Date:   2016-11-10T11:43:00Z

Backport commit of the following:

commit 612eb3daffe608995aac28eed019b3e6ef9d66d3
Author: Aleksei Scherbakov 
Date:   Fri Aug 19 13:28:39 2016 +0300

ignite-2795 Support 'copyOnRead' for SQL queries

commit b7499828c928e02e8e554f960f3754e4d08bfbe0
Author: Anton Vinogradov 
Date:   2016-11-10T13:10:21Z

IGNITE-500 CacheLoadingConcurrentGridStartSelfTest fails (DataStreamer data 
loss at unstable topology in !allowOverwrite mode fixed)

commit baa752660c6eddf27d15a812252b01b5872385de
Author: iveselovskiy 
Date:   2016-11-10T15:47:09Z

IGNITE-4208: Hadoop: Fixed a bug preventing normal secondary file system 
start. This closes #1228.

commit ef9d6cf9e334c35b03dfa42e4ce0680c85a693a4
Author: iveselovskiy 
Date:   2016-11-10T15:47:09Z

IGNITE-4208: Hadoop: Fixed a bug preventing normal secondary file system 
start. This closes #1228.

commit 884b281218d88c028daab25d35c14ee2b41be36e
Author: Pavel Tupitsyn 
Date:   2016-11-10T17:35:15Z

IGNITE-4186 .NET: Fix "Invalid session release request" exception in 
IgniteSessionStateStoreProvider.SetAndReleaseItemExclusive

This closes #1227

commit 

Re: Ignite Benchmarking page on readme.io

[Anton Vinogradov]

Aleksei,

Good idea.
Could you please prepare page in MD format and attach link to branch
containing it to the issue to review before publication?



On Thu, Sep 7, 2017 at 1:45 PM, Aleksei Zaitsev 
wrote:

> Hi, guys.
>
> Issue[1] stated that we have not any information about Apache Ignite
> benchmarking on our site https://apacheignite.readme.io. I want to add
> such a page, but I can’t find appropriate section for it. I suggest to make
> new section named ‘Tests and Benchmarking’ and put all information about
> benchmaring in section page ‘Perfomance Tests’
>
> Thoughts?
>
> [1] https://issues.apache.org/jira/browse/IGNITE-6278
>

[jira] [Created] (IGNITE-6302) Client heap starts constantly growing when server offheap memory gets full

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-6302:
---

 Summary: Client heap starts constantly growing when server offheap 
memory gets full
 Key: IGNITE-6302
 URL: https://issues.apache.org/jira/browse/IGNITE-6302
 Project: Ignite
  Issue Type: Bug
  Components: general, streaming
Affects Versions: 2.1
Reporter: Ksenia Rybakova


Load benchmark is streaming data to grid. Page memory maxSize is set. Sometimes 
IgniteOutOfMemoryException is not thrown at servers when maxSize is reached. 
This is the first problem. The second one - client's heap starts to grow 
constantly after server's offheap memory gets full.

Load config:
- org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark is 
used to stream data
- 1 client, 4 server nodes
- client heap:  -Xms20g -Xmx20g, server heap: -Xms4g -Xmx4g
- memory policy maxSize: 5Gb
- page size: 2Kb
- number of entries to preload: 35M

At some point servers reach max offheap size (number of pages in log doesn't 
change and this number matches 5Gb maxSize). IgniteOutOfMemoryException is not 
thrown and client starts to utilize more and more heap capacity.

All configs are attached.





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

Re: [DISCUSSION] Urgent Ignite bug fix release

[Oleg Ostanin]

We created the release build procedure on Apache CI server according to
this ticket:
https://issues.apache.org/jira/browse/IGNITE-5249
We also changed the checksum calculation method:
https://issues.apache.org/jira/browse/IGNITE-5817

Oleg

On Thu, Sep 7, 2017 at 9:49 AM, 李玉珏@163 <18624049...@163.com> wrote:

> Currently,the latest version is apache-ignite-fabric-2.1.0-bin.zip <
> http://mirrors.hust.edu.cn/apache//ignite/2.1.0/apache-igni
> te-fabric-2.1.0-bin.zip>.
>
> and in http://www.gridgainsystems.com/nexus/content/repositories/
> external/org/apache/ignite/ignite-core/
>
> the latest version is 2.1.4,
>
> As I understand it, add 1 on the version number of 2.1.4, and then publish
> it to the ignite main website to ensure that both versions are
> consistent,is it ok?
>
>
> 在 2017/9/1 下午6:57, Anton Vinogradov 写道:
>
>> Hi,
>>
>> Reasonable question, but I propose to keep 2.2 as a release version for
>> this urgent release, since we never released X.Y.Z version before.
>>
>> Let's discuss this at separate thread.
>> Could you please start it?
>>
>>
>> On Fri, Sep 1, 2017 at 4:49 AM, 李玉珏@163 <18624049...@163.com > 18624049...@163.com>> wrote:
>>
>> Since it's an urgent bugfix version, why can't the version number
>> be defined as 2.1.1 or 2.1.4?
>> After all, functionality has not increased and documents do not
>> require big changes.
>> If the version number is 2.1 series, there is no need to publish a
>> new version of the document.
>>
>>
>>
>> 在 2017/8/28 下午10:19, Anton Vinogradov 写道:
>>
>> Igniters,
>>
>> Seems 2.2 is a urgent bugfix release, so it should be based on
>> 2.1,
>> In this case all other issues with fixVersion = 2.2 should be
>> moved to 2.3.
>>
>> Currently, I see 835 issues with fixVersion = 2.2
>>
>> Seems we should have only 4 issues with fixVersion = 2.2:
>> - Change default max memory size from 80% to 20% -
>> https://issues.apache.org/jira/browse/IGNITE-6182
>> 
>> - Detecting low memory on ignite node startup -
>> https://issues.apache.org/jira/browse/IGNITE-6003
>> 
>> - Backport of improvements to checkpoint algorithm -
>> https://issues.apache.org/jira/browse/IGNITE-??
>> ??
>> - ML profile is missing in 2.1 binary release -
>> https://issues.apache.org/jira/browse/IGNITE-6193
>> 
>>
>> Please correct me in case I've missed something.
>>
>> Ivan,
>>
>> Let's include to the release tickets with optimizations of
>> checkpointing
>>
>> algorithm:
>>
>> https://issues.apache.org/jira/browse/IGNITE-6178
>> 
>> https://issues.apache.org/jira/browse/IGNITE-6033
>> 
>> https://issues.apache.org/jira/browse/IGNITE-5961
>> 
>> This will help users who are experiencing problems with
>> slow checkpoints.
>> Also, let's include
>> https://issues.apache.org/jira/browse/IGNITE-6183
>>  to
>>
>> soften "Ignite node crashed in the middle of checkpoint"
>> message as per
>> discussion <
>> http://apache-ignite-developers.2346864.n4.nabble.com/
>> Ignite-close-G-stop-name-true-Change-flag-cancel-to-false-td20473.html
>> > Ignite-close-G-stop-name-true-Change-flag-cancel-to-false-td20473.html>
>>
>> .
>>
>> All of these issues should have fixVersion 2.3.
>> Please create backport issue and link it to all necessary issues.
>>
>> P.s. I've created branch ignite-2.2, currently it equals to
>> ignite-2.1.
>>
>> On Mon, Aug 28, 2017 at 4:05 PM, Anton Vinogradov
>> >
>> wrote:
>>
>> Denis,
>>
>> BTW, who is considered to be the release manager of
>> this release?
>>
>> I'll do it.
>>
>> On Mon, Aug 28, 2017 at 3:54 PM, Seliverstov Igor
>> >
>> wrote:
>>
>> Ok, the check happens at the node start time or on
>> NODE_JOIN event
>>
>> in general it looks like:
>>
>> 1) calculate expected used memory = heap max + system
>> cache max + all
>> custom policies max + default policy size and put it
>>  

RE: Massive commit sizes for processes with local Ignite Grid servers

[Raymond Wilson]

I tried an experiment where I ran only two instances of the server locally,
this is the result in the Task Manager:





*From:* Raymond Wilson [mailto:raymond_wil...@trimble.com]
*Sent:* Thursday, September 7, 2017 9:21 PM
*To:* u...@ignite.apache.org; 'dev@ignite.apache.org' 
*Subject:* Massive commit sizes for processes with local Ignite Grid servers



I’m running a set of four server applications on a local system to simulate
a cluster.



Each of the servers has the following memory configurations set:



public override void ConfigureRaptorGrid(IgniteConfiguration cfg)

{

cfg.JvmInitialMemoryMb = 512; // Set to minimum advised memory
for Ignite grid JVM of 512Mb

cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb



// Don't permit the Ignite node to use more than 1Gb RAM (handy
when running locally...)

cfg.MemoryConfiguration = new MemoryConfiguration()

{

SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024

};

}



The snap below is from the Windows 10 Task Manager where I have included
the Commit Size value. As can be seen, the four identical servers are using
very large and wildly varying commit sizes. Some Googling suggests this is
due to the JVM allocating the largest contiguous block of virtual memory it
can, but I would not have expected this size to be larger than the
configured memory for the JVM (1Gb plus memory from the wider process it is
running in, though this is only a few hundred Mb at most)





The result is that my local system reports ~50-60Gb committed memory on a
system with 16Gb of physical RAM, and I don’t think it likes it!



Is there are way to configure the Ignite JVM to be a better citizen with
respect to the commited size it requests from the host operating system?



Thanks,

Raymond.

Massive commit sizes for processes with local Ignite Grid servers

[Raymond Wilson]

I’m running a set of four server applications on a local system to simulate
a cluster.



Each of the servers has the following memory configurations set:



public override void ConfigureRaptorGrid(IgniteConfiguration cfg)

{

cfg.JvmInitialMemoryMb = 512; // Set to minimum advised memory
for Ignite grid JVM of 512Mb

cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb



// Don't permit the Ignite node to use more than 1Gb RAM (handy
when running locally...)

cfg.MemoryConfiguration = new MemoryConfiguration()

{

SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024

};

}



The snap below is from the Windows 10 Task Manager where I have included
the Commit Size value. As can be seen, the four identical servers are using
very large and wildly varying commit sizes. Some Googling suggests this is
due to the JVM allocating the largest contiguous block of virtual memory it
can, but I would not have expected this size to be larger than the
configured memory for the JVM (1Gb plus memory from the wider process it is
running in, though this is only a few hundred Mb at most)





The result is that my local system reports ~50-60Gb committed memory on a
system with 16Gb of physical RAM, and I don’t think it likes it!



Is there are way to configure the Ignite JVM to be a better citizen with
respect to the commited size it requests from the host operating system?



Thanks,

Raymond.

[GitHub] ignite pull request #2614: IGNITE-5829 on 2.1.5

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-5829 on 2.1.5



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-gg-pitr-2.1.5-ignite-5829

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

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


commit 1e08c3fb5c02ec8acafd71b50b6ad3b749259f1a
Author: Andrey V. Mashenkov 
Date:   2017-07-31T11:14:56Z

IGNITE-4800: Lucene query may fails with NPE. This closes #2315.

commit 3fdf453e89a7bd76dff6b6d0646e3821ea3921d5
Author: Andrey V. Mashenkov 
Date:   2017-07-31T14:32:12Z

IGNITE-4800: Lucene query may fails with NPE.
Test fixed.

commit e255a564985a12113984ec02f15a4443495b8ffc
Author: Nikolay Izhikov 
Date:   2017-08-02T08:52:44Z

ignite-5712 Context switching for optimistic transactions

commit 772d462b68c7de8517d1f61e2e05ec8eefb18eac
Author: Alexey Kuznetsov 
Date:   2017-08-03T04:55:15Z

Merge branch ignite-2.1.3 into ignite-2.1.4

commit 0f3b7ca25313083e4dc35e7842931a655abd
Author: tledkov-gridgain 
Date:   2017-08-04T08:46:14Z

IGNITE-5126: Batch support for this JDBC driver. This closes #2162.

commit d1a74a4be8744528e6ed23706174041ddb0f2618
Author: devozerov 
Date:   2017-08-04T09:04:38Z

Merge remote-tracking branch 'upstream/ignite-2.1.4' into ignite-2.1.4

commit 0b3a9a7176f5ae44a96ecf700c8147193dfbf064
Author: Igor Sapego 
Date:   2017-08-04T10:18:00Z

IGNITE-5923: ODBC: SQLGetTypeInfo now works with SQL_ALL_TYPES

(cherry picked from commit 48c914d)

commit 4e0385fbc0f50548f2da3407fdfdfe939b463c67
Author: Igor Sapego 
Date:   2017-08-04T15:34:27Z

IGNITE-5939: ODBC: SQLColAttributes now works with legacy attribute codes.

(cherry picked from commit 70ffa2c)

commit 4f02504475fd1e5cc3b9f4754856e44d20fdc1cb
Author: Alexey Kuznetsov 
Date:   2017-08-07T02:41:22Z

Merge branch ignite-2.1.3 into ignite-2.1.4.

commit b093afb8231135a4904f5fffd62f5b4c332f1d47
Author: tledkov-gridgain 
Date:   2017-08-08T09:05:36Z

IGNITE-5211: Added new constructor: QueryEntity(Class keyCls, Class 
valCls). This closes #2371. This closes #2388. This closes #2407.

commit 879f19106b22e66d5f6ea94424d961d049397410
Author: devozerov 
Date:   2017-08-08T12:16:58Z

IGNITE-5982: GridMapQueryExecutor was split into several pieces.

commit 7c77b869bc3efdf19e53cc2b064f4290fd73e2b2
Author: devozerov 
Date:   2017-08-09T08:47:58Z

IGNITE-5993: Removed unused SQL-related classes and methods (old tree 
index, snapshots, etc). This closes #2414.

commit ab18fdfcc4f6db1e54fb1f3b68ba7fbc31a7f6e7
Author: Andrey V. Mashenkov 
Date:   2017-07-14T17:14:47Z

IGNITE-5452: GridTimeoutProcessor can hang on stop. This closes #2279.

commit 580b6aa8e5a8a887397eab5c4c830ec28f45cd30
Author: Alexey Kuznetsov 
Date:   2017-08-09T10:22:54Z

IGNITE-5734 Web Console: Fixed npm dependencies.
(cherry picked from commit aeafbf1)

commit 841db65e56063605475710bc170de4aea672c31d
Author: Alexey Kuznetsov 
Date:   2017-08-09T11:55:04Z

IGNITE-5987 Added -nq (visor will not quit in batch mode) option for Visor 
Cmd.
(cherry picked from commit 8d6e842)

commit 5c2097856714a7803956d754735c68b21156019c
Author: Alexey Kuznetsov 
Date:   2017-08-11T03:25:36Z

IGNITE-5902 Implemented stop caches at once.
(cherry picked from commit ebb8765)

commit 8b2461942c18f228c0107020aa28c03711bdceda
Author: Alexey Kuznetsov 
Date:   2017-08-11T04:07:26Z

IGNITE-6012 Refactored GridJettyRestHandler.processRequest(): replace 
mapper.writeValueAsString with writeValue(stream, v).
(cherry picked from commit 3a390c8)

commit 3a7d4f4a79e7c0a23244387e3a68535375a66a87
Author: Alexey Kuznetsov 
Date:   2017-08-11T04:18:42Z

IGNITE-6013 Optimized processing response from cluster.
(cherry picked from commit b02c481)

commit 74d6ab9916b3a01c78cdf1ad86211c9fcbb2214d
Author: Alexey Goncharuk 
Date:   2017-08-14T08:08:28Z

Merge branch 'ignite-2.1.3' into ignite-2.1.4

commit fde550bac56fd0cc7c51c62a9c291dd4c3f3030c
Author: Ilya Lantukh 
Date:   2017-08-14T08:32:11Z

IGNITE-5941 - Fixed index name length restrictions. This closes #2408

commit 13f38d79b57b395e43d42a8f3c278cf48336d7c5
Author: Dmitriy Govorukhin 

[jira] [Created] (IGNITE-6301) CacheConfiguration.indexedTypes never initialized and can be removed

[Nikolay Izhikov (JIRA)]

Nikolay Izhikov created IGNITE-6301:
---

 Summary: CacheConfiguration.indexedTypes never initialized and can 
be removed
 Key: IGNITE-6301
 URL: https://issues.apache.org/jira/browse/IGNITE-6301
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.1
Reporter: Nikolay Izhikov
Priority: Trivial


CacheConfiguration#indexedTypes never initialized

{code:java}
public class CacheConfiguration extends MutableConfiguration {
//...
/** */
private transient Class[] indexedTypes;
//
public CacheConfiguration setIndexedTypes(Class... indexedTypes) {
if (F.isEmpty(indexedTypes))
return this;

int len = indexedTypes.length;

if (len == 0)
return this;

A.ensure((len & 1) == 0,
"Number of indexed types is expected to be even. Refer to method 
javadoc for details.");

if (this.indexedTypes != null)
throw new CacheException("Indexed types can be set only once.");

Class[] newIndexedTypes = new Class[len];

// other method body fill qryEntities list.
{code}



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

[jira] [Created] (IGNITE-6300) BinaryObject's set size estimator

[Anton Vinogradov (JIRA)]

Anton Vinogradov created IGNITE-6300:


 Summary: BinaryObject's set size estimator
 Key: IGNITE-6300
 URL: https://issues.apache.org/jira/browse/IGNITE-6300
 Project: Ignite
  Issue Type: New Feature
Reporter: Anton Vinogradov
Assignee: Dmitriy Sorokin


Need to provide some API to estimate requirements for any data model.

For example:
1) You have classes A,B and C with known fields.
2) You know that you have to keep 1M of A, 2M of B and 45K of C.
3) BinarySizeEstimator should return you expected memory consumption on actual 
Ignite version without starting a node.



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

[GitHub] ignite pull request #2613: IGNITE-6297

[devozerov]

Github user devozerov closed the pull request at:

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


---

[jira] [Created] (IGNITE-6298) SQL: Print names of created tables on node startup

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6298:
---

 Summary: SQL: Print names of created tables on node startup
 Key: IGNITE-6298
 URL: https://issues.apache.org/jira/browse/IGNITE-6298
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov


Currently no information about created database objects are printed to the log. 
It might be very hard to understand what tables and indexes were created in 
response to processing of provided {{QueryEntity}}-es. 

We should print in the log the following information:
1) Created tables with their columns
2) Created indexes

Alternatively, may be it would be enough to print executed SQL statements!



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

[jira] [Created] (IGNITE-6297) JDBC: consistent driver names

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6297:
---

 Summary: JDBC: consistent driver names
 Key: IGNITE-6297
 URL: https://issues.apache.org/jira/browse/IGNITE-6297
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Vladimir Ozerov
 Fix For: 2.3


1) "Apache Ignite JDBC driver" - for client-node-based
2) "Apache Ignite Thin JDBC driver" - for thin



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

[GitHub] ignite pull request #2613: IGNITE-6297

[devozerov]

GitHub user devozerov opened a pull request:

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

IGNITE-6297



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

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

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

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


commit 6471712832ead30f919294e801ba3c7b455295ef
Author: devozerov 
Date:   2017-09-07T13:35:29Z

Done.




---

[jira] [Created] (IGNITE-6295) SQL: Get rid of "replicatedOnly" flag

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6295:
---

 Summary: SQL: Get rid of "replicatedOnly" flag
 Key: IGNITE-6295
 URL: https://issues.apache.org/jira/browse/IGNITE-6295
 Project: Ignite
  Issue Type: Task
  Components: sql
Reporter: Vladimir Ozerov


This flag acts as a hint that all tables are reside in {{REPLICATED}} cache. 
However, we already have this information in runtime! No need to ask users to 
think about it.

Let's deprecate that flag.



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

[jira] [Created] (IGNITE-6294) ODBC: Propagate SQLSTATE error codes

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6294:
---

 Summary: ODBC: Propagate SQLSTATE error codes
 Key: IGNITE-6294
 URL: https://issues.apache.org/jira/browse/IGNITE-6294
 Project: Ignite
  Issue Type: Task
  Components: odbc
Affects Versions: 2.1
Reporter: Vladimir Ozerov
Assignee: Igor Sapego
 Fix For: 2.3


We should propagate SQLSTATE to ODBC usrs when it's server-side part is ready 
[1].

[1] IGNITE-5620



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

RE: Massive commit sizes for processes with local Ignite Grid servers

[Raymond Wilson]

Hi Dmitry,



Thanks for the pointer to the MemoryPolicy.



I added the following:



cfg.MemoryConfiguration = new MemoryConfiguration()

{

SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024,

DefaultMemoryPolicyName = "defaultPolicy",

MemoryPolicies = new[]

{

new MemoryPolicyConfiguration

{

Name = "defaultPolicy",

InitialSize = 128 * 1024 * 1024,  // 128 MB

MaxSize = 1L * 1024 * 1024 * 1024  // 1 GB

}

}

};



After running both servers the commit size peaked at 4Gb for both processes
(with ~430Mb actual allocated memory) which is s significant improvement,
though still seems higher than might be expected.



Thanks,

Raymond.







*From:* Dmitry Pavlov [mailto:dpavlov@gmail.com]
*Sent:* Thursday, September 7, 2017 10:22 PM
*To:* u...@ignite.apache.org; dev@ignite.apache.org
*Subject:* Re: Massive commit sizes for processes with local Ignite Grid
servers



Hi Raymond,



Total memory usage since 2.0 version is determined as sum of heap size and
memory policies MaxSizes (overall segment sizes). If it is not configured
there is 80% of physical RAM is used for each node (before 2.2). In 2.2
this behaviour will be changed.



To run several nodes at one PC it may be required to manually setup Memory
Configuration and Memory Policy(ies).





Hi Igniters, esp. Pavel T.



please share your thoughts. To which Java property value of
SystemCacheMaxSize is now mapped?



Sincerely,

Dmitriy Pavlov



P.S. Please see example of configuration

https://apacheignite-net.readme.io/docs/durable-memory



MemoryPolicies = new[]

{

  new MemoryPolicyConfiguration

  {

Name = "defaultPolicy",

MaxSize = 4L * 1024 * 1024 * 1025  // 4 GB

  }

}



чт, 7 сент. 2017 г. в 12:44, Raymond Wilson :

I tried an experiment where I ran only two instances of the server locally,
this is the result in the Task Manager:





*From:* Raymond Wilson [mailto:raymond_wil...@trimble.com]
*Sent:* Thursday, September 7, 2017 9:21 PM
*To:* u...@ignite.apache.org; 'dev@ignite.apache.org' 
*Subject:* Massive commit sizes for processes with local Ignite Grid servers



I’m running a set of four server applications on a local system to simulate
a cluster.



Each of the servers has the following memory configurations set:



public override void ConfigureRaptorGrid(IgniteConfiguration cfg)

{

cfg.JvmInitialMemoryMb = 512; // Set to minimum advised memory
for Ignite grid JVM of 512Mb

cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb



// Don't permit the Ignite node to use more than 1Gb RAM (handy
when running locally...)

cfg.MemoryConfiguration = new MemoryConfiguration()

{

SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024

};

}



The snap below is from the Windows 10 Task Manager where I have included
the Commit Size value. As can be seen, the four identical servers are using
very large and wildly varying commit sizes. Some Googling suggests this is
due to the JVM allocating the largest contiguous block of virtual memory it
can, but I would not have expected this size to be larger than the
configured memory for the JVM (1Gb plus memory from the wider process it is
running in, though this is only a few hundred Mb at most)





The result is that my local system reports ~50-60Gb committed memory on a
system with 16Gb of physical RAM, and I don’t think it likes it!



Is there are way to configure the Ignite JVM to be a better citizen with
respect to the commited size it requests from the host operating system?



Thanks,

Raymond.

[jira] [Created] (IGNITE-6293) SQL: Support FOREIGN KEY constraint

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6293:
---

 Summary: SQL: Support FOREIGN KEY constraint
 Key: IGNITE-6293
 URL: https://issues.apache.org/jira/browse/IGNITE-6293
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov


We need to support {{FOREIGN KEY}} constraint. This is a complex, though 
achievable thing.
1) We need to check constraint during inserts and updates (from both SQL and 
cache API). 
2) We need to support different modes of {{CASCADE}} actions - "remove", "set 
null". 

In general case it would require distributed operations, possibly with 
predicates. However, as a first iteration, it would be enough to support FK 
only for co-located data. In this case everything could be done locally.

*Important* 
Implementation of FK typically depends heavily on underlying MVCC and 
transaction subsystems. That said, we should implement it after MVCC and 
transactional SQL.



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

[jira] [Created] (IGNITE-6292) SQL: Support CHECK constraint

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-6292:
---

 Summary: SQL: Support CHECK constraint
 Key: IGNITE-6292
 URL: https://issues.apache.org/jira/browse/IGNITE-6292
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.1
Reporter: Vladimir Ozerov


Currently we do not support {{CHECK}} constraint, which is very important in 
SQL world. Need to investigate how we can add it. Essentially, we have two ways:
1) Either delegate constraint validation to H2 somehow. But remember that we 
should do that early during update, and we should do that efficiently. Need to 
investigate H2 API to find out how to achieve that.
2) Or we should wait for development of our own execution engine, which is a 
huge thing and would not appear fast. In this case we would be able to 
pre-compile expression somehow and execute it whenever we want.



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

[GitHub] ignite pull request #2612: IGNITE-6282: Implemented lazy initialization of I...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-6282: Implemented lazy initialization of IgniteImpl members.



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

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

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

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


commit a2f6c685d982179c406eb14937ea35e3df7a4699
Author: Igor Sapego 
Date:   2017-09-06T16:42:26Z

IGNITE-6282: Minor fixes for standalone node.

commit 32449b7b77b363809d0438fadd1bf606fb9b7899
Author: Igor Sapego 
Date:   2017-09-06T16:58:21Z

IGNITE-6282: Added test.

commit fd4abb7856c420d1b2a304799dbf154a58b7ff6e
Author: Igor Sapego 
Date:   2017-09-06T17:35:41Z

IGNITE-6282: Added Lazy template

commit 8859db85a29aee5fd3c7d3545f6e9dd7aaf03f06
Author: Igor Sapego 
Date:   2017-09-07T12:17:37Z

IGNITE-6282: Implemented lazy initialization of IgniteImpl members




---

[GitHub] ignite pull request #2611: Ignite 2.1.3 p2

[ilantukh]

GitHub user ilantukh opened a pull request:

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

Ignite 2.1.3 p2



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

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

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

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


commit 1e08c3fb5c02ec8acafd71b50b6ad3b749259f1a
Author: Andrey V. Mashenkov 
Date:   2017-07-31T11:14:56Z

IGNITE-4800: Lucene query may fails with NPE. This closes #2315.

commit 3fdf453e89a7bd76dff6b6d0646e3821ea3921d5
Author: Andrey V. Mashenkov 
Date:   2017-07-31T14:32:12Z

IGNITE-4800: Lucene query may fails with NPE.
Test fixed.

commit e255a564985a12113984ec02f15a4443495b8ffc
Author: Nikolay Izhikov 
Date:   2017-08-02T08:52:44Z

ignite-5712 Context switching for optimistic transactions

commit 772d462b68c7de8517d1f61e2e05ec8eefb18eac
Author: Alexey Kuznetsov 
Date:   2017-08-03T04:55:15Z

Merge branch ignite-2.1.3 into ignite-2.1.4

commit 0f3b7ca25313083e4dc35e7842931a655abd
Author: tledkov-gridgain 
Date:   2017-08-04T08:46:14Z

IGNITE-5126: Batch support for this JDBC driver. This closes #2162.

commit d1a74a4be8744528e6ed23706174041ddb0f2618
Author: devozerov 
Date:   2017-08-04T09:04:38Z

Merge remote-tracking branch 'upstream/ignite-2.1.4' into ignite-2.1.4

commit 0b3a9a7176f5ae44a96ecf700c8147193dfbf064
Author: Igor Sapego 
Date:   2017-08-04T10:18:00Z

IGNITE-5923: ODBC: SQLGetTypeInfo now works with SQL_ALL_TYPES

(cherry picked from commit 48c914d)

commit 4e0385fbc0f50548f2da3407fdfdfe939b463c67
Author: Igor Sapego 
Date:   2017-08-04T15:34:27Z

IGNITE-5939: ODBC: SQLColAttributes now works with legacy attribute codes.

(cherry picked from commit 70ffa2c)

commit 4f02504475fd1e5cc3b9f4754856e44d20fdc1cb
Author: Alexey Kuznetsov 
Date:   2017-08-07T02:41:22Z

Merge branch ignite-2.1.3 into ignite-2.1.4.

commit b093afb8231135a4904f5fffd62f5b4c332f1d47
Author: tledkov-gridgain 
Date:   2017-08-08T09:05:36Z

IGNITE-5211: Added new constructor: QueryEntity(Class keyCls, Class 
valCls). This closes #2371. This closes #2388. This closes #2407.

commit 879f19106b22e66d5f6ea94424d961d049397410
Author: devozerov 
Date:   2017-08-08T12:16:58Z

IGNITE-5982: GridMapQueryExecutor was split into several pieces.

commit 7c77b869bc3efdf19e53cc2b064f4290fd73e2b2
Author: devozerov 
Date:   2017-08-09T08:47:58Z

IGNITE-5993: Removed unused SQL-related classes and methods (old tree 
index, snapshots, etc). This closes #2414.

commit ab18fdfcc4f6db1e54fb1f3b68ba7fbc31a7f6e7
Author: Andrey V. Mashenkov 
Date:   2017-07-14T17:14:47Z

IGNITE-5452: GridTimeoutProcessor can hang on stop. This closes #2279.

commit 580b6aa8e5a8a887397eab5c4c830ec28f45cd30
Author: Alexey Kuznetsov 
Date:   2017-08-09T10:22:54Z

IGNITE-5734 Web Console: Fixed npm dependencies.
(cherry picked from commit aeafbf1)

commit 841db65e56063605475710bc170de4aea672c31d
Author: Alexey Kuznetsov 
Date:   2017-08-09T11:55:04Z

IGNITE-5987 Added -nq (visor will not quit in batch mode) option for Visor 
Cmd.
(cherry picked from commit 8d6e842)

commit 5c2097856714a7803956d754735c68b21156019c
Author: Alexey Kuznetsov 
Date:   2017-08-11T03:25:36Z

IGNITE-5902 Implemented stop caches at once.
(cherry picked from commit ebb8765)

commit 8b2461942c18f228c0107020aa28c03711bdceda
Author: Alexey Kuznetsov 
Date:   2017-08-11T04:07:26Z

IGNITE-6012 Refactored GridJettyRestHandler.processRequest(): replace 
mapper.writeValueAsString with writeValue(stream, v).
(cherry picked from commit 3a390c8)

commit 3a7d4f4a79e7c0a23244387e3a68535375a66a87
Author: Alexey Kuznetsov 
Date:   2017-08-11T04:18:42Z

IGNITE-6013 Optimized processing response from cluster.
(cherry picked from commit b02c481)

commit 74d6ab9916b3a01c78cdf1ad86211c9fcbb2214d
Author: Alexey Goncharuk 
Date:   2017-08-14T08:08:28Z

Merge branch 'ignite-2.1.3' into ignite-2.1.4

commit fde550bac56fd0cc7c51c62a9c291dd4c3f3030c
Author: Ilya Lantukh 
Date:   2017-08-14T08:32:11Z

IGNITE-5941 - Fixed index name length restrictions. This closes #2408

commit 13f38d79b57b395e43d42a8f3c278cf48336d7c5
Author: Dmitriy Govorukhin 
Date:   

[jira] [Created] (IGNITE-6291) JDBC thin protocol compatibility

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-6291:


 Summary: JDBC thin protocol compatibility
 Key: IGNITE-6291
 URL: https://issues.apache.org/jira/browse/IGNITE-6291
 Project: Ignite
  Issue Type: Bug
  Components: jdbc
Affects Versions: 2.2
Reporter: Taras Ledkov
Assignee: Taras Ledkov


After merger IGNITE-6118 and IGNITE-5233. The JDBC thin protocol compatibility 
is broken.
The new client's handshake cannot be parsed by old servers because the server 
fails handshake by protocol's version.

So, we have to implement compatibility handshake to support this case.



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

[GitHub] ignite pull request #2610: Fix Licenses & Javadoc tests.

[alamar]

GitHub user alamar opened a pull request:

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

Fix Licenses & Javadoc tests.



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

$ git pull https://github.com/alamar/ignite ignite-licjd

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

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


commit 73048e993170a85b40ece4142c0f447ba3a365cf
Author: Ilya Kasnacheev 
Date:   2017-09-07T12:07:00Z

Fix Licenses & Javadoc tests.




---

[GitHub] ignite pull request #2609: ignite-6289 Remove "allOrNone" flag from IgniteSe...

[dmekhanikov]

GitHub user dmekhanikov opened a pull request:

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

ignite-6289 Remove "allOrNone" flag from IgniteServices#deployAll method



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

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

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

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


commit 07203c75b49d176be22b8f7bafc17b0b07d797cc
Author: Denis Mekhanikov 
Date:   2017-09-07T11:47:05Z

ignite-6289 Remove "allOrNone" flag from IgniteServices#deployAll method




---

Re: Massive commit sizes for processes with local Ignite Grid servers

[Alexey Kukushkin]

OK, please ignore - I see you might have found a cause in the other thread.

On Thu, Sep 7, 2017 at 2:45 PM, Alexey Kukushkin 
wrote:

> Raymond,
>
> So you see 3 "extra" GB that your server app takes. Is it possible your
> app really loads additional 3GB of referenced libraries and data besides
> Ignite? Did you try temporarily changing the code to NOT start Ignite and
> see how much memory such an app takes?
>
> On Thu, Sep 7, 2017 at 1:49 PM, Raymond Wilson  > wrote:
>
>> Hi Dmitry,
>>
>>
>>
>> Thanks for the pointer to the MemoryPolicy.
>>
>>
>>
>> I added the following:
>>
>>
>>
>> cfg.MemoryConfiguration = new MemoryConfiguration()
>>
>> {
>>
>> SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024,
>>
>> DefaultMemoryPolicyName = "defaultPolicy",
>>
>> MemoryPolicies = new[]
>>
>> {
>>
>> new MemoryPolicyConfiguration
>>
>> {
>>
>> Name = "defaultPolicy",
>>
>> InitialSize = 128 * 1024 * 1024,  // 128 MB
>>
>> MaxSize = 1L * 1024 * 1024 * 1024  // 1 GB
>>
>> }
>>
>> }
>>
>> };
>>
>>
>>
>> After running both servers the commit size peaked at 4Gb for both
>> processes (with ~430Mb actual allocated memory) which is s significant
>> improvement, though still seems higher than might be expected.
>>
>>
>>
>> Thanks,
>>
>> Raymond.
>>
>>
>>
>>
>>
>>
>>
>> *From:* Dmitry Pavlov [mailto:dpavlov@gmail.com]
>> *Sent:* Thursday, September 7, 2017 10:22 PM
>> *To:* u...@ignite.apache.org; dev@ignite.apache.org
>> *Subject:* Re: Massive commit sizes for processes with local Ignite Grid
>> servers
>>
>>
>>
>> Hi Raymond,
>>
>>
>>
>> Total memory usage since 2.0 version is determined as sum of heap size
>> and memory policies MaxSizes (overall segment sizes). If it is not
>> configured there is 80% of physical RAM is used for each node (before 2.2).
>> In 2.2 this behaviour will be changed.
>>
>>
>>
>> To run several nodes at one PC it may be required to manually setup
>> Memory Configuration and Memory Policy(ies).
>>
>>
>>
>>
>>
>> Hi Igniters, esp. Pavel T.
>>
>>
>>
>> please share your thoughts. To which Java property value of
>> SystemCacheMaxSize is now mapped?
>>
>>
>>
>> Sincerely,
>>
>> Dmitriy Pavlov
>>
>>
>>
>> P.S. Please see example of configuration
>>
>> https://apacheignite-net.readme.io/docs/durable-memory
>>
>>
>>
>> MemoryPolicies = new[]
>>
>> {
>>
>>   new MemoryPolicyConfiguration
>>
>>   {
>>
>> Name = "defaultPolicy",
>>
>> MaxSize = 4L * 1024 * 1024 * 1025  // 4 GB
>>
>>   }
>>
>> }
>>
>>
>>
>> чт, 7 сент. 2017 г. в 12:44, Raymond Wilson :
>>
>> I tried an experiment where I ran only two instances of the server
>> locally, this is the result in the Task Manager:
>>
>>
>>
>>
>>
>> *From:* Raymond Wilson [mailto:raymond_wil...@trimble.com]
>> *Sent:* Thursday, September 7, 2017 9:21 PM
>> *To:* u...@ignite.apache.org; 'dev@ignite.apache.org' <
>> dev@ignite.apache.org>
>> *Subject:* Massive commit sizes for processes with local Ignite Grid
>> servers
>>
>>
>>
>> I’m running a set of four server applications on a local system to
>> simulate a cluster.
>>
>>
>>
>> Each of the servers has the following memory configurations set:
>>
>>
>>
>> public override void ConfigureRaptorGrid(IgniteConfiguration cfg)
>>
>> {
>>
>> cfg.JvmInitialMemoryMb = 512; // Set to minimum advised
>> memory for Ignite grid JVM of 512Mb
>>
>> cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb
>>
>>
>>
>> // Don't permit the Ignite node to use more than 1Gb RAM
>> (handy when running locally...)
>>
>> cfg.MemoryConfiguration = new MemoryConfiguration()
>>
>> {
>>
>> SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024
>>
>> };
>>
>> }
>>
>>
>>
>> The snap below is from the Windows 10 Task Manager where I have included
>> the Commit Size value. As can be seen, the four identical servers are using
>> very large and wildly varying commit sizes. Some Googling suggests this is
>> due to the JVM allocating the largest contiguous block of virtual memory it
>> can, but I would not have expected this size to be larger than the
>> configured memory for the JVM (1Gb plus memory from the wider process it is
>> running in, though this is only a few hundred Mb at most)
>>
>>
>>
>>
>>
>> The result is that my local system reports ~50-60Gb committed memory on a
>> system with 16Gb of physical RAM, and I don’t think it likes it!
>>
>>
>>
>> Is there are way to configure the Ignite JVM to be a better citizen with
>> respect to the commited size it requests from the host operating system?
>>
>>
>>
>> Thanks,
>>
>> Raymond.
>>
>>
>>
>>
>
>
> --
> Best regards,
> Alexey
>

Re: Massive commit sizes for processes with local Ignite Grid servers

[Alexey Kukushkin]

Raymond,

So you see 3 "extra" GB that your server app takes. Is it possible your app
really loads additional 3GB of referenced libraries and data besides
Ignite? Did you try temporarily changing the code to NOT start Ignite and
see how much memory such an app takes?

On Thu, Sep 7, 2017 at 1:49 PM, Raymond Wilson 
wrote:

> Hi Dmitry,
>
>
>
> Thanks for the pointer to the MemoryPolicy.
>
>
>
> I added the following:
>
>
>
> cfg.MemoryConfiguration = new MemoryConfiguration()
>
> {
>
> SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024,
>
> DefaultMemoryPolicyName = "defaultPolicy",
>
> MemoryPolicies = new[]
>
> {
>
> new MemoryPolicyConfiguration
>
> {
>
> Name = "defaultPolicy",
>
> InitialSize = 128 * 1024 * 1024,  // 128 MB
>
> MaxSize = 1L * 1024 * 1024 * 1024  // 1 GB
>
> }
>
> }
>
> };
>
>
>
> After running both servers the commit size peaked at 4Gb for both
> processes (with ~430Mb actual allocated memory) which is s significant
> improvement, though still seems higher than might be expected.
>
>
>
> Thanks,
>
> Raymond.
>
>
>
>
>
>
>
> *From:* Dmitry Pavlov [mailto:dpavlov@gmail.com]
> *Sent:* Thursday, September 7, 2017 10:22 PM
> *To:* u...@ignite.apache.org; dev@ignite.apache.org
> *Subject:* Re: Massive commit sizes for processes with local Ignite Grid
> servers
>
>
>
> Hi Raymond,
>
>
>
> Total memory usage since 2.0 version is determined as sum of heap size and
> memory policies MaxSizes (overall segment sizes). If it is not configured
> there is 80% of physical RAM is used for each node (before 2.2). In 2.2
> this behaviour will be changed.
>
>
>
> To run several nodes at one PC it may be required to manually setup Memory
> Configuration and Memory Policy(ies).
>
>
>
>
>
> Hi Igniters, esp. Pavel T.
>
>
>
> please share your thoughts. To which Java property value of
> SystemCacheMaxSize is now mapped?
>
>
>
> Sincerely,
>
> Dmitriy Pavlov
>
>
>
> P.S. Please see example of configuration
>
> https://apacheignite-net.readme.io/docs/durable-memory
>
>
>
> MemoryPolicies = new[]
>
> {
>
>   new MemoryPolicyConfiguration
>
>   {
>
> Name = "defaultPolicy",
>
> MaxSize = 4L * 1024 * 1024 * 1025  // 4 GB
>
>   }
>
> }
>
>
>
> чт, 7 сент. 2017 г. в 12:44, Raymond Wilson :
>
> I tried an experiment where I ran only two instances of the server
> locally, this is the result in the Task Manager:
>
>
>
>
>
> *From:* Raymond Wilson [mailto:raymond_wil...@trimble.com]
> *Sent:* Thursday, September 7, 2017 9:21 PM
> *To:* u...@ignite.apache.org; 'dev@ignite.apache.org' <
> dev@ignite.apache.org>
> *Subject:* Massive commit sizes for processes with local Ignite Grid
> servers
>
>
>
> I’m running a set of four server applications on a local system to
> simulate a cluster.
>
>
>
> Each of the servers has the following memory configurations set:
>
>
>
> public override void ConfigureRaptorGrid(IgniteConfiguration cfg)
>
> {
>
> cfg.JvmInitialMemoryMb = 512; // Set to minimum advised
> memory for Ignite grid JVM of 512Mb
>
> cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb
>
>
>
> // Don't permit the Ignite node to use more than 1Gb RAM
> (handy when running locally...)
>
> cfg.MemoryConfiguration = new MemoryConfiguration()
>
> {
>
> SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024
>
> };
>
> }
>
>
>
> The snap below is from the Windows 10 Task Manager where I have included
> the Commit Size value. As can be seen, the four identical servers are using
> very large and wildly varying commit sizes. Some Googling suggests this is
> due to the JVM allocating the largest contiguous block of virtual memory it
> can, but I would not have expected this size to be larger than the
> configured memory for the JVM (1Gb plus memory from the wider process it is
> running in, though this is only a few hundred Mb at most)
>
>
>
>
>
> The result is that my local system reports ~50-60Gb committed memory on a
> system with 16Gb of physical RAM, and I don’t think it likes it!
>
>
>
> Is there are way to configure the Ignite JVM to be a better citizen with
> respect to the commited size it requests from the host operating system?
>
>
>
> Thanks,
>
> Raymond.
>
>
>
>


-- 
Best regards,
Alexey

[GitHub] ignite pull request #2512: IGNITE-5855 Type-safe parameters setting fixes cr...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Ignite Benchmarking page on readme.io

[Aleksei Zaitsev]

Hi, guys.

Issue[1] stated that we have not any information about Apache Ignite 
benchmarking on our site https://apacheignite.readme.io. I want to add such a 
page, but I can’t find appropriate section for it. I suggest to make new 
section named ‘Tests and Benchmarking’ and put all information about 
benchmaring in section page ‘Perfomance Tests’

Thoughts?

[1] https://issues.apache.org/jira/browse/IGNITE-6278

Re: Massive commit sizes for processes with local Ignite Grid servers

[Dmitry Pavlov]

Hi Raymond,

Total memory usage since 2.0 version is determined as sum of heap size and
memory policies MaxSizes (overall segment sizes). If it is not configured
there is 80% of physical RAM is used for each node (before 2.2). In 2.2
this behaviour will be changed.

To run several nodes at one PC it may be required to manually setup Memory
Configuration and Memory Policy(ies).


Hi Igniters, esp. Pavel T.

please share your thoughts. To which Java property value of
SystemCacheMaxSize is now mapped?

Sincerely,
Dmitriy Pavlov

P.S. Please see example of configuration
https://apacheignite-net.readme.io/docs/durable-memory

MemoryPolicies = new[]
{
  new MemoryPolicyConfiguration
  {
Name = "defaultPolicy",
MaxSize = 4L * 1024 * 1024 * 1025  // 4 GB
  }
}


чт, 7 сент. 2017 г. в 12:44, Raymond Wilson :

> I tried an experiment where I ran only two instances of the server
> locally, this is the result in the Task Manager:
>
>
>
>
>
> *From:* Raymond Wilson [mailto:raymond_wil...@trimble.com]
> *Sent:* Thursday, September 7, 2017 9:21 PM
> *To:* u...@ignite.apache.org; 'dev@ignite.apache.org' <
> dev@ignite.apache.org>
> *Subject:* Massive commit sizes for processes with local Ignite Grid
> servers
>
>
>
> I’m running a set of four server applications on a local system to
> simulate a cluster.
>
>
>
> Each of the servers has the following memory configurations set:
>
>
>
> public override void ConfigureRaptorGrid(IgniteConfiguration cfg)
>
> {
>
> cfg.JvmInitialMemoryMb = 512; // Set to minimum advised
> memory for Ignite grid JVM of 512Mb
>
> cfg.JvmMaxMemoryMb = 1 * 1024; // Set max to 1Gb
>
>
>
> // Don't permit the Ignite node to use more than 1Gb RAM
> (handy when running locally...)
>
> cfg.MemoryConfiguration = new MemoryConfiguration()
>
> {
>
> SystemCacheMaxSize = (long)1 * 1024 * 1024 * 1024
>
> };
>
> }
>
>
>
> The snap below is from the Windows 10 Task Manager where I have included
> the Commit Size value. As can be seen, the four identical servers are using
> very large and wildly varying commit sizes. Some Googling suggests this is
> due to the JVM allocating the largest contiguous block of virtual memory it
> can, but I would not have expected this size to be larger than the
> configured memory for the JVM (1Gb plus memory from the wider process it is
> running in, though this is only a few hundred Mb at most)
>
>
>
>
>
> The result is that my local system reports ~50-60Gb committed memory on a
> system with 16Gb of physical RAM, and I don’t think it likes it!
>
>
>
> Is there are way to configure the Ignite JVM to be a better citizen with
> respect to the commited size it requests from the host operating system?
>
>
>
> Thanks,
>
> Raymond.
>
>
>

Re: IGNITE-2894 - Binary object inside of Externalizable still serialized with OptimizedMarshaller

[Nikita Amelchev]

I also agree that we should try to use Externalizable without
deserialization on servers. I will do it in a way suggested in the review.
The Externalizable will marshal through type GridBinaryMarshaller.OBJ, in
addition, I’ll add a flag in BinaryConfiguration which will be used to turn
on the old way with OptimizedMarshaller for compatibility with the current
data format.

2017-09-06 4:21 GMT+03:00 Dmitriy Setrakyan :

> Vova, I agree. Let's stay loyal to our binary serialization protocol.
>
> Do you know if we will be loosing any functionality available in
> Externalizable, but not present in our binary protocol?
>
> D.
>
> On Mon, Sep 4, 2017 at 11:38 PM, Vladimir Ozerov 
> wrote:
>
> > Folks,
> >
> > Let's discuss how this should be handled properly. I proposed to use the
> > same format as regular binary object, with all data being written in
> "raw"
> > form. This would give us one critical advantage - we will be able to work
> > with such objects without deserialization on the server. Hence, no
> classes
> > will be needed on the server side. Current implementation (see PR in the
> > ticket) defines separate format which require deserialization, I am not
> OK
> > with it.
> >
> > Thoughts?
> >
> > On Wed, Aug 23, 2017 at 6:11 PM, Nikita Amelchev 
> > wrote:
> >
> > > Hello, Igniters!
> > >
> > > I've developed Externalizable interface support using BinaryMarshaller
> > [1].
> > >
> > > I have a misunderstanding with defining BinaryWriteMode in
> > > BinaryUtils.mode(cls): there is AffinityKey class which implements
> > > Externalizable and registered with ReflectiveSerialize,
> BinaryMarshaller
> > > defines it as BinaryWriteMode.OBJ and uses reflection according to
> > current
> > > logic. I want to say that AffinityKey must be defined as
> > > BinaryWriteMode.OBJ although the class implements the Externalizable
> > > interface.
> > > I have to add a new one more parameter in BinaryUtils.mode(cls) to
> define
> > > BinaryWriteMode in a proper way.
> > > Could you please review and comment my solution [2]?
> > >
> > > BTW, I have benchmarked my solution by GridMarshallerPerformanceTest
> and
> > it
> > > becomes faster up to 2 times (GridMarshaller).My JMH tests show that
> > > marshal faster up to 50% and unmarshal faster up to 100% on an
> > > Externalizable object.
> > >
> > > Also, I've filed an issue for Serializable interface support using
> > > BinaryMarshaller [3] as it has been described earlier.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-2894
> > > [2] https://reviews.ignite.apache.org/ignite/review/IGNT-CR-278
> > > [3] https://issues.apache.org/jira/browse/IGNITE-6172
> > >
> > > 2017-08-21 20:43 GMT+03:00 Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > > Nikita,
> > > >
> > > > I think anything binary related should have higher priority than
> > > > Externalizable. I.e. if user explicitly implemented Binarylizable or
> > > > provided a BinarySerializer, then BinaryMarshaller should of course
> use
> > > > that and ignore Externalizable.
> > > >
> > > > -Val
> > > >
> > > > On Mon, Aug 21, 2017 at 9:29 AM, Nikita Amelchev <
> nsamelc...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > Hello, Igniters.
> > > > >
> > > > > I am developing Externalizable interface support by
> BinaryMarshaller
> > > > > through new type constant. BinaryMarshaller allows using
> > > BinarySerializer
> > > > > to manage serialization. I need to define BinaryWriteMode in the
> > > > > BinaryClassDescriptor constructor. In case of the Binarylizable
> > > > interface -
> > > > > serializer is ignored and BinaryWriteMode is BINARY. Can I do the
> > same
> > > > with
> > > > > the Externalizable interface?
> > > > >
> > > > > In this case, I have issues with AffinityKey: some tests have
> failed
> > > > > because of they except serialization logic of defined the
> serializer
> > > > > instead of Externalizable logic. What is the priority between
> > > predefined
> > > > > BinarySerializer for class and implementation of Externalizable
> > > > interface?
> > > > >
> > > > > 2017-08-01 13:09 GMT+03:00 Vladimir Ozerov :
> > > > >
> > > > > > Valya,
> > > > > > It makes sense to have both Externalizable and Binarylizable, as
> > user
> > > > > might
> > > > > > want to serialize object for different systems. E.g. deserialize
> > > binary
> > > > > > stream from Kafka in Externalizable mode, and then put it to
> Ignite
> > > > with
> > > > > > Binarylizable to allow for field access without deserialization.
> > > > > >
> > > > > > Nikita,
> > > > > > I think that Externalizable should be written in the same way as
> we
> > > > write
> > > > > > fields in "raw" mode. So may be it will be enough to simply
> > implement
> > > > our
> > > > > > own ObjectOutput interface on top of existing BinaryWriterExImpl.
> > > Makes
> > > > > > sense?
> > > > > >
> > > > > > Vladimir.
> > > > > >
> > > > > 

[jira] [Created] (IGNITE-6290) Data loss in case of manual rebalance

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-6290:
---

 Summary: Data loss in case of manual rebalance
 Key: IGNITE-6290
 URL: https://issues.apache.org/jira/browse/IGNITE-6290
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.1
Reporter: Andrey Gura
 Fix For: 2.3


Data can be lost due to a manual rebalancing. 

See reproducer that always fails when topology consist of two nodes and no of 
them was stopped (except of case when {{NODES_CNT}} was initially 2).



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

[GitHub] ignite pull request #2604: IGNITE-6193 ML profile is missing in 2.1 binary r...

[oignatenko]

Github user oignatenko closed the pull request at:

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


---

[GitHub] ignite pull request #2608: IGNITE-6190: Let pass collections as arguments to...

[shroman]

GitHub user shroman opened a pull request:

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

IGNITE-6190: Let pass collections as arguments to SQL queries.



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

$ git pull https://github.com/shroman/ignite IGNITE-6190

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

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


commit 7e5a1ad1ad7100cb2f5a35a02aead071bdc03085
Author: shroman 
Date:   2017-09-07T09:41:55Z

IGNITE-6190: Let pass collections as arguments to SQL queries.




---

[jira] [Created] (IGNITE-6289) Remove "allOrNone" flag from IgniteServices#deployAll method

[Denis Mekhanikov (JIRA)]

Denis Mekhanikov created IGNITE-6289:


 Summary: Remove "allOrNone" flag from IgniteServices#deployAll 
method
 Key: IGNITE-6289
 URL: https://issues.apache.org/jira/browse/IGNITE-6289
 Project: Ignite
  Issue Type: Improvement
Reporter: Denis Mekhanikov
Assignee: Denis Mekhanikov


{{allOrNone}} flag in {{IgniteServices#deployAll}} method, introduced in 
IGNITE-5145, looks counter-intuitive. It should be removed and 
partial-deployment approach should be chosen as default.



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

[jira] [Created] (IGNITE-6288) NPE on SQL query with parameters on custom schema name

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-6288:


 Summary: NPE on SQL query with parameters on custom schema name
 Key: IGNITE-6288
 URL: https://issues.apache.org/jira/browse/IGNITE-6288
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.2
 Environment: *Root cause*: cache name is used instead of schema name 
at the {{CacheQueryPartitionInfo}}

Reproducer: 
Please add the short test to the tests class {{SqlSchemaSelfTest}}
{code}
public void testCustomSchemaName() throws Exception {
QueryEntity qe = new QueryEntity()
.setValueType(Person.class.getName())
.setKeyType(Long.class.getName())
.setValueFieldName("_value")
.setKeyFieldName("id")
.addQueryField("id", Long.class.getName(), null)
.addQueryField("_value", Person.class.getName(), null)
.addQueryField("name", String.class.getName(), null)
.addQueryField("orgId", Long.class.getName(), null);

qe.setTableName("Person");

IgniteCache cache = node.createCache(new 
CacheConfiguration()
.setName(CACHE_PERSON)
.setQueryEntities(Collections.singletonList(qe))
.setSqlSchema("TEST"));

cache.put(1L, new Person("Vasya", 2));

assertEquals(1, node.context().query().querySqlFieldsNoCache(
new SqlFieldsQuery("SELECT id, name, orgId FROM TEST.Person where 
(id = ?)").setArgs(1L), false
).getAll().size());
}
{code}
Reporter: Taras Ledkov






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

[GitHub] ignite pull request #2607: tests unmuted

[voipp]

Github user voipp closed the pull request at:

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


---

Re: [DISCUSSION] Urgent Ignite bug fix release

[李玉珏]

Currently,the latest version is apache-ignite-fabric-2.1.0-bin.zip 
.


and in 
http://www.gridgainsystems.com/nexus/content/repositories/external/org/apache/ignite/ignite-core/


the latest version is 2.1.4,

As I understand it, add 1 on the version number of 2.1.4, and then 
publish it to the ignite main website to ensure that both versions are 
consistent,is it ok?



在 2017/9/1 下午6:57, Anton Vinogradov 写道:

Hi,

Reasonable question, but I propose to keep 2.2 as a release version 
for this urgent release, since we never released X.Y.Z version before.


Let's discuss this at separate thread.
Could you please start it?


On Fri, Sep 1, 2017 at 4:49 AM, 李玉珏@163 <18624049...@163.com 
> wrote:


Since it's an urgent bugfix version, why can't the version number
be defined as 2.1.1 or 2.1.4?
After all, functionality has not increased and documents do not
require big changes.
If the version number is 2.1 series, there is no need to publish a
new version of the document.



在 2017/8/28 下午10:19, Anton Vinogradov 写道:

Igniters,

Seems 2.2 is a urgent bugfix release, so it should be based on
2.1,
In this case all other issues with fixVersion = 2.2 should be
moved to 2.3.

Currently, I see 835 issues with fixVersion = 2.2

Seems we should have only 4 issues with fixVersion = 2.2:
- Change default max memory size from 80% to 20% -
https://issues.apache.org/jira/browse/IGNITE-6182

- Detecting low memory on ignite node startup -
https://issues.apache.org/jira/browse/IGNITE-6003

- Backport of improvements to checkpoint algorithm -
https://issues.apache.org/jira/browse/IGNITE-??
??
- ML profile is missing in 2.1 binary release -
https://issues.apache.org/jira/browse/IGNITE-6193


Please correct me in case I've missed something.

Ivan,

Let's include to the release tickets with optimizations of
checkpointing

algorithm:

https://issues.apache.org/jira/browse/IGNITE-6178

https://issues.apache.org/jira/browse/IGNITE-6033

https://issues.apache.org/jira/browse/IGNITE-5961

This will help users who are experiencing problems with
slow checkpoints.
Also, let's include
https://issues.apache.org/jira/browse/IGNITE-6183
 to

soften "Ignite node crashed in the middle of checkpoint"
message as per
discussion <

http://apache-ignite-developers.2346864.n4.nabble.com/Ignite-close-G-stop-name-true-Change-flag-cancel-to-false-td20473.html



.

All of these issues should have fixVersion 2.3.
Please create backport issue and link it to all necessary issues.

P.s. I've created branch ignite-2.2, currently it equals to
ignite-2.1.

On Mon, Aug 28, 2017 at 4:05 PM, Anton Vinogradov
>
wrote:

Denis,

BTW, who is considered to be the release manager of
this release?

I'll do it.

On Mon, Aug 28, 2017 at 3:54 PM, Seliverstov Igor
>
wrote:

Ok, the check happens at the node start time or on
NODE_JOIN event

in general it looks like:

1) calculate expected used memory = heap max + system
cache max + all
custom policies max + default policy size and put it
into a node attribute

2) get total physycal memory, calculate expected safe
to be used memory
amount (leave 4 gb min or 20% of available memory for OS)

3) if expected used memory + expected used memory of
other nodes on the
host > than safe to be used memory amount, start
calculating suggestions

4) Each ignite instance needs at least 512mb heap +
40mb system cache +
100mb default polycy, if available memory is less we

[GitHub] ignite pull request #2607: tests unmuted

[voipp]

GitHub user voipp opened a pull request:

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

tests unmuted



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

$ git pull https://github.com/voipp/ignite ignite-4931-on-2.1

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

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


commit 83a72f7eab0035e7c782916adc27b98339720641
Author: voipp 
Date:   2017-09-07T05:51:55Z

tests unmuted




---