[jira] [Created] (IGNITE-8306) Web console: grid UI regression

2018-04-17 Thread Ilya Borisov (JIRA)
Ilya Borisov created IGNITE-8306:


 Summary: Web console: grid UI regression
 Key: IGNITE-8306
 URL: https://issues.apache.org/jira/browse/IGNITE-8306
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Ilya Borisov
Assignee: Dmitriy Shabalin
 Attachments: image-2018-04-18-12-23-44-129.png, 
image-2018-04-18-12-24-20-991.png

*How to reproduce:*
1. Go to admin panel.
2. Click on "all" in columns dropdown twice to hide all columns.
3. Enable "Last login" column.

*What happens:*
Column headers of "User" and "Last login" have different height, the rows are 
misaligned.
 !image-2018-04-18-12-23-44-129.png! 

*What should happen:*
Column headers should have the same height, rows should not become offset 
relative to other columns.
 !image-2018-04-18-12-24-20-991.png! 



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


Re: Docker deployment with EXTERNAL_LIBS environment variable

2018-04-17 Thread Roman Shtykh
I had the same problem (pretty common not having -i option) and fixed it. Need 
a review.https://issues.apache.org/jira/browse/IGNITE-8143
-- Roman
 

On Tuesday, April 17, 2018, 7:15:25 p.m. GMT+9, Petr Ivanov 
 wrote:  
 
 Hi, Kseniya.


I guess that something wrong with wget in distribution (alpine-linux). I will 
need some testing to investigate further.



> On 17 Apr 2018, at 13:02, Ksenia Vazhdaeva  wrote:
> 
> Hello,
> 
> I am trying to deploy Apache Ignite 2.4.0 in docker using external libs as
> described at https://apacheignite.readme.io/docs/docker-deployment
> 
> /docker run -d --name ignite -v
> /storage/ignite/ignite-server-config.xml:/etc/ignite/ignite-server-config.xml
> \
>    -e "CONFIG_URI=file:///etc/ignite/ignite-server-config.xml" -p
> 47500:47500 \
>    -e
> "EXTERNAL_LIBS=http://central.maven.org/maven2/org/apache/ignite/ignite-schedule/1.0.0/ignite-schedule-1.0.0.jar;
> \
>    apacheignite/ignite:2.4.0/
> 
> Docker container is started but in docker logs there is an error
> 
> /wget: unrecognized option: i
> BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary.
> 
> Usage: wget [-c|--continue] [--spider] [-q|--quiet] [-O|--output-document
> FILE]
>     [--header 'header: value'] [-Y|--proxy on/off] [-P DIR]
>     [-S|--server-response] [-U|--user-agent AGENT] [-T SEC] URL.../
> 
> Thus the external lib is not loaded.
> Could you, please, help me to resolve the problem or provide me with another
> way to add external libraries to Ignite classpath?
> 
> Thanks in advance,
> Ksenia
> 
> 
> 
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
  

[GitHub] ignite pull request #3860: IGNITE-7993 Striped pool can't be disabled

2018-04-17 Thread gromtech
GitHub user gromtech opened a pull request:

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

IGNITE-7993 Striped pool can't be disabled

Added an option to disable Striped Pool and use IgniteThreadPoolExecutor 
instead.

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

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

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

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


commit d869cea40d7f3aa289459647f833819c721d8e39
Author: Roman Guseinov 
Date:   2018-03-20T08:29:40Z

IGNITE-7993 Striped pool can't be disabled

* Renamed StripedExecutor to StripedExecutorImpl
* Added StripedExecutor interface
* Added StripedExecutorProxy (extends IgniteThreadPoolExecutor impl 
StripedExecutor)
* Added performance optimization suggestion
* Added StripedExecutorProxyTest




---


Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

2018-04-17 Thread Denis Magda
Dmitriy,

We don't want to disable the baseline topology for the scenario discussed
here. The goal is to make it more flexible by triggering the rebalancing in
some circumstances.

As for the SAFE or AGGRESSIVE policies, haven't seen the discussion on the
dev. So, not sure what it's intended for (use case, scenario, behavior).

--
Denis

On Tue, Apr 17, 2018 at 11:55 AM, Dmitriy Setrakyan 
wrote:

> On Tue, Apr 17, 2018 at 10:47 AM, Denis Magda  wrote:
>
> > Thanks, Pavel!
> >
> > Alexey, Ivan, could you check that there are no any pitfalls in the
> example
> > and it can be used as a template for our users?
> > https://issues.apache.org/jira/secure/attachment/
> > 12919452/BaselineWatcher.java
>
>
> Denis, I think the proper fix is to add ability to the product to disable
> BLT (baseline topology). I remember seeing a discussion in have SAFE and
> AGGRESSIVE (of SAFE and NONE) policies for BLT. Do we have a ticket for it?
>
> D.
>


[jira] [Created] (IGNITE-8305) Update metrics page with new storage and memory related metics

2018-04-17 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-8305:
---

 Summary: Update metrics page with new storage and memory related 
metics
 Key: IGNITE-8305
 URL: https://issues.apache.org/jira/browse/IGNITE-8305
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Prachi Garg
 Fix For: 2.5


The new metrics are added by the endeavor: 
https://issues.apache.org/jira/browse/IGNITE-8078



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


[jira] [Created] (IGNITE-8304) Document failures handing in Ignite

2018-04-17 Thread Denis Magda (JIRA)
Denis Magda created IGNITE-8304:
---

 Summary: Document failures handing in Ignite
 Key: IGNITE-8304
 URL: https://issues.apache.org/jira/browse/IGNITE-8304
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Denis Magda
Assignee: Andrey Gura
 Fix For: 2.5


IEP-14: 
https://cwiki.apache.org/confluence/display/IGNITE/IEP-14+Ignite+failures+handling

The following failures will be treated as critical and can lead to an automatic 
node termination depending on configuration:
* System critical errors (e.g. OutOfMemoryError);
* Unintentional system worker termination (e.g. due to an unhandled exception);
* Cluster node segmentation.



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


RE: [jira] [Created] (IGNITE-8279) Clients can't operate on services after deactivation

2018-04-17 Thread Raymond Wilson
Thanks for the extra detail Denis. I agree, it is not critical for 2.5 given
the workaround you describe.

-Original Message-
From: Denis Mekhanikov [mailto:dmekhani...@gmail.com]
Sent: Wednesday, April 18, 2018 6:44 AM
To: dev@ignite.apache.org
Subject: Re: [jira] [Created] (IGNITE-8279) Clients can't operate on
services after deactivation

Raymond,

The issue here is that client connections lose subscriptions to events,
related to service deployment.
So, clients can deploy services to other nodes, but they don't return
execution from *IgniteServices#deploy* *methods.

The workaround here is to restart clients, that were present in the cluster
during deactivation.

We've been having this issue since activation feature was introduced. This
is not some recent regression. Nobody complained about it, so I don't think
it's critical.
It will be fixed in 2.6, since patches are already not accepted into 2.5

Denis

вт, 17 апр. 2018 г. в 15:52, Dmitry Pavlov :

> Hi Raymond,
>
> I thought 2.5 is already freezed.
> Several days remained to release (vote), so it is not likely this
> issue can be done.
>
> Probably Denis M. or Andrey G. could correct me if I'm wrong.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 16 апр. 2018 г. в 21:52, Raymond Wilson :
>
> > Hi Denis,
> >
> > Would this be better to target 2.5? It seems like a significant
> > regression...
> >
> > Thanks,
> > Raymond.
> >
> > Sent from my iPhone
> >
> > > On 17/04/2018, at 1:46 AM, Denis Mekhanikov (JIRA)
> > > 
> > wrote:
> > >
> > > Denis Mekhanikov created IGNITE-8279:
> > > 
> > >
> > > Summary: Clients can't operate on services after
> deactivation
> > > Key: IGNITE-8279
> > > URL: https://issues.apache.org/jira/browse/IGNITE-8279
> > > Project: Ignite
> > >  Issue Type: Bug
> > >Affects Versions: 2.4
> > >Reporter: Denis Mekhanikov
> > >Assignee: Denis Mekhanikov
> > > Fix For: 2.6
> > > Attachments: ServiceDeploymentAfterDeactivationTest.java
> > >
> > > When this cluster gets deactivated and activated back again,
> > > clients
> > become incapable of service deployment. Calls to
> {{IgniteService.deploy*}}
> > methods hang indefinitely, and no services are getting deployed to
> > these clients.
> > >
> > > After deactivation, {{ServiceEntriesListener}} stops being invoked
> > > in
> > service cache changes.
> > >
> > > Find attached test, reproducing this problem.
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v7.6.3#76005)
> >
>


Re: [GitHub] ignite pull request #3719: IGNITE-8048 merge query entities for dynamic cach...

2018-04-17 Thread Manu
Hi! 

I have taken a look at this new functionality and it is very interesting.
But I have a couple of doubts about the performance.

For each modification of the same QueryEntitity, a new
SchemaAbstractOperation is generated, in the case of adding columns the
performance is not affected, but in the case of creating new indexes I think
there is a problem:

- If the modification in the QueryEntitity contains the creation of N
indexes, N SchemaIndexCreateOperation are generated for the same table, this
causes the underline cache to be scanned N times to populate each indice (by
SchemaIndexCacheVisitorClosure). For caches with a few data is not a
problem, but for caches with millions of records is not optimal.

A possible solution would be to create a new type of SchemaAbstractOperation
(for example SchemaUpgradeQueryEntityOperation with the new QueryEntity,
boolean forceRebuild, boolean forceMutateQueryEntity), to register on one
block this new QueryEntitity for:

- Create new indices at same time (populate all indices with a single scan)
(auto, like now)
- With on demand forceMutateQueryEntity (ignore QueryEntity patch checks),
ability to eliminate indices (and fully release resources) and columns. Over
time the QueryEntity will evolve and at some point it is possible that
certain columns and indices are not necessary any more... I think it would
be interesting to allow trim indexed data and eliminate unused columns.

Hope it helps!

Regards




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


Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

2018-04-17 Thread Dmitriy Setrakyan
On Tue, Apr 17, 2018 at 10:47 AM, Denis Magda  wrote:

> Thanks, Pavel!
>
> Alexey, Ivan, could you check that there are no any pitfalls in the example
> and it can be used as a template for our users?
> https://issues.apache.org/jira/secure/attachment/
> 12919452/BaselineWatcher.java


Denis, I think the proper fix is to add ability to the product to disable
BLT (baseline topology). I remember seeing a discussion in have SAFE and
AGGRESSIVE (of SAFE and NONE) policies for BLT. Do we have a ticket for it?

D.


Re: [jira] [Created] (IGNITE-8279) Clients can't operate on services after deactivation

2018-04-17 Thread Denis Mekhanikov
Raymond,

The issue here is that client connections lose subscriptions to events,
related to service deployment.
So, clients can deploy services to other nodes, but they don't return
execution from *IgniteServices#deploy* *methods.

The workaround here is to restart clients, that were present in the cluster
during deactivation.

We've been having this issue since activation feature was introduced. This
is not some recent regression. Nobody complained about it, so I don't think
it's critical.
It will be fixed in 2.6, since patches are already not accepted into 2.5

Denis

вт, 17 апр. 2018 г. в 15:52, Dmitry Pavlov :

> Hi Raymond,
>
> I thought 2.5 is already freezed.
> Several days remained to release (vote), so it is not likely this issue can
> be done.
>
> Probably Denis M. or Andrey G. could correct me if I'm wrong.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 16 апр. 2018 г. в 21:52, Raymond Wilson :
>
> > Hi Denis,
> >
> > Would this be better to target 2.5? It seems like a significant
> > regression...
> >
> > Thanks,
> > Raymond.
> >
> > Sent from my iPhone
> >
> > > On 17/04/2018, at 1:46 AM, Denis Mekhanikov (JIRA) 
> > wrote:
> > >
> > > Denis Mekhanikov created IGNITE-8279:
> > > 
> > >
> > > Summary: Clients can't operate on services after
> deactivation
> > > Key: IGNITE-8279
> > > URL: https://issues.apache.org/jira/browse/IGNITE-8279
> > > Project: Ignite
> > >  Issue Type: Bug
> > >Affects Versions: 2.4
> > >Reporter: Denis Mekhanikov
> > >Assignee: Denis Mekhanikov
> > > Fix For: 2.6
> > > Attachments: ServiceDeploymentAfterDeactivationTest.java
> > >
> > > When this cluster gets deactivated and activated back again, clients
> > become incapable of service deployment. Calls to
> {{IgniteService.deploy*}}
> > methods hang indefinitely, and no services are getting deployed to these
> > clients.
> > >
> > > After deactivation, {{ServiceEntriesListener}} stops being invoked in
> > service cache changes.
> > >
> > > Find attached test, reproducing this problem.
> > >
> > >
> > >
> > > --
> > > This message was sent by Atlassian JIRA
> > > (v7.6.3#76005)
> >
>


[GitHub] ignite pull request #3856: IGNITE-8301: remove unnecessary check

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[jira] [Created] (IGNITE-8303) Node could be stopped due to a valid termination of exchange worker

2018-04-17 Thread Andrey Gura (JIRA)
Andrey Gura created IGNITE-8303:
---

 Summary: Node could be stopped due to a valid termination of 
exchange worker
 Key: IGNITE-8303
 URL: https://issues.apache.org/jira/browse/IGNITE-8303
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Gura
Assignee: Andrey Kuznetsov
 Fix For: 2.5


Node could be stopped due to a valid termination of exchange worker. See 
handling of {{IgniteClientDisconnectedCheckedException}} and 
{{IgniteNeedReconnectException}} exceptions where {{return}} statement is valid 
in case of client node reconnection.




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


Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

2018-04-17 Thread Denis Magda
Thanks, Pavel!

Alexey, Ivan, could you check that there are no any pitfalls in the example
and it can be used as a template for our users?
https://issues.apache.org/jira/secure/attachment/12919452/BaselineWatcher.java

--
Denis

On Tue, Apr 17, 2018 at 10:40 AM, Pavel Kovalenko 
wrote:

> Denis,
>
> I've attached example how to manage baseline automatically (It's named
> BaselineWatcher). It's just an concept and doesn't cover all possible
> cases, but might be good for a start.
>
> 2018-04-13 2:14 GMT+03:00 Denis Magda :
>
> > Pavel, thanks for the suggestions. They would definitely work out. I
> would
> > document the one with the event subscription:
> > https://issues.apache.org/jira/browse/IGNITE-8241
> >
> > Could you help preparing a sample code snippet with such a listener that
> > will be added to the doc? I know that there are some caveats related to
> the
> > way how such an event has to be processed.
> >
> > Ivan, truly like your idea. Alex G., what's your thought on this?
> >
> > --
> > Denis
> >
> > On Thu, Apr 12, 2018 at 2:22 PM, Ivan Rakov 
> wrote:
> >
> > > Guys,
> > >
> > > I also heard complaints about absence of option to automatically change
> > > baseline topology. They absolutely make sense.
> > > What Pavel suggested will work as a workaround. I think, in future
> > > releases we should give user an option to enable a similar behavior via
> > > Ignite Configuration.
> > > It may be called "Baseline Topology change policy". I see it as
> > rule-based
> > > language, which allows to specify conditions of BLT change using
> several
> > > parameters - timeout and minimum allowed number of partition copies
> left
> > > (maybe this option should be provided also on per-cache-group level).
> > > Policy can also specify conditions for including new nodes in BLT if
> they
> > > are present - including node attributes filters and so on.
> > >
> > > What do you think?
> > >
> > > Best Regards,
> > > Ivan Rakov
> > >
> > >
> > > On 12.04.2018 19:41, Pavel Kovalenko wrote:
> > >
> > >> Denis,
> > >>
> > >> It's just one of the ways to implement it. We also can subscribe on
> node
> > >> join / fail events to properly track downtime of a node.
> > >>
> > >> 2018-04-12 19:38 GMT+03:00 Pavel Kovalenko :
> > >>
> > >> Denis,
> > >>>
> > >>> Using our API we can implement this task as follows:
> > >>> Do each minute:
> > >>> 1) Get all alive server nodes consistent ids =>
> > >>> ignite().context().discovery().aliveServerNodes() =>
> > >>> mapToConsistentIds().
> > >>> 2) Get current baseline topology => ignite().cluster().
> > >>> currentBaselineTopology()
> > >>> 3) For each node in baseline and not in alive server nodes check
> > timeout
> > >>> for this node.
> > >>> 4) If timeout is reached remove node from baseline
> > >>> 5) If baseline is changed set new baseline => ignite().cluster().
> > >>> setNewBaseline()
> > >>>
> > >>>
> > >>> 2018-04-12 2:18 GMT+03:00 Denis Magda :
> > >>>
> > >>> Pavel, Val,
> > 
> >  So, it means that the rebalancing will be initiated only after an
> >  administrator remove the failed node from the topology, right?
> > 
> >  Next, imagine that you are that IT administrator who has to automate
> > the
> >  rebalancing activation if the node failed and not recovered within 1
> >  minute. What would you do and what Ignite provides to fulfill the
> > task?
> > 
> >  --
> >  Denis
> > 
> >  On Wed, Apr 11, 2018 at 1:01 PM, Pavel Kovalenko <
> jokse...@gmail.com>
> >  wrote:
> > 
> >  Denis,
> > >
> > > In case of incomplete baseline topology IgniteCache.rebalance()
> will
> > do
> > > nothing, because this event doesn't trigger partitions exchange or
> > >
> >  affinity
> > 
> > > change, so states of existing partitions are hold.
> > >
> > > 2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
> > > valentin.kuliche...@gmail.com>:
> > >
> > > Denis,
> > >>
> > >> In my understanding, in this case you should remove node from BLT
> > and
> > >>
> > > that
> > >
> > >> will trigger the rebalancing, no?
> > >>
> > >> -Val
> > >>
> > >> On Wed, Apr 11, 2018 at 12:23 PM, Denis Magda <
> dma...@gridgain.com>
> > >>
> > > wrote:
> > >
> > >> Igniters,
> > >>>
> > >>> As we know the rebalancing doesn't happen if one of the nodes
> goes
> > >>>
> > >> down,
> > >
> > >> thus, shrinking the baseline topology. It complies with our
> > >>>
> > >> assumption
> > 
> > > that
> > >>
> > >>> the node should be recovered soon and there is no need to waste
> > >>> CPU/memory/networking resources of the cluster shifting the data
> > >>>
> > >> around.
> > >
> > >> However, there are always edge cases. I was reasonably asked how
> to
> > >>>
> > >> trigger

Re: Triggering rebalancing on timeout or manually if the baseline topology is not reassembled

2018-04-17 Thread Pavel Kovalenko
Denis,

I've attached example how to manage baseline automatically (It's named
BaselineWatcher). It's just an concept and doesn't cover all possible
cases, but might be good for a start.

2018-04-13 2:14 GMT+03:00 Denis Magda :

> Pavel, thanks for the suggestions. They would definitely work out. I would
> document the one with the event subscription:
> https://issues.apache.org/jira/browse/IGNITE-8241
>
> Could you help preparing a sample code snippet with such a listener that
> will be added to the doc? I know that there are some caveats related to the
> way how such an event has to be processed.
>
> Ivan, truly like your idea. Alex G., what's your thought on this?
>
> --
> Denis
>
> On Thu, Apr 12, 2018 at 2:22 PM, Ivan Rakov  wrote:
>
> > Guys,
> >
> > I also heard complaints about absence of option to automatically change
> > baseline topology. They absolutely make sense.
> > What Pavel suggested will work as a workaround. I think, in future
> > releases we should give user an option to enable a similar behavior via
> > Ignite Configuration.
> > It may be called "Baseline Topology change policy". I see it as
> rule-based
> > language, which allows to specify conditions of BLT change using several
> > parameters - timeout and minimum allowed number of partition copies left
> > (maybe this option should be provided also on per-cache-group level).
> > Policy can also specify conditions for including new nodes in BLT if they
> > are present - including node attributes filters and so on.
> >
> > What do you think?
> >
> > Best Regards,
> > Ivan Rakov
> >
> >
> > On 12.04.2018 19:41, Pavel Kovalenko wrote:
> >
> >> Denis,
> >>
> >> It's just one of the ways to implement it. We also can subscribe on node
> >> join / fail events to properly track downtime of a node.
> >>
> >> 2018-04-12 19:38 GMT+03:00 Pavel Kovalenko :
> >>
> >> Denis,
> >>>
> >>> Using our API we can implement this task as follows:
> >>> Do each minute:
> >>> 1) Get all alive server nodes consistent ids =>
> >>> ignite().context().discovery().aliveServerNodes() =>
> >>> mapToConsistentIds().
> >>> 2) Get current baseline topology => ignite().cluster().
> >>> currentBaselineTopology()
> >>> 3) For each node in baseline and not in alive server nodes check
> timeout
> >>> for this node.
> >>> 4) If timeout is reached remove node from baseline
> >>> 5) If baseline is changed set new baseline => ignite().cluster().
> >>> setNewBaseline()
> >>>
> >>>
> >>> 2018-04-12 2:18 GMT+03:00 Denis Magda :
> >>>
> >>> Pavel, Val,
> 
>  So, it means that the rebalancing will be initiated only after an
>  administrator remove the failed node from the topology, right?
> 
>  Next, imagine that you are that IT administrator who has to automate
> the
>  rebalancing activation if the node failed and not recovered within 1
>  minute. What would you do and what Ignite provides to fulfill the
> task?
> 
>  --
>  Denis
> 
>  On Wed, Apr 11, 2018 at 1:01 PM, Pavel Kovalenko 
>  wrote:
> 
>  Denis,
> >
> > In case of incomplete baseline topology IgniteCache.rebalance() will
> do
> > nothing, because this event doesn't trigger partitions exchange or
> >
>  affinity
> 
> > change, so states of existing partitions are hold.
> >
> > 2018-04-11 22:27 GMT+03:00 Valentin Kulichenko <
> > valentin.kuliche...@gmail.com>:
> >
> > Denis,
> >>
> >> In my understanding, in this case you should remove node from BLT
> and
> >>
> > that
> >
> >> will trigger the rebalancing, no?
> >>
> >> -Val
> >>
> >> On Wed, Apr 11, 2018 at 12:23 PM, Denis Magda 
> >>
> > wrote:
> >
> >> Igniters,
> >>>
> >>> As we know the rebalancing doesn't happen if one of the nodes goes
> >>>
> >> down,
> >
> >> thus, shrinking the baseline topology. It complies with our
> >>>
> >> assumption
> 
> > that
> >>
> >>> the node should be recovered soon and there is no need to waste
> >>> CPU/memory/networking resources of the cluster shifting the data
> >>>
> >> around.
> >
> >> However, there are always edge cases. I was reasonably asked how to
> >>>
> >> trigger
> >>
> >>> the rebalancing within the baseline topology manually or on timeout
> >>>
> >> if:
> 
> > - It's not expected that the failed node would be resurrected in
> >>>
> >> the
> 
> > nearest time and
> >>> - It's not likely that that node will be replaced by the other
> >>>
> >> one.
> 
> > The question. If I call IgniteCache.rebalance() or configure
> >>> CacheConfiguration.rebalanceTimeout will the rebalancing be fired
> >>>
> >> within
> >
> >> the baseline topology?
> >>>
> >>> --
> >>> 

[GitHub] ignite pull request #3859: IGNITE-7909 - Java code example.

2018-04-17 Thread VeryFatBoy
GitHub user VeryFatBoy opened a pull request:

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

IGNITE-7909 - Java code example.

Java version of IgniteDataFrameWriteExample.scala

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

$ git pull https://github.com/VeryFatBoy/ignite VeryFatBoy-patch-3

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

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


commit 8306e87058e12eb192322c01ee5b8295237372fd
Author: VeryFatBoy 
Date:   2018-04-17T17:36:58Z

IGNITE-7909 - Java code example.




---


[GitHub] ignite pull request #3858: IGNITE-7909 - Java code example.

2018-04-17 Thread VeryFatBoy
GitHub user VeryFatBoy opened a pull request:

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

IGNITE-7909 - Java code example.

Java version of IgniteDataFrameExample.scala

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

$ git pull https://github.com/VeryFatBoy/ignite VeryFatBoy-patch-2

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

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


commit 52026e922b670289d928a2b711f3c53e0ea23a2a
Author: VeryFatBoy 
Date:   2018-04-17T17:33:41Z

IGNITE-7909 - Java code example.




---


[GitHub] ignite pull request #3857: IGNITE-7909 - Java code example.

2018-04-17 Thread VeryFatBoy
GitHub user VeryFatBoy opened a pull request:

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

IGNITE-7909 - Java code example.

Java version of IgniteCatalogExample.scala

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

$ git pull https://github.com/VeryFatBoy/ignite VeryFatBoy-patch-1

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

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


commit 7582c341c9ce6dad60fc486a137075a7f3269a97
Author: VeryFatBoy 
Date:   2018-04-17T17:28:35Z

IGNITE-7909 - Java code example.




---


[jira] [Created] (IGNITE-8302) PDS Direct IO flaky failure by timeout: 10% testPageRecoveryAfterFileCorruption

2018-04-17 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-8302:
--

 Summary: PDS Direct IO flaky failure by timeout: 10% 
testPageRecoveryAfterFileCorruption 
 Key: IGNITE-8302
 URL: https://issues.apache.org/jira/browse/IGNITE-8302
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


Direct IO test history

[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-136031826311252=testDetails]

   [PDS (Direct IO) 
[2]|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo2=%3Cdefault%3E=buildTypeStatusDiv]
 [ tests 2  failed in build 
[https://ci.ignite.apache.org/viewLog.html?buildId=1217180]]  
   IgnitePdsNativeIoTestSuite2: 
IgnitePdsRecoveryAfterFileCorruptionTest.testPageRecoveryAfterFileCorruption[ 
(master fail rate 
10,4%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-136031826311252=%3Cdefault%3E=testDetails]
 

 

Non direct IO test probably uses page cache and runs faster

[https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-4950157166855933524=testDetails]

 

We need to increase timeout or reduce tested pages count or remove test from 
Direct IO suite at all.



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


[GitHub] ignite pull request #3856: IGNITE-8301: remove unnecessary check

2018-04-17 Thread Mmuzaf
GitHub user Mmuzaf opened a pull request:

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

IGNITE-8301: remove unnecessary check



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

$ git pull https://github.com/Mmuzaf/ignite ignite-8301

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

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


commit 9397192c12080f6d5a17800dc788cd162f4345ab
Author: Maxim Muzafarov 
Date:   2018-04-17T17:05:10Z

IGNITE-8301: remove unnecessary check




---


[jira] [Created] (IGNITE-8301) testReconnectCacheDestroyedAndCreated should excpect recreated client cache

2018-04-17 Thread Maxim Muzafarov (JIRA)
Maxim Muzafarov created IGNITE-8301:
---

 Summary: testReconnectCacheDestroyedAndCreated should excpect 
recreated client cache
 Key: IGNITE-8301
 URL: https://issues.apache.org/jira/browse/IGNITE-8301
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
 Fix For: 2.6


Due to changes IGNITE-2766 have merged, client cache recreates after node 
reconnects.

This check became unnecessary for 
{{IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated}} and 
should be removed.
{code:java}
GridTestUtils.assertThrows(log, new Callable() {
@Override public Object call() throws Exception {
return clientCache.get(1);
}
}, IllegalStateException.class, null);
{code}
Currently we have exception:
{code:java}
java.lang.AssertionError: Exception has not been thrown.
at 
org.apache.ignite.testframework.GridTestUtils.assertThrows(GridTestUtils.java:328)
at 
org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated(IgniteClientReconnectCacheTest.java:897)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2080)
at 
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:140)
at 
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:1995)
at java.lang.Thread.run(Thread.java:748)
{code}



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


[GitHub] ignite pull request #3811: IGNITE-8166 PME hangs when error occurs during ch...

2018-04-17 Thread alex-plekhanov
Github user alex-plekhanov closed the pull request at:

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


---


[GitHub] ignite pull request #3853: IGNITE-2766 Fix .net test.

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #3713: IGNITE-8033 Flaky failure of TxOptimisticDeadlock...

2018-04-17 Thread alex-plekhanov
Github user alex-plekhanov closed the pull request at:

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


---


Re: [TEST ERROR] org.apache.spark.sql.AnalysisException: Path does not exist

2018-04-17 Thread Dmitry Pavlov
Hi Nikolay,

Could you please step in?

Sincerely,
Dmitriy Pavlov

вт, 17 апр. 2018 г. в 18:19, Akmal Chaudhri :

> I am running the Spark DataFrame tests on Java code locally.
>
> One test is failing because of a path issue. In the Java code is the line:
>
> *//Load content of json file to data frame.*
> *Dataset personsDataFrame =
> spark.read().json("examples/src/main/resources/person.json");*
>
> which works perfectly when the Java code is run.
>
> However, if running the test, it cannot find the *person.json* file using
> the above path. If I modify the path to:
>
>
> *"../examples/src/main/resources/person.json"*
>
> then it works fine. However, then the Java code fails.
>
> I have searched on SO and Google and other people have reported similar
> issues with Spark.
>
> Is there any easy fix so that both the Java code and the test are happy?
>
> Thank you.
>


Re: Make TC Green in OSGI: IgniteKarafFeaturesInstallationTest

2018-04-17 Thread Dmitry Pavlov
Hi,

I've created one more issue for 2nd test (
https://issues.apache.org/jira/browse/IGNITE-8300) and removed OSGI from
RunAll chain.

Both tickets now include links to TC where OSGI can be retrurned to RunAll
once it is fixed.

Sincerely,
Dmitriy Pavlov

пт, 13 апр. 2018 г. в 22:16, Raúl Kripalani :

> Hey Dmitry,
>
> Loving the name of the endeavour [make TC green again] ;-)
> Feel free to do that for now. I'll take a look as soon as I have some
> spare cycles.
>
> Cheers!
>
> On Fri, Apr 13, 2018 at 3:24 PM, Dmitry Pavlov 
> wrote:
>
>> Hi Igniters,
>>
>> I've created https://issues.apache.org/jira/browse/IGNITE-8254 and muted
>> test.
>>
>> Second test in OSGI suite is also flaky, and probably we should remove
>> OSGI build from Run-All at all. What do you think?
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>>
>> вт, 10 апр. 2018 г. в 19:54, Dmitry Pavlov :
>>
>>> Hi Raúl, Igniters,
>>>
>>> Test related to OSGI/Karaf
>>> (IgniteKarafFeaturesInstallationTest.testAllBundlesActiveAndFeaturesInstalled)
>>> is currently failing
>>> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=451522206339372479=%3Cdefault%3E=testDetails
>>> with low success rate.
>>>
>>> Recently Igniters have done 2 fixes for make this test passing (
>>> https://issues.apache.org/jira/browse/IGNITE-7646 ,
>>> https://issues.apache.org/jira/browse/IGNITE-7814 ) but test is failing
>>> anyway.
>>>
>>> Could you please step in and help to make this test green?
>>>
>>> Sincerely,
>>> Dmitriy Pavlov
>>>
>>>
>


Re: Deprecate CacheRebalanceMode.NONE

2018-04-17 Thread Dmitry Pavlov
+1

вт, 17 апр. 2018 г. в 19:14, Pavel Kovalenko :

> +1
> I also agree to remove this option in 3.0
>
> 2018-04-17 19:00 GMT+03:00 Yakov Zhdanov :
>
> > +1 here
> >
> > Always wanted to remove ForceKeysRequest =)
> >
> > --Yakov
> >
>


[jira] [Created] (IGNITE-8300) IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked is flaky in master

2018-04-17 Thread Dmitriy Pavlov (JIRA)
Dmitriy Pavlov created IGNITE-8300:
--

 Summary: 
IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked is flaky in master
 Key: IGNITE-8300
 URL: https://issues.apache.org/jira/browse/IGNITE-8300
 Project: Ignite
  Issue Type: Improvement
  Components: osgi
Reporter: Dmitriy Pavlov


OSGi [ tests 1 ]

IgniteOsgiTestSuite: 
IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked (master fail rate 
8,5%)
{noformat}
IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked  
This test looks flaky: 
Frequent test status changes: 18 changes out of 39 invocations
Test status change in build without changes: from failed to successful
View test history »
java.rmi.NotBoundException: 98dec331-52f1-4481-bb5b-5190a52e9dca
{noformat}
Because this issue is test failure issue for second OSGI test from 2 test 
(previous was https://issues.apache.org/jira/browse/IGNITE-8254) OSGI suite is 
removed from RunAll chain.

Both test failures are muted and there is no reason to run this suite until 
this issue or 8254 is fixed



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


Re: Deprecate CacheRebalanceMode.NONE

2018-04-17 Thread Pavel Kovalenko
+1
I also agree to remove this option in 3.0

2018-04-17 19:00 GMT+03:00 Yakov Zhdanov :

> +1 here
>
> Always wanted to remove ForceKeysRequest =)
>
> --Yakov
>


Re: Deprecate CacheRebalanceMode.NONE

2018-04-17 Thread Yakov Zhdanov
+1 here

Always wanted to remove ForceKeysRequest =)

--Yakov


[jira] [Created] (IGNITE-8299) Optimize allocations and CPU consumption in active page replacement scenario

2018-04-17 Thread Ivan Rakov (JIRA)
Ivan Rakov created IGNITE-8299:
--

 Summary: Optimize allocations and CPU consumption in active page 
replacement scenario
 Key: IGNITE-8299
 URL: https://issues.apache.org/jira/browse/IGNITE-8299
 Project: Ignite
  Issue Type: Improvement
Reporter: Ivan Rakov
Assignee: Ivan Rakov


Ignite performance significantly decreases when total size of local data is 
much greater than size of RAM. It can be explained by change of disk access 
pattern (random reads + random writes is complex even for SSDs), but after 
analysis of persistence code and JFRs it's clear that there's still room for 
optimization.
The following possible optimizations should be investigated:
1) PageMemoryImpl.Segment#partGeneration performs allocation of 
GroupPartitionId during HashMap.get - we can get rid of it
2) LoadedPagesMap#getNearestAt is invoked at least 5 times in 
PageMemoryImpl.Segment#removePageForReplacement. It performs two allocations - 
we can get rid of it
3) If one of 5 evict candidates was erroneous, we'll find 5 new ones - we can 
reuse remaining 4 instead



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


[GitHub] ignite pull request #3854: Error while trying to archive wal segment

2018-04-17 Thread zstan
GitHub user zstan opened a pull request:

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

Error while trying to archive wal segment



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

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

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

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


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

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

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578

[TEST ERROR] org.apache.spark.sql.AnalysisException: Path does not exist

2018-04-17 Thread Akmal Chaudhri
I am running the Spark DataFrame tests on Java code locally.

One test is failing because of a path issue. In the Java code is the line:

*//Load content of json file to data frame.*
*Dataset personsDataFrame =
spark.read().json("examples/src/main/resources/person.json");*

which works perfectly when the Java code is run.

However, if running the test, it cannot find the *person.json* file using
the above path. If I modify the path to:


*"../examples/src/main/resources/person.json"*

then it works fine. However, then the Java code fails.

I have searched on SO and Google and other people have reported similar
issues with Spark.

Is there any easy fix so that both the Java code and the test are happy?

Thank you.


[GitHub] ignite pull request #3852: Error while trying to archive wal segment

2018-04-17 Thread zstan
Github user zstan closed the pull request at:

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


---


[GitHub] ignite pull request #3853: IGNITE-2766 Fix .net test.

2018-04-17 Thread alamar
GitHub user alamar opened a pull request:

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

IGNITE-2766 Fix .net test.



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

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

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

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


commit 5fbed1f4e48b9666a983d23ce22c5d51bebede7d
Author: Ilya Kasnacheev 
Date:   2018-04-17T15:09:20Z

IGNITE-2766 Fix .net test.




---


[GitHub] ignite pull request #3697: IGNITE-8021 Delete cache config files when destro...

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #3852: Error while trying to archive wal segment

2018-04-17 Thread zstan
GitHub user zstan opened a pull request:

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

Error while trying to archive wal segment



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

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

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

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


commit e7ca9b65a68de7752195c8f4d2b5180f3c77d19f
Author: Dmitriy Govorukhin 
Date:   2017-11-13T18:52:47Z

ignite-blt-merge -> ignite-2.4.1

commit cc8168fc184bb7f5e3cc3bbb0743397097f78bfb
Author: Dmitriy Govorukhin 
Date:   2017-11-13T19:13:01Z

merge ignite-pitr-rc1 -> ignite-2.4.1

commit 87e6d74cf6a251c7984f9e68c391f790feccc281
Author: Dmitriy Govorukhin 
Date:   2017-11-14T12:49:33Z

ignite-gg-12877 Compact consistent ID in WAL

commit 9f5a22711baea05bd37ab07c8f928a4837dd83a4
Author: Ilya Lantukh 
Date:   2017-11-14T14:12:28Z

Fixed javadoc.

commit d5af2d78dd8eef8eca8ac5391d31d8c779649bb0
Author: Alexey Kuznetsov 
Date:   2017-11-15T08:09:00Z

IGNITE-6913 Baseline: Added new options to controls.sh for baseline 
manipulations.

commit 713924ce865752b6e99b03bd624136541cea5f9f
Author: Sergey Chugunov 
Date:   2017-11-15T09:03:12Z

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

commit b65fd134e748d496f732ec2aa0953a0531f544b8
Author: Ilya Lantukh 
Date:   2017-11-15T12:54:35Z

TX read logging if PITR is enabled.

commit 9b2a567c0e04dc33116b51f88bee75f76e9107d1
Author: Ilya Lantukh 
Date:   2017-11-15T13:45:16Z

TX read logging if PITR is enabled.

commit 993058ccf0b2b8d9e80750c3e45a9ffa31d85dfa
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:51:54Z

ignite-2.4.1 optimization for store full set node more compacted

commit 1eba521f608d39967aec376b397b7fc800234e54
Author: Dmitriy Govorukhin 
Date:   2017-11-15T13:52:22Z

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

commit 564b3fd51f8a7d1d81cb6874df66d0270623049c
Author: Sergey Chugunov 
Date:   2017-11-15T14:00:51Z

IGNITE-5850 fixed issue with initialization of data regions on node 
activation, fixed issue with auto-activation when random node joins inactive 
cluster with existing BLT

commit c6d1fa4da7adfadc80abdc7eaf6452b86a4f6aa4
Author: Sergey Chugunov 
Date:   2017-11-15T16:23:08Z

IGNITE-5850 transitionResult is set earlier when request for changing 
BaselineTopology is sent

commit d65674363163e38a4c5fdd73d1c8d8e1c7610797
Author: Sergey Chugunov 
Date:   2017-11-16T11:59:07Z

IGNITE-5850 new failover tests for changing BaselineTopology up (new node 
added to topology)

commit 20552f3851fe8825191b144179be032965e0b5c6
Author: Sergey Chugunov 
Date:   2017-11-16T12:53:43Z

IGNITE-5850 improved error message when online node is removed from baseline

commit 108bbcae4505ac904a6db774643ad600bfb42c21
Author: Sergey Chugunov 
Date:   2017-11-16T13:45:52Z

IGNITE-5850 BaselineTopology should not change on cluster deactivation

commit deb641ad3bdbf260fa60ad6bf607629652e324bd
Author: Dmitriy Govorukhin 
Date:   2017-11-17T09:45:44Z

ignite-2.4.1 truncate wal and checkpoint history on move/delete snapshot

commit 3c8b06f3659af30d1fd148ccc0f40e216a56c998
Author: Alexey Goncharuk 
Date:   2017-11-17T12:48:12Z

IGNITE-6947 Abandon remap after single map if future is done (fixes NPE)

commit ba2047e5ae7d271a677e0c418375d82d78c4023e
Author: devozerov 
Date:   2017-11-14T12:26:31Z

IGNITE-6901: Fixed assertion during 
IgniteH2Indexing.rebuildIndexesFromHash. This closes #3027.

commit abfc0466d6d61d87255d0fe38cbdf11ad46d4f89
Author: Sergey Chugunov 
Date:   2017-11-17T13:40:57Z

IGNITE-5850 tests for queries in presence of BaselineTopology

commit f4eabaf2a905abacc4c60c01d3ca04f6ca9ec188
Author: Sergey Chugunov 
Date:   2017-11-17T17:23:02Z

IGNITE-5850 implementation for setBaselineTopology(long topVer) migrated 
from wc-251

commit 4edeccd3e0b671aa277f58995df9ff9935baa95a
Author: EdShangGG 
Date:   2017-11-17T18:21:17Z

GG-13074 Multiple snapshot test failures after baseline topology is 
introduced
-adding baseline test to suite
-fixing issues with baseline

commit edae228c8f55990c15ef3044be987dcb00d6c81a
Author: EdShangGG 
Date:   2017-11-18T10:36:41Z

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578

Deprecate CacheRebalanceMode.NONE

2018-04-17 Thread Ilya Lantukh
Igniters,

While working on rebalancing optimizations, I've discovered that we have
very weird logic for CacheRebalanceMode.NONE. In this mode we always keep
partitions in OWNING state even if their data is outdated, breaking our
internal invariants. In this mode every cache.get(...) will lead to sending
ForceKeysRequests to the youngest owner - and it's the only case where
Ignite still needs force keys mechanics. To maintain data consistency in
such mode a user has to ensure that nodes never leave or fail, which is
impossible in real world.

So, I suggest to deprecate CacheRebalanceMode.NONE and remove it in Ignite
3.0 because:
a. It has no real use-case. If a user wants to have control on rebalancing
process, we provide other mechanics: baseline topology and manual
rebalancing (rebalanceDelay == -1).
b. It adds too much complexity to our code and architecture.

Please share your thoughts.

-- 
Best regards,
Ilya


[GitHub] ignite pull request #3851: Ignite 5994

2018-04-17 Thread SharplEr
GitHub user SharplEr opened a pull request:

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

Ignite 5994



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

$ git pull https://github.com/SharplEr/ignite ignite-5994

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

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


commit d01c94b2706775a84862dbdb61f3251d86bfd9ad
Author: Zhang Yuan 
Date:   2017-08-14T03:38:25Z

IGNITE-5994 Implemented.

commit f30f33761320d5f525609817b1c72e9d05f69223
Author: Alexander Menshikov 
Date:   2018-04-17T13:52:16Z

remove unnesesary null checks




---


[GitHub] ignite pull request #3833: IGNITE-8282 Direct IO: support fdatasync, which d...

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #3850: IGNITE-8243 Fixed possible memory leak

2018-04-17 Thread Jokser
GitHub user Jokser opened a pull request:

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

IGNITE-8243 Fixed possible memory leak



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

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

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

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


commit 5d2a9d883ecc031b64f27ebe837cd471321dc677
Author: Pavel Kovalenko 
Date:   2018-04-17T13:20:56Z

IGNITE-8243 Fixed possible memory leak. Added latch manager to diagnostic 
messages.




---


[GitHub] ignite pull request #3849: B+Tree operation may result in an infinite loop i...

2018-04-17 Thread SpiderRus
GitHub user SpiderRus opened a pull request:

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

B+Tree operation may result in an infinite loop in some case



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

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

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

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


commit ee0401d130c3f1bbfd80a25fae50b51fb3f20147
Author: Алексей Стельмак 
Date:   2018-04-17T13:22:35Z

B+Tree operation may result in an infinite loop in some case




---


Re: [jira] [Created] (IGNITE-8279) Clients can't operate on services after deactivation

2018-04-17 Thread Dmitry Pavlov
Hi Raymond,

I thought 2.5 is already freezed.
Several days remained to release (vote), so it is not likely this issue can
be done.

Probably Denis M. or Andrey G. could correct me if I'm wrong.

Sincerely,
Dmitriy Pavlov

пн, 16 апр. 2018 г. в 21:52, Raymond Wilson :

> Hi Denis,
>
> Would this be better to target 2.5? It seems like a significant
> regression...
>
> Thanks,
> Raymond.
>
> Sent from my iPhone
>
> > On 17/04/2018, at 1:46 AM, Denis Mekhanikov (JIRA) 
> wrote:
> >
> > Denis Mekhanikov created IGNITE-8279:
> > 
> >
> > Summary: Clients can't operate on services after deactivation
> > Key: IGNITE-8279
> > URL: https://issues.apache.org/jira/browse/IGNITE-8279
> > Project: Ignite
> >  Issue Type: Bug
> >Affects Versions: 2.4
> >Reporter: Denis Mekhanikov
> >Assignee: Denis Mekhanikov
> > Fix For: 2.6
> > Attachments: ServiceDeploymentAfterDeactivationTest.java
> >
> > When this cluster gets deactivated and activated back again, clients
> become incapable of service deployment. Calls to {{IgniteService.deploy*}}
> methods hang indefinitely, and no services are getting deployed to these
> clients.
> >
> > After deactivation, {{ServiceEntriesListener}} stops being invoked in
> service cache changes.
> >
> > Find attached test, reproducing this problem.
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v7.6.3#76005)
>


[GitHub] ignite pull request #3847: Ignite 2.3.2 p2

2018-04-17 Thread AMashenkov
GitHub user AMashenkov opened a pull request:

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

Ignite 2.3.2 p2

For test purposes.

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

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

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

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


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:   

[GitHub] ignite pull request #3846: Ignite 7778-test

2018-04-17 Thread tledkov-gridgain
GitHub user tledkov-gridgain opened a pull request:

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

Ignite 7778-test



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

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

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

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


commit 806b8cc0928bff85bf25d75ae807483b811d33c3
Author: tledkov-gridgain 
Date:   2018-04-13T13:46:32Z

IGNITE-7778: add test

commit 220aadd7c8309f39c9208fce2b2d291bda0b5891
Author: tledkov-gridgain 
Date:   2018-04-13T16:04:42Z

IGNITE-7778: save the progress

commit 2d718edb1b76cf93441977018344f630577d18b8
Author: Andrey V. Mashenkov 
Date:   2017-12-14T14:32:11Z

WIP.Test added.

commit 73565faee2a3fba5303a6d6dc1eab262fdfa4bbb
Author: Andrey V. Mashenkov 
Date:   2018-04-04T16:13:23Z

Tests added.

commit d82ac7d61a16e74e87d3aa0d0ddfd723dd1b926c
Author: Andrey V. Mashenkov 
Date:   2017-12-15T11:09:38Z

ignite-5874: WIP. Fixed checkpoint lock assertion in entry->onExpired.

commit 3a577243e92828c1530f0b2f9b0484e6bc30b96b
Author: Andrey V. Mashenkov 
Date:   2018-04-04T19:22:40Z

ignite-5874: WIP. Pending tree moved to partition.

commit ffd2c0a2962da0ac682d5e0b64002c501a675109
Author: Andrey V. Mashenkov 
Date:   2018-04-06T16:32:20Z

WIP. Minors.

commit a43e139762a99442e98eb0c57cbfc135fca58a39
Author: AMRepo 
Date:   2018-04-06T20:37:14Z

Tests fixed.

commit aab77079ee3b588afc0a539167b75233b31e29bf
Author: AMRepo 
Date:   2018-04-06T21:22:27Z

Minors

commit 5fddb814951d569d3247a8818806865f774782e5
Author: AMRepo 
Date:   2018-04-06T21:41:03Z

Minors

commit d388e666939530e2e15ddfad70a3a34ee493ef19
Author: Andrey V. Mashenkov 
Date:   2018-04-10T16:27:54Z

WIP. Minor optimization.

commit 5d3b5a48eeb94d7b660ec49d3432554cdbcad5d5
Author: Andrey V. Mashenkov 
Date:   2018-04-10T17:54:50Z

Styles.
Force expiration when non-empty pending tree is recovered from PDS.

commit 6375a12888a8d3e6b34a1eda9150c1a6c579cd8e
Author: Andrey V. Mashenkov 
Date:   2018-04-10T18:34:46Z

Fixed region size in test.

commit d5811349dad9276b6d0d9dc9d851b05d1b3a44e4
Author: Andrey V. Mashenkov 
Date:   2018-04-10T18:42:15Z

Styles. Revert minor unrelated changes.

commit fb892bff1a2d23f9276cbb861648c26ef33bc27a
Author: Andrey V. Mashenkov 
Date:   2018-04-11T11:28:57Z

Revert unrelated assert.

commit 412e8493781a6780f4d10a3b0bceb3a53d531fbd
Author: Andrey V. Mashenkov 
Date:   2018-04-11T15:18:37Z

WIP. Fix non-initialized data store usage.

commit 8437f7200917c8f5a528fb88af04cab2e6a77488
Author: Andrey V. Mashenkov 
Date:   2018-04-11T16:01:32Z

Minors.

commit 88cdac826513230adc7d40609ea0511e78fc69f0
Author: Andrey V. Mashenkov 
Date:   2018-04-11T17:54:57Z

Add partition reservation.

commit c2c4d1b0e9d4a31f2fa0b205ca2ff4b7ed0e1f5e
Author: Andrey V. Mashenkov 
Date:   2018-04-11T18:09:03Z

Add partition reservation.
Fixed javadoc.

commit c82dc75490657b9c8be1c487735f3fcd222ec9b6
Author: Andrey V. Mashenkov 
Date:   2018-04-12T08:11:51Z

Fix topology version.

commit bae7d25439f987317dcf5b4af643b7a70aa406bb
Author: Andrey V. Mashenkov 
Date:   2018-04-12T11:24:42Z

Fix page version upgrade.

commit a6c7cb362de81db3350b23c1a6a6da9715d9810e
Author: Andrey V. Mashenkov 
Date:   2018-04-12T15:34:11Z

Fix PageSnapshot address.

commit b8f6b94638ef96dc4d939d156ada2bbb61ed7411
Author: Andrey V. Mashenkov 
Date:   2018-04-12T15:50:34Z

Fixed javadoc.

commit cc2b682662d50153c3be7967cc0030724f7a7498
Author: Andrey V. Mashenkov 
Date:   2018-04-12T17:14:23Z

Fixed tests.
Fixed styles.

commit 45cf1bf69c2db91b90de4d1e3c282e0238b7477d
Author: Andrey V. Mashenkov 
Date:   2018-04-13T16:56:38Z

Remove partition size validation as with expiry policy partition sizes may 
differ.
Move expire to under busyLock as pendingTree should be updated together 
with dataTree entry.

commit a70fa1c4f8fca25405fe2db81a88e9927797efaf
Author: tledkov-gridgain 
Date:   2018-04-16T11:36:19Z

Merge branch '_master' into ignite-7778

commit 393af03eaaa4e994520535c9cb672191702c9f19
Author: Andrey V. Mashenkov 
Date:   2018-04-16T13:44:40Z

  

[GitHub] ignite pull request #3814: Fixed skipping of affinity calculation in case wh...

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #3845: IGNITE-8078 New metrics for data store

2018-04-17 Thread DmitriyGovorukhin
GitHub user DmitriyGovorukhin opened a pull request:

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

IGNITE-8078 New metrics for data store



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

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

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

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


commit 1814fbb5f62629ee3e5f4c9f4d44e39a1a38e871
Author: Dmitriy Govorukhin 
Date:   2018-04-17T08:32:56Z

IGNITE-8078 wal metrics added

commit 4835a59bf5c04232753e90ed61e95ca358f7528d
Author: Dmitriy Govorukhin 
Date:   2018-04-17T08:35:14Z

IGNITE-8078 FsyncWal fix rollover metrics

commit 9af5217822d30d4d430ef9a20d51893c27a58959
Author: Dmitriy Govorukhin 
Date:   2018-04-17T08:35:55Z

IGNITE-8078 remove reset wal metrics

commit b8ec647bfe28fdef584e8303bc243b98fcf11afa
Author: Dmitriy Govorukhin 
Date:   2018-04-17T09:11:41Z

IGNITE-8078 added pageRead pageWritten and pageReplaced metrics

commit da446efdfe867d06491864de142b96e0cba90312
Author: Dmitriy Govorukhin 
Date:   2018-04-17T10:00:11Z

IGNITE-8078 added offheapSize and offHeapUsedSize

commit 75634fd1cf7cf54b4cc38cf556b9494c1ae049eb
Author: Dmitriy Govorukhin 
Date:   2018-04-17T10:03:09Z

IGNITE-8078 added new method on IgniteMXBean. getCurrentCoordinator

commit ab31657f7863e682f7b5b47c6279a9d589c77498
Author: Dmitriy Govorukhin 
Date:   2018-04-17T10:08:05Z

IGNITE-8078 add methods to CacheGroupMetrics interface, implement 
partitionIndexes and group type

commit ea82b8bd888d978fe20789a5edfff97167a00ce2
Author: Dmitriy Govorukhin 
Date:   2018-04-17T10:29:29Z

IGNITE-8078 fix compilation error




---


[GitHub] ignite pull request #3782: IGNITE-8078

2018-04-17 Thread DmitriyGovorukhin
Github user DmitriyGovorukhin closed the pull request at:

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


---


[jira] [Created] (IGNITE-8297) TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily

2018-04-17 Thread Andrey Kuznetsov (JIRA)
Andrey Kuznetsov created IGNITE-8297:


 Summary: 
TxRollbackOnTimeoutNearCacheTest.testRandomMixedTxConfigurations fails flakily 
 Key: IGNITE-8297
 URL: https://issues.apache.org/jira/browse/IGNITE-8297
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
Assignee: Andrey Kuznetsov
 Fix For: 2.6


Transactions sometimes don't stop on timeout. Speaking more detailed, 
{{GridNearOptimisticTxPrepareFuture}} and 
{{GridNearOptimisticSerializableTxPrepareFuture}} has {{keyLockFut}} field that 
can remain uncompleted after timeout occured.



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


[GitHub] ignite pull request #3844: IGNITE-8266: remove stopAllGrids in afterTestsSto...

2018-04-17 Thread Mmuzaf
GitHub user Mmuzaf opened a pull request:

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

IGNITE-8266: remove stopAllGrids in afterTestsStoped



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

$ git pull https://github.com/Mmuzaf/ignite ignite-8266

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

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


commit 7d39d5b1afbc0d55b9dfeb504a38d1a83a656b7f
Author: Maxim Muzafarov 
Date:   2018-04-17T11:04:06Z

IGNITE-8266: remove stopAllGrids for cache pkg




---


[GitHub] ignite pull request #3843: Ignite 7770 2

2018-04-17 Thread andrey-kuznetsov
GitHub user andrey-kuznetsov opened a pull request:

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

Ignite 7770 2

Includes all reliable fixes found so far. 

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

$ git pull https://github.com/andrey-kuznetsov/ignite ignite-7770-2

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

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


commit 8a46bf807a0c933c9e4d9d2c83c27d03722b6055
Author: Andrey Kuznetsov 
Date:   2018-03-18T17:08:33Z

IGNITE-7770 A bunch of changes to fix tx timeout handling.

commit 6d4361f607b496a6d27657b5c03fea5c9642ba3f
Author: Andrey Kuznetsov 
Date:   2018-03-19T06:23:30Z

IGNITE-7770 Restored TX threadMap cleaning on fast-finish commit.

commit f48c1dff43f67ac989115871c2440122d00a5bde
Author: Andrey Kuznetsov 
Date:   2018-03-19T08:42:06Z

IGNITE-7770: Decremented test launch number in a suite.

commit a06ac6a138683bed977d66f2385339d504821a0e
Author: Andrey Kuznetsov 
Date:   2018-03-19T11:30:40Z

IGNITE-7770: Temporarily removed all tests but one from the suite.

commit 458ab27455a9dd299d07f06396eb803fb1579817
Author: Andrey Kuznetsov 
Date:   2018-03-19T13:48:38Z

IGNITE-7770: Reverted original test suite state.

commit 427469c0e23a9e47f7b549d744a5fc077cfb5dc5
Author: Andrey Kuznetsov 
Date:   2018-03-19T13:51:43Z

IGNITE-7770: One more addition to temporary NPE workaround.

commit d64bcd551024b482170515582b4b4fc00c91490b
Author: Andrey Kuznetsov 
Date:   2018-03-19T15:39:53Z

IGNITE-6186: Fixed optimistic serializable prepare future as well.

commit 84b85e424c2d68309fb782cc51044f8714b60d3e
Author: Andrey Kuznetsov 
Date:   2018-03-20T10:40:37Z

IGNITE-7770 Minor cleanup.

commit 47e3ac8a46df4c264c2285f68fb6bce1460a5702
Author: Andrey Kuznetsov 
Date:   2018-03-27T12:36:04Z

IGNITE-7770: Concurrent timeout handling in prepare/pessimistic.

commit e2d4fccdea0170c1e7d97d3708506aca860a2a5a
Author: Andrey Kuznetsov 
Date:   2018-04-09T10:36:38Z

Merge branch 'master' into ignite-7770-1

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/near/GridNearTxLocal.java

commit 46663218ccda0ebd6c4df1f4b84ffe98e30e7d18
Author: Andrey Kuznetsov 
Date:   2018-04-13T10:33:14Z

IGNITE-7770: No need for NPE bypassing since IGNITE-7983 has been fixed.




---


[GitHub] ignite pull request #3842: IGNITE-8295: Fixed wrong checkpointLock vs partSt...

2018-04-17 Thread AMashenkov
GitHub user AMashenkov opened a pull request:

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

IGNITE-8295: Fixed wrong checkpointLock vs partStoreLock order.



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

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

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

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


commit fb7956b0c4fc9d8b62aac1f831e0c0ef939275da
Author: Andrey V. Mashenkov 
Date:   2018-04-17T10:32:12Z

Fixed wrong checkpointLock vs partStoreLock order.




---


[jira] [Created] (IGNITE-8296) Move Spark Scala code examples to correct directory and prefix with "Scalar" to follow convention used with other Scala examples

2018-04-17 Thread Akmal Chaudhri (JIRA)
Akmal Chaudhri created IGNITE-8296:
--

 Summary: Move Spark Scala code examples to correct directory and 
prefix with "Scalar" to follow convention used with other Scala examples 
 Key: IGNITE-8296
 URL: https://issues.apache.org/jira/browse/IGNITE-8296
 Project: Ignite
  Issue Type: Improvement
  Components: spark
Affects Versions: 2.4
Reporter: Akmal Chaudhri
Assignee: Akmal Chaudhri
 Fix For: 2.5


# The Spark Scala code examples are in the wrong directory. They should be 
moved to the correct directory structure.
 # The Spark Scala code examples should follow the naming convention used for 
other Scala code examples and be prefixed with "Scalar".



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


Re: affinityRun/Call in C++

2018-04-17 Thread Igor Sapego
Hi, Lucas,

Yeah, I know of all these issues as we faced them while we
were implementing compute API in C++. We have decided
to avoid mangling/de-mangling hell and instead ask of user
to manual register classes, so we can find and call propper
methods.

Best Regards,
Igor

On Tue, Apr 17, 2018 at 2:19 AM, Lucas Beeler 
wrote:

> Hi Guys,
>
> Having (very unfortunately) done a boatload of C++ programming while I was
> at university, there are some issues to consider here. One of the biggest
> is compiler name mangling  wiki/Name_mangling#Real-world_effects_of_C++_name_mangling>. Now, I’m
> guessing you’ve heard about this, but it’s a lot nastier than people think
> it is. For example, you can’t link an object built with GCC on Linux to one
> built with LLVM on Linux (though this may be changing with the introduction
> of a “standard” Linux ABI and name mangling scheme, c.f. this Oracle
> TechNet article  storage-dev/stablecplusplusabi-333927.html>). Essentially, C++ object
> code built with different compilers—or even different versions of the same
> compiler—have totally different name mangling schemes and ABIs. So we’d
> need to pick one and stick with it. The Wikipedia article linked-to above
> explains this problem better than I can.
>
> So we’d have to standardize on one compiler ABI, then build the native
> code portions of our C++-to-JVM bridge with that compiler, such that object
> code loaded from the client side during a compute invocation could be
> dynamically linked to our native code interface on the server side, since
> code built with different name mangling schemes and different ABIs can’t be
> linked together. The most obvious choice is the GCC/Linux ABI, since most
> of our users deploy on Linux and GCC comes as the standard compiler suite
> on most distros. What’s more, IIRC, it’s possible to force Visual Studio on
> Windows and LLVM on the Mac to output GCC Linux ABI-compliant code. This
> way, we’d give our users the capability to run unit tests in CppUnit, etc.
> on their development laptops and then have that same compiled object be
> able to work seamlessly when our server side code loads it and links it
> into the server C++ runtime.
>
> Hope that all makes sense. I’m happy to contribute to this effort.
>
> Take care,
> Lucas
>
> --
> Lucas BEELER
> Technical Consultant, Professional Services
> GridGain Systems
> www.gridgain.com
>
> > On Apr 16, 2018, at 9:02 AM, Igor Sapego  wrote:
> >
> > It depends on which functionality is needed, as there are
> > several versions of those methods. Some would require
> > implementing of Cluster API, which is not present in C++ also.
> >
> > Best Regards,
> > Igor
> >
> > On Mon, Apr 16, 2018 at 6:41 PM, Denis Magda  wrote:
> >
> >> Do we target it for 2.6 release? It shouldn't be time-consuming to
> support
> >> it, right?
> >>
> >> --
> >> Denis
> >>
> >> On Mon, Apr 16, 2018 at 2:48 AM, Igor Sapego 
> wrote:
> >>
> >>> Guys,
> >>>
> >>> I've created a ticket: [1]
> >>>
> >>> [1] - https://issues.apache.org/jira/browse/IGNITE-8273
> >>>
> >>> Best Regards,
> >>> Igor
> >>>
> >>> On Wed, Apr 11, 2018 at 2:44 AM, Valentin Kulichenko <
> >>> valentin.kuliche...@gmail.com> wrote:
> >>>
>  Is there a ticket? Let's create one if not.
> 
>  -Val
> 
>  On Tue, Apr 10, 2018 at 6:17 AM, Vladimir Ozerov <
> voze...@gridgain.com
> >>>
>  wrote:
> 
> > Val,
> >
> > They are simply not implemented yet. I am not aware of concrete plans
> >>> to
> > support them.
> >
> > On Mon, Apr 9, 2018 at 11:33 PM, Valentin Kulichenko <
> > valentin.kuliche...@gmail.com> wrote:
> >
> >> Guys,
> >>
> >> Is there a way to run collocated compute job in C++? I can't find
> >> affinityRun and affinityCall method in C++ compute API, am I
> >> missing
> >> something? If we really don't have them, is there any particular
> >>> reason
> > for
> >> this and/or plans to add them?
> >>
> >> -Val
> >>
> >
> 
> >>>
> >>
>
>


[jira] [Created] (IGNITE-8295) Possible deadlock on partition eviction.

2018-04-17 Thread Andrew Mashenkov (JIRA)
Andrew Mashenkov created IGNITE-8295:


 Summary: Possible deadlock on partition eviction.
 Key: IGNITE-8295
 URL: https://issues.apache.org/jira/browse/IGNITE-8295
 Project: Ignite
  Issue Type: Bug
Reporter: Andrew Mashenkov
 Attachments: deadlock.stack

GridCacheOffheapManager.recreateCacheDataStore() calls updatePartitionCounter() 
under partStoreLock which may try to acquire checkpointReadLock.

recreateCacheDataStore() method can be called with checkpointReadLock (on 
GridDhtPartitionsExchangeFuture.updatePartitionFullMap) 
or without checkpointReadLock (GridDhtPartitionEvictor thread calls 
evictPartitionAsync),

So, checkpoint can cause a deadlock if it happens in between.


Seems, we should acquire checkpointReadLock before partStoreLock. 
  



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


[jira] [Created] (IGNITE-8294) Web console: make "Beta" ribbon less obtrusive

2018-04-17 Thread Ilya Borisov (JIRA)
Ilya Borisov created IGNITE-8294:


 Summary: Web console: make "Beta" ribbon less obtrusive
 Key: IGNITE-8294
 URL: https://issues.apache.org/jira/browse/IGNITE-8294
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Borisov
Assignee: Ilya Borisov


As of now, the ribbon obstructs important controls underneath it, especially 
connected clusters user menu. Something has to be done with this issue, but the 
ribbon should remain in some form or another.



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


[GitHub] ignite pull request #3841: IGNITE-8162 Handle ClassNotFoundException during ...

2018-04-17 Thread dgarus
GitHub user dgarus opened a pull request:

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

IGNITE-8162 Handle ClassNotFoundException during deserialization of 
persisted cache configuration



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

$ git pull https://github.com/dgarus/ignite ignite-8162

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

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


commit fd28f4bef77f4e8d4d94290de598f156f60e1e50
Author: denis.garus 
Date:   2018-04-17T09:41:30Z

IGNITE-8162 Show meaningful message with instruction how to overcome 
ClassNotFoundException during deserialization of persisted cache configuration

commit 9b84851a9cbbd89ec1d9e901e83a95afdc67f9e4
Author: denis.garus 
Date:   2018-04-17T09:52:28Z

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




---


[jira] [Created] (IGNITE-8293) BinaryContext#isCustomJavaSerialization fails when only readObject is declared in a class

2018-04-17 Thread MihkelJ (JIRA)
MihkelJ created IGNITE-8293:
---

 Summary: BinaryContext#isCustomJavaSerialization fails when only 
readObject is declared in a class
 Key: IGNITE-8293
 URL: https://issues.apache.org/jira/browse/IGNITE-8293
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.4
Reporter: MihkelJ


Consider this class:

 
{code:java}
public class Test implements Serializable {

private transient AtomicBoolean dirty = new AtomicBoolean(false);

private void readObject(java.io.ObjectInputStream in) throws IOException, 
ClassNotFoundException {
dirty = new AtomicBoolean(false);
}

//methods to check and mark class as dirty
}{code}
{{isCustomJavaSerialization}} will get a {{NoSuchMethodException}} when trying 
to grab the {{writeObject}} method and falsely conclude that Test doesn't use 
custom serialization.

 



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


[GitHub] ignite pull request #3840: IGNITE-8292: Broken yardstick compilation

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #3840: IGNITE-8292: Broken yardstick compilation

2018-04-17 Thread ybabak
GitHub user ybabak opened a pull request:

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

IGNITE-8292: Broken yardstick compilation

fixed.

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

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

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

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


commit a86b8afcc0751624c913a0fac49738a7f125cb64
Author: YuriBabak 
Date:   2018-04-17T08:18:22Z

IGNITE-8292: Broken yardstick compilation

fixed.




---


[GitHub] ignite pull request #3839: Ignite 6681 .NET: QueryMetrics

2018-04-17 Thread gromtech
GitHub user gromtech opened a pull request:

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

Ignite 6681 .NET: QueryMetrics

* Propagated cache methods: ResetQueryMetrics, QueryMetrics
* Added CacheQueryMetricsTest

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

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

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

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


commit dcce784133d18682295006a18285876b44309920
Author: Roman Guseinov 
Date:   2018-04-03T13:53:24Z

IGNITE-6681 .NET: QueryMetrics

commit dcaaf71579566052a66d61260128fc43eb7bc6cc
Author: Roman Guseinov 
Date:   2018-04-17T08:07:38Z

IGNITE-6681 Added CacheQueryMetricsTest




---


[GitHub] ignite pull request #3838: IGNITE-8292: Broken yardstick compilation

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] ignite pull request #3838: IGNITE-8292: Broken yardstick compilation

2018-04-17 Thread ybabak
GitHub user ybabak opened a pull request:

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

IGNITE-8292: Broken yardstick compilation

fixed.

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

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

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

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


commit a86b8afcc0751624c913a0fac49738a7f125cb64
Author: YuriBabak 
Date:   2018-04-17T08:18:22Z

IGNITE-8292: Broken yardstick compilation

fixed.




---


[jira] [Created] (IGNITE-8292) Broken yardstick compilation

2018-04-17 Thread Yury Babak (JIRA)
Yury Babak created IGNITE-8292:
--

 Summary: Broken yardstick compilation
 Key: IGNITE-8292
 URL: https://issues.apache.org/jira/browse/IGNITE-8292
 Project: Ignite
  Issue Type: Bug
  Components: ml, yardstick
Affects Versions: 2.5
Reporter: Yury Babak
Assignee: Yury Babak






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


Re: Service grid redesign

2018-04-17 Thread Denis Mekhanikov
Val,

Service initialisation is not going to happen in the discovery thread.
It should be done asynchronously, and initialisation results should be sent
to the coordinator over communication.
This is described in the IEP:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-17%3A+Oil+Change+in+Service+Grid#IEP-17:OilChangeinServiceGrid-Successfulscenario

*init()* method is a validation step, making sure, that service is ready
for work.
And deployment shouldn't be considered successful until *init()* methods
finish their work on the assigned nodes.
Also *cancel() *and *init() *methods may be useful if we decide to
implement moving existing services to new nodes

 in
future.
These methods can be used to save and restore service's state from cache,
when it is rebalanced to another node.

As Denis said, if we are not going to prevent nodes from starting on
service failures, then we should at least generate corresponding events.
Otherwise there won't be any way to react to service initialization
failures during nodes startup.

Denis

вт, 17 апр. 2018 г. в 6:59, Valentin Kulichenko <
valentin.kuliche...@gmail.com>:

> I agree we shouldn't do anything synchronously within discovery threads. If
> something goes wrong, we just need to properly notify the user, logging and
> events seem to be right options to achieve that.
>
> BTW, with this design I'm not sure init() method makes sense, probably we
> should deprecate it.
>
> -Val
>
> On Mon, Apr 16, 2018 at 12:03 PM, Denis Magda  wrote:
>
> > Denis,
> >
> > In general, service initialization shouldn't prevent a node from joining
> > the cluster or slowing down that process. Thus, I would start the
> > initialization routines only after the node is accepted by the cluster.
> If
> > the initialization fails then we need to report a respective message to
> the
> > logs and, probably, generate a system event the user can be subscribed
> to.
> >
> > Regardless, of the service initialization time, I think we still need to
> > utilize discovery SPI to avoid problems discussed later.
> >
> > Val, others, what do you think about that?
> >
> >
> > --
> > Denis
> >
> > On Mon, Apr 16, 2018 at 10:29 AM, Denis Mekhanikov <
> dmekhani...@gmail.com>
> > wrote:
> >
> > > Basically, my question is: at which moment services should be deployed
> on
> > > connecting nodes?
> > > Should we reject a node from being included into a topology, if
> services,
> > > that are assigned to it, fail to deploy?
> > >
> > > It would be good to be sure, that all assigned services are initialised
> > and
> > > working, when node start is finished.
> > > Otherwise it's unclear, how to notify a user about failures in service
> > > initialisation on new nodes.
> > >
> > > If we decide to provide such guarantee, then how are we going to do
> that?
> > > Is procedure, that I described, viable?
> > > It requires hacking through the discovery protocol, which is a thing,
> > that
> > > should be avoided.
> > > So, maybe there is another way to achieve the same thing?
> > >
> > > Denis
> > >
> > > сб, 14 апр. 2018 г. в 1:48, Denis Magda :
> > >
> > > > It sounds like it's not a trivial thing to support the automatic
> > services
> > > > redeployment after a restart. Let's postpone it for now, guys
> > > concentrating
> > > > on more urgent things related to the services.
> > > >
> > > > Alex, Vladimir,
> > > >
> > > > Could you have a look at Denis question about the discovery-based
> > > > deployment? Guess it's the only one thing that prevents us from the
> IEP
> > > > finalization.
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Fri, Apr 13, 2018 at 5:30 AM, Denis Mekhanikov <
> > dmekhani...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > Vladimir,
> > > > >
> > > > > Currently we don't save binary metadata to disk, when persistence
> is
> > > > > disabled.
> > > > > But we still persist marshaller mappings for some reason, and I
> > > > personally
> > > > > believe, that we shouldn't.
> > > > >
> > > > > But I agree, that we should separate data and service persistence
> > > > > configuration.
> > > > > Right now persistence of services is configured in a pretty
> > non-obvious
> > > > > manner.
> > > > > It should be a clear way to tell Ignite, whether you want services
> to
> > > be
> > > > > persisted or not.
> > > > >
> > > > > I'm not sure, that we should make "statefullness" in general
> > > > configurable.
> > > > > Users don't care much, whether metadata is preserved on restarts,
> or
> > > not.
> > > > >
> > > > > Denis
> > > > >
> > > > > пт, 13 апр. 2018 г. в 14:29, Vladimir Ozerov  >:
> > > > >
> > > > > > Alex,
> > > > > >
> > > > > > I would say that we've already had this behavior for years -
> > > marshaller
> > > > > > cache. I think it is time to agree that 

[jira] [Created] (IGNITE-8291) Web Console: Unable to build generated Dockerfile "apt-get not found"

2018-04-17 Thread Alexey Kuznetsov (JIRA)
Alexey Kuznetsov created IGNITE-8291:


 Summary: Web Console: Unable to build generated Dockerfile 
"apt-get not found"
 Key: IGNITE-8291
 URL: https://issues.apache.org/jira/browse/IGNITE-8291
 Project: Ignite
  Issue Type: Bug
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.5


Since IGNITE-2.1 docker image based on alpine.



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


[GitHub] ignite pull request #3719: IGNITE-8048 merge query entities for dynamic cach...

2018-04-17 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[jira] [Created] (IGNITE-8290) Activation message handling fails with AssertionError sporadically.

2018-04-17 Thread Andrew Mashenkov (JIRA)
Andrew Mashenkov created IGNITE-8290:


 Summary: Activation message handling fails with AssertionError 
sporadically.
 Key: IGNITE-8290
 URL: https://issues.apache.org/jira/browse/IGNITE-8290
 Project: Ignite
  Issue Type: Bug
  Components: general
Reporter: Andrew Mashenkov


Some test fails sporadically due to AssertionError while processing custom 
discovery message which leads to grid and tests handing.

 

[19:28:05]W: [org.apache.ignite:ignite-indexing] java.lang.AssertionError: 
lastAffVer=AffinityTopologyVersion [topVer=3, minorTopVer=1], 
topVer=AffinityTopologyVersion [topVer=3, minorTopVer=1
], customMsg=ChangeGlobalStateMessage 
[id=1d578a0d261-a3a64f2e-2262-43b5-9974-0e0f14aa9780, 
reqId=22459434-7b5d-4e55-8c21-084d360c4e8d, 
initiatingNodeId=1c2ee197-646e-4003-9399-8a544d10, activate=true
, baselineTopology=BaselineTopology [id=0, branchingHash=1456858826, 
branchingType='Cluster activation', 
baselineNodes=[5cb0eb2b-e407-47ef-bed9-c41755727aae, 
742ee126-3357-4b00-9150-8e2368cdb5b7, 45f42481
-f232-4b0c-921d-0090610e2d86]], forceChangeBaselineTopology=false, 
timestamp=1523896084990]
 at 
org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onDiscoveryEvent(CacheAffinitySharedManager.java:174)
 at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onDiscoveryEvent(GridCacheProcessor.java:3280)
 at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery0(GridDiscoveryManager.java:694)
 at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$4.onDiscovery(GridDiscoveryManager.java:589)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.notifyDiscoveryListener(ServerImpl.java:5479)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processCustomMessage(ServerImpl.java:5305)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2765)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
 at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
 at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)



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


[jira] [Created] (IGNITE-8289) Document new feature in REST: new command AUTHENTICATE and how to use sessionToken

2018-04-17 Thread Alexey Kuznetsov (JIRA)
Alexey Kuznetsov created IGNITE-8289:


 Summary: Document new feature in REST: new command AUTHENTICATE 
and how to use sessionToken
 Key: IGNITE-8289
 URL: https://issues.apache.org/jira/browse/IGNITE-8289
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, rest
Reporter: Alexey Kuznetsov
Assignee: Prachi Garg
 Fix For: 2.5


[~pgarcia], Please document new REST command "authenticate" + how to use 
sessionToken to execute subsequent commands.

For example: 

[https://localhost:8080/ignite?cmd=authenticate=ignite=ignite]

Get  token, for example: 12DA3E2144344377BFA8155A7A796B3F

 

And execute "top" command.

[https://localhost:8080/ignite?cmd=top=12DA3E2144344377BFA8155A7A796B3F]

 

NOTE, token will be expired in 30 seconds, by default.

To set custom expire time, set system variable: IGNITE_REST_SESSION_TIMEOUT in 
seconds.

For example, -DIGNITE_REST_SESSION_TIMEOUT=3600

 



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


[GitHub] ignite pull request #3837: IGNITE-8066: AssertionError while trying to archi...

2018-04-17 Thread zstan
GitHub user zstan opened a pull request:

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

IGNITE-8066: AssertionError while trying to archive wal segment



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

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

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

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


commit 79bfdcd8a143dd602a9954a17440d4023b363193
Author: Evgeny Stanilovskiy 
Date:   2018-04-16T18:10:43Z

IGNITE-8066: AssertionError while trying to archive wal segment




---


[jira] [Created] (IGNITE-8288) ScanQuery ignore readFromBackups

2018-04-17 Thread Alexander Belyak (JIRA)
Alexander Belyak created IGNITE-8288:


 Summary: ScanQuery ignore readFromBackups
 Key: IGNITE-8288
 URL: https://issues.apache.org/jira/browse/IGNITE-8288
 Project: Ignite
  Issue Type: Bug
Reporter: Alexander Belyak


1) Create partitioned cache on



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