[jira] [Created] (IGNITE-6544) Can't switch WalMode from LOG_ONLY/BACKGROUND to DEFAULT

[Alexander Belyak (JIRA)]

Alexander Belyak created IGNITE-6544:


 Summary: Can't switch WalMode from LOG_ONLY/BACKGROUND to DEFAULT
 Key: IGNITE-6544
 URL: https://issues.apache.org/jira/browse/IGNITE-6544
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.1
Reporter: Alexander Belyak
 Fix For: 2.4


To reproduce:
1) Start ignite with persistence with LOG_ONLY/BACKGROUND log mode
2) Stop and start with DEFAULT log mode
Exception is:
{noformat}
Exception in thread "main" class org.apache.ignite.IgniteException: Failed to 
start processor: GridProcessorAdapter []
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
at org.apache.ignite.Ignition.start(Ignition.java:325)
at 
org.apache.ignite.examples.datagrid.CacheApiExample.main(CacheApiExample.java:59)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start 
processor: GridProcessorAdapter []
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1813)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:931)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1904)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1646)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1074)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:594)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:519)
at org.apache.ignite.Ignition.start(Ignition.java:322)
... 1 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to initialize 
WAL log segment (WAL segment size change is not 
supported):/tmp/s1/wal/0_0_0_0_0_0_0_1_lo_10_0_3_1_10_42_1_107_127_0_0_1_172_17_0_1_47500/.wal
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkFiles(FileWriteAheadLogManager.java:1420)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.checkOrPrepareFiles(FileWriteAheadLogManager.java:934)
at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.start0(FileWriteAheadLogManager.java:274)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.start(GridCacheSharedManagerAdapter.java:61)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.start(GridCacheProcessor.java:614)
at 
org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1810)
... 8 more
{noformat}



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

Re: Participation in the development of Apache Ignite

[Denis Magda]

Hello Ilya!

Persmissions have bee granted. Please don’t hesitate to discuss the ticket 
implementation details with the community first before getting down to the 
implementation. You can get a valuable feedback from us ;)

—
Denis

> On Oct 2, 2017, at 2:28 PM, Илья Ножкин  wrote:
> 
> Hello!
> I liked your project and ML module particulalry and I want to help you in
> the development. I have already discussed this idea with chief developer of
> ML module and he approved it. For that moment I've chosen a ticket and I
> need only a permission to assign myself to Jira issues. I would be glad if
> you give that rights to my account (ilya-nozhkin).
> 
> Sincerely,
> Ilya Nozhkin

Re: [DISCUSS] Ignite Update Checker

[Denis Magda]

I can’t see it. Could you share a direct link to it?

If we can add one more script like that and it will work then the question
is closed.

Denis

On Monday, October 2, 2017, Dmitriy Setrakyan  wrote:

> Denis, I can see the download.cgi script in SVN. Am I missing something?
>
> On Mon, Oct 2, 2017 at 5:31 PM, Denis Magda  > wrote:
>
> > Dmitriy,
> >
> > That’s the rule.  See replies in the ticket [1]
> >
> > *Background: the TLP server is already pretty darned busy just serving
> > *static* sites. Dynamic operation for near-200 PMCs would bury the
> machine.
> > Our policy of "static-only websites" has been in place since the
> Foundation
> > started*
> >
> > Download scripts seem to be the only exception and we as PMC don’t even
> > have access to them.
> >
> > If you want to keep pushing this direction let’s craft a message to Greg
> > and Daniel directly. I don’t know what else to ask for here rather than a
> > virtual machine that’s conceivably to much for a single script like that.
> >
> > [1] https://issues.apache.org/jira/browse/INFRA-15182 <
> > https://issues.apache.org/jira/browse/INFRA-15182>
> >
> > —
> > Denis
> >
> > > On Oct 2, 2017, at 2:48 AM, Dmitriy Setrakyan  >
> > wrote:
> > >
> > > On Mon, Oct 2, 2017 at 12:46 PM, Vladimir Ozerov  >
> > > wrote:
> > >
> > >> I am not sure it is good idea to send requests to 3rd-party addresses
> > from
> > >> Ignite node. Let's do not make the same mistakes again.
> > >>
> > >
> > > Agree with Vladimir.
> > >
> > > We obviously have CGI support on the website. Can someone explain why
> CGI
> > > is not possible to use?
> > >
> > >
> > >>
> > >> On Mon, Oct 2, 2017 at 12:42 PM, Andrey Novikov <
> anovi...@gridgain.com >
> > >> wrote:
> > >>
> > >>> We may directly send request to GA from Ignite node:
> > >>> https://developers.google.com/analytics/devguides/
> > >> collection/protocol/v1/
> > >>>  > >> collection/protocol/v1/
> > 
> > >>> Latest version can be received from maven central:
> > >>> https://repo1.maven.org/maven2/org/apache/ignite/
> > >>> ignite-core/maven-metadata.xml  > >>> maven2/org/apache/ignite/ignite-core/maven-metadata.xml>
> > >>>
> > >>>
> >  2 окт. 2017 г., в 12:51, Dmitriy Setrakyan  >
> > >>> написал(а):
> > 
> >  Denis,
> > 
> >  I am not sure I understand. We already do have CGI enabled for
> >  download.cgi. Is there something else we need?
> > 
> >  D.
> > 
> >  On Mon, Oct 2, 2017 at 8:35 AM, Denis Magda  >
> > >> wrote:
> > 
> > > There is an obstacle. There is no way to execute the script using
> PHP
> > >> or
> > > similar sever side language and trigger GA as discussed earlier:
> > > https://issues.apache.org/jira/browse/INFRA-15182
> > >
> > > How else can we tackle this?
> > >
> > > Denis
> > >
> > > On Thursday, September 7, 2017, Dmitriy Setrakyan <
> > >>> dsetrak...@apache.org >
> > > wrote:
> > >
> > >> I think it is safe to assume at this point that everyone is in
> > >> general
> > >> agreement, since there are no active objections.
> > >>
> > >> I have filed a ticket for the 2.3 release. Let's try to make it
> > >> happen:
> > >> https://issues.apache.org/jira/browse/IGNITE-6305
> > >>
> > >> D.
> > >>
> > >> On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org 
> > >> >
> > >> wrote:
> > >>
> > >>>
> > >>>
> > >>> On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani <
> > >> raul@evosent.com 
> > >> >
> > >>> wrote:
> > >>>
> >  Yeah, I guess that's doable as well and requires less management
> > > effort
> >  than my suggestion. We could use events [1] to store payload
> data
> > > (e.g.
> >  IP,
> >  version, etc.)
> > >>>
> > >>>
> > >>> Yes, we could use events or some other similar API provided by
> GA.
> > >>>
> > >>>
> >  What the download page CGI developed in? PHP?
> > 
> > >>>
> > >>> To be honest, no clue. I guess someone in the community can
> figure
> > >> it
> > >> out:
> > >>> https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
> > >>>
> > >>>
> >  However, I'm not sure whether storing this data in a 3rd party
> > > (Google)
> > >> is
> >  compliant with the ASF policy. I guess it's no biggie, but if
> > >> there's
> >  doubt
> >  in the PMC, it's better to ask legal@.
> > >>>
> > >>>
> > >>> I am not sure there is anything to ask about. The whole Ignite
> > >> website
> 

Re: [DISCUSS] Ignite Update Checker

[Dmitriy Setrakyan]

Denis, I can see the download.cgi script in SVN. Am I missing something?

On Mon, Oct 2, 2017 at 5:31 PM, Denis Magda  wrote:

> Dmitriy,
>
> That’s the rule.  See replies in the ticket [1]
>
> *Background: the TLP server is already pretty darned busy just serving
> *static* sites. Dynamic operation for near-200 PMCs would bury the machine.
> Our policy of "static-only websites" has been in place since the Foundation
> started*
>
> Download scripts seem to be the only exception and we as PMC don’t even
> have access to them.
>
> If you want to keep pushing this direction let’s craft a message to Greg
> and Daniel directly. I don’t know what else to ask for here rather than a
> virtual machine that’s conceivably to much for a single script like that.
>
> [1] https://issues.apache.org/jira/browse/INFRA-15182 <
> https://issues.apache.org/jira/browse/INFRA-15182>
>
> —
> Denis
>
> > On Oct 2, 2017, at 2:48 AM, Dmitriy Setrakyan 
> wrote:
> >
> > On Mon, Oct 2, 2017 at 12:46 PM, Vladimir Ozerov 
> > wrote:
> >
> >> I am not sure it is good idea to send requests to 3rd-party addresses
> from
> >> Ignite node. Let's do not make the same mistakes again.
> >>
> >
> > Agree with Vladimir.
> >
> > We obviously have CGI support on the website. Can someone explain why CGI
> > is not possible to use?
> >
> >
> >>
> >> On Mon, Oct 2, 2017 at 12:42 PM, Andrey Novikov 
> >> wrote:
> >>
> >>> We may directly send request to GA from Ignite node:
> >>> https://developers.google.com/analytics/devguides/
> >> collection/protocol/v1/
> >>>  >> collection/protocol/v1/
> 
> >>> Latest version can be received from maven central:
> >>> https://repo1.maven.org/maven2/org/apache/ignite/
> >>> ignite-core/maven-metadata.xml  >>> maven2/org/apache/ignite/ignite-core/maven-metadata.xml>
> >>>
> >>>
>  2 окт. 2017 г., в 12:51, Dmitriy Setrakyan 
> >>> написал(а):
> 
>  Denis,
> 
>  I am not sure I understand. We already do have CGI enabled for
>  download.cgi. Is there something else we need?
> 
>  D.
> 
>  On Mon, Oct 2, 2017 at 8:35 AM, Denis Magda 
> >> wrote:
> 
> > There is an obstacle. There is no way to execute the script using PHP
> >> or
> > similar sever side language and trigger GA as discussed earlier:
> > https://issues.apache.org/jira/browse/INFRA-15182
> >
> > How else can we tackle this?
> >
> > Denis
> >
> > On Thursday, September 7, 2017, Dmitriy Setrakyan <
> >>> dsetrak...@apache.org>
> > wrote:
> >
> >> I think it is safe to assume at this point that everyone is in
> >> general
> >> agreement, since there are no active objections.
> >>
> >> I have filed a ticket for the 2.3 release. Let's try to make it
> >> happen:
> >> https://issues.apache.org/jira/browse/IGNITE-6305
> >>
> >> D.
> >>
> >> On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
> > dsetrak...@apache.org
> >> >
> >> wrote:
> >>
> >>>
> >>>
> >>> On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani <
> >> raul@evosent.com
> >> >
> >>> wrote:
> >>>
>  Yeah, I guess that's doable as well and requires less management
> > effort
>  than my suggestion. We could use events [1] to store payload data
> > (e.g.
>  IP,
>  version, etc.)
> >>>
> >>>
> >>> Yes, we could use events or some other similar API provided by GA.
> >>>
> >>>
>  What the download page CGI developed in? PHP?
> 
> >>>
> >>> To be honest, no clue. I guess someone in the community can figure
> >> it
> >> out:
> >>> https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
> >>>
> >>>
>  However, I'm not sure whether storing this data in a 3rd party
> > (Google)
> >> is
>  compliant with the ASF policy. I guess it's no biggie, but if
> >> there's
>  doubt
>  in the PMC, it's better to ask legal@.
> >>>
> >>>
> >>> I am not sure there is anything to ask about. The whole Ignite
> >> website
> > is
> >>> GA enabled, and all we are doing is accessing a standard web page
> >> from
> >> the
> >>> Ignite web site. The information gathered from GA is available only
> >> to
> >> the
> >>> Ignite PMC. Frankly, I think legal@ will be very confused by this
> >>> question.
> >>>
> >>> Even ASF website itself uses GA: https://www.apache.org/
> >>> foundation/policies/privacy.html
> >>>
> >>>
>  I think Cos said it's OK; maybe Roman can pitch in.
> 
> >>>
> >>> Sure, would be nice to hear from Roman as well.
> >>>
> >>>
>  Cheers.
> 
>  [1]
>  

Participation in the development of Apache Ignite

[Илья Ножкин]

Hello!
I liked your project and ML module particulalry and I want to help you in
the development. I have already discussed this idea with chief developer of
ML module and he approved it. For that moment I've chosen a ticket and I
need only a permission to assign myself to Jira issues. I would be glad if
you give that rights to my account (ilya-nozhkin).

Sincerely,
Ilya Nozhkin

PRIMARY_SYNC+readFromBackup semantics

[Valentin Kulichenko]

Igniters,

I noticed that combination of PRIMARY_SYNC mode and readFromBackup=true
(both are default values BTW) introduces weird semantics when reading *on a
backup node*. Basically, if I do put and then get for the same key in the
same thread, I can get previous value. In my understanding, this happens
because even local backup is updated asynchronously in this case.

First of all, this is obviously confusing and would be considered as a bug
by most of the users (I just updated the key with some value, why would I
get another value when reading it?).

Second of all, it seems that we send a network message from primary node to
local backup, which doesn't make much sense to me and looks like
unnecessary performance overhead.

Is it possible to update local backup synchronously in this scenario?

-Val

[GitHub] ignite pull request #2790: Ignite web console docker should listen to all in...

[aNutForAJarOfTuna]

GitHub user aNutForAJarOfTuna opened a pull request:

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

Ignite web console docker should listen to all interface for nginx.

When running ignite web console standalone on remote machine, nginx setting 
set backend api as localhost which cause browser to lookup wrong hostname. 
Setting to 0.0.0.0 will ensure correct binding.

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

$ git pull https://github.com/aNutForAJarOfTuna/ignite fix_docker_standalone

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

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


commit f256f049b5c23ebab5671bcf99ac9c8ed6a85483
Author: pzang 
Date:   2017-10-02T20:36:28Z

Ignite web console docker should listen to all interface for nginx.




---

Re: Persistence per memory policy configuration

[Ivan Rakov]

Denis,

Yes, you're right. All cache groups without specific data region 
configured will be persistent.
And if you want to add another persistent data region, you should set 
*isPeristenceEnabled* flag in its *DataRegionConfiguration* explictly.


Best Regards,
Ivan Rakov

On 02.10.2017 21:01, Denis Magda wrote:

Missed the point with defaults. Makes sense to me now. So to wrap this up, if I 
want to enable the persistence globally and don’t have any regions configured 
explicitly I need to take the default region and switch the persistence on for 
it. Is my understanding correct?

—
Denis


On Oct 2, 2017, at 10:57 AM, Ivan Rakov  wrote:

Denis, why do you need to access an instance of the default region bean? If you 
want to set any parameter, just instantiate new bean with this parameter set 
(like in XML snipped below). Other parameters will be automatically initialized 
with their default values.

Best Regards,
Ivan Rakov

On 02.10.2017 19:28, Denis Magda wrote:

  
  
  
  
  
  
  
  
  
  

In other data regions persistence will be disabled by default.

Ivan, how to get an instance to the default region bean and change a parameter? 
Obviously, if the goal is to enable the persistence I don’t want to create the 
default region bean from scratch.

—
Denis


On Oct 2, 2017, at 9:11 AM, Ivan Rakov  wrote:

Agree with Alexey.

Properties like *defaultDataRegionSize*, *isDefaultPersistenceEnabled* can 
confuse users who don't know that there's such thing as default data region. 
They can decide they are inherited by all data regions where size and 
persistence flag are not explicitly set.

Let's get rid of these properties and add *defaultRegionConfiguration* property 
with explicit configuration of default data region.

Regarding XML configuration, changing size or persistence flag of default data 
region will be just two lines longer (for bean description):


  
  
  
  
  
  
  
  
  
  

In other data regions persistence will be disabled by default.
I've updated draft in https://issues.apache.org/jira/browse/IGNITE-6030 with 
these changes.

Best Regards,
Ivan Rakov

On 02.10.2017 18:35, Denis Magda wrote:

To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m not an expert 
in Spring so how do I get defaultRegionConfiguration bean first to change any 
parameter?

—
Denis


On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk  wrote:

Agree with Vladimir. If we are to implement this, we would either need to
have a Boolean (non-primitive) for persistenceEnabled on
DataRegionConfiguration, or introduce an enum for this field which is also
an overkill. On the other hand, one can assume that the defaults we are
talking about are actually inherited. To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Thoughts?

2017-10-02 15:19 GMT+03:00 Ivan Rakov :


Vladimir,

I like your approach because it's easier to implement.

However, user may be confused by setting *isDefaultPersistenceEnabled*
flag and seeing that persistence is not enabled by default in custom memory
region. I'll add clarifying Javadoc at this place.

Best Regards,
Ivan Rakov


On 02.10.2017 11:28, Vladimir Ozerov wrote:


Ivan,

I do not think this is correct approach, because it will be hard to
explain, and you will have to use "Boolean" instead of "boolean" for
DataRegionConfiguration. I do not think we need default "persistence
enabled" for all regions. Instead, we should have "persistence enabled"
flag for default region only. It should not be propagated to custom
regions.

On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
wrote:

Guys, I think I got the point now.

Let's check the final design:

*DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
property (default = false), which will be used for enabling persistence
in
default data region.
*DataRegionConfiguration* will have *isPersistenceEnabled* property,
which
will be used for enabling persistence in corresponding data region. If
value is not set, value of *DataStorageConfiguration::isD
efaultPersistenceEnabled*
will be used by default.

Best Regards,
Ivan Rakov



On 02.10.2017 7:49, Dmitriy Setrakyan wrote:

On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:

On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:


1) You're right. I forgot to include the main flag in

DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be

enabled globally if 

Re: Persistence per memory policy configuration

[Denis Magda]

Missed the point with defaults. Makes sense to me now. So to wrap this up, if I 
want to enable the persistence globally and don’t have any regions configured 
explicitly I need to take the default region and switch the persistence on for 
it. Is my understanding correct?

—
Denis

> On Oct 2, 2017, at 10:57 AM, Ivan Rakov  wrote:
> 
> Denis, why do you need to access an instance of the default region bean? If 
> you want to set any parameter, just instantiate new bean with this parameter 
> set (like in XML snipped below). Other parameters will be automatically 
> initialized with their default values.
> 
> Best Regards,
> Ivan Rakov
> 
> On 02.10.2017 19:28, Denis Magda wrote:
  
  >>> class="org.apache.ignite.configuration.DataStorageConfiguration">
  
  
  >>> class="org.apache.ignite.configuration.DataRegionConfiguration">
  
  
  
  
  
>>> In other data regions persistence will be disabled by default.
>> Ivan, how to get an instance to the default region bean and change a 
>> parameter? Obviously, if the goal is to enable the persistence I don’t want 
>> to create the default region bean from scratch.
>> 
>> —
>> Denis
>> 
>>> On Oct 2, 2017, at 9:11 AM, Ivan Rakov  wrote:
>>> 
>>> Agree with Alexey.
>>> 
>>> Properties like *defaultDataRegionSize*, *isDefaultPersistenceEnabled* can 
>>> confuse users who don't know that there's such thing as default data 
>>> region. They can decide they are inherited by all data regions where size 
>>> and persistence flag are not explicitly set.
>>> 
>>> Let's get rid of these properties and add *defaultRegionConfiguration* 
>>> property with explicit configuration of default data region.
>>> 
>>> Regarding XML configuration, changing size or persistence flag of default 
>>> data region will be just two lines longer (for bean description):
>>> 
  
  >>> class="org.apache.ignite.configuration.DataStorageConfiguration">
  
  
  >>> class="org.apache.ignite.configuration.DataRegionConfiguration">
  
  
  
  
  
>>> In other data regions persistence will be disabled by default.
>>> I've updated draft in https://issues.apache.org/jira/browse/IGNITE-6030 
>>> with these changes.
>>> 
>>> Best Regards,
>>> Ivan Rakov
>>> 
>>> On 02.10.2017 18:35, Denis Magda wrote:
> To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.
 Won’t it complicate the configuration from a Spring XML file? I’m not an 
 expert in Spring so how do I get defaultRegionConfiguration bean first to 
 change any parameter?
 
 —
 Denis
 
> On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk  
> wrote:
> 
> Agree with Vladimir. If we are to implement this, we would either need to
> have a Boolean (non-primitive) for persistenceEnabled on
> DataRegionConfiguration, or introduce an enum for this field which is also
> an overkill. On the other hand, one can assume that the defaults we are
> talking about are actually inherited. To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.
> 
> Thoughts?
> 
> 2017-10-02 15:19 GMT+03:00 Ivan Rakov :
> 
>> Vladimir,
>> 
>> I like your approach because it's easier to implement.
>> 
>> However, user may be confused by setting *isDefaultPersistenceEnabled*
>> flag and seeing that persistence is not enabled by default in custom 
>> memory
>> region. I'll add clarifying Javadoc at this place.
>> 
>> Best Regards,
>> Ivan Rakov
>> 
>> 
>> On 02.10.2017 11:28, Vladimir Ozerov wrote:
>> 
>>> Ivan,
>>> 
>>> I do not think this is correct approach, because it will be hard to
>>> explain, and you will have to use "Boolean" instead of "boolean" for
>>> DataRegionConfiguration. I do not think we need default "persistence
>>> enabled" for all regions. Instead, we should have "persistence enabled"
>>> flag for default region only. It should not be propagated to custom
>>> regions.
>>> 
>>> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
>>> wrote:
>>> 
>>> Guys, I think I got the point now.
 Let's check the final design:
 
 *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
 property (default = false), which will be used for enabling persistence
 in
 default data region.
 *DataRegionConfiguration* will have 

Re: Persistence per memory policy configuration

[Ivan Rakov]

Denis, why do you need to access an instance of the default region bean? 
If you want to set any parameter, just instantiate new bean with this 
parameter set (like in XML snipped below). Other parameters will be 
automatically initialized with their default values.


Best Regards,
Ivan Rakov

On 02.10.2017 19:28, Denis Magda wrote:

  
  
  
  
  
  
  
  
  
  

In other data regions persistence will be disabled by default.

Ivan, how to get an instance to the default region bean and change a parameter? 
Obviously, if the goal is to enable the persistence I don’t want to create the 
default region bean from scratch.

—
Denis


On Oct 2, 2017, at 9:11 AM, Ivan Rakov  wrote:

Agree with Alexey.

Properties like *defaultDataRegionSize*, *isDefaultPersistenceEnabled* can 
confuse users who don't know that there's such thing as default data region. 
They can decide they are inherited by all data regions where size and 
persistence flag are not explicitly set.

Let's get rid of these properties and add *defaultRegionConfiguration* property 
with explicit configuration of default data region.

Regarding XML configuration, changing size or persistence flag of default data 
region will be just two lines longer (for bean description):


  
  
  
  
  
  
  
  
  
  

In other data regions persistence will be disabled by default.
I've updated draft in https://issues.apache.org/jira/browse/IGNITE-6030 with 
these changes.

Best Regards,
Ivan Rakov

On 02.10.2017 18:35, Denis Magda wrote:

To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m not an expert 
in Spring so how do I get defaultRegionConfiguration bean first to change any 
parameter?

—
Denis


On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk  wrote:

Agree with Vladimir. If we are to implement this, we would either need to
have a Boolean (non-primitive) for persistenceEnabled on
DataRegionConfiguration, or introduce an enum for this field which is also
an overkill. On the other hand, one can assume that the defaults we are
talking about are actually inherited. To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Thoughts?

2017-10-02 15:19 GMT+03:00 Ivan Rakov :


Vladimir,

I like your approach because it's easier to implement.

However, user may be confused by setting *isDefaultPersistenceEnabled*
flag and seeing that persistence is not enabled by default in custom memory
region. I'll add clarifying Javadoc at this place.

Best Regards,
Ivan Rakov


On 02.10.2017 11:28, Vladimir Ozerov wrote:


Ivan,

I do not think this is correct approach, because it will be hard to
explain, and you will have to use "Boolean" instead of "boolean" for
DataRegionConfiguration. I do not think we need default "persistence
enabled" for all regions. Instead, we should have "persistence enabled"
flag for default region only. It should not be propagated to custom
regions.

On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
wrote:

Guys, I think I got the point now.

Let's check the final design:

*DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
property (default = false), which will be used for enabling persistence
in
default data region.
*DataRegionConfiguration* will have *isPersistenceEnabled* property,
which
will be used for enabling persistence in corresponding data region. If
value is not set, value of *DataStorageConfiguration::isD
efaultPersistenceEnabled*
will be used by default.

Best Regards,
Ivan Rakov



On 02.10.2017 7:49, Dmitriy Setrakyan wrote:

On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:

On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:


1) You're right. I forgot to include the main flag in

DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be

enabled globally if at least one memory region has this flag set.

I’m confused. Why the persistence should be enabled *globally* if the
purpose is to have it set for a specific region? If it’s enabled for
region
A only, I don’t want to have it activated for region B.

Yes, you are right. By default the persistence will be disabled
globally.


But we should also give users a way to switch the default behavior from
in-memory only (no-persistence) to persistence.

Re: Persistence per memory policy configuration

[Dmitriy Setrakyan]

On Mon, Oct 2, 2017 at 7:28 PM, Denis Magda  wrote:

>
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >>  
> >
> > In other data regions persistence will be disabled by default.
>
> Ivan, how to get an instance to the default region bean and change a
> parameter? Obviously, if the goal is to enable the persistence I don’t want
> to create the default region bean from scratch.
>

Denis, I think this is the only way. If we don't create the
defaultRegionConfiguration, then we have to make sure that all the
properties are inherited from DataStorageConfiguration. From the feedback I
have seen so far, folks think that the inheritance can get really confusing
here.

[GitHub] ignite pull request #2789: ignite-5714 refactoring threadId removed

[voipp]

GitHub user voipp opened a pull request:

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

ignite-5714 refactoring threadId removed



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

$ git pull https://github.com/voipp/ignite ignite-5714-threadId-removed1

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

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


commit 967eb3a1d503c65596b420e466cf798c2b6cdf41
Author: voipp 
Date:   2017-09-27T13:01:58Z

ignite-5714 refactoring threadId removed




---

Re: Persistence per memory policy configuration

[Denis Magda]

>>  
>>  > class="org.apache.ignite.configuration.DataStorageConfiguration">
>>  
>>  
>>  > class="org.apache.ignite.configuration.DataRegionConfiguration">
>>  
>>  
>>  
>>  
>>  
> 
> In other data regions persistence will be disabled by default.

Ivan, how to get an instance to the default region bean and change a parameter? 
Obviously, if the goal is to enable the persistence I don’t want to create the 
default region bean from scratch.

—
Denis

> On Oct 2, 2017, at 9:11 AM, Ivan Rakov  wrote:
> 
> Agree with Alexey.
> 
> Properties like *defaultDataRegionSize*, *isDefaultPersistenceEnabled* can 
> confuse users who don't know that there's such thing as default data region. 
> They can decide they are inherited by all data regions where size and 
> persistence flag are not explicitly set.
> 
> Let's get rid of these properties and add *defaultRegionConfiguration* 
> property with explicit configuration of default data region.
> 
> Regarding XML configuration, changing size or persistence flag of default 
> data region will be just two lines longer (for bean description):
> 
>>  
>>  > class="org.apache.ignite.configuration.DataStorageConfiguration">
>>  
>>  
>>  > class="org.apache.ignite.configuration.DataRegionConfiguration">
>>  
>>  
>>  
>>  
>>  
> 
> In other data regions persistence will be disabled by default.
> I've updated draft in https://issues.apache.org/jira/browse/IGNITE-6030 with 
> these changes.
> 
> Best Regards,
> Ivan Rakov
> 
> On 02.10.2017 18:35, Denis Magda wrote:
>>> To resolve this, I suggest to
>>> introduce just another field defaultRegionConfiguration and get rid of
>>> other defaults in DataStorageConfiguration.
>> Won’t it complicate the configuration from a Spring XML file? I’m not an 
>> expert in Spring so how do I get defaultRegionConfiguration bean first to 
>> change any parameter?
>> 
>> —
>> Denis
>> 
>>> On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk  
>>> wrote:
>>> 
>>> Agree with Vladimir. If we are to implement this, we would either need to
>>> have a Boolean (non-primitive) for persistenceEnabled on
>>> DataRegionConfiguration, or introduce an enum for this field which is also
>>> an overkill. On the other hand, one can assume that the defaults we are
>>> talking about are actually inherited. To resolve this, I suggest to
>>> introduce just another field defaultRegionConfiguration and get rid of
>>> other defaults in DataStorageConfiguration.
>>> 
>>> Thoughts?
>>> 
>>> 2017-10-02 15:19 GMT+03:00 Ivan Rakov :
>>> 
 Vladimir,
 
 I like your approach because it's easier to implement.
 
 However, user may be confused by setting *isDefaultPersistenceEnabled*
 flag and seeing that persistence is not enabled by default in custom memory
 region. I'll add clarifying Javadoc at this place.
 
 Best Regards,
 Ivan Rakov
 
 
 On 02.10.2017 11:28, Vladimir Ozerov wrote:
 
> Ivan,
> 
> I do not think this is correct approach, because it will be hard to
> explain, and you will have to use "Boolean" instead of "boolean" for
> DataRegionConfiguration. I do not think we need default "persistence
> enabled" for all regions. Instead, we should have "persistence enabled"
> flag for default region only. It should not be propagated to custom
> regions.
> 
> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
> wrote:
> 
> Guys, I think I got the point now.
>> Let's check the final design:
>> 
>> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
>> property (default = false), which will be used for enabling persistence
>> in
>> default data region.
>> *DataRegionConfiguration* will have *isPersistenceEnabled* property,
>> which
>> will be used for enabling persistence in corresponding data region. If
>> value is not set, value of *DataStorageConfiguration::isD
>> efaultPersistenceEnabled*
>> will be used by default.
>> 
>> Best Regards,
>> Ivan Rakov
>> 
>> 
>> 
>> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>> 
>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:
>>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:
>>> 
 1) You're right. I forgot to include the main flag in
> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
 enabled globally if at least one memory region has this flag set.
 
 I’m confused. Why the persistence should be enabled *globally* if the
 purpose is to have it set for a specific region? If it’s enabled for
 

[jira] [Created] (IGNITE-6543) Web agent: improve error messages in case of connection to cluster failed

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-6543:


 Summary: Web agent: improve error messages in case of connection 
to cluster failed
 Key: IGNITE-6543
 URL: https://issues.apache.org/jira/browse/IGNITE-6543
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Affects Versions: 2.1
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.4


Right now it is non informative text like this: "[2017-10-02 17:47:40,357][WARN 
][pool-1-thread-1][ClusterListener] Failed connect to cluster."

We should print more information.



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

Re: Persistence per memory policy configuration

[Ivan Rakov]

Agree with Alexey.

Properties like *defaultDataRegionSize*, *isDefaultPersistenceEnabled* 
can confuse users who don't know that there's such thing as default data 
region. They can decide they are inherited by all data regions where 
size and persistence flag are not explicitly set.


Let's get rid of these properties and add *defaultRegionConfiguration* 
property with explicit configuration of default data region.


Regarding XML configuration, changing size or persistence flag of 
default data region will be just two lines longer (for bean description):



 
 class="org.apache.ignite.configuration.DataStorageConfiguration">
 

 
 class="org.apache.ignite.configuration.DataRegionConfiguration">
 

 
 
 
 


In other data regions persistence will be disabled by default.
I've updated draft in https://issues.apache.org/jira/browse/IGNITE-6030 
with these changes.


Best Regards,
Ivan Rakov

On 02.10.2017 18:35, Denis Magda wrote:

To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m not an expert 
in Spring so how do I get defaultRegionConfiguration bean first to change any 
parameter?

—
Denis


On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk  wrote:

Agree with Vladimir. If we are to implement this, we would either need to
have a Boolean (non-primitive) for persistenceEnabled on
DataRegionConfiguration, or introduce an enum for this field which is also
an overkill. On the other hand, one can assume that the defaults we are
talking about are actually inherited. To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Thoughts?

2017-10-02 15:19 GMT+03:00 Ivan Rakov :


Vladimir,

I like your approach because it's easier to implement.

However, user may be confused by setting *isDefaultPersistenceEnabled*
flag and seeing that persistence is not enabled by default in custom memory
region. I'll add clarifying Javadoc at this place.

Best Regards,
Ivan Rakov


On 02.10.2017 11:28, Vladimir Ozerov wrote:


Ivan,

I do not think this is correct approach, because it will be hard to
explain, and you will have to use "Boolean" instead of "boolean" for
DataRegionConfiguration. I do not think we need default "persistence
enabled" for all regions. Instead, we should have "persistence enabled"
flag for default region only. It should not be propagated to custom
regions.

On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
wrote:

Guys, I think I got the point now.

Let's check the final design:

*DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
property (default = false), which will be used for enabling persistence
in
default data region.
*DataRegionConfiguration* will have *isPersistenceEnabled* property,
which
will be used for enabling persistence in corresponding data region. If
value is not set, value of *DataStorageConfiguration::isD
efaultPersistenceEnabled*
will be used by default.

Best Regards,
Ivan Rakov



On 02.10.2017 7:49, Dmitriy Setrakyan wrote:

On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:

On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:


1) You're right. I forgot to include the main flag in

DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be

enabled globally if at least one memory region has this flag set.

I’m confused. Why the persistence should be enabled *globally* if the
purpose is to have it set for a specific region? If it’s enabled for
region
A only, I don’t want to have it activated for region B.

Yes, you are right. By default the persistence will be disabled
globally.


But we should also give users a way to switch the default behavior from
in-memory only (no-persistence) to persistence.

Re: Persistence per memory policy configuration

[Denis Magda]

> To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.

Won’t it complicate the configuration from a Spring XML file? I’m not an expert 
in Spring so how do I get defaultRegionConfiguration bean first to change any 
parameter?

—
Denis

> On Oct 2, 2017, at 8:30 AM, Alexey Goncharuk  
> wrote:
> 
> Agree with Vladimir. If we are to implement this, we would either need to
> have a Boolean (non-primitive) for persistenceEnabled on
> DataRegionConfiguration, or introduce an enum for this field which is also
> an overkill. On the other hand, one can assume that the defaults we are
> talking about are actually inherited. To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.
> 
> Thoughts?
> 
> 2017-10-02 15:19 GMT+03:00 Ivan Rakov :
> 
>> Vladimir,
>> 
>> I like your approach because it's easier to implement.
>> 
>> However, user may be confused by setting *isDefaultPersistenceEnabled*
>> flag and seeing that persistence is not enabled by default in custom memory
>> region. I'll add clarifying Javadoc at this place.
>> 
>> Best Regards,
>> Ivan Rakov
>> 
>> 
>> On 02.10.2017 11:28, Vladimir Ozerov wrote:
>> 
>>> Ivan,
>>> 
>>> I do not think this is correct approach, because it will be hard to
>>> explain, and you will have to use "Boolean" instead of "boolean" for
>>> DataRegionConfiguration. I do not think we need default "persistence
>>> enabled" for all regions. Instead, we should have "persistence enabled"
>>> flag for default region only. It should not be propagated to custom
>>> regions.
>>> 
>>> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
>>> wrote:
>>> 
>>> Guys, I think I got the point now.
 
 Let's check the final design:
 
 *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
 property (default = false), which will be used for enabling persistence
 in
 default data region.
 *DataRegionConfiguration* will have *isPersistenceEnabled* property,
 which
 will be used for enabling persistence in corresponding data region. If
 value is not set, value of *DataStorageConfiguration::isD
 efaultPersistenceEnabled*
 will be used by default.
 
 Best Regards,
 Ivan Rakov
 
 
 
 On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
 
 On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:
> 
> On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:
> 
>> 1) You're right. I forgot to include the main flag in
>>> 
>>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>> enabled globally if at least one memory region has this flag set.
>> 
>> I’m confused. Why the persistence should be enabled *globally* if the
>> purpose is to have it set for a specific region? If it’s enabled for
>> region
>> A only, I don’t want to have it activated for region B.
>> 
>> Yes, you are right. By default the persistence will be disabled
>> globally.
>> 
> But we should also give users a way to switch the default behavior from
> in-memory only (no-persistence) to persistence.
> 
> 
> 
>> 

Re: Persistence per memory policy configuration

[Alexey Kuznetsov]

Guys,

Please, do not add  Boolean (non-primitive) to configurations.
It is really the pain to handle them in tools like WebConsole.
Enum would be better.

I'm not insisting, but just a minor note.


On Mon, Oct 2, 2017 at 10:30 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Agree with Vladimir. If we are to implement this, we would either need to
> have a Boolean (non-primitive) for persistenceEnabled on
> DataRegionConfiguration, or introduce an enum for this field which is also
> an overkill. On the other hand, one can assume that the defaults we are
> talking about are actually inherited. To resolve this, I suggest to
> introduce just another field defaultRegionConfiguration and get rid of
> other defaults in DataStorageConfiguration.
>
> Thoughts?
>
> 2017-10-02 15:19 GMT+03:00 Ivan Rakov :
>
> > Vladimir,
> >
> > I like your approach because it's easier to implement.
> >
> > However, user may be confused by setting *isDefaultPersistenceEnabled*
> > flag and seeing that persistence is not enabled by default in custom
> memory
> > region. I'll add clarifying Javadoc at this place.
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 02.10.2017 11:28, Vladimir Ozerov wrote:
> >
> >> Ivan,
> >>
> >> I do not think this is correct approach, because it will be hard to
> >> explain, and you will have to use "Boolean" instead of "boolean" for
> >> DataRegionConfiguration. I do not think we need default "persistence
> >> enabled" for all regions. Instead, we should have "persistence enabled"
> >> flag for default region only. It should not be propagated to custom
> >> regions.
> >>
> >> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
> >> wrote:
> >>
> >> Guys, I think I got the point now.
> >>>
> >>> Let's check the final design:
> >>>
> >>> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
> >>> property (default = false), which will be used for enabling persistence
> >>> in
> >>> default data region.
> >>> *DataRegionConfiguration* will have *isPersistenceEnabled* property,
> >>> which
> >>> will be used for enabling persistence in corresponding data region. If
> >>> value is not set, value of *DataStorageConfiguration::isD
> >>> efaultPersistenceEnabled*
> >>> will be used by default.
> >>>
> >>> Best Regards,
> >>> Ivan Rakov
> >>>
> >>>
> >>>
> >>> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
> >>>
> >>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:
> 
>  On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:
> 
> > 1) You're right. I forgot to include the main flag in
> >>
> >> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will
> be
> > enabled globally if at least one memory region has this flag set.
> >
> > I’m confused. Why the persistence should be enabled *globally* if the
> > purpose is to have it set for a specific region? If it’s enabled for
> > region
> > A only, I don’t want to have it activated for region B.
> >
> > Yes, you are right. By default the persistence will be disabled
> > globally.
> >
>  But we should also give users a way to switch the default behavior
> from
>  in-memory only (no-persistence) to persistence.
> 
> 
> 
> >
>



-- 
Alexey Kuznetsov

Re: Persistence per memory policy configuration

[Alexey Goncharuk]

Agree with Vladimir. If we are to implement this, we would either need to
have a Boolean (non-primitive) for persistenceEnabled on
DataRegionConfiguration, or introduce an enum for this field which is also
an overkill. On the other hand, one can assume that the defaults we are
talking about are actually inherited. To resolve this, I suggest to
introduce just another field defaultRegionConfiguration and get rid of
other defaults in DataStorageConfiguration.

Thoughts?

2017-10-02 15:19 GMT+03:00 Ivan Rakov :

> Vladimir,
>
> I like your approach because it's easier to implement.
>
> However, user may be confused by setting *isDefaultPersistenceEnabled*
> flag and seeing that persistence is not enabled by default in custom memory
> region. I'll add clarifying Javadoc at this place.
>
> Best Regards,
> Ivan Rakov
>
>
> On 02.10.2017 11:28, Vladimir Ozerov wrote:
>
>> Ivan,
>>
>> I do not think this is correct approach, because it will be hard to
>> explain, and you will have to use "Boolean" instead of "boolean" for
>> DataRegionConfiguration. I do not think we need default "persistence
>> enabled" for all regions. Instead, we should have "persistence enabled"
>> flag for default region only. It should not be propagated to custom
>> regions.
>>
>> On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov 
>> wrote:
>>
>> Guys, I think I got the point now.
>>>
>>> Let's check the final design:
>>>
>>> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
>>> property (default = false), which will be used for enabling persistence
>>> in
>>> default data region.
>>> *DataRegionConfiguration* will have *isPersistenceEnabled* property,
>>> which
>>> will be used for enabling persistence in corresponding data region. If
>>> value is not set, value of *DataStorageConfiguration::isD
>>> efaultPersistenceEnabled*
>>> will be used by default.
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>>
>>>
>>> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>>>
>>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:

 On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:

> 1) You're right. I forgot to include the main flag in
>>
>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
> enabled globally if at least one memory region has this flag set.
>
> I’m confused. Why the persistence should be enabled *globally* if the
> purpose is to have it set for a specific region? If it’s enabled for
> region
> A only, I don’t want to have it activated for region B.
>
> Yes, you are right. By default the persistence will be disabled
> globally.
>
 But we should also give users a way to switch the default behavior from
 in-memory only (no-persistence) to persistence.



>

[GitHub] ignite pull request #2788: ignite-5714 xid instead thread id in postLockWrit...

[voipp]

GitHub user voipp opened a pull request:

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

ignite-5714 xid instead thread id in postLockWrite



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

$ git pull https://github.com/voipp/ignite ignite-5714-postLockWrite-edited

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

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


commit 71937d553ac815202f612c9c8bcb7b883c88a27d
Author: voipp 
Date:   2017-10-02T14:48:05Z

ignite-5714 xid instead thread id in postLockWrite




---

[GitHub] ignite pull request #2787: IGNITE-6542 Reliably close SocketChannel in TcpCo...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-6542 Reliably close SocketChannel in TcpCommunicationSpi.



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

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

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

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


commit 8a30823815e082eb2a44667f6b8e3fc455187976
Author: Ilya Kasnacheev 
Date:   2017-09-29T12:53:17Z

IGNITE-6071

commit b63be488f1b85d3cae4f0f9678c1945626c1fb60
Author: Ilya Kasnacheev 
Date:   2017-10-02T14:46:42Z

IGNITE-6542 Reliably close SocketChannel in TcpCommunicationSpi.




---

Re: [DISCUSS] Ignite Update Checker

[Denis Magda]

Dmitriy, 

That’s the rule.  See replies in the ticket [1]

*Background: the TLP server is already pretty darned busy just serving *static* 
sites. Dynamic operation for near-200 PMCs would bury the machine. Our policy 
of "static-only websites" has been in place since the Foundation started*

Download scripts seem to be the only exception and we as PMC don’t even have 
access to them.

If you want to keep pushing this direction let’s craft a message to Greg and 
Daniel directly. I don’t know what else to ask for here rather than a virtual 
machine that’s conceivably to much for a single script like that.

[1] https://issues.apache.org/jira/browse/INFRA-15182 


—
Denis

> On Oct 2, 2017, at 2:48 AM, Dmitriy Setrakyan  wrote:
> 
> On Mon, Oct 2, 2017 at 12:46 PM, Vladimir Ozerov 
> wrote:
> 
>> I am not sure it is good idea to send requests to 3rd-party addresses from
>> Ignite node. Let's do not make the same mistakes again.
>> 
> 
> Agree with Vladimir.
> 
> We obviously have CGI support on the website. Can someone explain why CGI
> is not possible to use?
> 
> 
>> 
>> On Mon, Oct 2, 2017 at 12:42 PM, Andrey Novikov 
>> wrote:
>> 
>>> We may directly send request to GA from Ignite node:
>>> https://developers.google.com/analytics/devguides/
>> collection/protocol/v1/
>>> > collection/protocol/v1/
 
>>> Latest version can be received from maven central:
>>> https://repo1.maven.org/maven2/org/apache/ignite/
>>> ignite-core/maven-metadata.xml >> maven2/org/apache/ignite/ignite-core/maven-metadata.xml>
>>> 
>>> 
 2 окт. 2017 г., в 12:51, Dmitriy Setrakyan 
>>> написал(а):
 
 Denis,
 
 I am not sure I understand. We already do have CGI enabled for
 download.cgi. Is there something else we need?
 
 D.
 
 On Mon, Oct 2, 2017 at 8:35 AM, Denis Magda 
>> wrote:
 
> There is an obstacle. There is no way to execute the script using PHP
>> or
> similar sever side language and trigger GA as discussed earlier:
> https://issues.apache.org/jira/browse/INFRA-15182
> 
> How else can we tackle this?
> 
> Denis
> 
> On Thursday, September 7, 2017, Dmitriy Setrakyan <
>>> dsetrak...@apache.org>
> wrote:
> 
>> I think it is safe to assume at this point that everyone is in
>> general
>> agreement, since there are no active objections.
>> 
>> I have filed a ticket for the 2.3 release. Let's try to make it
>> happen:
>> https://issues.apache.org/jira/browse/IGNITE-6305
>> 
>> D.
>> 
>> On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org
>> >
>> wrote:
>> 
>>> 
>>> 
>>> On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani <
>> raul@evosent.com
>> >
>>> wrote:
>>> 
 Yeah, I guess that's doable as well and requires less management
> effort
 than my suggestion. We could use events [1] to store payload data
> (e.g.
 IP,
 version, etc.)
>>> 
>>> 
>>> Yes, we could use events or some other similar API provided by GA.
>>> 
>>> 
 What the download page CGI developed in? PHP?
 
>>> 
>>> To be honest, no clue. I guess someone in the community can figure
>> it
>> out:
>>> https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
>>> 
>>> 
 However, I'm not sure whether storing this data in a 3rd party
> (Google)
>> is
 compliant with the ASF policy. I guess it's no biggie, but if
>> there's
 doubt
 in the PMC, it's better to ask legal@.
>>> 
>>> 
>>> I am not sure there is anything to ask about. The whole Ignite
>> website
> is
>>> GA enabled, and all we are doing is accessing a standard web page
>> from
>> the
>>> Ignite web site. The information gathered from GA is available only
>> to
>> the
>>> Ignite PMC. Frankly, I think legal@ will be very confused by this
>>> question.
>>> 
>>> Even ASF website itself uses GA: https://www.apache.org/
>>> foundation/policies/privacy.html
>>> 
>>> 
 I think Cos said it's OK; maybe Roman can pitch in.
 
>>> 
>>> Sure, would be nice to hear from Roman as well.
>>> 
>>> 
 Cheers.
 
 [1]
 https://developers.google.com/analytics/devguides/collection
 /analyticsjs/events
 
 On Sat, Aug 26, 2017 at 12:23 AM, Dmitriy Setrakyan <
 dsetrak...@apache.org >
 wrote:
 
> Raul,
> 
> Could point about Javascript, it will not work because it executes
> in
 the
> browser. This means we need a 

[jira] [Created] (IGNITE-6542) SocketChannel may not be closed in createTcpClient()

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-6542:
---

 Summary: SocketChannel may not be closed in createTcpClient()
 Key: IGNITE-6542
 URL: https://issues.apache.org/jira/browse/IGNITE-6542
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.2
Reporter: Ilya Kasnacheev
Assignee: Ilya Kasnacheev


There's no finally() on ch in TcpCommunicationSpi.createTcpClient()

So there's a long block of code where resource consistency is hanging on a 
hair. This can lead to file descriptor starvation as well.



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

[GitHub] ignite pull request #2786: IGNITE-6382 .NET: Set up NDepend analysis on Team...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-6382 .NET: Set up NDepend analysis on TeamCity



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

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

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

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


commit 5dcc07739a3c5ced03e74d46d875e293f9af0d8c
Author: Pavel Tupitsyn 
Date:   2017-10-02T13:55:52Z

IGNITE-6382 .NET: Set up NDepend analysis on TeamCity

commit 81bcfd31fb2d8ca2d5ec260908ad268d1cfd8735
Author: Pavel Tupitsyn 
Date:   2017-10-02T14:07:36Z

Exclude false warnings




---

[GitHub] ignite pull request #2785: IGNITE-6517 .NET: DataStreamer DefaultPerNodeBuff...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-6541) .NET: Refactor DataStreamer configuration

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-6541:
--

 Summary: .NET: Refactor DataStreamer configuration
 Key: IGNITE-6541
 URL: https://issues.apache.org/jira/browse/IGNITE-6541
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Pavel Tupitsyn


Current DataStreamer configuration works like this:

{code}
using (var streamer = ignite.GetDataStreamer("myCache"))
{
streamer.AllowOverwrite = true;
streamer.SkipStore = false;
// etc
}
{code}

All configuration {{IDataStreamer}} properties have "Setter must be called 
before any add/remove operation" comment on them.

This is quite strange and not consistent with other APIs. Change to this:

{code}
var cfg = new DataStreamerConfiguration
{
AllowOverwrite = true,
SkipStore = false,
// etc
};

using (var streamer = ignite.GetDataStreamer("myCache", cfg))
{
// stream data
}
{code}



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

[jira] [Created] (IGNITE-6540) Human readable WAL parser result has no human readable data

[Dmitry Sherstobitov (JIRA)]

Dmitry Sherstobitov created IGNITE-6540:
---

 Summary: Human readable WAL parser result has no human readable 
data
 Key: IGNITE-6540
 URL: https://issues.apache.org/jira/browse/IGNITE-6540
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Dmitry Sherstobitov
 Fix For: 2.3


Simple example with put 1 record in cache generation a lot of data in WAL

{code:java}
try (Ignite ignite = 
Ignition.start("examples/config/persistentstore/example-persistent-store.xml")) 
{
try (IgniteCache cache = 
ignite.getOrCreateCache(CACHE_NAME)) {
 cache.put(1, "NEW_VALUE_1");
}
}
{code}

See result of script in attachments



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

Context switching for pessimistic transactions

[ALEKSEY KUZNETSOV]

Hi, Igntrs!

I’m working on a ticket "Context switching for pessimistic transactions"
[1].

Goal of the ticket is to support transaction suspend()\resume() operations
for pessimistic transactions. Resume can be called in another thread.

Imagine, we started pessimistic transaction in thread T1 and then perform
put operation, which leads to sending GridDistributedLockRequest to another
node. Lock request contains thread id of the transaction. Then we call
suspend, resume in another thread and we also must send messages to other
nodes to change thread id.

It seems complicated task.It’s better to get rid of sending thread id to
the nodes.

We can use transaction xid on other nodes instead of thread id. Xid is sent
to nodes in GridDistributedLockRequest#nearXidVer

So I propose:

1) On remote nodes instead of thread id of near transaction
GridDistributedLockRequest#threadId use its xid
GridDistributedLockRequest#nearXidVer.

2) Remove usages of near transaction's thread id on remote nodes.

Thoughts?

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

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #2785: IGNITE-6517 .NET: DataStreamer DefaultPerNodeBuff...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-6517 .NET: DataStreamer DefaultPerNodeBufferSize, 
DefaultParallelOpsMultiplier, Timeout



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

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

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

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






---

[jira] [Created] (IGNITE-6539) Human readable WAL parser fails if empty log files exists in directory

[Dmitry Sherstobitov (JIRA)]

Dmitry Sherstobitov created IGNITE-6539:
---

 Summary: Human readable WAL parser fails if empty log files exists 
in directory
 Key: IGNITE-6539
 URL: https://issues.apache.org/jira/browse/IGNITE-6539
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Dmitry Sherstobitov
 Fix For: 2.3


While scanning WAL files script may detect empty files.
In this case script throws SegmentEofException "Reached logical end of the 
segment"



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

[jira] [Created] (IGNITE-6538) Ignite Activate/Deactivate Cluster suite: After tests validation improvements test became flaky on TC

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-6538:
--

 Summary: Ignite Activate/Deactivate Cluster suite: After tests 
validation improvements test became flaky on TC
 Key: IGNITE-6538
 URL: https://issues.apache.org/jira/browse/IGNITE-6538
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.1
Reporter: Dmitriy Pavlov
 Fix For: 2.4


https://ci.ignite.apache.org/project.html?projectId=Ignite20Tests=-238119157387028099=testDetails_Ignite20Tests=%3Cdefault%3E

recent changes from [IGNITE-6124] which probably showed this problem is 
following 
{noformat}
 fail("Activation should fail");
{noformat}
org.apache.ignite.internal.processors.cache.persistence.standbycluster.IgniteChangeGlobalStateTest#testActivateAfterFailGetLock



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

Re: Persistence per memory policy configuration

[Ivan Rakov]

Vladimir,

I like your approach because it's easier to implement.

However, user may be confused by setting *isDefaultPersistenceEnabled* 
flag and seeing that persistence is not enabled by default in custom 
memory region. I'll add clarifying Javadoc at this place.


Best Regards,
Ivan Rakov

On 02.10.2017 11:28, Vladimir Ozerov wrote:

Ivan,

I do not think this is correct approach, because it will be hard to
explain, and you will have to use "Boolean" instead of "boolean" for
DataRegionConfiguration. I do not think we need default "persistence
enabled" for all regions. Instead, we should have "persistence enabled"
flag for default region only. It should not be propagated to custom regions.

On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov  wrote:


Guys, I think I got the point now.

Let's check the final design:

*DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
property (default = false), which will be used for enabling persistence in
default data region.
*DataRegionConfiguration* will have *isPersistenceEnabled* property, which
will be used for enabling persistence in corresponding data region. If
value is not set, value of 
*DataStorageConfiguration::isDefaultPersistenceEnabled*
will be used by default.

Best Regards,
Ivan Rakov



On 02.10.2017 7:49, Dmitriy Setrakyan wrote:


On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:

On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:

1) You're right. I forgot to include the main flag in


DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
enabled globally if at least one memory region has this flag set.

I’m confused. Why the persistence should be enabled *globally* if the
purpose is to have it set for a specific region? If it’s enabled for
region
A only, I don’t want to have it activated for region B.

Yes, you are right. By default the persistence will be disabled globally.

But we should also give users a way to switch the default behavior from
in-memory only (no-persistence) to persistence.

[GitHub] ignite pull request #2781: IGNITE-6520: Using actual AffinityReadyFuture res...

[andrey-kuznetsov]

Github user andrey-kuznetsov closed the pull request at:

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


---

[GitHub] ignite pull request #2784: IGNITE-6054

[alexpaschenko]

GitHub user alexpaschenko opened a pull request:

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

IGNITE-6054



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

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

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

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


commit 5e144a6a9147798e147768062c1dd5a0adcce2a4
Author: Alexander Paschenko 
Date:   2017-09-28T19:22:22Z

IGNITE-6054 Flat PK

commit dca4ab001908b0a08486425db74d86c2799071bd
Author: Alexander Paschenko 
Date:   2017-09-29T18:32:37Z

IGNITE-6054 Contd.

commit 6a286e14cb260c17e972c023f6c332914ce45525
Author: Alexander Paschenko 
Date:   2017-10-02T12:08:41Z

IGNITE-6054 Finished.




---

[GitHub] ignite pull request #2783: IGNITE-6469: SQL: NOT NULL validation for values ...

[skalashnikov]

GitHub user skalashnikov opened a pull request:

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

IGNITE-6469: SQL: NOT NULL validation for values provided by Cache 
Interceptor



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

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

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

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


commit c9b2f4a9f3a4886f295d86bed31b504de6a9bcfd
Author: skalashnikov 
Date:   2017-10-01T20:26:30Z

IGNITE-6469: SQL: NOT NULL validation for values provided by Cache 
Interceptor

commit 5286e5d739828625083c0cd94c7eafc2e9a30966
Author: skalashnikov 
Date:   2017-10-02T09:01:46Z

Merge branch 'master' of https://github.com/apache/ignite into ignite-6469




---

Re: [DISCUSS] Ignite Update Checker

[Dmitriy Setrakyan]

On Mon, Oct 2, 2017 at 12:46 PM, Vladimir Ozerov 
wrote:

> I am not sure it is good idea to send requests to 3rd-party addresses from
> Ignite node. Let's do not make the same mistakes again.
>

Agree with Vladimir.

We obviously have CGI support on the website. Can someone explain why CGI
is not possible to use?


>
> On Mon, Oct 2, 2017 at 12:42 PM, Andrey Novikov 
> wrote:
>
> > We may directly send request to GA from Ignite node:
> > https://developers.google.com/analytics/devguides/
> collection/protocol/v1/
> >  collection/protocol/v1/
> > >
> > Latest version can be received from maven central:
> > https://repo1.maven.org/maven2/org/apache/ignite/
> > ignite-core/maven-metadata.xml  > maven2/org/apache/ignite/ignite-core/maven-metadata.xml>
> >
> >
> > > 2 окт. 2017 г., в 12:51, Dmitriy Setrakyan 
> > написал(а):
> > >
> > > Denis,
> > >
> > > I am not sure I understand. We already do have CGI enabled for
> > > download.cgi. Is there something else we need?
> > >
> > > D.
> > >
> > > On Mon, Oct 2, 2017 at 8:35 AM, Denis Magda 
> wrote:
> > >
> > >> There is an obstacle. There is no way to execute the script using PHP
> or
> > >> similar sever side language and trigger GA as discussed earlier:
> > >> https://issues.apache.org/jira/browse/INFRA-15182
> > >>
> > >> How else can we tackle this?
> > >>
> > >> Denis
> > >>
> > >> On Thursday, September 7, 2017, Dmitriy Setrakyan <
> > dsetrak...@apache.org>
> > >> wrote:
> > >>
> > >>> I think it is safe to assume at this point that everyone is in
> general
> > >>> agreement, since there are no active objections.
> > >>>
> > >>> I have filed a ticket for the 2.3 release. Let's try to make it
> happen:
> > >>> https://issues.apache.org/jira/browse/IGNITE-6305
> > >>>
> > >>> D.
> > >>>
> > >>> On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
> > >> dsetrak...@apache.org
> > >>> >
> > >>> wrote:
> > >>>
> > 
> > 
> >  On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani <
> raul@evosent.com
> > >>> >
> >  wrote:
> > 
> > > Yeah, I guess that's doable as well and requires less management
> > >> effort
> > > than my suggestion. We could use events [1] to store payload data
> > >> (e.g.
> > > IP,
> > > version, etc.)
> > 
> > 
> >  Yes, we could use events or some other similar API provided by GA.
> > 
> > 
> > > What the download page CGI developed in? PHP?
> > >
> > 
> >  To be honest, no clue. I guess someone in the community can figure
> it
> > >>> out:
> >  https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
> > 
> > 
> > > However, I'm not sure whether storing this data in a 3rd party
> > >> (Google)
> > >>> is
> > > compliant with the ASF policy. I guess it's no biggie, but if
> there's
> > > doubt
> > > in the PMC, it's better to ask legal@.
> > 
> > 
> >  I am not sure there is anything to ask about. The whole Ignite
> website
> > >> is
> >  GA enabled, and all we are doing is accessing a standard web page
> from
> > >>> the
> >  Ignite web site. The information gathered from GA is available only
> to
> > >>> the
> >  Ignite PMC. Frankly, I think legal@ will be very confused by this
> >  question.
> > 
> >  Even ASF website itself uses GA: https://www.apache.org/
> >  foundation/policies/privacy.html
> > 
> > 
> > > I think Cos said it's OK; maybe Roman can pitch in.
> > >
> > 
> >  Sure, would be nice to hear from Roman as well.
> > 
> > 
> > > Cheers.
> > >
> > > [1]
> > > https://developers.google.com/analytics/devguides/collection
> > > /analyticsjs/events
> > >
> > > On Sat, Aug 26, 2017 at 12:23 AM, Dmitriy Setrakyan <
> > > dsetrak...@apache.org >
> > > wrote:
> > >
> > >> Raul,
> > >>
> > >> Could point about Javascript, it will not work because it executes
> > >> in
> > > the
> > >> browser. This means we need a server-side script, like CGI we are
> > >>> using
> > > on
> > >> our download page.
> > >>
> > >> How about this approach. We create something like
> ignite-version.cgi
> > > script
> > >> which will invoke a call to GA and then return the latest version.
> > >>
> > >> This should work, right?
> > >>
> > >> D.
> > >>
> > >> On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani <
> > >> raul@evosent.com
> > >>> >
> > >> wrote:
> > >>
> > >>> Hey Dmitriy and all
> > >>>
> > >>> Also, since we have GA enabled for the website, we can track how
> > >>> many
> > >> times
> >  this page was accessed, which will be equal to the number of
> > >>> starts.
> > >> This
> >  way, the counter 

Re: [DISCUSS] Ignite Update Checker

[Vladimir Ozerov]

I am not sure it is good idea to send requests to 3rd-party addresses from
Ignite node. Let's do not make the same mistakes again.

On Mon, Oct 2, 2017 at 12:42 PM, Andrey Novikov 
wrote:

> We may directly send request to GA from Ignite node:
> https://developers.google.com/analytics/devguides/collection/protocol/v1/
>  >
> Latest version can be received from maven central:
> https://repo1.maven.org/maven2/org/apache/ignite/
> ignite-core/maven-metadata.xml  maven2/org/apache/ignite/ignite-core/maven-metadata.xml>
>
>
> > 2 окт. 2017 г., в 12:51, Dmitriy Setrakyan 
> написал(а):
> >
> > Denis,
> >
> > I am not sure I understand. We already do have CGI enabled for
> > download.cgi. Is there something else we need?
> >
> > D.
> >
> > On Mon, Oct 2, 2017 at 8:35 AM, Denis Magda  wrote:
> >
> >> There is an obstacle. There is no way to execute the script using PHP or
> >> similar sever side language and trigger GA as discussed earlier:
> >> https://issues.apache.org/jira/browse/INFRA-15182
> >>
> >> How else can we tackle this?
> >>
> >> Denis
> >>
> >> On Thursday, September 7, 2017, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> >> wrote:
> >>
> >>> I think it is safe to assume at this point that everyone is in general
> >>> agreement, since there are no active objections.
> >>>
> >>> I have filed a ticket for the 2.3 release. Let's try to make it happen:
> >>> https://issues.apache.org/jira/browse/IGNITE-6305
> >>>
> >>> D.
> >>>
> >>> On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
> >> dsetrak...@apache.org
> >>> >
> >>> wrote:
> >>>
> 
> 
>  On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani  >>> >
>  wrote:
> 
> > Yeah, I guess that's doable as well and requires less management
> >> effort
> > than my suggestion. We could use events [1] to store payload data
> >> (e.g.
> > IP,
> > version, etc.)
> 
> 
>  Yes, we could use events or some other similar API provided by GA.
> 
> 
> > What the download page CGI developed in? PHP?
> >
> 
>  To be honest, no clue. I guess someone in the community can figure it
> >>> out:
>  https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
> 
> 
> > However, I'm not sure whether storing this data in a 3rd party
> >> (Google)
> >>> is
> > compliant with the ASF policy. I guess it's no biggie, but if there's
> > doubt
> > in the PMC, it's better to ask legal@.
> 
> 
>  I am not sure there is anything to ask about. The whole Ignite website
> >> is
>  GA enabled, and all we are doing is accessing a standard web page from
> >>> the
>  Ignite web site. The information gathered from GA is available only to
> >>> the
>  Ignite PMC. Frankly, I think legal@ will be very confused by this
>  question.
> 
>  Even ASF website itself uses GA: https://www.apache.org/
>  foundation/policies/privacy.html
> 
> 
> > I think Cos said it's OK; maybe Roman can pitch in.
> >
> 
>  Sure, would be nice to hear from Roman as well.
> 
> 
> > Cheers.
> >
> > [1]
> > https://developers.google.com/analytics/devguides/collection
> > /analyticsjs/events
> >
> > On Sat, Aug 26, 2017 at 12:23 AM, Dmitriy Setrakyan <
> > dsetrak...@apache.org >
> > wrote:
> >
> >> Raul,
> >>
> >> Could point about Javascript, it will not work because it executes
> >> in
> > the
> >> browser. This means we need a server-side script, like CGI we are
> >>> using
> > on
> >> our download page.
> >>
> >> How about this approach. We create something like ignite-version.cgi
> > script
> >> which will invoke a call to GA and then return the latest version.
> >>
> >> This should work, right?
> >>
> >> D.
> >>
> >> On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani <
> >> raul@evosent.com
> >>> >
> >> wrote:
> >>
> >>> Hey Dmitriy and all
> >>>
> >>> Also, since we have GA enabled for the website, we can track how
> >>> many
> >> times
>  this page was accessed, which will be equal to the number of
> >>> starts.
> >> This
>  way, the counter information is tracked and monitored by the
> >>> Ignite
> >> PMC.
> >>>
> >>>
> >>> Unfortunately this won't work because GA is loaded via Javascript
> >> on
> > the
> >>> browser, so Google will never receive the page hit.
> >>>
> >>> Given the constraints, the most viable solution is an HTTPS
> >> endpoint
> >>> running on ASF infra that Ignite invokes via a GET or POST
> >> request.
> > The
> >>> simplest thing is to write each request in a log file, along with
> >>> the
> 

Re: [DISCUSS] Ignite Update Checker

[Andrey Novikov]

We may directly send request to GA from Ignite node: 
https://developers.google.com/analytics/devguides/collection/protocol/v1/ 

Latest version can be received from maven central: 
https://repo1.maven.org/maven2/org/apache/ignite/ignite-core/maven-metadata.xml 



> 2 окт. 2017 г., в 12:51, Dmitriy Setrakyan  написал(а):
> 
> Denis,
> 
> I am not sure I understand. We already do have CGI enabled for
> download.cgi. Is there something else we need?
> 
> D.
> 
> On Mon, Oct 2, 2017 at 8:35 AM, Denis Magda  wrote:
> 
>> There is an obstacle. There is no way to execute the script using PHP or
>> similar sever side language and trigger GA as discussed earlier:
>> https://issues.apache.org/jira/browse/INFRA-15182
>> 
>> How else can we tackle this?
>> 
>> Denis
>> 
>> On Thursday, September 7, 2017, Dmitriy Setrakyan 
>> wrote:
>> 
>>> I think it is safe to assume at this point that everyone is in general
>>> agreement, since there are no active objections.
>>> 
>>> I have filed a ticket for the 2.3 release. Let's try to make it happen:
>>> https://issues.apache.org/jira/browse/IGNITE-6305
>>> 
>>> D.
>>> 
>>> On Sat, Aug 26, 2017 at 3:06 PM, Dmitriy Setrakyan <
>> dsetrak...@apache.org
>>> >
>>> wrote:
>>> 
 
 
 On Sat, Aug 26, 2017 at 3:22 AM, Raúl Kripalani >> >
 wrote:
 
> Yeah, I guess that's doable as well and requires less management
>> effort
> than my suggestion. We could use events [1] to store payload data
>> (e.g.
> IP,
> version, etc.)
 
 
 Yes, we could use events or some other similar API provided by GA.
 
 
> What the download page CGI developed in? PHP?
> 
 
 To be honest, no clue. I guess someone in the community can figure it
>>> out:
 https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
 
 
> However, I'm not sure whether storing this data in a 3rd party
>> (Google)
>>> is
> compliant with the ASF policy. I guess it's no biggie, but if there's
> doubt
> in the PMC, it's better to ask legal@.
 
 
 I am not sure there is anything to ask about. The whole Ignite website
>> is
 GA enabled, and all we are doing is accessing a standard web page from
>>> the
 Ignite web site. The information gathered from GA is available only to
>>> the
 Ignite PMC. Frankly, I think legal@ will be very confused by this
 question.
 
 Even ASF website itself uses GA: https://www.apache.org/
 foundation/policies/privacy.html
 
 
> I think Cos said it's OK; maybe Roman can pitch in.
> 
 
 Sure, would be nice to hear from Roman as well.
 
 
> Cheers.
> 
> [1]
> https://developers.google.com/analytics/devguides/collection
> /analyticsjs/events
> 
> On Sat, Aug 26, 2017 at 12:23 AM, Dmitriy Setrakyan <
> dsetrak...@apache.org >
> wrote:
> 
>> Raul,
>> 
>> Could point about Javascript, it will not work because it executes
>> in
> the
>> browser. This means we need a server-side script, like CGI we are
>>> using
> on
>> our download page.
>> 
>> How about this approach. We create something like ignite-version.cgi
> script
>> which will invoke a call to GA and then return the latest version.
>> 
>> This should work, right?
>> 
>> D.
>> 
>> On Fri, Aug 25, 2017 at 2:42 PM, Raúl Kripalani <
>> raul@evosent.com
>>> >
>> wrote:
>> 
>>> Hey Dmitriy and all
>>> 
>>> Also, since we have GA enabled for the website, we can track how
>>> many
>> times
 this page was accessed, which will be equal to the number of
>>> starts.
>> This
 way, the counter information is tracked and monitored by the
>>> Ignite
>> PMC.
>>> 
>>> 
>>> Unfortunately this won't work because GA is loaded via Javascript
>> on
> the
>>> browser, so Google will never receive the page hit.
>>> 
>>> Given the constraints, the most viable solution is an HTTPS
>> endpoint
>>> running on ASF infra that Ignite invokes via a GET or POST
>> request.
> The
>>> simplest thing is to write each request in a log file, along with
>>> the
>>> timestamp, the version reported by the client, maybe the IP (not
>>> sure
>> about
>>> the ASF rules about this concerning privacy, I guess it's OK if
>> you
> make
>> it
>>> an opt-in) and a unique node identifier, i.e. a UUID the node
>>> creates
> on
>>> first startup or something.
>>> 
>>> This endpoint would need some basic DDoS protection and
>> blacklisting
> to
>>> prevent data spoofing.
>>> 
>>> If we'll be 

[GitHub] ignite pull request #2778: ignite-6485 Binary marshalling with writeReplace/...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-6537) Transactions bug

[tommyjarvis (JIRA)]

tommyjarvis created IGNITE-6537:
---

 Summary: Transactions bug 
 Key: IGNITE-6537
 URL: https://issues.apache.org/jira/browse/IGNITE-6537
 Project: Ignite
  Issue Type: Bug
  Components: examples
Affects Versions: 2.2
 Environment: general
Reporter: tommyjarvis


Code:
get ignite:
==
   org.apache.ignite.configuration.IgniteConfiguration cfg = new 
org.apache.ignite.configuration.IgniteConfiguration();

TcpDiscoverySpi spi = new TcpDiscoverySpi();
spi.setLocalPort(48501);
spi.setLocalPortRange(20);
TcpDiscoveryVmIpFinder ipFinder = new TcpDiscoveryVmIpFinder();
ipFinder.setAddresses(serverList);
spi.setIpFinder(ipFinder);

TcpCommunicationSpi commSpi = new TcpCommunicationSpi();
commSpi.setSlowClientQueueLimit(1000);
commSpi.setLocalPort(48101);
cfg.setClientMode(true);
cfg.setDiscoverySpi(spi);
cfg.setCommunicationSpi(commSpi);
cfg.setPeerClassLoadingEnabled(true);
PersistentStoreConfiguration persistentStoreConfiguration = new 
PersistentStoreConfiguration();
cfg.setPersistentStoreConfiguration(persistentStoreConfiguration); 
ignite = Ignition.start(cfg);
==
transaction like this:

   Thread t = new Thread(() -> {
try (Transaction tx = ignite.transactions().txStart()) {
for (int i = 0; i < 1000; i++) {
cache.put(i, i);
}
tx.commit();
}

});
t.start();
//
int lastSize = 0;
while (true) {
int size = cache.size();
//int size = cache2.localSize();
size = cache.query(new ScanQuery<>()).getAll().size();
if (size != lastSize) {
System.out.println(size);
lastSize = size;
}
System.out.println("##" + size);
}

i thought  only print ###0  and ###1000
but after i run print like this:
163
##163
515
##515
1000
##1000
##1000






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

[jira] [Created] (IGNITE-6536) NPE on registerClassName() with MappedName

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-6536:
--

 Summary: NPE on registerClassName() with MappedName
 Key: IGNITE-6536
 URL: https://issues.apache.org/jira/browse/IGNITE-6536
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.1
Reporter: Alexandr Kuramshin
 Fix For: None


{{NullPointerException}} occurs in 
{{org.apache.ignite.internal.MarshallerContextImpl#registerClassName}} on 
trying to compare {{mappedName.className()}} of already existed {{typeId}} 
mapping with the new one {{clsName}} has come as a parameter.

Actually 
{{org.apache.ignite.internal.processors.marshaller.MappedName#className}} may 
not be null but it was. So we should check {{clsName}} comes in {{MappedName}} 
constructor, to prevent same NPEs in the future.



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

Re: Persistence per memory policy configuration

[Vladimir Ozerov]

Ivan,

I do not think this is correct approach, because it will be hard to
explain, and you will have to use "Boolean" instead of "boolean" for
DataRegionConfiguration. I do not think we need default "persistence
enabled" for all regions. Instead, we should have "persistence enabled"
flag for default region only. It should not be propagated to custom regions.

On Mon, Oct 2, 2017 at 11:14 AM, Ivan Rakov  wrote:

> Guys, I think I got the point now.
>
> Let's check the final design:
>
> *DataStorageConfiguration* will have *isDefaultPersistenceEnabled*
> property (default = false), which will be used for enabling persistence in
> default data region.
> *DataRegionConfiguration* will have *isPersistenceEnabled* property, which
> will be used for enabling persistence in corresponding data region. If
> value is not set, value of 
> *DataStorageConfiguration::isDefaultPersistenceEnabled*
> will be used by default.
>
> Best Regards,
> Ivan Rakov
>
>
>
> On 02.10.2017 7:49, Dmitriy Setrakyan wrote:
>
>> On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:
>>
>> On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:

 1) You're right. I forgot to include the main flag in

>>> DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
>>> enabled globally if at least one memory region has this flag set.
>>>
>>> I’m confused. Why the persistence should be enabled *globally* if the
>>> purpose is to have it set for a specific region? If it’s enabled for
>>> region
>>> A only, I don’t want to have it activated for region B.
>>>
>>> Yes, you are right. By default the persistence will be disabled globally.
>> But we should also give users a way to switch the default behavior from
>> in-memory only (no-persistence) to persistence.
>>
>>
>

Re: Persistence per memory policy configuration

[Ivan Rakov]

Guys, I think I got the point now.

Let's check the final design:

*DataStorageConfiguration* will have *isDefaultPersistenceEnabled* 
property (default = false), which will be used for enabling persistence 
in default data region.
*DataRegionConfiguration* will have *isPersistenceEnabled* property, 
which will be used for enabling persistence in corresponding data 
region. If value is not set, value of 
*DataStorageConfiguration::isDefaultPersistenceEnabled* will be used by 
default.


Best Regards,
Ivan Rakov


On 02.10.2017 7:49, Dmitriy Setrakyan wrote:

On Mon, Oct 2, 2017 at 7:46 AM, Denis Magda  wrote:


On Oct 1, 2017, at 4:41 AM, Ivan Rakov  wrote:

1) You're right. I forgot to include the main flag in

DataRegionConfiguration - *isPersistenceEnabled*. Persistence will be
enabled globally if at least one memory region has this flag set.

I’m confused. Why the persistence should be enabled *globally* if the
purpose is to have it set for a specific region? If it’s enabled for region
A only, I don’t want to have it activated for region B.


Yes, you are right. By default the persistence will be disabled globally.
But we should also give users a way to switch the default behavior from
in-memory only (no-persistence) to persistence.

[GitHub] ignite pull request #2782: IGNITE-6534: Configure NotNull fields with annota...

[shroman]

GitHub user shroman opened a pull request:

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

IGNITE-6534: Configure NotNull fields with annotations.



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

$ git pull https://github.com/shroman/ignite GNITE-6534

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

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


commit ecca39d788f39de7eafded9e0523c5d97e0803eb
Author: shroman 
Date:   2017-10-02T07:13:18Z

IGNITE-6534: Configure NotNull fields with annotations.




---