Re: Durable Memory and Ignite Persistence Tuning

[dsetrakyan]

Cos, great point!

I think the Ignite community should start load testing with default settings, 
without any config changes. This should open a lot of holes.

⁣D.​

On Sep 1, 2017, 9:57 PM, at 9:57 PM, Konstantin Boudnik  wrote:
>Just to spice it up: in my experience, having a few hundred parameters
>one can
>tweak (I am making up the number here) is a tough UX call. In JVM, we
>had a
>team that worked on heuristics that would auto-tune a bunch of things
>during
>the VM startup. Hence, providing the best user experience in most
>cases.
>
>Do you think something like this is feasible in case of persistence
>functionality? Documenting it first is a great first step, but perhaps
>wrapping this knowledge into some soft of code, would be even better.
>
>I do have an anecdotal evidence where an experienced Ignite developer
>tried to implement a message processing system with Ignite 2.0. After a
>week
>of getting nowhere performance wise, he dropped it and implemented
>something
>custom with Java and nothing else. Take it or leave it: that's why I
>called
>this "anecdotal" in the first place.
>
>Speaking strictly for myself: when I come across blog posts about
>tuning of
>Apache Kudu or Apache Impala the skin on the back of head starts
>crawling. I
>imagine 95% of the potential users of these applications would turn
>away right
>at that point. If the system doesn't work well enough out of the box -
>screw
>it, there's 355 other alternatives available in the FOSS market.
>
>Thoughts?
>  Cos
>
>On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
>> Igniters,
>>
>> I see a lot of complains regarding the performance of the subj on the
>user
>> list. At the same time, I do believe that in most scenarios it’s a
>lack of
>> knowledge that we keep in secret.
>>
>> It's time to document Durable Memory and its Native Persistence
>tuning
>> parameters. Let's start doing this for Linux based deployments first.
>Here
>> is what we have for now (which is almost nothing):
>> https://apacheignite.readme.io/docs/durable-memory-tuning
>> 
>>
>> Ideally, at some point we have to come up with doc like this:
>>
>https://access.redhat.com/sites/default/files/attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
>>
>> Please share your expertise in a form of settings that have to be put
>on the
>> paper. We put them in JIRA and document afterwords:
>> https://issues.apache.org/jira/browse/IGNITE-6246
>> 
>>
>> —
>> Denis

[GitHub] ignite pull request #2582: IGNITE-6133

[vk23]

GitHub user vk23 opened a pull request:

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

IGNITE-6133

Added clearNodeLocalMap() method for IgniteMXBean.

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

$ git pull https://github.com/vk23/ignite master

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

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


commit 39dbbfc0dd71e59c21ee8c6f58a26677f53d18e2
Author: vk 
Date:   2017-09-01T20:36:33Z

IGNITE-6133

Added clearNodeLocalMap() method for IgniteMXBean.




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

Re: How to configure ignite-jcl and Ignite-slf4j logger

[Prachi Garg]

Yes, I tried using it, but strangely this is the output I get when use
-DIGNITE_QUIET=false
( I set this property in Idea ->Run -> Edit Configurations -> VM options)

log4j:WARN No appenders could be found for logger
(org.apache.ignite.internal.util.typedef.G).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
Sep 01, 2017 2:33:07 PM java.util.logging.LogManager$RootLogger log
SEVERE: Failed to resolve default logging config file:
config/java.util.logging.properties
class org.apache.ignite.internal.GridLoggerProxy

Process finished with exit code 0


On Fri, Sep 1, 2017 at 2:30 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Prachi,
>
> It looks like you're running in quiet mode. Did you try to set
> -DIGNITE_QUIET=false
> system property?
>
> -Val
>
> On Fri, Sep 1, 2017 at 10:43 AM, Prachi Garg  wrote:
>
> > Nikolai,
> >
> > I have specified 'gridlogger' property in 'IgniteConfiguration', but
> looks
> > like it does not get instantiated.
> >
> >  > class="org.apache.ignite.configuration.IgniteConfiguration">
> >
> > 
> > 
> > 
> > 
> >  > value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> > 
> > 
> > 
> > 
> >
> > 
> > ...
> >
> > 
> >
> >
> >
> >
> > On Fri, Sep 1, 2017 at 10:16 AM, Nikolay Tikhonov <
> ntikho...@gridgain.com>
> > wrote:
> >
> > > Hi Denis,
> > >
> > > JCL it's wrapper for logging system (similar sl4j) which can be used
> > > together with log4j. I guess that JavaDoc correct.
> > >
> > > On Fri, Sep 1, 2017 at 5:40 PM, Denis Magda  wrote:
> > >
> > > > Nikolai,
> > > >
> > > > Looking at JCL documentation I see the usage of Log4j together with
> > JCL:
> > > >
> > > > * 
> > > > *  ...
> > > > *  property name="gridLogger"
> > > > *  bean class="org.apache.ignite.
> logger.jcl.JclLogger"
> > > > *  constructor-arg type="org.apache.commons.
> > > > logging.Log"
> > > > *  bean class="org.apache.commons.
> > > > logging.impl.Log4JLogger"
> > > > *  constructor-arg type="java.lang.String"
> > > > value="config/ignite-log4j.xml"/
> > > > *  /bean
> > > > *  /constructor-arg
> > > > *  /bean
> > > > *  /property
> > > > *  ...
> > > > * 
> > > >
> > > >
> > > > or
> > > >
> > > > * And the same configuration if you'd like to configure Ignite in
> your
> > > > code:
> > > > * 
> > > > *  IgniteConfiguration cfg = new IgniteConfiguration();
> > > > *  ...
> > > > *  IgniteLogger log = new JclLogger(new
> Log4JLogger("config/ignite-
> > > > log4j.xml"));
> > > > *  ...
> > > > *  cfg.setGridLogger(log);
> > > > * 
> > > >
> > > >
> > > > Is it wrong? Could you fix the Java Doc in a proper way?
> > > >
> > > >
> > > > > On Sep 1, 2017, at 3:12 AM, Nikolai Tikhonov  >
> > > > wrote:
> > > > >
> > > > > Hello Prachi!
> > > > >
> > > > > You need to set gridLogger property in IgniteConfiguration and
> remove
> > > > ignite-log4j dependency from POM file.
> > > > >
> > > > > For example for Sl4j logger:
> > > > >
> > > > > igniteConfiguration.setGridLogger(new Slf4jLogger());
> > > > >
> > > > > and for Jc logger:
> > > > >
> > > > > igniteConfiguration.setGridLogger(new JclLogger());
> > > > >
> > > > > On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg  > >  > > > pg...@gridgain.com>> wrote:
> > > > > Engineers,
> > > > >
> > > > > In the attempt to document loggers supported by Ignite, I am
> having a
> > > > hard
> > > > > time configuring ignite-jcl and ignite-slf4j (I could configure
> log4j
> > > and
> > > > > log4j2). I don't see the log message on my console when I use
> > > ignite-jcl
> > > > or
> > > > > ignite-slf4j.
> > > > >
> > > > >  Below is the configuration and sample code I am using:
> > > > >
> > > > > *ignite-log4j.xml*
> > > > >
> > > > > 
> > > > >  > > > > xmlns:log4j='http://jakarta.apache.org/log4j/ <
> > > > http://jakarta.apache.org/log4j/>'>
> > > > >
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >
> > > > > 
> > > > >
> > > > >
> > > > > *Maven dependency -*
> > > > >
> > > > > 
> > > > > org.apache.ignite
> > > > > ignite-log4j
> > > > > 2.1.0
> > > > > 
> > > > >
> > > > > 
> > > > > org.apache.ignite
> > > > > ignite-jcl
> > > > > 2.1.0
> > > > > 
> > > > >
> > > > >
> > > > > *Configuration for JCL ( as specified in javadoc)- *
> > > > >
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > >  > > > > value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > 

Re: How to configure ignite-jcl and Ignite-slf4j logger

[Valentin Kulichenko]

Prachi,

It looks like you're running in quiet mode. Did you try to set
-DIGNITE_QUIET=false
system property?

-Val

On Fri, Sep 1, 2017 at 10:43 AM, Prachi Garg  wrote:

> Nikolai,
>
> I have specified 'gridlogger' property in 'IgniteConfiguration', but looks
> like it does not get instantiated.
>
>  class="org.apache.ignite.configuration.IgniteConfiguration">
>
> 
> 
> 
> 
>  value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> 
> 
> 
> 
>
> 
> ...
>
> 
>
>
>
>
> On Fri, Sep 1, 2017 at 10:16 AM, Nikolay Tikhonov 
> wrote:
>
> > Hi Denis,
> >
> > JCL it's wrapper for logging system (similar sl4j) which can be used
> > together with log4j. I guess that JavaDoc correct.
> >
> > On Fri, Sep 1, 2017 at 5:40 PM, Denis Magda  wrote:
> >
> > > Nikolai,
> > >
> > > Looking at JCL documentation I see the usage of Log4j together with
> JCL:
> > >
> > > * 
> > > *  ...
> > > *  property name="gridLogger"
> > > *  bean class="org.apache.ignite.logger.jcl.JclLogger"
> > > *  constructor-arg type="org.apache.commons.
> > > logging.Log"
> > > *  bean class="org.apache.commons.
> > > logging.impl.Log4JLogger"
> > > *  constructor-arg type="java.lang.String"
> > > value="config/ignite-log4j.xml"/
> > > *  /bean
> > > *  /constructor-arg
> > > *  /bean
> > > *  /property
> > > *  ...
> > > * 
> > >
> > >
> > > or
> > >
> > > * And the same configuration if you'd like to configure Ignite in your
> > > code:
> > > * 
> > > *  IgniteConfiguration cfg = new IgniteConfiguration();
> > > *  ...
> > > *  IgniteLogger log = new JclLogger(new Log4JLogger("config/ignite-
> > > log4j.xml"));
> > > *  ...
> > > *  cfg.setGridLogger(log);
> > > * 
> > >
> > >
> > > Is it wrong? Could you fix the Java Doc in a proper way?
> > >
> > >
> > > > On Sep 1, 2017, at 3:12 AM, Nikolai Tikhonov 
> > > wrote:
> > > >
> > > > Hello Prachi!
> > > >
> > > > You need to set gridLogger property in IgniteConfiguration and remove
> > > ignite-log4j dependency from POM file.
> > > >
> > > > For example for Sl4j logger:
> > > >
> > > > igniteConfiguration.setGridLogger(new Slf4jLogger());
> > > >
> > > > and for Jc logger:
> > > >
> > > > igniteConfiguration.setGridLogger(new JclLogger());
> > > >
> > > > On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg  >  > > pg...@gridgain.com>> wrote:
> > > > Engineers,
> > > >
> > > > In the attempt to document loggers supported by Ignite, I am having a
> > > hard
> > > > time configuring ignite-jcl and ignite-slf4j (I could configure log4j
> > and
> > > > log4j2). I don't see the log message on my console when I use
> > ignite-jcl
> > > or
> > > > ignite-slf4j.
> > > >
> > > >  Below is the configuration and sample code I am using:
> > > >
> > > > *ignite-log4j.xml*
> > > >
> > > > 
> > > >  > > > xmlns:log4j='http://jakarta.apache.org/log4j/ <
> > > http://jakarta.apache.org/log4j/>'>
> > > >
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > > 
> > > >
> > > >
> > > > *Maven dependency -*
> > > >
> > > > 
> > > > org.apache.ignite
> > > > ignite-log4j
> > > > 2.1.0
> > > > 
> > > >
> > > > 
> > > > org.apache.ignite
> > > > ignite-jcl
> > > > 2.1.0
> > > > 
> > > >
> > > >
> > > > *Configuration for JCL ( as specified in javadoc)- *
> > > >
> > > > 
> > > > 
> > > > 
> > > > 
> > > >  > > > value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> > > > 
> > > > 
> > > > 
> > > > 
> > > >
> > > >
> > > > *Sample code I am using- *
> > > >
> > > > public class LoggerExample {
> > > > public static void main(String[] args) throws IgniteException {
> > > > try (Ignite ignite =
> > > > Ignition.start("/Users/prachig/myexamples/config/
> cluster-config.xml"))
> > > > {
> > > > ignite.log().info("Info Message 1 Logged !!!");
> > > > ignite.log().info("Info Message 2 Logged !!!");
> > > >
> > > > System.out.println(ignite.log().getClass());
> > > > }
> > > > }
> > > > }
> > > >
> > > > *Output*
> > > >
> > > > /Library/Java/JavaVirtualMachines/jdk1.8.0_
> > 74.jdk/Contents/Home/bin/java
> > > > -Didea.launcher.port=7535
> > > > "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA
> > > > CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> > > > "/Library/Java/JavaVirtualMachines/jdk1.8.0_
> > > 74.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/
> > > JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> > > deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> > > 

Re: Durable Memory and Ignite Persistence Tuning

[Nikita Ivanov]

My points was in support of auto-tune for Ignite's internals. As far as
environment, sure, we need to have a doc.
--
Nikita Ivanov


On Fri, Sep 1, 2017 at 1:23 PM, Denis Magda  wrote:

> It doesn’t matter how many configuration parameters your platform,
> database or operating system has - the performance tuning usually takes
> place in business deployments. The performance optimizations might happen
> behind the scene by heuristic algorithms or basic checks or be explained in
> performance guides or both.
>
> This discussion is about this exact guide that is vital for DevOps and
> Admins. Make it first and you’ll reveal the spots for auto-tuning.
> Otherwise, we can spend months keeping a blind eye on this problem waiting
> for fully automated heaven and cleanest API in the world but nothing will
> happen at all.
>
> —
> Denis
>
> > On Sep 1, 2017, at 12:49 PM, Nikita Ivanov  wrote:
> >
> > 200% agree.
> >
> > UX is major problem for Ignite (especially so for 2.0 with all major
> > redev). Removing (!) configuration properties should be THE GOAL, not
> > adding new one or documenting them (which is a crutch to begin with).
> >
> > When I see a product with dozens config properties or more I desperately
> > look for ways not to use it...
> >
> > My 2 cents,
> > --
> > Nikita Ivanov
> >
> >
> > On Fri, Sep 1, 2017 at 12:02 PM, Konstantin Boudnik 
> wrote:
> >
> >> Just to spice it up: in my experience, having a few hundred parameters
> one
> >> can
> >> tweak (I am making up the number here) is a tough UX call. In JVM, we
> had a
> >> team that worked on heuristics that would auto-tune a bunch of things
> >> during
> >> the VM startup. Hence, providing the best user experience in most cases.
> >>
> >> Do you think something like this is feasible in case of persistence
> >> functionality? Documenting it first is a great first step, but perhaps
> >> wrapping this knowledge into some soft of code, would be even better.
> >>
> >> I do have an anecdotal evidence where an experienced Ignite developer
> >> tried to implement a message processing system with Ignite 2.0. After a
> >> week
> >> of getting nowhere performance wise, he dropped it and implemented
> >> something
> >> custom with Java and nothing else. Take it or leave it: that's why I
> called
> >> this "anecdotal" in the first place.
> >>
> >> Speaking strictly for myself: when I come across blog posts about
> tuning of
> >> Apache Kudu or Apache Impala the skin on the back of head starts
> crawling.
> >> I
> >> imagine 95% of the potential users of these applications would turn away
> >> right
> >> at that point. If the system doesn't work well enough out of the box -
> >> screw
> >> it, there's 355 other alternatives available in the FOSS market.
> >>
> >> Thoughts?
> >>  Cos
> >>
> >> On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
> >>> Igniters,
> >>>
> >>> I see a lot of complains regarding the performance of the subj on the
> >> user
> >>> list. At the same time, I do believe that in most scenarios it’s a lack
> >> of
> >>> knowledge that we keep in secret.
> >>>
> >>> It's time to document Durable Memory and its Native Persistence tuning
> >>> parameters. Let's start doing this for Linux based deployments first.
> >> Here
> >>> is what we have for now (which is almost nothing):
> >>> https://apacheignite.readme.io/docs/durable-memory-tuning
> >>> 
> >>>
> >>> Ideally, at some point we have to come up with doc like this:
> >>> https://access.redhat.com/sites/default/files/
> >> attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
> >>>
> >>> Please share your expertise in a form of settings that have to be put
> on
> >> the
> >>> paper. We put them in JIRA and document afterwords:
> >>> https://issues.apache.org/jira/browse/IGNITE-6246
> >>> 
> >>>
> >>> —
> >>> Denis
> >>
>
>

Re: Durable Memory and Ignite Persistence Tuning

[Denis Magda]

It doesn’t matter how many configuration parameters your platform, database or 
operating system has - the performance tuning usually takes place in business 
deployments. The performance optimizations might happen behind the scene by 
heuristic algorithms or basic checks or be explained in performance guides or 
both.

This discussion is about this exact guide that is vital for DevOps and Admins. 
Make it first and you’ll reveal the spots for auto-tuning. Otherwise, we can 
spend months keeping a blind eye on this problem waiting for fully automated 
heaven and cleanest API in the world but nothing will happen at all.

—
Denis  

> On Sep 1, 2017, at 12:49 PM, Nikita Ivanov  wrote:
> 
> 200% agree.
> 
> UX is major problem for Ignite (especially so for 2.0 with all major
> redev). Removing (!) configuration properties should be THE GOAL, not
> adding new one or documenting them (which is a crutch to begin with).
> 
> When I see a product with dozens config properties or more I desperately
> look for ways not to use it...
> 
> My 2 cents,
> --
> Nikita Ivanov
> 
> 
> On Fri, Sep 1, 2017 at 12:02 PM, Konstantin Boudnik  wrote:
> 
>> Just to spice it up: in my experience, having a few hundred parameters one
>> can
>> tweak (I am making up the number here) is a tough UX call. In JVM, we had a
>> team that worked on heuristics that would auto-tune a bunch of things
>> during
>> the VM startup. Hence, providing the best user experience in most cases.
>> 
>> Do you think something like this is feasible in case of persistence
>> functionality? Documenting it first is a great first step, but perhaps
>> wrapping this knowledge into some soft of code, would be even better.
>> 
>> I do have an anecdotal evidence where an experienced Ignite developer
>> tried to implement a message processing system with Ignite 2.0. After a
>> week
>> of getting nowhere performance wise, he dropped it and implemented
>> something
>> custom with Java and nothing else. Take it or leave it: that's why I called
>> this "anecdotal" in the first place.
>> 
>> Speaking strictly for myself: when I come across blog posts about tuning of
>> Apache Kudu or Apache Impala the skin on the back of head starts crawling.
>> I
>> imagine 95% of the potential users of these applications would turn away
>> right
>> at that point. If the system doesn't work well enough out of the box -
>> screw
>> it, there's 355 other alternatives available in the FOSS market.
>> 
>> Thoughts?
>>  Cos
>> 
>> On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
>>> Igniters,
>>> 
>>> I see a lot of complains regarding the performance of the subj on the
>> user
>>> list. At the same time, I do believe that in most scenarios it’s a lack
>> of
>>> knowledge that we keep in secret.
>>> 
>>> It's time to document Durable Memory and its Native Persistence tuning
>>> parameters. Let's start doing this for Linux based deployments first.
>> Here
>>> is what we have for now (which is almost nothing):
>>> https://apacheignite.readme.io/docs/durable-memory-tuning
>>> 
>>> 
>>> Ideally, at some point we have to come up with doc like this:
>>> https://access.redhat.com/sites/default/files/
>> attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
>>> 
>>> Please share your expertise in a form of settings that have to be put on
>> the
>>> paper. We put them in JIRA and document afterwords:
>>> https://issues.apache.org/jira/browse/IGNITE-6246
>>> 
>>> 
>>> —
>>> Denis
>> 

Re: Durable Memory and Ignite Persistence Tuning

[Nikita Ivanov]

200% agree.

UX is major problem for Ignite (especially so for 2.0 with all major
redev). Removing (!) configuration properties should be THE GOAL, not
adding new one or documenting them (which is a crutch to begin with).

When I see a product with dozens config properties or more I desperately
look for ways not to use it...

My 2 cents,
--
Nikita Ivanov


On Fri, Sep 1, 2017 at 12:02 PM, Konstantin Boudnik  wrote:

> Just to spice it up: in my experience, having a few hundred parameters one
> can
> tweak (I am making up the number here) is a tough UX call. In JVM, we had a
> team that worked on heuristics that would auto-tune a bunch of things
> during
> the VM startup. Hence, providing the best user experience in most cases.
>
> Do you think something like this is feasible in case of persistence
> functionality? Documenting it first is a great first step, but perhaps
> wrapping this knowledge into some soft of code, would be even better.
>
> I do have an anecdotal evidence where an experienced Ignite developer
> tried to implement a message processing system with Ignite 2.0. After a
> week
> of getting nowhere performance wise, he dropped it and implemented
> something
> custom with Java and nothing else. Take it or leave it: that's why I called
> this "anecdotal" in the first place.
>
> Speaking strictly for myself: when I come across blog posts about tuning of
> Apache Kudu or Apache Impala the skin on the back of head starts crawling.
> I
> imagine 95% of the potential users of these applications would turn away
> right
> at that point. If the system doesn't work well enough out of the box -
> screw
> it, there's 355 other alternatives available in the FOSS market.
>
> Thoughts?
>   Cos
>
> On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
> > Igniters,
> >
> > I see a lot of complains regarding the performance of the subj on the
> user
> > list. At the same time, I do believe that in most scenarios it’s a lack
> of
> > knowledge that we keep in secret.
> >
> > It's time to document Durable Memory and its Native Persistence tuning
> > parameters. Let's start doing this for Linux based deployments first.
> Here
> > is what we have for now (which is almost nothing):
> > https://apacheignite.readme.io/docs/durable-memory-tuning
> > 
> >
> > Ideally, at some point we have to come up with doc like this:
> > https://access.redhat.com/sites/default/files/
> attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
> >
> > Please share your expertise in a form of settings that have to be put on
> the
> > paper. We put them in JIRA and document afterwords:
> > https://issues.apache.org/jira/browse/IGNITE-6246
> > 
> >
> > —
> > Denis
>

Re: Durable Memory and Ignite Persistence Tuning

[Denis Magda]

Cos,

Sure, as I see from the @dev list a lot of efforts are put to the auto-tune 
way. We need to keep to this way whenever it’s possible.

However, it might be the case that we can’t auto-tune some parameters (Linux 
kernel behavior) or we know that setting A will be auto-tuned in release 2.x 
but for now we should explain how to set it manually.

Even more, we can review that page over the time and decide that now we’re 
ready to auto-tune parameter B.

—
Denis

> On Sep 1, 2017, at 12:02 PM, Konstantin Boudnik  wrote:
> 
> Just to spice it up: in my experience, having a few hundred parameters one can
> tweak (I am making up the number here) is a tough UX call. In JVM, we had a
> team that worked on heuristics that would auto-tune a bunch of things during
> the VM startup. Hence, providing the best user experience in most cases.
> 
> Do you think something like this is feasible in case of persistence
> functionality? Documenting it first is a great first step, but perhaps
> wrapping this knowledge into some soft of code, would be even better.
> 
> I do have an anecdotal evidence where an experienced Ignite developer
> tried to implement a message processing system with Ignite 2.0. After a week
> of getting nowhere performance wise, he dropped it and implemented something
> custom with Java and nothing else. Take it or leave it: that's why I called
> this "anecdotal" in the first place.
> 
> Speaking strictly for myself: when I come across blog posts about tuning of
> Apache Kudu or Apache Impala the skin on the back of head starts crawling. I
> imagine 95% of the potential users of these applications would turn away right
> at that point. If the system doesn't work well enough out of the box - screw
> it, there's 355 other alternatives available in the FOSS market.
> 
> Thoughts?
>  Cos
> 
> On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
>> Igniters,
>> 
>> I see a lot of complains regarding the performance of the subj on the user
>> list. At the same time, I do believe that in most scenarios it’s a lack of
>> knowledge that we keep in secret.
>> 
>> It's time to document Durable Memory and its Native Persistence tuning
>> parameters. Let's start doing this for Linux based deployments first. Here
>> is what we have for now (which is almost nothing):
>> https://apacheignite.readme.io/docs/durable-memory-tuning
>> 
>> 
>> Ideally, at some point we have to come up with doc like this:
>> https://access.redhat.com/sites/default/files/attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
>> 
>> Please share your expertise in a form of settings that have to be put on the
>> paper. We put them in JIRA and document afterwords:
>> https://issues.apache.org/jira/browse/IGNITE-6246
>> 
>> 
>> —
>> Denis

Re: Durable Memory and Ignite Persistence Tuning

[Konstantin Boudnik]

Just to spice it up: in my experience, having a few hundred parameters one can
tweak (I am making up the number here) is a tough UX call. In JVM, we had a
team that worked on heuristics that would auto-tune a bunch of things during
the VM startup. Hence, providing the best user experience in most cases.

Do you think something like this is feasible in case of persistence
functionality? Documenting it first is a great first step, but perhaps
wrapping this knowledge into some soft of code, would be even better.

I do have an anecdotal evidence where an experienced Ignite developer
tried to implement a message processing system with Ignite 2.0. After a week
of getting nowhere performance wise, he dropped it and implemented something
custom with Java and nothing else. Take it or leave it: that's why I called
this "anecdotal" in the first place.

Speaking strictly for myself: when I come across blog posts about tuning of
Apache Kudu or Apache Impala the skin on the back of head starts crawling. I
imagine 95% of the potential users of these applications would turn away right
at that point. If the system doesn't work well enough out of the box - screw
it, there's 355 other alternatives available in the FOSS market.

Thoughts?
  Cos

On Fri, Sep 01, 2017 at 11:08AM, Denis Magda wrote:
> Igniters,
> 
> I see a lot of complains regarding the performance of the subj on the user
> list. At the same time, I do believe that in most scenarios it’s a lack of
> knowledge that we keep in secret.
> 
> It's time to document Durable Memory and its Native Persistence tuning
> parameters. Let's start doing this for Linux based deployments first. Here
> is what we have for now (which is almost nothing):
> https://apacheignite.readme.io/docs/durable-memory-tuning
> 
> 
> Ideally, at some point we have to come up with doc like this:
> https://access.redhat.com/sites/default/files/attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf
> 
> Please share your expertise in a form of settings that have to be put on the
> paper. We put them in JIRA and document afterwords:
> https://issues.apache.org/jira/browse/IGNITE-6246
> 
> 
> —
> Denis


signature.asc
Description: Digital signature

[jira] [Created] (IGNITE-6247) Review Ignite & Cassandra Integration Documentation

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6247:
---

 Summary: Review Ignite & Cassandra Integration Documentation
 Key: IGNITE-6247
 URL: https://issues.apache.org/jira/browse/IGNITE-6247
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Prachi Garg


Ignite & Cassandra [1] end users shared the feedback that the documentation 
doesn't precisely state corner cases or pitfalls that might arise.

Specifically, consider these bullet points [2] by Roger Fischer.

Review the existing documentation and make sure all the points like these [2] 
and another brought up in that discussion are documented there to avoid any 
uncertainty.

[1] https://apacheignite-mix.readme.io/docs/ignite-with-apache-cassandra
[2] 
http://apache-ignite-users.70518.x6.nabble.com/Ignite-2-1-0-Thread-deadlock-on-DefaultSingletonBeanRegistry-getSingleton-td16481.html#a16604



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

Durable Memory and Ignite Persistence Tuning

[Denis Magda]

Igniters,

I see a lot of complains regarding the performance of the subj on the user 
list. At the same time, I do believe that in most scenarios it’s a lack of 
knowledge that we keep in secret.

It's time to document Durable Memory and its Native Persistence tuning 
parameters. Let's start doing this for Linux based deployments first. Here is 
what we have for now (which is almost nothing): 
https://apacheignite.readme.io/docs/durable-memory-tuning 


Ideally, at some point we have to come up with doc like this: 
https://access.redhat.com/sites/default/files/attachments/deploying-oracle-12c-on-rhel6_1.2_1.pdf

Please share your expertise in a form of settings that have to be put on the 
paper. We put them in JIRA and document afterwords:
https://issues.apache.org/jira/browse/IGNITE-6246 


—
Denis

[jira] [Created] (IGNITE-6246) Document Durable Memory and Linux Kernel Tuning Parameters

[Denis Magda (JIRA)]

Denis Magda created IGNITE-6246:
---

 Summary: Document Durable Memory and Linux Kernel Tuning Parameters
 Key: IGNITE-6246
 URL: https://issues.apache.org/jira/browse/IGNITE-6246
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
Assignee: Alexei Scherbakov


It's time to document Durable Memory and its Native Persistence tuning 
parameters. Let's start doing this for Linux based deployments first.
https://apacheignite.readme.io/docs/durable-memory-tuning

As for the operating system related settings we should borrow the parameters 
used for GC tuning:
https://apacheignite.readme.io/v2.1/docs/jvm-and-system-tuning#linux-kernel-tuning

It's totally fine to have sections for different Linux distributions on that 
page (like RedHat 6 and 7) if the set of parameters varies. 



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

Re: Ignite Durable Memory & Persistent Store introduction for developers

[Dmitry Pavlov]

Hi Denis,

Sure, I would be glad if you have some time to review the page. Thank you
for edits and careful review!

According to recent questions and feedback from Igniters, I would also like
to extend section about memory organization.

Please give me a couple of days to address your questions and extend wiki.

Sincerely,
Dmitriy Pavlov


пт, 1 сент. 2017 г. в 19:50, Denis Magda :

> Dmitriy,
>
> First of all, thanks for putting this low level details on paper! Current
> and future community members will be grateful to you.
>
> Second, let me be a reviewer of the page and suggest some improvements.
> Until the review is over I would encourage us to hold on with any public
> announcements such as blog post.
>
> I’ve reviewed and edited Ignite Durable Memory section (
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-IgniteDurableMemory
> <
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-IgniteDurableMemory>).
> Please address the questions below and I’ll move on with the new sections
> afterwards.
>
> 1) "Different caches and its partitions bring more complex addressing
> scheme but it is still possible to map from page ID to position in
> particular file: pageId => file + offset in this file”.
>
> Probably this appears too early in the doc because above we just
> introduced page ID notion with durable memory and now we’re talking about
> some files? Are these files of ignite persistence? What if the persistence
> is disabled? Honestly, the sentence gets out of the story context.
>
>
> 2) "Also, the tree pages can be merged into one if < 50% of space is used.”
>
> 50% of the whole memory available? Please clarify.
>
>
> 3) "There is one page ID table per memory segment.”
>
> It’s the same segment as it’s described in the main doc, right?
> https://apacheignite.readme.io/docs/memory-architecture#section-memory-segment
> <
> https://apacheignite.readme.io/docs/memory-architecture#section-memory-segment
> >
>
>
> 4) "within unsafe segment”
>
> If we want to mention “usafe” here we need to explain what that is.
>
> 5) "If memory amount less than whole index size, Ignite still can operate.”
>
> How do we define “index size”? Is this the page size?
>
>
> —
> Denis
>
>
> > On Aug 30, 2017, at 8:24 AM, Dmitry Pavlov 
> wrote:
> >
> > Hi Igniters,
> >
> >
> > I am glad to introduce two new wiki articles. These articles contain
> > high-level description of
> >
> > - Ignite Durable Memory (
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood
> > )
> >
> > - and Ignite Persistent Store (
> >
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
> > )
> >
> > These articles cover basic principles and internal design. Pages may be
> > useful for new contributors during start of working with persistent store
> > code base.
> >
> >
> > I would like to thank all contributors who helped me with my questions.
> > Their answers and support made it possible to start this description.
> >
> >
> > I will appreciate any feedback and questions. Suggestions and edits are
> > welcome, of course.
> >
> >
> > Sincerely,
> >
> > Dmitriy Pavlov
>
>

Re: How to configure ignite-jcl and Ignite-slf4j logger

[Prachi Garg]

Nikolai,

I have specified 'gridlogger' property in 'IgniteConfiguration', but looks
like it does not get instantiated.














...






On Fri, Sep 1, 2017 at 10:16 AM, Nikolay Tikhonov 
wrote:

> Hi Denis,
>
> JCL it's wrapper for logging system (similar sl4j) which can be used
> together with log4j. I guess that JavaDoc correct.
>
> On Fri, Sep 1, 2017 at 5:40 PM, Denis Magda  wrote:
>
> > Nikolai,
> >
> > Looking at JCL documentation I see the usage of Log4j together with JCL:
> >
> > * 
> > *  ...
> > *  property name="gridLogger"
> > *  bean class="org.apache.ignite.logger.jcl.JclLogger"
> > *  constructor-arg type="org.apache.commons.
> > logging.Log"
> > *  bean class="org.apache.commons.
> > logging.impl.Log4JLogger"
> > *  constructor-arg type="java.lang.String"
> > value="config/ignite-log4j.xml"/
> > *  /bean
> > *  /constructor-arg
> > *  /bean
> > *  /property
> > *  ...
> > * 
> >
> >
> > or
> >
> > * And the same configuration if you'd like to configure Ignite in your
> > code:
> > * 
> > *  IgniteConfiguration cfg = new IgniteConfiguration();
> > *  ...
> > *  IgniteLogger log = new JclLogger(new Log4JLogger("config/ignite-
> > log4j.xml"));
> > *  ...
> > *  cfg.setGridLogger(log);
> > * 
> >
> >
> > Is it wrong? Could you fix the Java Doc in a proper way?
> >
> >
> > > On Sep 1, 2017, at 3:12 AM, Nikolai Tikhonov 
> > wrote:
> > >
> > > Hello Prachi!
> > >
> > > You need to set gridLogger property in IgniteConfiguration and remove
> > ignite-log4j dependency from POM file.
> > >
> > > For example for Sl4j logger:
> > >
> > > igniteConfiguration.setGridLogger(new Slf4jLogger());
> > >
> > > and for Jc logger:
> > >
> > > igniteConfiguration.setGridLogger(new JclLogger());
> > >
> > > On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg   > pg...@gridgain.com>> wrote:
> > > Engineers,
> > >
> > > In the attempt to document loggers supported by Ignite, I am having a
> > hard
> > > time configuring ignite-jcl and ignite-slf4j (I could configure log4j
> and
> > > log4j2). I don't see the log message on my console when I use
> ignite-jcl
> > or
> > > ignite-slf4j.
> > >
> > >  Below is the configuration and sample code I am using:
> > >
> > > *ignite-log4j.xml*
> > >
> > > 
> > >  > > xmlns:log4j='http://jakarta.apache.org/log4j/ <
> > http://jakarta.apache.org/log4j/>'>
> > >
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > > 
> > >
> > > 
> > >
> > >
> > > *Maven dependency -*
> > >
> > > 
> > > org.apache.ignite
> > > ignite-log4j
> > > 2.1.0
> > > 
> > >
> > > 
> > > org.apache.ignite
> > > ignite-jcl
> > > 2.1.0
> > > 
> > >
> > >
> > > *Configuration for JCL ( as specified in javadoc)- *
> > >
> > > 
> > > 
> > > 
> > > 
> > >  > > value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> > > 
> > > 
> > > 
> > > 
> > >
> > >
> > > *Sample code I am using- *
> > >
> > > public class LoggerExample {
> > > public static void main(String[] args) throws IgniteException {
> > > try (Ignite ignite =
> > > Ignition.start("/Users/prachig/myexamples/config/cluster-config.xml"))
> > > {
> > > ignite.log().info("Info Message 1 Logged !!!");
> > > ignite.log().info("Info Message 2 Logged !!!");
> > >
> > > System.out.println(ignite.log().getClass());
> > > }
> > > }
> > > }
> > >
> > > *Output*
> > >
> > > /Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/bin/java
> > > -Didea.launcher.port=7535
> > > "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA
> > > CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> > > "/Library/Java/JavaVirtualMachines/jdk1.8.0_
> > 74.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/
> > JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> > deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> > 74.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/
> > Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> > lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.
> > 8.0_74.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/
> > Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> > lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.
> > 8.0_74.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/
> > JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> > ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> > 74.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/
> > JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> 

[GitHub] ignite pull request #2298: IGNITE-5750 Change HMSM format to hh:mm:ss.mmm

[asfgit]

Github user asfgit closed the pull request at:

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


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

Re: How to configure ignite-jcl and Ignite-slf4j logger

[Nikolay Tikhonov]

Hi Denis,

JCL it's wrapper for logging system (similar sl4j) which can be used
together with log4j. I guess that JavaDoc correct.

On Fri, Sep 1, 2017 at 5:40 PM, Denis Magda  wrote:

> Nikolai,
>
> Looking at JCL documentation I see the usage of Log4j together with JCL:
>
> * 
> *  ...
> *  property name="gridLogger"
> *  bean class="org.apache.ignite.logger.jcl.JclLogger"
> *  constructor-arg type="org.apache.commons.
> logging.Log"
> *  bean class="org.apache.commons.
> logging.impl.Log4JLogger"
> *  constructor-arg type="java.lang.String"
> value="config/ignite-log4j.xml"/
> *  /bean
> *  /constructor-arg
> *  /bean
> *  /property
> *  ...
> * 
>
>
> or
>
> * And the same configuration if you'd like to configure Ignite in your
> code:
> * 
> *  IgniteConfiguration cfg = new IgniteConfiguration();
> *  ...
> *  IgniteLogger log = new JclLogger(new Log4JLogger("config/ignite-
> log4j.xml"));
> *  ...
> *  cfg.setGridLogger(log);
> * 
>
>
> Is it wrong? Could you fix the Java Doc in a proper way?
>
>
> > On Sep 1, 2017, at 3:12 AM, Nikolai Tikhonov 
> wrote:
> >
> > Hello Prachi!
> >
> > You need to set gridLogger property in IgniteConfiguration and remove
> ignite-log4j dependency from POM file.
> >
> > For example for Sl4j logger:
> >
> > igniteConfiguration.setGridLogger(new Slf4jLogger());
> >
> > and for Jc logger:
> >
> > igniteConfiguration.setGridLogger(new JclLogger());
> >
> > On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg > wrote:
> > Engineers,
> >
> > In the attempt to document loggers supported by Ignite, I am having a
> hard
> > time configuring ignite-jcl and ignite-slf4j (I could configure log4j and
> > log4j2). I don't see the log message on my console when I use ignite-jcl
> or
> > ignite-slf4j.
> >
> >  Below is the configuration and sample code I am using:
> >
> > *ignite-log4j.xml*
> >
> > 
> >  > xmlns:log4j='http://jakarta.apache.org/log4j/ <
> http://jakarta.apache.org/log4j/>'>
> >
> > 
> > 
> > 
> > 
> > 
> > 
> >
> > 
> > 
> > 
> > 
> >
> > 
> >
> >
> > *Maven dependency -*
> >
> > 
> > org.apache.ignite
> > ignite-log4j
> > 2.1.0
> > 
> >
> > 
> > org.apache.ignite
> > ignite-jcl
> > 2.1.0
> > 
> >
> >
> > *Configuration for JCL ( as specified in javadoc)- *
> >
> > 
> > 
> > 
> > 
> >  > value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> > 
> > 
> > 
> > 
> >
> >
> > *Sample code I am using- *
> >
> > public class LoggerExample {
> > public static void main(String[] args) throws IgniteException {
> > try (Ignite ignite =
> > Ignition.start("/Users/prachig/myexamples/config/cluster-config.xml"))
> > {
> > ignite.log().info("Info Message 1 Logged !!!");
> > ignite.log().info("Info Message 2 Logged !!!");
> >
> > System.out.println(ignite.log().getClass());
> > }
> > }
> > }
> >
> > *Output*
> >
> > /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java
> > -Didea.launcher.port=7535
> > "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA
> > CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> > "/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/charsets.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> deploy.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/cldrdata.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/dnsns.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/jaccess.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/jfxrt.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/localedata.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/nashorn.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/sunec.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/sunjce_provider.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/sunpkcs11.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/zipfs.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/javaws.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> jce.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/jfr.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> jfxswt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/jsse.jar:/Library/Java/
> 

Re: Ignite Durable Memory & Persistent Store introduction for developers

[Denis Magda]

Dmitriy,

First of all, thanks for putting this low level details on paper! Current and 
future community members will be grateful to you.

Second, let me be a reviewer of the page and suggest some improvements. Until 
the review is over I would encourage us to hold on with any public 
announcements such as blog post. 

I’ve reviewed and edited Ignite Durable Memory section 
(https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood#IgniteDurableMemory-underthehood-IgniteDurableMemory
 
).
 Please address the questions below and I’ll move on with the new sections 
afterwards.

1) "Different caches and its partitions bring more complex addressing scheme 
but it is still possible to map from page ID to position in particular file: 
pageId => file + offset in this file”.

Probably this appears too early in the doc because above we just introduced 
page ID notion with durable memory and now we’re talking about some files? Are 
these files of ignite persistence? What if the persistence is disabled? 
Honestly, the sentence gets out of the story context.


2) "Also, the tree pages can be merged into one if < 50% of space is used.”

50% of the whole memory available? Please clarify.


3) "There is one page ID table per memory segment.”

It’s the same segment as it’s described in the main doc, right? 
https://apacheignite.readme.io/docs/memory-architecture#section-memory-segment 



4) "within unsafe segment” 

If we want to mention “usafe” here we need to explain what that is.

5) "If memory amount less than whole index size, Ignite still can operate.”

How do we define “index size”? Is this the page size?


—
Denis


> On Aug 30, 2017, at 8:24 AM, Dmitry Pavlov  wrote:
> 
> Hi Igniters,
> 
> 
> I am glad to introduce two new wiki articles. These articles contain
> high-level description of
> 
> - Ignite Durable Memory (
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Durable+Memory+-+under+the+hood
> )
> 
> - and Ignite Persistent Store (
> https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood
> )
> 
> These articles cover basic principles and internal design. Pages may be
> useful for new contributors during start of working with persistent store
> code base.
> 
> 
> I would like to thank all contributors who helped me with my questions.
> Their answers and support made it possible to start this description.
> 
> 
> I will appreciate any feedback and questions. Suggestions and edits are
> welcome, of course.
> 
> 
> Sincerely,
> 
> Dmitriy Pavlov

[GitHub] ignite pull request #2581: IGNITE-6188: ODBC: Fix for SQLFreeStmt(SQL_CLOSE)...

[isapego]

GitHub user isapego opened a pull request:

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

IGNITE-6188: ODBC: Fix for SQLFreeStmt(SQL_CLOSE).



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

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

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

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


commit 54f1c71c6a743406bba4f82ce1bb0810912dece2
Author: Igor Sapego 
Date:   2017-09-01T16:29:08Z

IGNITE-6188: Added test.

commit 7e30295db6cdb2571a0e996998cd0b6dc6785c1b
Author: Igor Sapego 
Date:   2017-09-01T16:41:10Z

IGNITE-6188: Fix




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

[jira] [Created] (IGNITE-6245) ODBC: update query should return affected rows number for non-batch queries as well.

[Andrew Mashenkov (JIRA)]

Andrew Mashenkov created IGNITE-6245:


 Summary: ODBC: update query should return affected rows number for 
non-batch queries as well.
 Key: IGNITE-6245
 URL: https://issues.apache.org/jira/browse/IGNITE-6245
 Project: Ignite
  Issue Type: Bug
Reporter: Andrew Mashenkov
 Fix For: 2.3


Looks like OdbcQueryExecuteResult class doesn't have rowAffected field that 
OdbcQueryExecuteBatchResult has.



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

Re: Hopeless looping in TcpCommunicationSpi

[Ilya Kasnacheev]

Yes, the same problem is possible with server-server communication. I've
amended my pull request to include a test for that.

There are already Thread.sleeps() in this look so I propose to add a
countdown to maxConnectionAttempts instead of while(true)

Ideally we should find a way to log last error, such issues are hard to
debug otherwise.

-- 
Ilya Kasnacheev

2017-09-01 15:27 GMT+03:00 Yakov Zhdanov :

> Ilya, I reviewed your test and I now see the point.
>
> Is the same possible with server-server? Or failure process will be
> initiated for remote node by local one?
>
> Will the following work for client? If connection fails then client takes a
> pause for 1 sec with Thread.sleep() and takes another attempt. If
> maxConnectionAttempts (3 by default) fails then client stops and restart
> itself.
>
> --Yakov
>

[jira] [Created] (IGNITE-6244) .NET: Thin client: ScanQuery

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6244:
--

 Summary: .NET: Thin client: ScanQuery
 Key: IGNITE-6244
 URL: https://issues.apache.org/jira/browse/IGNITE-6244
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.3


Implement ScanQuery in thin client.

Challenges:
* Query cursor. This will require some kind of HandleRegistry on Java side, so 
we can pass an ID back to client.
* Predicate. Thin client is not .NET-specific. We need a way to support 
predicates in (at least) Java and .NET, there should be some platform id.



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

Re: How to configure ignite-jcl and Ignite-slf4j logger

[Denis Magda]

Nikolai,

Looking at JCL documentation I see the usage of Log4j together with JCL:

* 
*  ...
*  property name="gridLogger"
*  bean class="org.apache.ignite.logger.jcl.JclLogger"
*  constructor-arg type="org.apache.commons.logging.Log"
*  bean 
class="org.apache.commons.logging.impl.Log4JLogger"
*  constructor-arg type="java.lang.String" 
value="config/ignite-log4j.xml"/
*  /bean
*  /constructor-arg
*  /bean
*  /property
*  ...
* 


or

* And the same configuration if you'd like to configure Ignite in your code:
* 
*  IgniteConfiguration cfg = new IgniteConfiguration();
*  ...
*  IgniteLogger log = new JclLogger(new 
Log4JLogger("config/ignite-log4j.xml"));
*  ...
*  cfg.setGridLogger(log);
* 


Is it wrong? Could you fix the Java Doc in a proper way?


> On Sep 1, 2017, at 3:12 AM, Nikolai Tikhonov  wrote:
> 
> Hello Prachi!
> 
> You need to set gridLogger property in IgniteConfiguration and remove 
> ignite-log4j dependency from POM file.
> 
> For example for Sl4j logger:
> 
> igniteConfiguration.setGridLogger(new Slf4jLogger());
> 
> and for Jc logger:
> 
> igniteConfiguration.setGridLogger(new JclLogger());
> 
> On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg  > wrote:
> Engineers,
> 
> In the attempt to document loggers supported by Ignite, I am having a hard
> time configuring ignite-jcl and ignite-slf4j (I could configure log4j and
> log4j2). I don't see the log message on my console when I use ignite-jcl or
> ignite-slf4j.
> 
>  Below is the configuration and sample code I am using:
> 
> *ignite-log4j.xml*
> 
> 
>  xmlns:log4j='http://jakarta.apache.org/log4j/ 
> '>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> *Maven dependency -*
> 
> 
> org.apache.ignite
> ignite-log4j
> 2.1.0
> 
> 
> 
> org.apache.ignite
> ignite-jcl
> 2.1.0
> 
> 
> 
> *Configuration for JCL ( as specified in javadoc)- *
> 
> 
> 
> 
> 
>  value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> 
> 
> 
> 
> 
> 
> *Sample code I am using- *
> 
> public class LoggerExample {
> public static void main(String[] args) throws IgniteException {
> try (Ignite ignite =
> Ignition.start("/Users/prachig/myexamples/config/cluster-config.xml"))
> {
> ignite.log().info("Info Message 1 Logged !!!");
> ignite.log().info("Info Message 2 Logged !!!");
> 
> System.out.println(ignite.log().getClass());
> }
> }
> }
> 
> *Output*
> 
> /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java
> -Didea.launcher.port=7535
> "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA
> CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> 

[GitHub] ignite pull request #2580: IGNITE-6236 .NET: Thin client: cache.Get and Put ...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-6236 .NET: Thin client: cache.Get and Put for user types



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

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

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

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


commit fe7699a44160da698bc37491f6858f88db6bfed8
Author: Pavel Tupitsyn 
Date:   2017-09-01T14:23:29Z

IGNITE-6236 .NET: Thin client: cache.Get and Put for user types




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

[GitHub] ignite pull request #2464: IGNITE-5849 metastorage

[kdudkov]

Github user kdudkov closed the pull request at:

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


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

[GitHub] ignite pull request #1893: Ignite-3054 nio connections

[kdudkov]

Github user kdudkov closed the pull request at:

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


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

Re: Hopeless looping in TcpCommunicationSpi

[Yakov Zhdanov]

Ilya, I reviewed your test and I now see the point.

Is the same possible with server-server? Or failure process will be
initiated for remote node by local one?

Will the following work for client? If connection fails then client takes a
pause for 1 sec with Thread.sleep() and takes another attempt. If
maxConnectionAttempts (3 by default) fails then client stops and restart
itself.

--Yakov

Re: IgniteFuture -> CompletableFuture

[Vladimir Ozerov]

Exactly.

On Fri, Sep 1, 2017 at 2:51 PM, Yakov Zhdanov  wrote:

> >>Vova, I am not sure I understand. How will it be released?
>
> This can be a module containing only java8 related stuff including method
> that converts IgniteFuture to completable future. And it should be built
> with java8.
>
> --Yakov
>

[GitHub] ignite pull request #2579: Ignite 6014 on 2.1.4 branch

[Jokser]

GitHub user Jokser opened a pull request:

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

Ignite 6014 on 2.1.4 branch



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

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

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

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


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:   

[GitHub] ignite pull request #2578: IGNITE-6014 Transaction records in WAL.

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-6014 Transaction records in WAL.



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

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

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

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


commit b36d13e2d122f559320dbfceb043d392228c8e1a
Author: Pavel Kovalenko 
Date:   2017-09-01T11:47:13Z

IGNITE-6014 Transaction records in WAL.




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

Re: IgniteFuture -> CompletableFuture

[Yakov Zhdanov]

>>Vova, I am not sure I understand. How will it be released?

This can be a module containing only java8 related stuff including method
that converts IgniteFuture to completable future. And it should be built
with java8.

--Yakov

Re: Cluster auto activation design proposal

[Dmitriy Setrakyan]

How about this:


> *interface ClusterActivator {*
> *boolean activate(Collection nodes);**}*


Out of the box, we can provide this implementation of the activation filter:


>
> *ClusterInitialActiveSet implements ClusterActivator { *
> *InigeInitialActiveSet(String... addresses);**}*


Then user configuration can look as follows:

*IgniteConfiguration.setActivationFilter(new
> ClusterInitialActiveSet("1.2.3.4", "4.3.2.1", etc));*


Thoughts?

D.

On Fri, Sep 1, 2017 at 1:47 PM, Sergey Chugunov 
wrote:

> Dmitriy,
>
> The idea is interesting however I cannot come up with a clear use case
> which can be widely adopted.
> I would give users a simple API at first to cover 80% of their needs and
> then collect some feedback and start thinking about adding new
> functionality.
>
> Makes sense?
>
> Sergey.
>
> On Thu, Aug 31, 2017 at 3:55 AM, Dmitriy Setrakyan 
> wrote:
>
> > Hm... Can we also ask user to optionally provide a predicate which will
> > receive a collection of nodes started so far and return true if the
> > activation should happen? Will it be useful?
> >
> > On Wed, Aug 30, 2017 at 6:28 PM, Sergey Chugunov <
> > sergey.chugu...@gmail.com>
> > wrote:
> >
> > > Nick,
> > >
> > > As I summed up in this thread above, calling setter for initial
> > activation
> > > nodes is not the only option:
> > >
> > >1. user starts up new cluster of desired number of nodes and
> activates
> > >it using existing API.
> > >BLT is created with all nodes presented in the cluster at the moment
> > of
> > >activation, no API is needed;
> > >
> > >2. user prepares BLT using web-console or visor CMD tools and sets
> it
> > to
> > >the cluster. New API setter is needed:
> > >Ignite.activation().setInitialActivationNodes(Collection<
> ClusterNode>
> > >nodes);
> > >
> > >3. user provides via static configuration a list of nodes that are
> > >expected to be in the cluster.
> > >User starts nodes one by one; when all preconfigured nodes are
> started
> > >cluster is activated and BLT is created.
> > >As list of nodes may be huge it is provided via separate file to
> avoid
> > >flooding main configuration.
> > >
> > > So the option you proposed is already in the list.
> > >
> > > As for idea of activating cluster based only on number of nodes may be
> > > risky.
> > > E.g. if user starts up with data stored on disk and unexpected node
> joins
> > > the topology.
> > > Cluster will get activated with N-1 nodes where all the data is
> presented
> > > and one node completely empty. Data loss may happen in such scenario.
> > >
> > > Thanks,
> > > Sergey.
> > >
> > >
> > > On Wed, Aug 30, 2017 at 4:23 PM, Nick Pordash 
> > > wrote:
> > >
> > > > How is a user expected to produce a collection of ClusterNode prior
> to
> > > all
> > > > of the expected nodes joining? Users don't create instances of this,
> so
> > > as
> > > > far as I can tell it would have to be retrieved from IgniteCluster.
> > > > However, would doing that and calling the proposed method be really
> any
> > > > different than calling Ignite.activate and using the current set of
> > > server
> > > > nodes as that collection?
> > > >
> > > > From a user's perspective is it really necessary that specific nodes
> > need
> > > > to be identified vs saying that they expect N server nodes to be in
> the
> > > > cluster for auto activation?
> > > >
> > > > -Nick
> > > >
> > > > On Wed, Aug 30, 2017, 1:23 AM Sergey Chugunov <
> > sergey.chugu...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > Now I see your point and I think you're right.
> > > > >
> > > > > We can give end-user a simple setter like
> > > > > Ignite::activation::setInitialActivationNodes(
> > Collection
> > > > > nodes) to provide collection of nodes that grid must reach to
> > activate
> > > > > automatically.
> > > > >
> > > > > And then using the collection we'll create BaselineTopology
> > abstraction
> > > > > internally.
> > > > >
> > > > > As a result user won't be exposed to our internal abstractions and
> > will
> > > > > work with intuitive concept of collection of nodes.
> > > > >
> > > > > Thanks,
> > > > > Sergey.
> > > > >
> > > > >
> > > > > On Mon, Aug 28, 2017 at 4:39 PM, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > Sergey, the interface you are suggesting is internal, not
> external.
> > > Why
> > > > > > should user ever see it or care about it?
> > > > > >
> > > > > > D.
> > > > > >
> > > > > > On Mon, Aug 28, 2017 at 3:18 PM, Sergey Chugunov <
> > > > > > sergey.chugu...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Dmitriy,
> > > > > > >
> > > > > > > It was my misunderstanding, I believe that setter is not enough
> > and
> > > > we
> > > > > > need
> > > > > > > a full-fledged entity.
> > > > > > >
> > > > > > > We should also be able to check if BLTs are 

[GitHub] ignite pull request #2577: IGNITE-5999 : Fixed calculation of moving partiti...

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-5999 : Fixed calculation of moving partitions count.



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

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

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

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


commit bd23da34b1a77e4c9742b7021e6917ca91fadf8f
Author: Ilya Lantukh 
Date:   2017-09-01T11:25:34Z

ignite-5999 : Fixed calculation of moving partitions count.




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

[GitHub] ignite pull request #2576: IGNITE-5849 refactor DataPageIO & FreeList, intro...

[kdudkov]

GitHub user kdudkov opened a pull request:

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

IGNITE-5849 refactor DataPageIO & FreeList, introduce MetaStorage



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

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

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

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


commit 8474db6c56f6cacaa0745f1f43beaa812b65cb2f
Author: Konstantin Dudkov 
Date:   2017-08-17T10:39:28Z

IGNITE-5849 refactor DataPageIO & FreeList, introduce MetaStorage




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

Re: [DISCUSSION] Urgent Ignite bug fix release

[Dmitry Pavlov]

Hi, at least for this release I suggest to keep versioning as is and use 2.2

Without solved issue with
http://apache-ignite-developers.2346864.n4.nabble.com/usage-analytics-td19504.html
Ignite will not remind users about latest available ignite version.
Versioning structure change will confuse users for now. But keeping 2.2
will allow Ignite users to take newest version with urgent fixes.

I think is it important to achieve users to update. But without
notification server is it complex.

Sincerely,
Dmitriy Pavlov

пт, 1 сент. 2017 г. в 4:50, 李玉珏@163 <18624049...@163.com>:

> 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 <
> avinogra...@gridgain.com>
> > 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 cannot suggest
> >>> anything reasonable, print warning, stop calculation.
> >>>
> >>> 5) check heap size (shouldn't exceed 30% of available memory
> (total_memory
> >>> - reserved for OS memory) * 30% for all JVMs, if it exeedes, suggest
> just
> >>> calculated value or 512MB minimal)
> >>>
> >>> 6) check if system cache size changed, suggest default value if it's so
> >>>
> >>> 7) in case 100 mb * policies count < available memory, suggest using
> >>> default policy with max size equals to remaining memory (available -
> heap
> >>> -
> >>> system cache)
> >>>
> >>> 8) calculate new size for each memory policy ( it's user defined size *
> >>> (remaining / (all_policies_size * nodes_cnt)); in proportion to
> >>> remaining memory, devided by nodes number on the host or 100 mb
> minimal)
> >>>
> >>> 9) print suggestions
> >>>
> >>>
> >>>
> >>> 2017-08-28 15:10 GMT+03:00 Dmitriy Setrakyan :
> >>>
>  Igor, can you please describe the algorithm with all the thresholds?
> 
>  On Mon, Aug 28, 2017 at 4:56 AM, Seliverstov Igor <
> gvvinbl...@gmail.com
> 
>  wrote:
> 
> > The suggestion here is based on initial settings, and it's so because
>  there
> > is no other nodes on the host in the example.
> >
> > The algorithm tries to preserve the original ratio of memory policies
> > keeping numbers 

Re: IGNITE-2779 BinaryMarshaller caches must be cleaned during client reconnect.

[Nikita Amelchev]

Hi, Igniters.

I have done issue 2779 - BinaryMarshaller caches must be cleaned during
client reconnect.[1]

Could you, please, review?

Solution:

We stop server nodes and keep alive the client. Then we take a new instance
of the cache and client node throws an exception in
BinaryReaderExImpl.getOrCreateSchema when try read from cache. A client
couldn't take metadata from context.

Problem was that user type descriptor was cached on the client and absent
on servers. I clean user descriptors after client disconnect. It fixes the
issue. I have tested solution.[2]

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

TC:
https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=projectOverview_Ignite20Tests=pull%2F2518%2Fhead
Upsource: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-328

2017-02-16 17:22 GMT+03:00 ALEKSEY KUZNETSOV :

> will take the ticket https://issues.apache.org/jira/browse/IGNITE-2779
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*
>



-- 
Best wishes,
Amelchev Nikita

Re: [DISCUSSION] Urgent Ignite bug fix release

[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 <
>> avinogra...@gridgain.com>
>> 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 cannot suggest
 anything reasonable, print warning, stop calculation.

 5) check heap size (shouldn't exceed 30% of available memory
 (total_memory
 - reserved for OS memory) * 30% for all JVMs, if it exeedes, suggest
 just
 calculated value or 512MB minimal)

 6) check if system cache size changed, suggest default value if it's so

 7) in case 100 mb * policies count < available memory, suggest using
 default policy with max size equals to remaining memory (available -
 heap
 -
 system cache)

 8) calculate new size for each memory policy ( it's user defined size *
 (remaining / (all_policies_size * nodes_cnt)); in proportion to
 remaining memory, devided by nodes number on the host or 100 mb minimal)

 9) print suggestions



 2017-08-28 15:10 GMT+03:00 Dmitriy Setrakyan :

 Igor, can you please describe the algorithm with all the thresholds?
>
> On Mon, Aug 28, 2017 at 4:56 AM, Seliverstov Igor <
> gvvinbl...@gmail.com
>
> wrote:
>
> The suggestion here is based on initial settings, and it's so because
>>
> there
>
>> is no other nodes on the host in the example.
>>
>> The algorithm tries to preserve the original ratio of memory policies
>> keeping numbers reasonable (for example after some thresshold it will
>> suggest not to use several memory policies if there is not enough of
>>
> memory
>
>> for all of them) and taking into consideration nodes count on the
>>
> host,

> each jvm heap, needed memory for OS, etc
>>
>> 2017-08-28 14:38 GMT+03:00 Dmitriy 

[jira] [Created] (IGNITE-6243) RazorSQL crashed on try edit, describe and another actions with table.

[Aleksey Chetaev (JIRA)]

Aleksey Chetaev created IGNITE-6243:
---

 Summary: RazorSQL crashed on try edit, describe and another 
actions with table.
 Key: IGNITE-6243
 URL: https://issues.apache.org/jira/browse/IGNITE-6243
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.1
Reporter: Aleksey Chetaev


1. Install ODBC on Windows.
2. Crete DSN for Ignite ODBC Driver.
3. Connect by RazorSQL using ODBC.
4. Create new table. 
5. Try to edit table, using right click.
RazorSQL crashed without error.

Need check that it's not crash of Apache Ignite ODBC driver.



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

Re: Cluster auto activation design proposal

[Sergey Chugunov]

Dmitriy,

The idea is interesting however I cannot come up with a clear use case
which can be widely adopted.
I would give users a simple API at first to cover 80% of their needs and
then collect some feedback and start thinking about adding new
functionality.

Makes sense?

Sergey.

On Thu, Aug 31, 2017 at 3:55 AM, Dmitriy Setrakyan 
wrote:

> Hm... Can we also ask user to optionally provide a predicate which will
> receive a collection of nodes started so far and return true if the
> activation should happen? Will it be useful?
>
> On Wed, Aug 30, 2017 at 6:28 PM, Sergey Chugunov <
> sergey.chugu...@gmail.com>
> wrote:
>
> > Nick,
> >
> > As I summed up in this thread above, calling setter for initial
> activation
> > nodes is not the only option:
> >
> >1. user starts up new cluster of desired number of nodes and activates
> >it using existing API.
> >BLT is created with all nodes presented in the cluster at the moment
> of
> >activation, no API is needed;
> >
> >2. user prepares BLT using web-console or visor CMD tools and sets it
> to
> >the cluster. New API setter is needed:
> >Ignite.activation().setInitialActivationNodes(Collection
> >nodes);
> >
> >3. user provides via static configuration a list of nodes that are
> >expected to be in the cluster.
> >User starts nodes one by one; when all preconfigured nodes are started
> >cluster is activated and BLT is created.
> >As list of nodes may be huge it is provided via separate file to avoid
> >flooding main configuration.
> >
> > So the option you proposed is already in the list.
> >
> > As for idea of activating cluster based only on number of nodes may be
> > risky.
> > E.g. if user starts up with data stored on disk and unexpected node joins
> > the topology.
> > Cluster will get activated with N-1 nodes where all the data is presented
> > and one node completely empty. Data loss may happen in such scenario.
> >
> > Thanks,
> > Sergey.
> >
> >
> > On Wed, Aug 30, 2017 at 4:23 PM, Nick Pordash 
> > wrote:
> >
> > > How is a user expected to produce a collection of ClusterNode prior to
> > all
> > > of the expected nodes joining? Users don't create instances of this, so
> > as
> > > far as I can tell it would have to be retrieved from IgniteCluster.
> > > However, would doing that and calling the proposed method be really any
> > > different than calling Ignite.activate and using the current set of
> > server
> > > nodes as that collection?
> > >
> > > From a user's perspective is it really necessary that specific nodes
> need
> > > to be identified vs saying that they expect N server nodes to be in the
> > > cluster for auto activation?
> > >
> > > -Nick
> > >
> > > On Wed, Aug 30, 2017, 1:23 AM Sergey Chugunov <
> sergey.chugu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Dmitriy,
> > > >
> > > > Now I see your point and I think you're right.
> > > >
> > > > We can give end-user a simple setter like
> > > > Ignite::activation::setInitialActivationNodes(
> Collection
> > > > nodes) to provide collection of nodes that grid must reach to
> activate
> > > > automatically.
> > > >
> > > > And then using the collection we'll create BaselineTopology
> abstraction
> > > > internally.
> > > >
> > > > As a result user won't be exposed to our internal abstractions and
> will
> > > > work with intuitive concept of collection of nodes.
> > > >
> > > > Thanks,
> > > > Sergey.
> > > >
> > > >
> > > > On Mon, Aug 28, 2017 at 4:39 PM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org>
> > > > wrote:
> > > >
> > > > > Sergey, the interface you are suggesting is internal, not external.
> > Why
> > > > > should user ever see it or care about it?
> > > > >
> > > > > D.
> > > > >
> > > > > On Mon, Aug 28, 2017 at 3:18 PM, Sergey Chugunov <
> > > > > sergey.chugu...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Dmitriy,
> > > > > >
> > > > > > It was my misunderstanding, I believe that setter is not enough
> and
> > > we
> > > > > need
> > > > > > a full-fledged entity.
> > > > > >
> > > > > > We should also be able to check if BLTs are compatible. Interface
> > > looks
> > > > > > like this and use case for this functionality is described below.
> > > > > >
> > > > > > interface BaselineTopology {
> > > > > >Collection nodes();
> > > > > >boolean isCompatibleWith(BaselineTopology blt);
> > > > > > }
> > > > > >
> > > > > > Let's consider the following scenario:
> > > > > >
> > > > > >1. We have a grid with N nodes: it is up, active and has data
> in
> > > it.
> > > > > ->
> > > > > >BLT #1 created.
> > > > > >2. We shutdown the grid. Then divide it into two parts:
> > Part1_grid
> > > > and
> > > > > >Part2_grid.
> > > > > >3. We start and activate Part1_grid . Topology has changed ->
> > > BLT#2
> > > > > >created.
> > > > > >After that we shutdown that Part1_grid.
> > > > > >4. We start and activate Part2_grid. Topology also 

Re: IgniteFuture -> CompletableFuture

[Dmitry Pavlov]

We can build project using java 8 partially for java 7 and partially for
java 8 (target bytecode version).



I guess for end user it will be something like 2 artifacts to be dependent
from

- group: 'org.apache.ignite', name: 'ignite-core', version: '2.3'

- group: 'org.apache.ignite', name: 'ignite-core8', version: '2.3'

 Am I right?



But what will we do with ignite-core8 when we support Java8 in the long run


пт, 1 сент. 2017 г. в 13:35, Dmitriy Setrakyan :

> On Thu, Aug 31, 2017 at 3:39 PM, Vladimir Ozerov 
> wrote:
>
> > There is no need to migrate to Java 8 to support CompletableFuture.
> Create
> > separate Maven project and compile it with Java 8 - this is it.
> >
>
> Vova, I am not sure I understand. How will it be released?
>
>
> >
> > On Thu, Aug 31, 2017 at 3:28 PM, Dmitry Pavlov 
> > wrote:
> >
> > > +1 for migrating to java 8.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > >
> > > On чт, 31 авг. 2017 г., 11:03 Yakov Zhdanov 
> wrote:
> > >
> > > > CompletableFuture is part of java 8.
> > > >
> > > > --Yakov
> > > >
> > > > 2017-08-31 4:46 GMT+03:00 Dmitriy Setrakyan :
> > > >
> > > > > Igniters,
> > > > >
> > > > > I received the following proposal in my blog. I think this is
> useful.
> > > Any
> > > > > thoughts?
> > > > >
> > > > > Please extend IgniteFuture by conversion method to
> > CompletableFuture. I
> > > > > > bored to write something like this:
> > > > >
> > > > >
> > > > > > asyncCache.invoke(key, entryProcessor);
> > > > > > CompletableFuture completableFuture = new CompletableFuture<>();
> > > > > > IgniteFuture igniteFuture = asyncCache.future();
> > > > > > IgniteInClosure> listener = (IgniteInClosure>)
> > completedIgniteFuture
> > > > -> {
> > > > > > Throwable exception = null;
> > > > > > T result = null;
> > > > > > try {
> > > > > > result = completedIgniteFuture.get();
> > > > > > } catch (Throwable t) {
> > > > > > exception = t;
> > > > > > }
> > > > > > if (exception != null) {
> > > > > > completableFuture.completeExceptionally(exception);
> > > > > > } else {
> > > > > > completableFuture.complete(result);
> > > > > > }
> > > > > > };
> > > > > > igniteFuture.listen(listener);
> > > > > > return completableFuture;
> > > > >
> > > >
> > >
> >
>

Re: IgniteFuture -> CompletableFuture

[Dmitriy Setrakyan]

On Thu, Aug 31, 2017 at 3:39 PM, Vladimir Ozerov 
wrote:

> There is no need to migrate to Java 8 to support CompletableFuture. Create
> separate Maven project and compile it with Java 8 - this is it.
>

Vova, I am not sure I understand. How will it be released?


>
> On Thu, Aug 31, 2017 at 3:28 PM, Dmitry Pavlov 
> wrote:
>
> > +1 for migrating to java 8.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> >
> > On чт, 31 авг. 2017 г., 11:03 Yakov Zhdanov  wrote:
> >
> > > CompletableFuture is part of java 8.
> > >
> > > --Yakov
> > >
> > > 2017-08-31 4:46 GMT+03:00 Dmitriy Setrakyan :
> > >
> > > > Igniters,
> > > >
> > > > I received the following proposal in my blog. I think this is useful.
> > Any
> > > > thoughts?
> > > >
> > > > Please extend IgniteFuture by conversion method to
> CompletableFuture. I
> > > > > bored to write something like this:
> > > >
> > > >
> > > > > asyncCache.invoke(key, entryProcessor);
> > > > > CompletableFuture completableFuture = new CompletableFuture<>();
> > > > > IgniteFuture igniteFuture = asyncCache.future();
> > > > > IgniteInClosure> listener = (IgniteInClosure>)
> completedIgniteFuture
> > > -> {
> > > > > Throwable exception = null;
> > > > > T result = null;
> > > > > try {
> > > > > result = completedIgniteFuture.get();
> > > > > } catch (Throwable t) {
> > > > > exception = t;
> > > > > }
> > > > > if (exception != null) {
> > > > > completableFuture.completeExceptionally(exception);
> > > > > } else {
> > > > > completableFuture.complete(result);
> > > > > }
> > > > > };
> > > > > igniteFuture.listen(listener);
> > > > > return completableFuture;
> > > >
> > >
> >
>

Re: Hopeless looping in TcpCommunicationSpi

[Ilya Kasnacheev]

Hello Yakov,

This is client repeatedly failing (for some spurious reason) after it
connects to socket in createTcpClient()

It would then return null and reserveClient() will retry. Forever.

I've prepared a sample pull request to reproduce and remedy the problem:
https://github.com/apache/ignite/pull/2575


-- 
Ilya Kasnacheev

2017-09-01 13:04 GMT+03:00 Yakov Zhdanov :

> Ilya, can you please provide more details? Is this client or server failing
> to connect?
>
> --Yakov
>

[GitHub] ignite pull request #2575: IGNITE-6071 Finite number of attempts in reserveC...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-6071 Finite number of attempts in reserveClient()



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

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

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

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


commit 1e8e082ced9fc99b20867d05ede08e881a0c503b
Author: Ilya Kasnacheev 
Date:   2017-09-01T10:24:52Z

IGNITE-6071 Finite number of attempts in reserveClient()




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

Re: How to configure ignite-jcl and Ignite-slf4j logger

[Nikolai Tikhonov]

Hello Prachi!

You need to set gridLogger property in IgniteConfiguration and remove
ignite-log4j dependency from POM file.

For example for Sl4j logger:

*igniteConfiguration.setGridLogger(new Slf4jLogger());*

and for Jc logger:

*igniteConfiguration.setGridLogger(new JclLogger());*

On Fri, Sep 1, 2017 at 2:44 AM, Prachi Garg  wrote:

> Engineers,
>
> In the attempt to document loggers supported by Ignite, I am having a hard
> time configuring ignite-jcl and ignite-slf4j (I could configure log4j and
> log4j2). I don't see the log message on my console when I use ignite-jcl or
> ignite-slf4j.
>
>  Below is the configuration and sample code I am using:
>
> *ignite-log4j.xml*
>
> 
>  xmlns:log4j='http://jakarta.apache.org/log4j/'>
>
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
>
> 
>
>
> *Maven dependency -*
>
> 
> org.apache.ignite
> ignite-log4j
> 2.1.0
> 
>
> 
> org.apache.ignite
> ignite-jcl
> 2.1.0
> 
>
>
> *Configuration for JCL ( as specified in javadoc)- *
>
> 
> 
> 
> 
>  value="/Users/prachig/myexamples/config/ignite-log4j.xml"/>
> 
> 
> 
> 
>
>
> *Sample code I am using- *
>
> public class LoggerExample {
> public static void main(String[] args) throws IgniteException {
> try (Ignite ignite =
> Ignition.start("/Users/prachig/myexamples/config/cluster-config.xml"))
> {
> ignite.log().info("Info Message 1 Logged !!!");
> ignite.log().info("Info Message 2 Logged !!!");
>
> System.out.println(ignite.log().getClass());
> }
> }
> }
>
> *Output*
>
> /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java
> -Didea.launcher.port=7535
> "-Didea.launcher.bin.path=/Applications/IntelliJ IDEA
> CE.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath
> "/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> charsets.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/deploy.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/cldrdata.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/dnsns.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/jaccess.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/jfxrt.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/ext/localedata.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/nashorn.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/sunec.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/ext/sunjce_provider.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> ext/sunpkcs11.jar:/Library/Java/JavaVirtualMachines/jdk1.
> 8.0_74.jdk/Contents/Home/jre/lib/ext/zipfs.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/javaws.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/jce.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> jfr.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/jfxswt.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> jsse.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/management-agent.jar:/Library/
> Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/
> lib/plugin.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/jre/lib/resources.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/
> rt.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/lib/ant-javafx.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/lib/dt.
> jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/lib/
> javafx-mx.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/lib/jconsole.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/lib/
> packager.jar:/Library/Java/JavaVirtualMachines/jdk1.8.0_
> 74.jdk/Contents/Home/lib/sa-jdi.jar:/Library/Java/
> JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/lib/
> tools.jar:/Users/prachig/myexamples/target/classes:/
> Users/prachig/.m2/repository/org/apache/ignite/ignite-core/
> 2.1.0/ignite-core-2.1.0.jar:/Users/prachig/.m2/repository/
> javax/cache/cache-api/1.0.0/cache-api-1.0.0.jar:/Users/
> prachig/.m2/repository/org/jetbrains/annotations/13.0/
> annotations-13.0.jar:/Users/prachig/.m2/repository/org/
> gridgain/ignite-shmem/1.0.0/ignite-shmem-1.0.0.jar:/Users/
> prachig/.m2/repository/org/apache/ignite/ignite-spring/2.
> 1.0/ignite-spring-2.1.0.jar:/Users/prachig/.m2/repository/
> org/apache/ignite/ignite-indexing/2.1.0/ignite-indexing-2.1.0.jar:/Users/

Re: Hopeless looping in TcpCommunicationSpi

[Yakov Zhdanov]

Ilya, can you please provide more details? Is this client or server failing
to connect?

--Yakov

Re: IgniteFuture -> CompletableFuture

[Yakov Zhdanov]

Agree. Vladimir's suggestions should work.

We cannot drop Java7 now.

--Yakov

[GitHub] ignite pull request #2570: IGNITE-6233 .NET: Extract type codes to a separat...

[asfgit]

Github user asfgit closed the pull request at:

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


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