[jira] [Created] (IGNITE-7579) NPE in GridDhtLocalPartition.cacheMapHolder()

[Alexandr Kuramshin (JIRA)]

Alexandr Kuramshin created IGNITE-7579:
--

 Summary: NPE in GridDhtLocalPartition.cacheMapHolder()
 Key: IGNITE-7579
 URL: https://issues.apache.org/jira/browse/IGNITE-7579
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.3
Reporter: Alexandr Kuramshin


The following scenario may occurs:
 # Multiple nodes construct an inactive cluster.
 # Cluster activation performed.
 # Some nodes fail activation.
 # On the other nodes caches will be stopped.
 # NPE occurs as a consequence of {{GridDhtPreloader.evictPartitionAsync()}}
{noformat}
Partition eviction failed, this can cause grid hang.
java.lang.NullPointerException: null
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.cacheMapHolder(GridDhtLocalPartition.java:253)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.clearAll(GridDhtLocalPartition.java:880)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLocalPartition.tryEvict(GridDhtLocalPartition.java:753)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:593)
    at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader$3.call(GridDhtPreloader.java:580)
    at 
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6639)
    at 
org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:967)
{noformat}
# Drop failed nodes from the cluster.
# The latter activation will be successful.
# PDS seems to be corrupted by the cause of NPE.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7578) Web console: Actualize configuration of ClientConnectorConfiguration

[Vasiliy Sisko (JIRA)]

Vasiliy Sisko created IGNITE-7578:
-

 Summary: Web console: Actualize configuration of 
ClientConnectorConfiguration
 Key: IGNITE-7578
 URL: https://issues.apache.org/jira/browse/IGNITE-7578
 Project: Ignite
  Issue Type: Bug
Reporter: Vasiliy Sisko






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3456: IGNITE-7576 - Tweak to version check regexp to fi...

[dwimsey]

GitHub user dwimsey opened a pull request:

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

IGNITE-7576 - Tweak to version check regexp to find OpenJDK

Haven't tested this extensively, it 'works for me' under OpenJDK 1.8 and 
OracleJDK 1.8

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

$ git pull https://github.com/dwimsey/ignite IGNITE-7576

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

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


commit 9b08c6ae216e92c29d4914847720d033ca7dcac2
Author: David Wimsey 
Date:   2018-01-31T01:56:38Z

IGNITE-7576 - Tweak to version check regexp to find OpenJDK




---

[GitHub] ignite pull request #3455: IGNITE-7577 Fixing public API active flag on base...

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

IGNITE-7577 Fixing public API active flag on baseline changes



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

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

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

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


commit 41cffaafa5deef039a14e057152d45399a0b97fc
Author: Alexey Goncharuk 
Date:   2018-01-30T22:16:01Z

IGNITE-7577 Fixing public API active flag on baseline changes




---

Re: IGNITE_HOME for persistence

[Dmitriy Setrakyan]

I think at this point all we can do is print a warning. However, starting
with 3.0, we should require IGNITE_HOME to be set if we cannot determine it
automatically. Do we print a warning already?

On Tue, Jan 30, 2018 at 12:55 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Denis, Dmitriy,
>
> I do not think the behavior should be in any way specific to the case when
> persistence is enabled. We have quite a bit of other information (such as
> binary marshaller metadata and marshaller class mappings) that are also
> stored in the work folder and may be required after the cluster restart,
> moreover, this has been so for years since ignite 1.0.
>
> If you think this is a blocker, please suggest what behavior we want to see
> in ignite 2.4. We cannot calculate IGNITE_HOME when Ignite is run in an
> embedded mode (in other words, the Ignite distribution package structure is
> not preserved). Printing a warning in this case looks good enough for me.
>
> 2018-01-30 23:35 GMT+03:00 Denis Magda :
>
> > The temp dir is no way to go for the persistence.
> >
> > I would enforce setting paths for the storage and WAL files if
> IGNITE_HOME
> > can't be calculated and we end up placing the storage files under the
> > temp.dir.
> >
> > Alex G., can you join this thread? Seems that there is an oversight on
> our
> > side that needs to be fixed in 2.4.
> >
> > —
> > Denis
> >
> > > On Jan 30, 2018, at 2:52 AM, Stanislav Lukyanov <
> stanlukya...@gmail.com>
> > wrote:
> > >
> > > I checked the code handling the IGNITE_HOME and persistent storage
> paths,
> > > and here is what the algorithm looks like.
> > >
> > > For IGNITE_HOME the following is checked in order; if on any step a
> > value is found then we use it.
> > > - IgniteHome in IgniteConfiguration
> > > - IGNITE_HOME system property
> > > - IGNITE_HOME environment variable
> > > - Current working directory (user.dir) and all its ancestors (all
> > directories are checked to have “bin/” and “config/”)
> > > - Class path entry containing ignite-core classes and all its ancestors
> > >
> > > After that, the working directory will be created at one of the
> > following paths
> > > - WorkingDirectory in IgniteConfiguration, if set
> > > - ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
> > > - ${java.io.tmpdir}/work
> > >
> > > Persistent storage will be stored in the working directory, unless
> > StoragePath are specified in the config
> > > (same for WAL and WalPath).
> > >
> > > The issue here is that if we’ve ended up having persistent DB in the
> > working directory in the /tmp,
> > > then persistence files will be cleared upon restart.
> > > Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if
> > IGNITE_HOME is not set, but that’s not the case.
> > >
> > > So, how about actually disallowing to run Ignite when IGNITE_HOME can’t
> > be calculated? Using /tmp for working
> > > directory seems to be an obscure and potentially harmful scenario.
> > > IgniteConfiguration’s documentation can also be adjusted to specify
> > actual steps used to find IgniteHome and WorkingDirectory
> > > if they aren’t set explicitly.
> > > Additionally, I’d suggest not to promote setting IGNITE_HOME system
> > property and environment variable
> > > (e.g. let’s remove it from readmeio). IgniteConfiguration seems to be
> > the most straightforward way to configure Ignite,
> > > and system properties should be used as a backup plan when convenient.
> > >
> > > WDYT?
> > >
> > > Thanks,
> > > Stan
> > >
> > > From: Denis Magda
> > > Sent: 30 января 2018 г. 3:38
> > > To: dev@ignite.apache.org
> > > Subject: Re: IGNITE_HOME for persistence
> > >
> > > No we don’t. I’ve never touched IGNITE_HOME variable for any other
> > purpose.
> > >
> > > As it was suggested, the reported should share the project to reproduce
> > his scenario.
> > >
> > > —
> > > Denis
> > >
> > >> On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan 
> wrote:
> > >>
> > >> Igniters,
> > >>
> > >> I have just stumbled upon this post on SO:
> > >> https://stackoverflow.com/questions/48434929/apache-
> > ignite-persistent-storage
> > >>
> > >> Do we require IGNITE_HOME to be set if the persistence is enabled? If
> > yes,
> > >> do we check for it on startup?
> > >>
> > >> D.
> > >
> > >
> >
> >
>

Re: IGNITE_HOME for persistence

[Dmitry Pavlov]

Hi Igniters,

Why it can be serious issue for end users? As far as I know IGNITE_HOME is
always set using start scripts, e.g. in ignite.sh.

If Ignite is started using java code from IDE, it may be required to set
storage directory or work or home directory. Until that, TEMP is convinient
for development.

IMO it is quite obvious that persistent store configuration has 2 methods
setPersistentEnabled and setStorageDirectory, isn't it? Moreover all paths
are logged at startup.

+1 for warn user if PDS-enabled ignite instance is started without any
explicit folder specification. But I can't find a reason to consider it
blocker for 2.4.

Sincerely,
Dmitriy Pavlov

вт, 30 янв. 2018 г. в 23:55, Alexey Goncharuk :

> Denis, Dmitriy,
>
> I do not think the behavior should be in any way specific to the case when
> persistence is enabled. We have quite a bit of other information (such as
> binary marshaller metadata and marshaller class mappings) that are also
> stored in the work folder and may be required after the cluster restart,
> moreover, this has been so for years since ignite 1.0.
>
> If you think this is a blocker, please suggest what behavior we want to see
> in ignite 2.4. We cannot calculate IGNITE_HOME when Ignite is run in an
> embedded mode (in other words, the Ignite distribution package structure is
> not preserved). Printing a warning in this case looks good enough for me.
>
> 2018-01-30 23:35 GMT+03:00 Denis Magda :
>
> > The temp dir is no way to go for the persistence.
> >
> > I would enforce setting paths for the storage and WAL files if
> IGNITE_HOME
> > can't be calculated and we end up placing the storage files under the
> > temp.dir.
> >
> > Alex G., can you join this thread? Seems that there is an oversight on
> our
> > side that needs to be fixed in 2.4.
> >
> > —
> > Denis
> >
> > > On Jan 30, 2018, at 2:52 AM, Stanislav Lukyanov <
> stanlukya...@gmail.com>
> > wrote:
> > >
> > > I checked the code handling the IGNITE_HOME and persistent storage
> paths,
> > > and here is what the algorithm looks like.
> > >
> > > For IGNITE_HOME the following is checked in order; if on any step a
> > value is found then we use it.
> > > - IgniteHome in IgniteConfiguration
> > > - IGNITE_HOME system property
> > > - IGNITE_HOME environment variable
> > > - Current working directory (user.dir) and all its ancestors (all
> > directories are checked to have “bin/” and “config/”)
> > > - Class path entry containing ignite-core classes and all its ancestors
> > >
> > > After that, the working directory will be created at one of the
> > following paths
> > > - WorkingDirectory in IgniteConfiguration, if set
> > > - ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
> > > - ${java.io.tmpdir}/work
> > >
> > > Persistent storage will be stored in the working directory, unless
> > StoragePath are specified in the config
> > > (same for WAL and WalPath).
> > >
> > > The issue here is that if we’ve ended up having persistent DB in the
> > working directory in the /tmp,
> > > then persistence files will be cleared upon restart.
> > > Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if
> > IGNITE_HOME is not set, but that’s not the case.
> > >
> > > So, how about actually disallowing to run Ignite when IGNITE_HOME can’t
> > be calculated? Using /tmp for working
> > > directory seems to be an obscure and potentially harmful scenario.
> > > IgniteConfiguration’s documentation can also be adjusted to specify
> > actual steps used to find IgniteHome and WorkingDirectory
> > > if they aren’t set explicitly.
> > > Additionally, I’d suggest not to promote setting IGNITE_HOME system
> > property and environment variable
> > > (e.g. let’s remove it from readmeio). IgniteConfiguration seems to be
> > the most straightforward way to configure Ignite,
> > > and system properties should be used as a backup plan when convenient.
> > >
> > > WDYT?
> > >
> > > Thanks,
> > > Stan
> > >
> > > From: Denis Magda
> > > Sent: 30 января 2018 г. 3:38
> > > To: dev@ignite.apache.org
> > > Subject: Re: IGNITE_HOME for persistence
> > >
> > > No we don’t. I’ve never touched IGNITE_HOME variable for any other
> > purpose.
> > >
> > > As it was suggested, the reported should share the project to reproduce
> > his scenario.
> > >
> > > —
> > > Denis
> > >
> > >> On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan 
> wrote:
> > >>
> > >> Igniters,
> > >>
> > >> I have just stumbled upon this post on SO:
> > >> https://stackoverflow.com/questions/48434929/apache-
> > ignite-persistent-storage
> > >>
> > >> Do we require IGNITE_HOME to be set if the persistence is enabled? If
> > yes,
> > >> do we check for it on startup?
> > >>
> > >> D.
> > >
> > >
> >
> >
>

[jira] [Created] (IGNITE-7577) GridClusterStateProcessor#publicApiActiveState returns false when baseline change is in progress

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7577:


 Summary: GridClusterStateProcessor#publicApiActiveState returns 
false when baseline change is in progress
 Key: IGNITE-7577
 URL: https://issues.apache.org/jira/browse/IGNITE-7577
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.4
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.5


Currently the method checks for the transition state, but it does not check if 
the active flag is changing. This leads to unexpected 'Cluster is not active' 
exceptions during baseline change.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: IGNITE_HOME for persistence

[Alexey Goncharuk]

Denis, Dmitriy,

I do not think the behavior should be in any way specific to the case when
persistence is enabled. We have quite a bit of other information (such as
binary marshaller metadata and marshaller class mappings) that are also
stored in the work folder and may be required after the cluster restart,
moreover, this has been so for years since ignite 1.0.

If you think this is a blocker, please suggest what behavior we want to see
in ignite 2.4. We cannot calculate IGNITE_HOME when Ignite is run in an
embedded mode (in other words, the Ignite distribution package structure is
not preserved). Printing a warning in this case looks good enough for me.

2018-01-30 23:35 GMT+03:00 Denis Magda :

> The temp dir is no way to go for the persistence.
>
> I would enforce setting paths for the storage and WAL files if IGNITE_HOME
> can't be calculated and we end up placing the storage files under the
> temp.dir.
>
> Alex G., can you join this thread? Seems that there is an oversight on our
> side that needs to be fixed in 2.4.
>
> —
> Denis
>
> > On Jan 30, 2018, at 2:52 AM, Stanislav Lukyanov 
> wrote:
> >
> > I checked the code handling the IGNITE_HOME and persistent storage paths,
> > and here is what the algorithm looks like.
> >
> > For IGNITE_HOME the following is checked in order; if on any step a
> value is found then we use it.
> > - IgniteHome in IgniteConfiguration
> > - IGNITE_HOME system property
> > - IGNITE_HOME environment variable
> > - Current working directory (user.dir) and all its ancestors (all
> directories are checked to have “bin/” and “config/”)
> > - Class path entry containing ignite-core classes and all its ancestors
> >
> > After that, the working directory will be created at one of the
> following paths
> > - WorkingDirectory in IgniteConfiguration, if set
> > - ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
> > - ${java.io.tmpdir}/work
> >
> > Persistent storage will be stored in the working directory, unless
> StoragePath are specified in the config
> > (same for WAL and WalPath).
> >
> > The issue here is that if we’ve ended up having persistent DB in the
> working directory in the /tmp,
> > then persistence files will be cleared upon restart.
> > Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if
> IGNITE_HOME is not set, but that’s not the case.
> >
> > So, how about actually disallowing to run Ignite when IGNITE_HOME can’t
> be calculated? Using /tmp for working
> > directory seems to be an obscure and potentially harmful scenario.
> > IgniteConfiguration’s documentation can also be adjusted to specify
> actual steps used to find IgniteHome and WorkingDirectory
> > if they aren’t set explicitly.
> > Additionally, I’d suggest not to promote setting IGNITE_HOME system
> property and environment variable
> > (e.g. let’s remove it from readmeio). IgniteConfiguration seems to be
> the most straightforward way to configure Ignite,
> > and system properties should be used as a backup plan when convenient.
> >
> > WDYT?
> >
> > Thanks,
> > Stan
> >
> > From: Denis Magda
> > Sent: 30 января 2018 г. 3:38
> > To: dev@ignite.apache.org
> > Subject: Re: IGNITE_HOME for persistence
> >
> > No we don’t. I’ve never touched IGNITE_HOME variable for any other
> purpose.
> >
> > As it was suggested, the reported should share the project to reproduce
> his scenario.
> >
> > —
> > Denis
> >
> >> On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan  wrote:
> >>
> >> Igniters,
> >>
> >> I have just stumbled upon this post on SO:
> >> https://stackoverflow.com/questions/48434929/apache-
> ignite-persistent-storage
> >>
> >> Do we require IGNITE_HOME to be set if the persistence is enabled? If
> yes,
> >> do we check for it on startup?
> >>
> >> D.
> >
> >
>
>

Re: IGNITE_HOME for persistence

[Dmitriy Setrakyan]

I think we should still keep System property and Environment variable
check. Our product has a user base that depends on these properties and
changing them at will is not an option.

I do agree that the product should not start if IGNITE_HOME cannot be
calculated, but I still do not understand how this could be possible.
Setting it to TMP directory seems vary flaky and should be disabled.

This seems to be a blocker for 2.4 release and needs to be fixed. Do we
have an appropriate ticket for this?

D.

On Tue, Jan 30, 2018 at 2:52 AM, Stanislav Lukyanov 
wrote:

> I checked the code handling the IGNITE_HOME and persistent storage paths,
> and here is what the algorithm looks like.
>
> For IGNITE_HOME the following is checked in order; if on any step a value
> is found then we use it.
> - IgniteHome in IgniteConfiguration
> - IGNITE_HOME system property
> - IGNITE_HOME environment variable
> - Current working directory (user.dir) and all its ancestors (all
> directories are checked to have “bin/” and “config/”)
> - Class path entry containing ignite-core classes and all its ancestors
>
> After that, the working directory will be created at one of the following
> paths
> - WorkingDirectory in IgniteConfiguration, if set
> - ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
> - ${java.io.tmpdir}/work
>
> Persistent storage will be stored in the working directory, unless
> StoragePath are specified in the config
> (same for WAL and WalPath).
>
> The issue here is that if we’ve ended up having persistent DB in the
> working directory in the /tmp,
> then persistence files will be cleared upon restart.
> Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if
> IGNITE_HOME is not set, but that’s not the case.
>
> So, how about actually disallowing to run Ignite when IGNITE_HOME can’t be
> calculated? Using /tmp for working
> directory seems to be an obscure and potentially harmful scenario.
> IgniteConfiguration’s documentation can also be adjusted to specify actual
> steps used to find IgniteHome and WorkingDirectory
> if they aren’t set explicitly.
> Additionally, I’d suggest not to promote setting IGNITE_HOME system
> property and environment variable
> (e.g. let’s remove it from readmeio). IgniteConfiguration seems to be the
> most straightforward way to configure Ignite,
> and system properties should be used as a backup plan when convenient.
>
> WDYT?
>
> Thanks,
> Stan
>
> From: Denis Magda
> Sent: 30 января 2018 г. 3:38
> To: dev@ignite.apache.org
> Subject: Re: IGNITE_HOME for persistence
>
> No we don’t. I’ve never touched IGNITE_HOME variable for any other purpose.
>
> As it was suggested, the reported should share the project to reproduce
> his scenario.
>
> —
> Denis
>
> > On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan  wrote:
> >
> > Igniters,
> >
> > I have just stumbled upon this post on SO:
> > https://stackoverflow.com/questions/48434929/apache-
> ignite-persistent-storage
> >
> > Do we require IGNITE_HOME to be set if the persistence is enabled? If
> yes,
> > do we check for it on startup?
> >
> > D.
>
>
>

Re: IGNITE_HOME for persistence

[Denis Magda]

The temp dir is no way to go for the persistence.

I would enforce setting paths for the storage and WAL files if IGNITE_HOME 
can't be calculated and we end up placing the storage files under the temp.dir.

Alex G., can you join this thread? Seems that there is an oversight on our side 
that needs to be fixed in 2.4.

—
Denis

> On Jan 30, 2018, at 2:52 AM, Stanislav Lukyanov  
> wrote:
> 
> I checked the code handling the IGNITE_HOME and persistent storage paths,
> and here is what the algorithm looks like.
> 
> For IGNITE_HOME the following is checked in order; if on any step a value is 
> found then we use it. 
> - IgniteHome in IgniteConfiguration
> - IGNITE_HOME system property
> - IGNITE_HOME environment variable
> - Current working directory (user.dir) and all its ancestors (all directories 
> are checked to have “bin/” and “config/”)
> - Class path entry containing ignite-core classes and all its ancestors
> 
> After that, the working directory will be created at one of the following 
> paths
> - WorkingDirectory in IgniteConfiguration, if set
> - ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
> - ${java.io.tmpdir}/work
> 
> Persistent storage will be stored in the working directory, unless 
> StoragePath are specified in the config
> (same for WAL and WalPath).
> 
> The issue here is that if we’ve ended up having persistent DB in the working 
> directory in the /tmp, 
> then persistence files will be cleared upon restart. 
> Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if 
> IGNITE_HOME is not set, but that’s not the case.
> 
> So, how about actually disallowing to run Ignite when IGNITE_HOME can’t be 
> calculated? Using /tmp for working 
> directory seems to be an obscure and potentially harmful scenario.
> IgniteConfiguration’s documentation can also be adjusted to specify actual 
> steps used to find IgniteHome and WorkingDirectory
> if they aren’t set explicitly.
> Additionally, I’d suggest not to promote setting IGNITE_HOME system property 
> and environment variable
> (e.g. let’s remove it from readmeio). IgniteConfiguration seems to be the 
> most straightforward way to configure Ignite, 
> and system properties should be used as a backup plan when convenient.
> 
> WDYT?
> 
> Thanks,
> Stan
> 
> From: Denis Magda
> Sent: 30 января 2018 г. 3:38
> To: dev@ignite.apache.org
> Subject: Re: IGNITE_HOME for persistence
> 
> No we don’t. I’ve never touched IGNITE_HOME variable for any other purpose.
> 
> As it was suggested, the reported should share the project to reproduce his 
> scenario.
> 
> —
> Denis
> 
>> On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan  wrote:
>> 
>> Igniters,
>> 
>> I have just stumbled upon this post on SO:
>> https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage
>> 
>> Do we require IGNITE_HOME to be set if the persistence is enabled? If yes,
>> do we check for it on startup?
>> 
>> D.
> 
> 

[jira] [Created] (IGNITE-7576) ignite.sh expect only oracle jdk, not openjdk

[David Wimsey (JIRA)]

David Wimsey created IGNITE-7576:


 Summary: ignite.sh expect only oracle jdk, not openjdk
 Key: IGNITE-7576
 URL: https://issues.apache.org/jira/browse/IGNITE-7576
 Project: Ignite
  Issue Type: Bug
Reporter: David Wimsey


https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob;f=bin/include/functions.sh;h=8f4570bd420d9e5c3815a6feb40e86c3986234be;hb=HEAD

 

On line 66, thats a pretty bad version check, never has a chance of working 
with OpenJDK.

 

Does this apache project not test against OpenJDK?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7575) Concurrent updates of common keys cause silent wrong update count (intermittent issue)

[Pavel Kuznetsov (JIRA)]

Pavel Kuznetsov created IGNITE-7575:
---

 Summary: Concurrent updates of common keys cause silent wrong 
update count (intermittent issue)
 Key: IGNITE-7575
 URL: https://issues.apache.org/jira/browse/IGNITE-7575
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Pavel Kuznetsov
Assignee: Alexander Paschenko


In case of concurrent updates that affects some common keys we get silent wrong 
update count

There's single table with two columns: key and val.
I'm performing the same query that updates the same 1000 rows. Query doesn't 
update keys, it only increments val.
In some cases I get expected exception "Failed to update some keys because they 
had been modified concurrently"  or have 1000 updated rows

In the other case, API tells me that more than 1000 rows updated. Expected  
result are exception or successfull update of 1000 rows

see reproducer attached. It should be run against 
```ignite/examples/src/main/java/org/apache/ignite/examples/ExampleNodeStartup.java```





--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7574) Ignite Getting Started confuses developers

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7574:
---

 Summary: Ignite Getting Started confuses developers
 Key: IGNITE-7574
 URL: https://issues.apache.org/jira/browse/IGNITE-7574
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Denis Magda
 Fix For: 2.4


By some reason, we suggest to build Ignite from sources at the very beginning 
of the getting started guide:

[https://apacheignite.readme.io/docs/getting-started]

I got a feedback that this confuses a lot especially because it's 100% 
optional! The reporter wasted much of his time trying to build Ignite with JDK 
9 and could succeed only after a private conversation with me.

 

Revisit and rework the guide.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7573) IgniteOfflineBaselineNodeFullApiSelfTest.testSize fails

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7573:


 Summary: IgniteOfflineBaselineNodeFullApiSelfTest.testSize fails
 Key: IGNITE-7573
 URL: https://issues.apache.org/jira/browse/IGNITE-7573
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 2.4
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.5






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (IGNITE-7572) Local cache fails to start on local node

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-7572:
-

 Summary: Local cache fails to start on local node
 Key: IGNITE-7572
 URL: https://issues.apache.org/jira/browse/IGNITE-7572
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.3
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov
 Fix For: 2.5


Reproducer:


import java.util.Arrays;
import org.apache.ignite.Ignite;
import org.apache.ignite.Ignition;
import org.apache.ignite.cache.CacheMode;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
import org.jetbrains.annotations.NotNull;

public class LocalCache {
 private static int id;

 public static void main(String[] args) throws InterruptedException {
 Ignition.setClientMode(false);

 Ignite server = Ignition.start(getConfiguration());

 System.out.println("Server is up");

 Ignition.setClientMode(true);
 Ignite client = Ignition.start(getConfiguration());

 System.out.println("Client is up");
 }

 @NotNull private static IgniteConfiguration getConfiguration() {
 IgniteConfiguration cfg = new IgniteConfiguration();

 TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
 finder.setAddresses(Arrays.asList("localhost:47500..47600"));

 cfg.setIgniteInstanceName("test" + id++);

 CacheConfiguration cacheConfiguration = new CacheConfiguration("TEST");
 cacheConfiguration.setCacheMode(CacheMode.LOCAL);

 cfg.setCacheConfiguration(cacheConfiguration);

 cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
 return cfg;
 }
}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Protect Ignite clusters from Meltdown and Spectre

[Denis Magda]

Apache Ignite community applied security patches against the notorious Meltdown 
Spectre vulnerabilities and completed performance testing of general operations 
and workloads that are typical for Ignite deployments.

The details are under the link:
https://blogs.apache.org/ignite/entry/meltdown-and-spectre-patches-show


—
Denis

> On Jan 8, 2018, at 1:11 PM, Denis Magda  wrote:
> 
> Make sure your Ignite clusters are protected from the fierce vulnerabilities 
> that rocked the world:
> https://blogs.apache.org/ignite/entry/protecting-apache-ignite-from-meltdown
> 
> —
> Denis

[jira] [Created] (IGNITE-7571) [Test fail]

[Eduard Shangareev (JIRA)]

Eduard Shangareev created IGNITE-7571:
-

 Summary: [Test fail]
 Key: IGNITE-7571
 URL: https://issues.apache.org/jira/browse/IGNITE-7571
 Project: Ignite
  Issue Type: Improvement
Reporter: Eduard Shangareev


{code:java}
[2018-01-30 19:53:21,836][ERROR][main][root] Test failed.
class org.apache.ignite.internal.IgniteFutureTimeoutCheckedException: Timeout 
was reached before computation completed.
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:242)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:159)
at 
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:151)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheGroupsTest.testNoKeyIntersectTxLocks(IgniteCacheGroupsTest.java:1788)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheGroupsTest.testNoKeyIntersect(IgniteCacheGroupsTest.java:1726)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheGroupsTest.testNoKeyIntersect(IgniteCacheGroupsTest.java:1536)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheGroupsTest.testNoKeyIntersectTx(IgniteCacheGroupsTest.java:1511)
at sun.reflect.GeneratedMethodAccessor30.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2000)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:132)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1915)
at java.lang.Thread.run(Thread.java:745){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3454: IGNITE-7569 Fixed index rebuild future

[agoncharuk]

GitHub user agoncharuk opened a pull request:

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

IGNITE-7569 Fixed index rebuild future



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

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

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

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


commit b7ae9e928846e3c5ffc2ad6412f25fbeab2417b3
Author: Alexey Goncharuk 
Date:   2018-01-30T14:41:09Z

IGNITE-7569 Fixed index rebuild future




---

[jira] [Created] (IGNITE-7570) Client nodes failed with "Failed to process invalid partitions response" during failover

[Ksenia Rybakova (JIRA)]

Ksenia Rybakova created IGNITE-7570:
---

 Summary: Client nodes failed with "Failed to process invalid 
partitions response" during failover
 Key: IGNITE-7570
 URL: https://issues.apache.org/jira/browse/IGNITE-7570
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Ksenia Rybakova


Some client nodes fail with "Failed to process invalid partitions response" 
during failover test:

{noformat}

[2018-01-30 16:27:58,610][INFO ][sys-#190][GridDhtPartitionsExchangeFuture] 
Received full message, will finish exchange 
[node=80ebd2ac-1432-4bfc-bab7-d9dbf56cdeb4, resVer=AffinityTopologyVersion 
[topVer=37, minorTopVer=0]]
[2018-01-30 16:27:58,688][INFO ][sys-#190][GridDhtPartitionsExchangeFuture] 
Finish exchange future [startVer=AffinityTopologyVersion [topVer=37, 
minorTopVer=0], resVer=AffinityTopologyVersion [topVer=37, minorTopVer=0], 
err=null]
<16:27:58> The benchmark of random operation 
failed.
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
Failed to process invalid partitions response (remote node reported invalid 
partitions but remote topology version does not differ from local) 
[topVer=AffinityTopologyVersion [topVer=37, minorTopVer=0], 
rmtTopVer=AffinityTopologyVersion [topVer=37, minorTopVer=0], part=204, 
nodeId=80ebd2ac-1432-4bfc-bab7-d9dbf56cdeb4]
 at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1294)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1673)
 at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.get(IgniteCacheProxyImpl.java:852)
 at 
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.get(GatewayProtectedCacheProxy.java:676)
 at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.doGet(IgniteCacheRandomOperationBenchmark.java:776)
 at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeRandomOperation(IgniteCacheRandomOperationBenchmark.java:624)
 at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.executeOutOfTx(IgniteCacheRandomOperationBenchmark.java:602)
 at 
org.apache.ignite.yardstick.cache.load.IgniteCacheRandomOperationBenchmark.test(IgniteCacheRandomOperationBenchmark.java:207)
 at org.yardstickframework.impl.BenchmarkRunner$2.run(BenchmarkRunner.java:178)
 at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to process 
invalid partitions response (remote node reported invalid partitions but remote 
topology version does not differ from local) [topVer=AffinityTopologyVersion 
[topVer=37, minorTopVer=0], rmtTopVer=AffinityTopologyVersion [topVer=37, 
minorTopVer=0], part=204, nodeId=80ebd2ac-1432-4bfc-bab7-d9dbf56cdeb4]
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.checkError(GridPartitionedSingleGetFuture.java:596)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:505)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:349)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$1400(GridDhtAtomicCache.java:130)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$15.apply(GridDhtAtomicCache.java:422)
 at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$15.apply(GridDhtAtomicCache.java:417)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1060)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:579)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:378)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:304)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:99)
 at 
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:293)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1555)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1183)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:126)
 at 
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1090)
 at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.run(StripedExecutor.java:499)
 ... 1 more
Finishing main test [ts=1

[jira] [Created] (IGNITE-7569) Index rebuild future is created too late

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-7569:


 Summary: Index rebuild future is created too late
 Key: IGNITE-7569
 URL: https://issues.apache.org/jira/browse/IGNITE-7569
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
 Fix For: 2.5


rebuildIndexesIfNeeded is called before the exchange future onDone method, 
which may be too late in a distributed case: a node may complete a local 
exchange and send a compute job to a remote node. In this case, if the job 
checks the index rebuild future, it may observe {{null}}.

To fix this, we should create the future in beforeExchange, and complete it 
after the rebuild is finished.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3453: IGNITE-7567: Fixed bug with datasest in examples

[asfgit]

Github user asfgit closed the pull request at:

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


---

Abandoned Patch Available JIRA tickets

[Pavel Tupitsyn]

Igniters,

We have *almost 60* of PATCH AVAILABLE tickets that are inactive for more
than a month:
https://issues.apache.org/jira/issues/?filter=12333285&jql=project%3Dignite%20AND%20status%3D%22Patch%20Available%22%20AND%20updated%20%3C%20-30d

(JQL: project=ignite AND status="Patch Available" AND updated < -30d)


Some of these tickets ask specific people for review without any answer.
You can check if you have any pending reviews with this link:
https://issues.apache.org/jira/issues/?filter=12333285&jql=project%3Dignite%20AND%20status%3D%22Patch%20Available%22%20AND%20updated%20%3C%20-30d%20AND%20comment%20%20~%20currentUser()

(JQL: project=ignite AND status="Patch Available" AND updated < -30d AND
comment  ~ currentUser())


I encourage everyone to walk through these tickets and see if you can help
with reviewing and merging some of these contributions.

Thanks,
Pavel

Re: Apache Ignite 2.4 release

[Pavel Tupitsyn]

Igniters, I will handle 2.4 release if there are no objections.
Let's take a bit more time for testing and start vote by the end of this
week.

Pavel

On Sat, Jan 27, 2018 at 3:32 AM, Denis Magda  wrote:

> Hi Vyacheslav,
>
> According to the previous review notes the impact of the changes might be
> significant, thus, I would recommend us to move the changes to the next
> release.
>
> BTW, don’t hesitate to ping reviewers more frequently if there is a
> pending/abandon review. We are all the people who are tend to forget or
> miss notifications ;)
>
> > On Jan 26, 2018, at 2:04 AM, Vyacheslav Daradur 
> wrote:
> >
> > Hi, Vladimir, it's good news. I'm looking forward to new Ignite release!
> >
> > Could you please share a release schedule for 'varint' optimizations?
> >
> > The task [1] is waiting for review for 5 months.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-5097
> >
> >
> > On Fri, Jan 26, 2018 at 12:51 PM, Vladimir Ozerov 
> wrote:
> >> Hi Igniters,
> >>
> >> As far as I can see all required tasks and fixes were merged. I propose
> to
> >> take several days of silence to test what we've done and start vote at
> the
> >> beginning of the next week.
> >>
> >> Makes sense?
> >>
> >> On Mon, Jan 22, 2018 at 8:39 PM, Denis Magda  wrote:
> >>
> >>> Ok, let’s target Wednesday as a code freeze date.
> >>>
> >>> Community members who are involved in 2.4 release please merge you
> fixes
> >>> and optimizations by that time.
> >>>
> >>> —
> >>> Denis
> >>>
>  On Jan 22, 2018, at 8:24 AM, Anton Vinogradov  wrote:
> 
>  Issues
>  https://issues.apache.org/jira/browse/IGNITE-6711
>  https://issues.apache.org/jira/browse/IGNITE-6902
> 
>  are in master and ignite-2.4
> 
>  On Mon, Jan 22, 2018 at 6:43 PM, Denis Magda 
> wrote:
> 
> > Igniters,
> >
> > What’s left and what prevents us from passing 2.4 through the QA
> phase?
> >
> > Petr, Anton, Vladimir, Alex G., others please chime in.
> >
> > —
> > Denis
> >
> >> On Jan 17, 2018, at 7:05 PM, Dmitriy Setrakyan <
> dsetrak...@apache.org>
> > wrote:
> >>
> >> Great news, indeed! Looking forward to 2.4 release.
> >>
> >> On Wed, Jan 17, 2018 at 2:55 AM, Vladimir Ozerov <
> voze...@gridgain.com
> 
> >> wrote:
> >>
> >>> Igniters,
> >>>
> >>> Great news - two very important tickets - baseline topology and
> Java 8
> >>> support - were merged to master. At this point it makes sense to
> >>> create
> > a
> >>> branch to stabilize the release and finalize outstanding tickets. I
> > created
> >>> the branch *ignite-2.4*. Please follow the rules below when merging
> >>> new
> >>> commits to master:
> >>> 1) If ticket is targeted for 2.4 release, please merge to master,
> then
> >>> cherry-pick to ignite-2.4
> >>> 2) Otherwise just merge to master.
> >>>
> >>> Vladimir.
> >>>
> >>> On Tue, Jan 16, 2018 at 12:32 PM, Anton Vinogradov <
> >>> avinogra...@gridgain.com
>  wrote:
> >>>
>  Denis,
> 
>  I'll review https://issues.apache.org/jira/browse/IGNITE-6902
> 
>  On Fri, Jan 12, 2018 at 11:45 PM, Denis Magda 
> > wrote:
> 
> > Here is the page create before:
> > https://cwiki.apache.org/confluence/display/IGNITE/
> >>> Apache+Ignite+2.4
> > <
> > https://cwiki.apache.org/confluence/display/IGNITE/
> >>> Apache+Ignite+2.4>
> >
> > This is good news. It will be perfect if we also release as many
>  "required
> > tickets" as we can:
> > https://cwiki.apache.org/confluence/display/IGNITE/
> >>> Apache+Ignite+2.4
> > <
> > https://cwiki.apache.org/confluence/display/IGNITE/
> >>> Apache+Ignite+2.4>
> >
> > My favorite is memory metrics in bytes:
> https://issues.apache.org/
> > jira/browse/IGNITE-6902   jira/browse/IGNITE-6902
> >>
> >
> > The discussion lists are flooded with the demands for this
> essential
> > capability. Who is going to review it?
> >
> > -
> > Denis
> >
> >> On Jan 12, 2018, at 11:22 AM, Dmitriy Setrakyan <
> >>> dsetrak...@apache.org
> >
> > wrote:
> >>
> >> +1
> >>
> >> Do we have a list of features for 2.4 documented anywhere?
> >>
> >> D.
> >>
> >> On Fri, Jan 12, 2018 at 7:43 AM, Pavel Tupitsyn <
> >>> ptupit...@apache.org>
> >> wrote:
> >>
> >>> +1
> >>>
> >>> But some stuff is not yet in master (like baseline topology),
> so
> >>> it
> >>> is
> > too
> >>> soon to create a branch, I think.
> >>>
> >>> Pavel
> >>>
> >>> On Fri, Jan 12, 2018 at 5:31 PM, Vladimir Ozerov <
>  voze...@gridgain.com>
> >>>

Re: Unresolved Ignite 2.4 tickets

[Pavel Tupitsyn]

Hi Dmitry,

Thanks for the heads up, I've moved all 2.4 tickets (except site and
documentation related) to 2.5.

Pavel

On Tue, Jan 30, 2018 at 3:36 PM, Dmitry Sherstobitov 
wrote:

> Hi!
>
> We are still having issues for ignite-2.4 release in PATCH AVAILABLE or
> OPEN state:
>
>
>1. IGNITE-7216 
> Refactor
>examples project
>
>
>1. IGNITE-6630 
> Incorrect
>   time units of average transaction commit/rollback duration cache
> metrics
>1. IGNITE-6500 POJO
>  fields of java wrapper type are not retaining null values
> from Cassandra
>  persistent store, while using ignite's CassandraCacheStoreFactory
>   1. IGNITE-6333 
> Improve
> cache transaction metrics to better understand
> transactions efficiency.
>  1. IGNITE-6252
> Cassandra
>Cache Store Session does not retry if prepare statement
> failed
> 1. IGNITE-7567
>   ML
>   example datasets should be moved in resource directory
>1. IGNITE-6005
>  [Test failed]
>  GridCachePartitionedDataStructuresFailoverSelfTest.
> testSemaphoreNonFailoverSafe
>
>
>1. IGNITE-5580 
> Improve
>node failure cause information
>
>
>1. IGNITE-5136
> GridLogThrottle
>   memory leak
>
>
>1. IGNITE-3999 
> Support
>   case insensitive search in SQL
>
>
>
> --
> Best regards,
> Dmitry Sherstobitov
>

Unresolved Ignite 2.4 tickets

[Dmitry Sherstobitov]

Hi!

We are still having issues for ignite-2.4 release in PATCH AVAILABLE or
OPEN state:


   1. IGNITE-7216 Refactor
   examples project


   1. IGNITE-6630 Incorrect
  time units of average transaction commit/rollback duration cache metrics
   1. IGNITE-6500 POJO
 fields of java wrapper type are not retaining null values
from Cassandra
 persistent store, while using ignite's CassandraCacheStoreFactory
  1. IGNITE-6333 Improve
cache transaction metrics to better understand
transactions efficiency.
 1. IGNITE-6252
Cassandra
   Cache Store Session does not retry if prepare statement failed
1. IGNITE-7567
  ML
  example datasets should be moved in resource directory
   1. IGNITE-6005
 [Test failed]
 
GridCachePartitionedDataStructuresFailoverSelfTest.testSemaphoreNonFailoverSafe


   1. IGNITE-5580 Improve
   node failure cause information


   1. IGNITE-5136
GridLogThrottle
  memory leak


   1. IGNITE-3999 Support
  case insensitive search in SQL



--
Best regards,
Dmitry Sherstobitov

[jira] [Created] (IGNITE-7568) Product version increment script

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7568:
--

 Summary: Product version increment script
 Key: IGNITE-7568
 URL: https://issues.apache.org/jira/browse/IGNITE-7568
 Project: Ignite
  Issue Type: Improvement
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.5


On every release we increment Ignite version (2.4.0 -> 2.5.0), and we do in in 
multiple places:
* {{pom.xml}} for Java
* {{AssemblyInfo.cs}} for C#
* {{configure.ac}} for C++

Currently this is done by hand (search and replace) and is error prone.
Create a bash script to update everything in one go.
Commit & push should be still manual.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3361: IGNITE-6810: SSL support for ODBC

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3453: IGNITE-7567: Fixed bug with datasest in examples

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-7567: Fixed bug with datasest in examples



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

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

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

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


commit 7d22bcd33fcea3a7588c46368b5289d5b306db7f
Author: Zinoviev Alexey 
Date:   2017-12-07T11:01:43Z

Merge from master

commit 84cbd8b380772ce773790b18066c86b663b1af27
Author: Zinoviev Alexey 
Date:   2017-12-13T10:36:56Z

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

commit b58db6a44be3c625174c1d89c577240771d1bfb4
Author: Zinoviev Alexey 
Date:   2017-12-26T16:37:24Z

Merged from master

commit f68785c2296ba414a89e4399c8fbece544cd18e2
Author: Zinoviev Alexey 
Date:   2018-01-10T13:59:30Z

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

commit 7be3c489c44c2305d96771d5a972f820e56af0e8
Author: Zinoviev Alexey 
Date:   2018-01-18T09:31:20Z

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

commit 171e4712b4949a13683151114d13d078eeea930e
Author: Zinoviev Alexey 
Date:   2018-01-30T11:13:52Z

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

commit 946c4d33e2e880a98710b2916cbbb3a71d186278
Author: Zinoviev Alexey 
Date:   2018-01-30T11:57:21Z

IGNITE-7567: Fixed bug

commit 82de5f81d94cd1eda0a5a2c79fd9d0bb2d663fd7
Author: Zinoviev Alexey 
Date:   2018-01-30T12:06:10Z

IGNITE-7567: Fixed licences

commit b48f21970bd4b0917a1136bbfe58521650d46e75
Author: Zinoviev Alexey 
Date:   2018-01-30T12:08:45Z

IGNITE-7567: Fixed licences




---

Re: Should we annotate @CacheLocalStore as @Depricated?

[Anton Vinogradov]

+1

On Tue, Jan 30, 2018 at 9:02 AM, Yakov Zhdanov  wrote:

> +1 for deprecation
>
>
>
> --Yakov
>
> 2018-01-30 1:06 GMT+03:00 Valentin Kulichenko <
> valentin.kuliche...@gmail.com
> >:
>
> > +1
> >
> > On Mon, Jan 29, 2018 at 8:31 AM, Andrey Mashenkov <
> > andrey.mashen...@gmail.com> wrote:
> >
> > > Vyacheslav,
> > >
> > > +1 for dropping @CacheLocalStore.
> > > Ignite have no support 2-phase commit for store and public API provides
> > no
> > > methods to users can easily implement it by themselves.
> > >
> > >
> > >
> > >
> > > On Mon, Jan 29, 2018 at 7:11 PM, Vyacheslav Daradur <
> daradu...@gmail.com
> > >
> > > wrote:
> > >
> > > > Hi Igniters,
> > > >
> > > > I've worked with Apache Ignite 3rd Party Persistent Storage tools
> > > recently.
> > > >
> > > > I found that use of CacheLocalStore annotation has hidden issues, for
> > > > example:
> > > > * rebalancing issues [1]
> > > > * possible data consistency issues [1]
> > > > * handling of CacheLocalStore on clients nodes [2]
> > > >
> > > > Valentin K. considers it necessary to make @CacheLocalStore
> deprecated
> > > > and remove. If we want to have a decentralized persistent storage we
> > > > should use Apache Ignite Native Persistence.
> > > >
> > > > If the community supports this decision I will create a new Jira
> issue.
> > > >
> > > > Any thoughts?
> > > >
> > > > [1] http://apache-ignite-developers.2346864.n4.nabble.
> > > > com/Losing-data-during-restarting-cluster-with-
> > > > persistence-enabled-tt24267.html
> > > > [2] http://apache-ignite-developers.2346864.n4.nabble.
> > com/How-to-handle-
> > > > CacheLocalStore-on-clients-node-tt25703.html
> > > >
> > > >
> > > >
> > > > --
> > > > Best Regards, Vyacheslav D.
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > > Andrey V. Mashenkov
> > >
> >
>

RE: IGNITE_HOME for persistence

[Stanislav Lukyanov]

I checked the code handling the IGNITE_HOME and persistent storage paths,
and here is what the algorithm looks like.

For IGNITE_HOME the following is checked in order; if on any step a value is 
found then we use it. 
- IgniteHome in IgniteConfiguration
- IGNITE_HOME system property
- IGNITE_HOME environment variable
- Current working directory (user.dir) and all its ancestors (all directories 
are checked to have “bin/” and “config/”)
- Class path entry containing ignite-core classes and all its ancestors

After that, the working directory will be created at one of the following paths
- WorkingDirectory in IgniteConfiguration, if set
- ${IGNITE_HOME}/work, if IGNITE_HOME could be calculated previously
- ${java.io.tmpdir}/work

Persistent storage will be stored in the working directory, unless StoragePath 
are specified in the config
(same for WAL and WalPath).

The issue here is that if we’ve ended up having persistent DB in the working 
directory in the /tmp, 
then persistence files will be cleared upon restart. 
Also, IgniteConfiguration::getIgniteHome claims that Igntie fails if 
IGNITE_HOME is not set, but that’s not the case.

So, how about actually disallowing to run Ignite when IGNITE_HOME can’t be 
calculated? Using /tmp for working 
directory seems to be an obscure and potentially harmful scenario.
IgniteConfiguration’s documentation can also be adjusted to specify actual 
steps used to find IgniteHome and WorkingDirectory
if they aren’t set explicitly.
Additionally, I’d suggest not to promote setting IGNITE_HOME system property 
and environment variable
(e.g. let’s remove it from readmeio). IgniteConfiguration seems to be the most 
straightforward way to configure Ignite, 
and system properties should be used as a backup plan when convenient.

WDYT?

Thanks,
Stan

From: Denis Magda
Sent: 30 января 2018 г. 3:38
To: dev@ignite.apache.org
Subject: Re: IGNITE_HOME for persistence

No we don’t. I’ve never touched IGNITE_HOME variable for any other purpose.

As it was suggested, the reported should share the project to reproduce his 
scenario.

—
Denis

> On Jan 26, 2018, at 9:05 PM, Dmitriy Setrakyan  wrote:
> 
> Igniters,
> 
> I have just stumbled upon this post on SO:
> https://stackoverflow.com/questions/48434929/apache-ignite-persistent-storage
> 
> Do we require IGNITE_HOME to be set if the persistence is enabled? If yes,
> do we check for it on startup?
> 
> D.

Re: Ignite Semaphore Bug 7090

[Dmitriy Setrakyan]

Tim, I added you as Ignite contributor. You can assign tickets to yourself
now.

On Sun, Jan 28, 2018 at 5:24 PM, Tim Onyschak  wrote:

> Jira Username: Timay
>
> On Sat, Jan 27, 2018 at 1:43 AM, Dmitriy Setrakyan 
> wrote:
>
>> Tim, can you please send your Apache Jira ID here, so I could add you as
>> Ignite contributor?
>>
>> On Thu, Jan 25, 2018 at 6:02 PM, Tim Onyschak 
>> wrote:
>>
>>> It does not look like i have permissions to assign tickets. I'll gladly
>>> take it, if somebody can assign it to me.
>>>
>>> Also, Vlad i updated the ticket with my comment as well.
>>>
>>>
>>> On Thu, Jan 25, 2018 at 7:44 PM, Yakov Zhdanov 
>>> wrote:
>>>
>>> > Vlad and Tim, thanks for working on this!
>>> >
>>> > Tim, please assign ticket to yourself to follow community process.
>>> > Currently I see it is unassigned.
>>> >
>>> > --Yakov
>>> >
>>> > 2018-01-25 8:53 GMT-08:00 Vladisav Jelisavcic :
>>> >
>>> >> Hi Tim,
>>> >>
>>> >> thank you for delving deeper into the problem,
>>> >> I left you a comment/question on the JIRA.
>>> >>
>>> >> Best regards,
>>> >> Vladisav
>>> >>
>>> >> On Tue, Jan 23, 2018 at 3:00 PM, Vladisav Jelisavcic <
>>> vladis...@gmail.com
>>> >> >
>>> >> wrote:
>>> >>
>>> >> > Hi Tim,
>>> >> >
>>> >> > thanks for the update! I left you a comment on Jira.
>>> >> >
>>> >> > Best regards,
>>> >> > Vladisav
>>> >> >
>>> >> > On Mon, Jan 22, 2018 at 6:17 PM, Tim Onyschak 
>>> >> wrote:
>>> >> >
>>> >> >> Hey Vladisav,
>>> >> >>
>>> >> >> I implemented your requests. Take a look, specifically, i created
>>> an
>>> >> >> interface to encapsulate the NodeUpdates and let
>>> >> >> the DataStructuresProcessor handle the execution by checking for
>>> one
>>> >> type
>>> >> >> as opposed to multiple if checks. In this case it checks for
>>> >> GridCacheNodeUpdate
>>> >> >> instance and executes onNodeRemoved. Let me know what you think.
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Tim
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sat, Jan 20, 2018 at 8:10 AM, Vladisav Jelisavcic <
>>> >> vladis...@gmail.com
>>> >> >> > wrote:
>>> >> >>
>>> >> >>> Hi Tim,
>>> >> >>>
>>> >> >>> I reviewed your contribution and left you some comments on the pr.
>>> >> >>> Thanks!
>>> >> >>>
>>> >> >>> Vladisav
>>> >> >>>
>>> >> >>> On Wed, Jan 17, 2018 at 10:14 PM, Vladisav Jelisavcic <
>>> >> >>> vladis...@gmail.com> wrote:
>>> >> >>>
>>> >>  Hi Tim,
>>> >> 
>>> >>  thank you for the contribution!
>>> >>  I'll do the review soon and let you know.
>>> >> 
>>> >> 
>>> >> 
>>> >>  On Wed, Jan 17, 2018 at 8:56 AM, Yakov Zhdanov <
>>> yzhda...@apache.org>
>>> >>  wrote:
>>> >> 
>>> >> > Thanks Tim! I hope Vlad can review your patch. If this does not
>>> >> happen
>>> >> > in
>>> >> > 2-3 days I will take a look. Can you please let me know on
>>> weekend
>>> >> if I
>>> >> > need to?
>>> >> >
>>> >> > --Yakov
>>> >> >
>>> >> > 2018-01-16 23:36 GMT+03:00 Tim Onyschak :
>>> >> >
>>> >> > > Hey all,
>>> >> > >
>>> >> > > I created a patch and posted to user group, was told feed back
>>> >> would
>>> >> > be
>>> >> > > left on the jira. I wanted to see if we could get a fix in
>>> with
>>> >> 2.4,
>>> >> > could
>>> >> > > somebody please review.
>>> >> > >
>>> >> > > http://apache-ignite-users.70518.x6.nabble.com/Semaphore-
>>> >> > > Stuck-when-no-acquirers-to-assign-permit-td18639.html
>>> >> > >
>>> >> > > https://issues.apache.org/jira/browse/IGNITE-7090
>>> >> > >
>>> >> > > https://github.com/apache/ignite/pull/3138
>>> >> > >
>>> >> > > Thanks,
>>> >> > > Tim
>>> >> > >
>>> >> >
>>> >> 
>>> >> 
>>> >> >>>
>>> >> >>
>>> >> >
>>> >>
>>> >
>>> >
>>>
>>
>>
>

[jira] [Created] (IGNITE-7567) ML example datasets should be moved in resoirce directory

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-7567:
-

 Summary: ML example datasets should be moved in resoirce directory
 Key: IGNITE-7567
 URL: https://issues.apache.org/jira/browse/IGNITE-7567
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Sergey Kozlov
 Fix For: 2.4


{\{org.apache.ignite.examples.ml.knn.classification.KNNClassificationExample}} 
and \{{org.apache.ignite.examples.ml.knn.regression.KNNRegressionExample}} use 
datesets from ../datasets

The data directory has to moved into resource directory 
\{{src/main/java/resources}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ignite pull request #3452: Ignite 2.3.2.b1

[alamar]

GitHub user alamar opened a pull request:

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

Ignite 2.3.2.b1



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

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

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

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


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

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

Signed-off-by: nikolay_tikhonov 

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

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

(cherry picked from commit 8ffa109)

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

Merge branch 'ignite-2.3.1' into ignite-2.3.2

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

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

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

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

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

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

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

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

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

Merge branch 'ignite-2.3.1' into ignite-2.3.2

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

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

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

This closes #2864

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

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

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

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

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

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

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

Merge branch 'ignite-2.3.1' into ignite-2.3.2

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

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

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

IGNITE-6627 .NET: Fix repeated known metadata updates

This closes #2876

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

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

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

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

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

Merge branch 'ignite-2.3.1' into ignite-2.3.2

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

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

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

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

IGNITE-6362 NPE in Log4J2Logger

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

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

commit 1e56de86525a79c895eba2d839b7887b61979b07
Author: Denis Mekhanikov 
Date

[GitHub] ignite pull request #3451: Service reassign with merge exchanges (TC run).

[xtern]

GitHub user xtern opened a pull request:

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

Service reassign with merge exchanges (TC run).



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

$ git pull https://github.com/xtern/ignite IGNITE-7366

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

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


commit f81f7e4c94450360add30d49c83aabaa98c8c551
Author: pereslegin-pa 
Date:   2018-01-25T15:49:56Z

IGNITE-7366 Fixed ready topology await on merge exchanges.




---

Re: .NET development on Linux & macOS is now possible

[Pavel Tupitsyn]

Yakov, thanks for trying this out.
Good point about build script, I've filed a ticket:
https://issues.apache.org/jira/browse/IGNITE-7566

As for tests - yes, these two seem to be flaky on TC as well, I'll have a
look.

Pavel

On Tue, Jan 30, 2018 at 8:34 AM, Yakov Zhdanov  wrote:

> Pavel,
>
> I tried this out recently and had few minor issues.
>
> 1. due to path issues mvn executable was not found, but process coninued to
> .net build
> 2. after I set path for mvn it still was failing due to incorrect java home
>
> Should we report maven build issues and stop the overall process with
> appropriate error message?
>
> Also 2 tests failed for me:
>
> Failed   TestClientDisposeWhileOperationsAreInProgress
> Error Message:
>Some tasks should have failed.
>   Expected: True
>   But was:  False
>
> Stack Trace:
>at
> Apache.Ignite.Core.Tests.Client.ClientConnectionTest.
> TestClientDisposeWhileOperationsAreInProgress()
> in
> /home/yzhdanov/projects/incubator-ignite/modules/platforms/dotnet/Apache.
> Ignite.Core.Tests/Client/ClientConnectionTest.cs:line
> 277
>
> Failed   TestAsyncCompletionOrder
> Error Message:
>Expected: False
>   But was:  True
>
> Stack Trace:
>at
> Apache.Ignite.Core.Tests.Client.Cache.CacheTest.TestAsyncCompletionOrder()
> in
> /home/yzhdanov/projects/incubator-ignite/modules/platforms/dotnet/Apache.
> Ignite.Core.Tests/Client/Cache/CacheTest.cs:line
> 855
>
> If you need logs just let me know.
>
> --Yakov
>

[jira] [Created] (IGNITE-7566) .NET: Build scripts: stop build when one of the steps fails

[Pavel Tupitsyn (JIRA)]

Pavel Tupitsyn created IGNITE-7566:
--

 Summary: .NET: Build scripts: stop build when one of the steps 
fails
 Key: IGNITE-7566
 URL: https://issues.apache.org/jira/browse/IGNITE-7566
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.4
Reporter: Pavel Tupitsyn
 Fix For: 2.5


We have multiple build scripts for various platforms:
* {{build.bat}} / {{build.ps1}} (Windows)
* {{build.sh}} (.NET Core Linux / macOS)
* {{build-mono.sh}} (Mono Linux / macOS)

Make sure that we stop build scripts execution when one of the steps fails.
For example, if Java build fails, we should show an error and stop instead of 
continuing to build .NET.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)