Re: [VOTE] Apache Ignite 2.6.0 RC1

[Dmitriy Setrakyan]

Andrey, this is the link I have:
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1

This list does not look short. It looks like a copy of 2.5.

D.

On Wed, Jul 11, 2018 at 5:48 AM, Andrey Gura  wrote:

> Sorry,
>
> You could check it using provided links.
>
>
>
> ср, 11 июл. 2018 г., 5:41 Andrey Gura :
>
> > Dmitry,
> >
> > It is emergency release so we have very short list of changes. You could
> > check it using provided links.
> >
> >
> > ср, 11 июл. 2018 г., 3:01 Dmitriy Setrakyan :
> >
> >> Not sure if this is worth a down vote, but the release notes seem like a
> >> copy of 2.5 release. I think 2.6 should have its own release notes.
> >>
> >> D.
> >>
> >> On Tue, Jul 10, 2018 at 8:02 PM, Andrey Gura  wrote:
> >>
> >> > Igniters,
> >> >
> >> > We've uploaded a 2.6.0 release candidate to
> >> > https://dist.apache.org/repos/dist/dev/ignite/2.6.0-rc1/
> >> >
> >> > Git tag name is 2.6.0-rc1.
> >> >
> >> > This release includes the following changes:
> >> >
> >> > Ignite:
> >> > * Fixed incorrect calculation of client affinity assignment with
> >> baseline.
> >> > * Fixed incorrect calculation of switch segment record in WAL.
> >> > * Fixed JVM crush during in-progress eviction and cache group stop.
> >> >
> >> > REST:
> >> > * Fixed serialization of BinaryObjects to JSON.
> >> >
> >> > Complete list of closed issues:
> >> >
> >> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20IGNITE%20AND%
> >> > 20fixVersion%20%3D%202.6%20AND%20(status%20%3D%
> >> > 20closed%20or%20status%20%3D%20resolved)
> >> >
> >> > DEVNOTES
> >> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> >> > plain;f=DEVNOTES.txt;hb=refs/tags/2.6.0-rc1
> >> >
> >> > RELEASE NOTES
> >> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> >> > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1
> >> >
> >> > Please start voting.
> >> >
> >> > +1 - to accept Apache Ignite 2.6.0-RC1
> >> > 0 - don't care either way
> >> > -1 - DO NOT accept Apache Ignite 2.6.0-RC1 (explain why)
> >> >
> >> > This vote will go for 72 hours.
> >> >
> >>
> >
>

Re: [VOTE] Apache Ignite 2.6.0 RC1

[Andrey Gura]

Sorry,

You could check it using provided links.



ср, 11 июл. 2018 г., 5:41 Andrey Gura :

> Dmitry,
>
> It is emergency release so we have very short list of changes. You could
> check it using provided links.
>
>
> ср, 11 июл. 2018 г., 3:01 Dmitriy Setrakyan :
>
>> Not sure if this is worth a down vote, but the release notes seem like a
>> copy of 2.5 release. I think 2.6 should have its own release notes.
>>
>> D.
>>
>> On Tue, Jul 10, 2018 at 8:02 PM, Andrey Gura  wrote:
>>
>> > Igniters,
>> >
>> > We've uploaded a 2.6.0 release candidate to
>> > https://dist.apache.org/repos/dist/dev/ignite/2.6.0-rc1/
>> >
>> > Git tag name is 2.6.0-rc1.
>> >
>> > This release includes the following changes:
>> >
>> > Ignite:
>> > * Fixed incorrect calculation of client affinity assignment with
>> baseline.
>> > * Fixed incorrect calculation of switch segment record in WAL.
>> > * Fixed JVM crush during in-progress eviction and cache group stop.
>> >
>> > REST:
>> > * Fixed serialization of BinaryObjects to JSON.
>> >
>> > Complete list of closed issues:
>> >
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
>> > 20fixVersion%20%3D%202.6%20AND%20(status%20%3D%
>> > 20closed%20or%20status%20%3D%20resolved)
>> >
>> > DEVNOTES
>> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>> > plain;f=DEVNOTES.txt;hb=refs/tags/2.6.0-rc1
>> >
>> > RELEASE NOTES
>> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
>> > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1
>> >
>> > Please start voting.
>> >
>> > +1 - to accept Apache Ignite 2.6.0-RC1
>> > 0 - don't care either way
>> > -1 - DO NOT accept Apache Ignite 2.6.0-RC1 (explain why)
>> >
>> > This vote will go for 72 hours.
>> >
>>
>

Re: [VOTE] Apache Ignite 2.6.0 RC1

[Andrey Gura]

Dmitry,

It is emergency release so we have very short list of changes. You could
check it using provided links.


ср, 11 июл. 2018 г., 3:01 Dmitriy Setrakyan :

> Not sure if this is worth a down vote, but the release notes seem like a
> copy of 2.5 release. I think 2.6 should have its own release notes.
>
> D.
>
> On Tue, Jul 10, 2018 at 8:02 PM, Andrey Gura  wrote:
>
> > Igniters,
> >
> > We've uploaded a 2.6.0 release candidate to
> > https://dist.apache.org/repos/dist/dev/ignite/2.6.0-rc1/
> >
> > Git tag name is 2.6.0-rc1.
> >
> > This release includes the following changes:
> >
> > Ignite:
> > * Fixed incorrect calculation of client affinity assignment with
> baseline.
> > * Fixed incorrect calculation of switch segment record in WAL.
> > * Fixed JVM crush during in-progress eviction and cache group stop.
> >
> > REST:
> > * Fixed serialization of BinaryObjects to JSON.
> >
> > Complete list of closed issues:
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> > 20fixVersion%20%3D%202.6%20AND%20(status%20%3D%
> > 20closed%20or%20status%20%3D%20resolved)
> >
> > DEVNOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > plain;f=DEVNOTES.txt;hb=refs/tags/2.6.0-rc1
> >
> > RELEASE NOTES
> > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> > plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1
> >
> > Please start voting.
> >
> > +1 - to accept Apache Ignite 2.6.0-RC1
> > 0 - don't care either way
> > -1 - DO NOT accept Apache Ignite 2.6.0-RC1 (explain why)
> >
> > This vote will go for 72 hours.
> >
>

Subscription

[Павлухин Иван]

Hi,

Please subscribe me.

-- 
Best regards,
Ivan Pavlukhin

Re: Ability to check and completely fill transactions on creation

[Dmitriy Setrakyan]

Anton,

Committing or rolling back from MXBean is OK, because it is not a listener,
but a direct invocation. However, it is not OK to allow synchronous
rollback from a filter or a listener. The only action you can do from a
listener is setRollbackOnly() which will cause the transaction to be rolled
back eventually. I think it achieves the same purpose.

D.

On Mon, Jul 9, 2018 at 2:25 PM, Anton Vinogradov  wrote:

> Dmitriy,
>
> Rollback from remote filter uses rollbackOnlyProxy [1], that's a special
> proxy allows rollback from another thread.
> It was specially designed to rollback transactions by "label" if necessary.
> So, I'm just finishing "label feature" to make it more useful at real
> production.
>
> Here's the example of remote filter with rollback (more examples can be
> found at PR [2])
>
> ignite.events().remoteListen(null,
> (IgnitePredicate)e -> {
> TransactionStateChangedEvent evt = (TransactionStateChangedEvent)e;
> Transaction tx = evt.tx();
> if (tx.label() == null) // Timeout and orher details can be checked as
> well.
> tx.rollback();
> return true;
> }, EVT_TX_STARTED);
>
> >> Calling rollback() or commit() from any filter or listener should not be
> allowed.
> Only rollback allowed, but reasonable question is "Why?", now I see we
> already doing this at:
> - TransactionsMXBean#getActiveTransactions -> foreach.rollback
> - control.sh --tx kill Xid
>
> The only one difference is that filter or listener can validate or/and
> rollback any tx synchronously, before it breaks something (eg. on start or
> resume),
> while TransactionsMXBean#getActiveTransactions or control.sh do this in
> batch way without any sync warranty.
>
>
> [1]
> org.apache.ignite.internal.processors.cache.distributed.
> near.GridNearTxLocal#rollbackOnlyProxy
> [2] https://github.com/apache/ignite/pull/4036
>
> пн, 9 июл. 2018 г. в 7:04, Dmitriy Setrakyan :
>
> > Anton, how do you plan to rollback the transaction from a remote filter?
> > Are you planning to call setRollbackOnly()? Calling rollback() or
> commit()
> > from any filter or listener should not be allowed.
> >
> > D.
> >
> > On Tue, Jul 3, 2018 at 1:55 AM, Anton Vinogradov  wrote:
> >
> > > Dmitriy, Yakov,
> > >
> > > I've finalized design and prepared the solution [1].
> > >
> > > 1) Only events from GridNearTxLocal are registered now.
> > >
> > > List of possible events:
> > >  public static final int[] EVTS_TX = {
> > > EVT_TX_STARTED,
> > > EVT_TX_COMMITTED,
> > > EVT_TX_ROLLED_BACK,
> > > EVT_TX_SUSPENDED,
> > > EVT_TX_RESUMED
> > > };
> > > 2) Transaction can be rolled back now inside
> > > - remote filter (always, since it always happens on node started this
> > > transaction)
> > > - local listener (only at node started this transaction)
> > >
> > > Rollback uses rollbackOnlyProxy [2] specially designed (and tested) to
> > > rollback any tx from any thread at node started the transaction.
> > >
> > > I see another public tools doing the same:
> > > - TransactionsMXBean#getActiveTransactions
> > > - control.sh --tx kill Xid
> > >
> > > Both able to rollback any tx at any state remotely.
> > >
> > > Yakov,
> > > could you please review the code?
> > >
> > > [1] https://github.com/apache/ignite/pull/4036 (TC checked)
> > > [2]
> > > org.apache.ignite.internal.processors.cache.distributed.
> > > near.GridNearTxLocal#rollbackOnlyProxy
> > >
> > > пт, 1 июн. 2018 г. в 23:33, Dmitriy Setrakyan :
> > >
> > > > Anton, we are very far from agreement. I think it makes sense to step
> > > back,
> > > > come up with a clean design and propose it again.
> > > >
> > > > On Fri, Jun 1, 2018 at 12:59 PM, Anton Vinogradov 
> > wrote:
> > > >
> > > > > Dmitriy,
> > > > >
> > > > > Unfortunately, we have more than 2 types of txs, full list is
> > > > >
> > > > > GridDhtTxLocal
> > > > > GridDhtTxRemote
> > > > > GridNearTxLocal
> > > > > GridNearTxRemote
> > > > >
> > > > > BTW, We have no clear documentation about behaviour and difference.
> > > > > I created an issue [1] to solve this, but seems no one interested
> :(
> > > > >
> > > >
> > > > The reason we do not have a documentation for these transaction
> classes
> > > is
> > > > because they are part of the internal implementation and should never
> > be
> > > > exposed to users.
> > > >
> > > > 1) What I see is that every Grid*Tx* have xid, startTime, isolation,
> > > > > concurrency, etc. So, there is no difference in params.
> > > > > Label is the only one exception to the rule, but this can be fixed.
> > > > >
> > > >
> > > > I am putting myself in the user's shoes, and no user will ever
> > understand
> > > > what is the difference between all these internal transaction classes
> > in
> > > > Ignite. Moreover, if you support events for all these transactions
> > types,
> > > > then users will start getting duplicate events of identical types for
> > the
> > > > same XID.
> > > >
> > > > As a user, all I care about is GridNearTxLocal events. On top of
> that,
>

Re: [VOTE] Apache Ignite 2.6.0 RC1

[Dmitriy Setrakyan]

Not sure if this is worth a down vote, but the release notes seem like a
copy of 2.5 release. I think 2.6 should have its own release notes.

D.

On Tue, Jul 10, 2018 at 8:02 PM, Andrey Gura  wrote:

> Igniters,
>
> We've uploaded a 2.6.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.6.0-rc1/
>
> Git tag name is 2.6.0-rc1.
>
> This release includes the following changes:
>
> Ignite:
> * Fixed incorrect calculation of client affinity assignment with baseline.
> * Fixed incorrect calculation of switch segment record in WAL.
> * Fixed JVM crush during in-progress eviction and cache group stop.
>
> REST:
> * Fixed serialization of BinaryObjects to JSON.
>
> Complete list of closed issues:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%
> 20fixVersion%20%3D%202.6%20AND%20(status%20%3D%
> 20closed%20or%20status%20%3D%20resolved)
>
> DEVNOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=DEVNOTES.txt;hb=refs/tags/2.6.0-rc1
>
> RELEASE NOTES
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_
> plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.6.0-RC1
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.6.0-RC1 (explain why)
>
> This vote will go for 72 hours.
>

Re: Automatic Handling of Long Stop-the-World Pauses

[Denis Magda]

I see, then we need to come up with an external process-based solution for
the sake of the new ticket.

--
Denis

On Tue, Jul 10, 2018 at 6:01 AM Andrey Gura  wrote:

> Denis,
>
> we have LongJVMPauseDetector. But it is Java thread that will be in
> safe-point during stop-the-world pause and therefore will not make any
> progress. So only external process can detect SW pause.
> On Mon, Jul 2, 2018 at 10:34 PM Denis Magda  wrote:
> >
> > Pavel,
> >
> > We already can monitor the state of individual nodes and show it through
> > metrics. Now I'd like to see how to go further and automate a decision on
> > if a node should be kicked off from the cluster or not.
> >
> > --
> > Denis
> >
> > On Mon, Jul 2, 2018 at 12:28 PM Pavel Kovalenko 
> wrote:
> >
> > > Denis,
> > >
> > > I think, JVM can't easily help to itself if it's in SW pause. Most
> > > solutions what I saw about handling such situations are checking
> heartbeats
> > > on other nodes or run in parallel supervisor process which can detect
> that
> > > JVM with Ignite in SW.
> > >
> > > 2018-07-02 20:54 GMT+03:00 Denis Magda :
> > >
> > > > Igniters,
> > > >
> > > > Pulling this discussion up. Any thoughts?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Thu, Jun 21, 2018 at 3:52 PM Denis Magda 
> wrote:
> > > >
> > > > > Igniters,
> > > > >
> > > > > It's a pleasure to see how our project is evolving in a directing
> of
> > > > being
> > > > > a self-healing solution:
> > > > >
> > > > >- Ignite can already handle critical failures such as OOM, File
> I/O
> > > > >issues, etc. [1]
> > > > >- There is an endeavor to fix cluster lock-ins due to partition
> map
> > > > >exchange issues. [2]
> > > > >
> > > > > There is one more notorious problem that might affect Ignite
> > > deployments
> > > > > which is long stop-the-world GC pauses.
> > > > >
> > > > > I know we did a little progress in this direction [3] by providing
> > > > > particular metrics that help to monitor the pauses. Why don't we
> keep
> > > the
> > > > > pace and teach Ignite to help itself if it sees there is a node
> that
> > > > brings
> > > > > down overall cluster performance due to an STP?
> > > > >
> > > > > I would create policies similar to the critical failures policies
> [4]
> > > or
> > > > > just add a long STP to the list of critical failures and reuse
> existing
> > > > > functionality.
> > > > >
> > > > > Thoughts? Anyone who'd like to implement the feature?
> > > > >
> > > > > [1] https://apacheignite.readme.io/docs/critical-failures-handling
> > > > > [2]
> > > > > http://apache-ignite-developers.2346864.n4.nabble.
> > > > com/IEP-25-Partition-Map-Exchange-hangs-resolving-td31819.html
> > > > > [3] https://issues.apache.org/jira/browse/IGNITE-6171
> > > > > [4]
> > > > > https://apacheignite.readme.io/docs/critical-failures-
> > > > handling#section-failure-handling
> > > > >
> > > >
> > >
>

Re: [VOTE] Apache Ignite 2.6.0 RC1

[Denis Magda]

+1 (binding)

--
Denis

On Tue, Jul 10, 2018 at 10:02 AM Andrey Gura  wrote:

> Igniters,
>
> We've uploaded a 2.6.0 release candidate to
> https://dist.apache.org/repos/dist/dev/ignite/2.6.0-rc1/
>
> Git tag name is 2.6.0-rc1.
>
> This release includes the following changes:
>
> Ignite:
> * Fixed incorrect calculation of client affinity assignment with baseline.
> * Fixed incorrect calculation of switch segment record in WAL.
> * Fixed JVM crush during in-progress eviction and cache group stop.
>
> REST:
> * Fixed serialization of BinaryObjects to JSON.
>
> Complete list of closed issues:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.6%20AND%20(status%20%3D%20closed%20or%20status%20%3D%20resolved)
>
> DEVNOTES
>
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.6.0-rc1
>
> RELEASE NOTES
>
> https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1
>
> Please start voting.
>
> +1 - to accept Apache Ignite 2.6.0-RC1
> 0 - don't care either way
> -1 - DO NOT accept Apache Ignite 2.6.0-RC1 (explain why)
>
> This vote will go for 72 hours.
>

[jira] [Created] (IGNITE-8978) Affinity throws "IgniteException: Failed to find cache" after an Ignite client re-connect

[Dmitry Konstantinov (JIRA)]

Dmitry Konstantinov created IGNITE-8978:
---

 Summary: Affinity throws "IgniteException: Failed to find cache" 
after an Ignite client re-connect
 Key: IGNITE-8978
 URL: https://issues.apache.org/jira/browse/IGNITE-8978
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
 Environment: ver. 2.5.0#20180523-sha1:86e110c7
OS: Windows 7 6.1 amd64
Java(TM) SE Runtime Environment 1.8.0_101-b13 Oracle Corporation Java 
HotSpot(TM) 64-Bit Server VM 25.101-b13
Reporter: Dmitry Konstantinov


Use case:
 # A single Ignite server node is deployed and running.
 # An ignite Java client connects to the server node and starts to do cache 
operations (put/get) + invoke Affinity.mapKeyToNode() method.
 # The Ignite server process is killed
 # Waiting for some time
 # Starting the Ignite server back.

{code:java}
public static void main(String ... args) throws InterruptedException {
Ignition.setClientMode(true);
String config = "ignite-config.xml";
try (Ignite ignite = Ignition.start(config)) {
String cacheName = "testCache";
IgniteCache cache = ignite.cache(cacheName);
Affinity affinity = ignite.affinity(cacheName);

while (true) {
try {
String key = "testKey";
cache.put(key, "testValue");
String value = cache.get(key);
ClusterNode primary = affinity.mapKeyToNode(key);
System.out.println("read value: " + value + ", primary node: " 
+ primary);
} catch (Exception e) {
System.out.println("Error: " + e.toString());
e.printStackTrace();
} finally {
Thread.sleep(1000);
}
}
}
}
{code}

Expected result:
 affinity.mapKeyToNode(key) starts to work after a re-connection to the 
restarted server

Actual result:
 affinity.mapKeyToNode(key) continues to throw the following exception:
{code:java}
class org.apache.ignite.IgniteException: Failed to find cache (cache was not 
started yet or cache was already stopped): testCache
at 
org.apache.ignite.internal.processors.cache.GridCacheAffinityManager.affinityTopologyVersion(GridCacheAffinityManager.java:402)
at 
org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.topologyVersion(GridCacheAffinityImpl.java:241)
at 
org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeysToNodes(GridCacheAffinityImpl.java:189)
at 
org.apache.ignite.internal.processors.cache.affinity.GridCacheAffinityImpl.mapKeyToNode(GridCacheAffinityImpl.java:182)
at test.ignite.Main.main(Main.java:25)
{code}



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

PR Reivew https://github.com/apache/ignite/pull/4300

[kcheng.mvp]

Dear igniters,

please help do the code review for jira 
https://issues.apache.org/jira/browse/IGNITE-8776
https://github.com/apache/ignite/pull/4300

Thanks,
kcheng.mvp



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

Re: Clusterwide settings validation

[Dmitriy Setrakyan]

What about an idea to have a validation template file (e.g.
ignite-validate.xml), and make sure on startup that all config properties
specified in that file match. This way a user could put this file somewhere
on a shared network drive and have an extra degree of confidence that the
configuration is valid.

Thoughts?

D.


On Tue, Jul 10, 2018 at 5:43 PM, Ivan Rakov  wrote:

> Slava,
>
> I agree. Different persistence enabled flag can cause unpleasant issues.
> I've left a comment in IGNITE-8951.
>
> Yakov,
>
> Seems like I misunderstood the point of the discussion from the very
> beginning. I thought that Andrew raised topic to discuss adding new checks
> that will fail node join (like we do for different page size and rebalance
> pool size). If we are talking about /printing warnin//gs//about all
> differences/, we indeed can start with logic that passes through
> configuration classes with reflection. As a next step, we can filter out
> the properties that are expected to be different (consistentId, etc). I
> believe, full list of such properties can't be collected without manual
> research.
>
> Best Regards,
> Ivan Rakov
>
>
> On 10.07.2018 14:06, Вячеслав Коптилин wrote:
>
>> .Hello Ivan,
>>
>> I think it would be nice to add validation
>> DataRegionConfiguration#persistenceEnabled property. That property must
>> be
>> the same across a cluster for the given data region.
>> Perhaps, different values of `initSize`, `maxSize` etc make sense in case
>> of a heterogeneous cluster, except  `persistenceEnabled`
>>
>> Thanks,
>> S.
>>
>> вт, 10 июл. 2018 г. в 13:42, Ivan Rakov :
>>
>> Guys,
>>>
>>> For your information: rebalanceThreadPoolSize validation is already
>>> implemented and merged to master:
>>> https://issues.apache.org/jira/browse/IGNITE-8904
>>> You can overview the commit to see the approach. By the way, we already
>>> validate some other parameters that can't differ among cluster nodes
>>> (page size, tx configuration): GridCacheProcessor#checkConsistency.
>>> We also match necessary part of CacheConfiguration between nodes in
>>> GridCacheUtils#checkAttributeMismatch method.
>>>
>>> Does anyone know another properties mismatch of which can backfire on us?
>>>
>>> Best Regards,
>>> Ivan Rakov
>>>
>>> On 10.07.2018 10:47, Andrew Medvedev wrote:
>>>
 Made comment there, c&p here as well

 Is it going to be a preconfigured set of  settings, or a whole range
 of settings?

 If latter :

 1) Property names in CacheConfiguration do not always correspond to
 getters (some follow different naming conventions, some are completely
 different, as in memPlcName and getDataRegionName()), so inclusion
 pattern ("get all properties") does not work quite well with them

 2) If using manual handling of getter methods, we see that a lot of
 metrics are returned by methods in CacheConfiguration and below,
 instead of properties (in TcpCommunicationSpi especially), and getter
 methods are not properly annotated. (for ex see
 https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
 pattern ("get all except metrics etc") forces us to manually exclude
 those, not quite well too, looks like a hack

 Plus some properties, although configurable, have their defaults
 dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE

 Just to make sure, we compare with coordinator, log locally, and
 client nodes are excluded?

 On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov 

>>> wrote:
>>>
 Guys, I created ticket for config params validation -
> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to
>
 comment.
>>>
 Yakov Zhdanov
> www.gridgain.com
>
> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev <
> andrew.y.medve...@gmail.com
>
 :

> Hi Nikolay
>>
>> No, we have been beaten by
>> https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
>> 22rebalanceThreadPoolSize%22
>> it is not checked on start
>>
>> Utility I mean check
>> org.apache.ignite.configuration.IgniteConfiguration and children
>>
>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov > >
>> wrote:
>>
>>> Hello, Andrew.
>>>
>>> Can you clarify your question?
>>>
>>> What checks do you mean, exactly?
>>> Do you mean internal Ignite checks or user-provided checks?
>>>
>>> Ignite checks configuration consistency on node start [1].
>>>
>>> Ignite do have consistency check for a joining node. Take a look at
>>>
>> [2]
>>>
 and all of it children.
>>
>>> [1] https://github.com/apache/ignite/blob/master/modules/
>>>
>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>>
>>> [2] https://github.com/apache/ignite/blob/master/modules/
>>>
>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>>
>>> В Ср, 04

[VOTE] Apache Ignite 2.6.0 RC1

[Andrey Gura]

Igniters,

We've uploaded a 2.6.0 release candidate to
https://dist.apache.org/repos/dist/dev/ignite/2.6.0-rc1/

Git tag name is 2.6.0-rc1.

This release includes the following changes:

Ignite:
* Fixed incorrect calculation of client affinity assignment with baseline.
* Fixed incorrect calculation of switch segment record in WAL.
* Fixed JVM crush during in-progress eviction and cache group stop.

REST:
* Fixed serialization of BinaryObjects to JSON.

Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%202.6%20AND%20(status%20%3D%20closed%20or%20status%20%3D%20resolved)

DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/2.6.0-rc1

RELEASE NOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/2.6.0-rc1

Please start voting.

+1 - to accept Apache Ignite 2.6.0-RC1
0 - don't care either way
-1 - DO NOT accept Apache Ignite 2.6.0-RC1 (explain why)

This vote will go for 72 hours.

[GitHub] ignite pull request #4347: IGNITE-8973 calculate partition hash and print in...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8973 calculate partition hash and print into standard output



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

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

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

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


commit 7cdf066a7dc7573bf350df8ce8394aae2bb13396
Author: Anton Kalashnikov 
Date:   2018-07-10T16:15:55Z

IGNITE-8973 calculate partition hash and print into standard output




---

[GitHub] ignite pull request #4346: Stockengine

[EdShangGG]

GitHub user EdShangGG opened a pull request:

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

Stockengine



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

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

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

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


commit 1cea80d29f4f1c61ed56ad1261b74ed42611bf64
Author: Ilya Lantukh 
Date:   2018-04-06T10:49:10Z

IGNITE-8018 Optimized GridCacheMapEntry initialValue() - Fixes #3686.

Signed-off-by: Alexey Goncharuk 

commit 37fc72542eb6baa8be8b41aecd08a194102d13c1
Author: Алексей Стельмак 
Date:   2018-04-06T15:28:22Z

IGNITE-8049 Limit the number of operation cycles in B+Tree - Fixes #3769.

Signed-off-by: dpavlov 

(cherry picked from commit e491f10)

commit 76e293654e34c927d6c9efc85a12e736b58a21f2
Author: Eduard Shangareev 
Date:   2018-04-06T16:22:07Z

IGNITE-8114 Add fail recovery mechanism to tracking pages - Fixes #3734.

Signed-off-by: dpavlov 

(cherry picked from commit 0829397)

commit 49f11db727febc83297c7f0f5de9e6f98f0197fa
Author: Alexey Kuznetsov 
Date:   2018-04-09T02:25:50Z

IGNITE-8159 control.sh: Fixed NPE on adding nodes on empty baseline and not 
active cluster.

(cherry picked from commit 834869c)

commit 9ad7be2f51b6dcdcdf43fedb298cd4e240f0adab
Author: Ilya Borisov 
Date:   2018-04-09T13:59:32Z

IGNITE-8155 Web Console: Fixed number pattern warning in browser console.

(cherry picked from commit 5d8f570)

commit 4aa56751906e5db7aad025a7193933fa929aae26
Author: Vasiliy Sisko 
Date:   2018-04-09T15:13:21Z

IGNITE-7940 Visor CMD: Added "cache -slp" and "cache -rlp" commands to show 
and reset lost partitions for specified cache.

(cherry picked from commit abfa0f5)

commit cc04c5c70af1bdbba834f73330e73277b60e23fc
Author: Eduard Shangareev 
Date:   2018-04-09T16:15:50Z

IGNITE-8114 Additional fix for Add fail recovery mechanism to tracking pages

(cherry picked from commit 961fc35)

commit c70d85aa36c702ea0f29bd8668e9bf0790f9ba11
Author: Vasiliy Sisko 
Date:   2018-04-10T08:42:24Z

IGNITE-8126 Web Console: Fixed code generation for cache load.

(cherry picked from commit a0a187b)

commit 8d3755b9c58eef12c5fc9cabfc0b1c05f6db716e
Author: Semyon Boikov 
Date:   2018-04-10T08:37:39Z

IGNITE-7222 Added ZooKeeper discovery SPI

commit b096a463c338565a7661f8a853a257518d872997
Author: Stanislav Lukyanov 
Date:   2018-04-09T11:33:13Z

IGNITE-7904: Changed IgniteUtils::cast not to trim exception chains. This 
closes #3683.

commit 82a4c024fe06ef8c8deeaf762f0cc20a8e481252
Author: Roman Guseinov 
Date:   2018-04-09T11:45:44Z

IGNITE-7944: Disconnected client node tries to send JOB_CANCEL message. 
Applied fix:
- Skip sending message if client disconnected;
- Throw IgniteCheckedException if a client node is disconnected and 
communication client is null.
This closes #3737.

commit c1745de37891026e0a719f0c1d1afe768dfccbf3
Author: Vasiliy Sisko 
Date:   2018-04-10T10:48:52Z

IGNITE-7927 Web Console: Fixed demo for non-collocated joins.

(cherry picked from commit 647620b)

commit b28287d1861fd841a18d0eef95eff309d21a55ef
Author: Alexey Goncharuk 
Date:   2018-04-10T13:22:28Z

IGNITE-8025 Future must fail if assertion error has been thrown in the 
worker thread

commit a832f2b2e5788c45114c3cb5529d7cf53d08f9a6
Author: Andrey Kuznetsov 
Date:   2018-04-10T14:30:12Z

ignite-7772 System workers critical failures handling

Signed-off-by: Andrey Gura 

commit 912433ba9aa113508d05930691b251eccd8f5870
Author: Aleksey Plekhanov 
Date:   2018-04-10T15:54:03Z

IGNITE-8069 IgniteOutOfMemoryException should be handled accordingly to 
provided failure handler

Signed-off-by: Andrey Gura 

commit 99feab6ace66d011b677fd4d57b44fc54da8fd4f
Author: Alexey Goncharuk 
Date:   2018-04-10T17:33:47Z

IGNITE-6430 Complete failing test early

commit 526fb0ee612ef71fde58a1274db35e8205304a63
Author: Dmitriy Sorokin 
Date:   2018-04-10T19:20:41Z

IGNITE-8101 Ability to terminate system workers by JMX for test purposes.

Signed-off-by: Andrey Gura 

commit b4cb2f0df944534743a9d73811e047eda572258c
Author: mcherkasov 
Date:   2018-04-11T00:27:20Z

IGNITE-8153 Nodes fail to connect each other when SSL is enabled - Fixes 
#3773.

Signed-off-by: Valentin Kulichenko 

commit b4cc9f2d45d78c360abe224165e707c23533469e
Author: Pavel Kovalenko 
Date:   2018-04-11T08:23:46Z

IGNITE-7871 Implemented additional synchronization phase for correct 
partition counters update

commit 9abfee69aa153888456f9e8574ece1f2d0cbe4d9
Author: dmitrievanthony 
Date:   2018-04-10T09:46:43Z

IGNITE-8059: Integrate decision tree wi

Re: Clusterwide settings validation

[Ivan Rakov]

Slava,

I agree. Different persistence enabled flag can cause unpleasant issues. 
I've left a comment in IGNITE-8951.


Yakov,

Seems like I misunderstood the point of the discussion from the very 
beginning. I thought that Andrew raised topic to discuss adding new 
checks that will fail node join (like we do for different page size and 
rebalance pool size). If we are talking about /printing 
warnin//gs//about all differences/, we indeed can start with logic that 
passes through configuration classes with reflection. As a next step, we 
can filter out the properties that are expected to be different 
(consistentId, etc). I believe, full list of such properties can't be 
collected without manual research.


Best Regards,
Ivan Rakov

On 10.07.2018 14:06, Вячеслав Коптилин wrote:

.Hello Ivan,

I think it would be nice to add validation
DataRegionConfiguration#persistenceEnabled property. That property must be
the same across a cluster for the given data region.
Perhaps, different values of `initSize`, `maxSize` etc make sense in case
of a heterogeneous cluster, except  `persistenceEnabled`

Thanks,
S.

вт, 10 июл. 2018 г. в 13:42, Ivan Rakov :


Guys,

For your information: rebalanceThreadPoolSize validation is already
implemented and merged to master:
https://issues.apache.org/jira/browse/IGNITE-8904
You can overview the commit to see the approach. By the way, we already
validate some other parameters that can't differ among cluster nodes
(page size, tx configuration): GridCacheProcessor#checkConsistency.
We also match necessary part of CacheConfiguration between nodes in
GridCacheUtils#checkAttributeMismatch method.

Does anyone know another properties mismatch of which can backfire on us?

Best Regards,
Ivan Rakov

On 10.07.2018 10:47, Andrew Medvedev wrote:

Made comment there, c&p here as well

Is it going to be a preconfigured set of  settings, or a whole range
of settings?

If latter :

1) Property names in CacheConfiguration do not always correspond to
getters (some follow different naming conventions, some are completely
different, as in memPlcName and getDataRegionName()), so inclusion
pattern ("get all properties") does not work quite well with them

2) If using manual handling of getter methods, we see that a lot of
metrics are returned by methods in CacheConfiguration and below,
instead of properties (in TcpCommunicationSpi especially), and getter
methods are not properly annotated. (for ex see
https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
pattern ("get all except metrics etc") forces us to manually exclude
those, not quite well too, looks like a hack

Plus some properties, although configurable, have their defaults
dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE

Just to make sure, we compare with coordinator, log locally, and
client nodes are excluded?

On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov 

wrote:

Guys, I created ticket for config params validation -
https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to

comment.

Yakov Zhdanov
www.gridgain.com

2018-07-04 10:51 GMT+03:00 Andrew Medvedev 
:

Hi Nikolay

No, we have been beaten by
https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
22rebalanceThreadPoolSize%22
it is not checked on start

Utility I mean check
org.apache.ignite.configuration.IgniteConfiguration and children

On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov 
wrote:

Hello, Andrew.

Can you clarify your question?

What checks do you mean, exactly?
Do you mean internal Ignite checks or user-provided checks?

Ignite checks configuration consistency on node start [1].

Ignite do have consistency check for a joining node. Take a look at

[2]

and all of it children.

[1] https://github.com/apache/ignite/blob/master/modules/

core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825

[2] https://github.com/apache/ignite/blob/master/modules/

core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153

В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:

Hello everybody

Our company has lots of nodes in cluster, and we have seen some
problems with inconsistent settings on nodes clusterwide. To help us
with this, we made an utility to check consistency of settings on
running cluster, but it is a hack, better ways seems to be settings
validation by each node itself on start/joining topology/etc..

1) Is his needed?
2) Have the implementation details been discussed somewhere?

Cheers

[GitHub] ignite pull request #4345: IGNITE-8975: Correct handling compressed archived...

[ivandasch]

GitHub user ivandasch opened a pull request:

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

IGNITE-8975: Correct handling compressed archived wal segment when co…

…mpression is switched off.

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

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

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

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


commit fb2019963a0e7408af39a27d816fec775652f661
Author: Ivan Daschinskiy 
Date:   2018-07-10T15:23:00Z

IGNITE-8975: Correct handling compressed archived wal segment when 
compression is switched off.




---

[GitHub] ignite pull request #3928: Ignite client reassign

[alamar]

Github user alamar closed the pull request at:

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


---

[GitHub] ignite pull request #2621: IGNITE-6070 Ensure that Web Session RequestWrappe...

[alamar]

Github user alamar closed the pull request at:

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


---

[GitHub] ignite pull request #3668: IGNITE-6711 DataRegionMetrics#totalAllocatedPages...

[alamar]

Github user alamar closed the pull request at:

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


---

[GitHub] ignite pull request #3755: Ignite 7712v1

[alamar]

Github user alamar closed the pull request at:

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


---

[jira] [Created] (IGNITE-8977) Need to update distributed SQL page

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-8977:
-

 Summary: Need to update distributed SQL page
 Key: IGNITE-8977
 URL: https://issues.apache.org/jira/browse/IGNITE-8977
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Reporter: Dmitriy Setrakyan
Assignee: Prachi Garg
 Fix For: 2.7


Main goal - less text, better structure.

Let's add the following sections:
 # Distributed SQL Indexes
 # {color:#33}Distributed SQL JOINs{color}
 # {color:#33}Memory-only{color}
 # {color:#33}Native Persistence{color}
 # {color:#33}Memory Management - here we should mention that due to Ignite 
memory management policies, the most used indexes will always end up being 
cached in memory, even when the persistence is enabled.{color}

 



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

[jira] [Created] (IGNITE-8976) Add native persistence section to Key-Value data grid page

[Dmitriy Setrakyan (JIRA)]

Dmitriy Setrakyan created IGNITE-8976:
-

 Summary: Add native persistence section to Key-Value data grid page
 Key: IGNITE-8976
 URL: https://issues.apache.org/jira/browse/IGNITE-8976
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Reporter: Dmitriy Setrakyan
Assignee: Prachi Garg
 Fix For: 2.7


# We need to add a section for Ignite native persistence
 # We need to add a native persistence image to this section.
 # We need to place current 3rd party DB image next to the 3rd party DB section



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

[jira] [Created] (IGNITE-8975) Invalid initialization of compressed archived WAL segment when WAL compression is switched off.

[Ivan Daschinskiy (JIRA)]

Ivan Daschinskiy created IGNITE-8975:


 Summary: Invalid initialization of compressed archived WAL segment 
when WAL compression is switched off.
 Key: IGNITE-8975
 URL: https://issues.apache.org/jira/browse/IGNITE-8975
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy
 Fix For: 2.7


After restarting node with WAL compression disabled and when compressed wal 
archive 
presentd, current implementation of FileWriteAheadLogManager ignores presenting 
compressed wal segment and initalizes empty brand new one. This causes 
following error:

{code:java}
2018-07-05 16:14:25.761 
[ERROR][exchange-worker-#153%DPL_GRID%DplGridNodeName%][o.a.i.i.p.c.p.c.CheckpointHistory]
 Failed to process checkpoint: CheckpointEntry 
[id=8dc4b1cc-dedd-4a57-8748-f5a7ecfd389d, timestamp=1530785506909, 
ptr=FileWALPointer [idx=4520, fileOff=860507725, len=691515]]
org.apache.ignite.IgniteCheckedException: Failed to find checkpoint record at 
the given WAL pointer: FileWALPointer [idx=4520, fileOff=860507725, len=691515]
at 
org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.initIfNeeded(CheckpointEntry.java:346)
at 
org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry$GroupStateLazyStore.access$300(CheckpointEntry.java:231)
at 
org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.initIfNeeded(CheckpointEntry.java:123)
at 
org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointEntry.groupState(CheckpointEntry.java:105)
at 
org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.isCheckpointApplicableForGroup(CheckpointHistory.java:377)
at 
org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointHistory.searchAndReserveCheckpoints(CheckpointHistory.java:304)
at 
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.reserveHistoryForExchange(GridCacheDatabaseSharedManager.java:1614)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.distributedExchange(GridDhtPartitionsExchangeFuture.java:1139)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:724)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2477)
at 
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2357)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at java.lang.Thread.run(Thread.java:745)
{code}




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

[GitHub] ignite pull request #4344: IGNITE-8900

[ilantukh]

GitHub user ilantukh opened a pull request:

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

IGNITE-8900



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

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

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

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


commit b3707b44c89b3bb4cb30d07cb1c9936264b0666e
Author: devozerov 
Date:   2018-06-29T20:01:26Z

Reproducer for IGNITE-8900 issue with broken links.

commit 1e05b9963592e20150d6006752da8a7b9fc87b09
Author: Alexey Goncharuk 
Date:   2018-06-30T11:08:45Z

Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite 
into ignite-8900-repro

commit 1c9c746c9ebae59a83f030689d0d7e90a429152e
Author: Alexey Goncharuk 
Date:   2018-06-30T13:23:21Z

IGNITE-8900 Attempting to fix the link issue

commit f819202d254f3b52f34a68d29cb48e120dc45810
Author: Ilya Lantukh 
Date:   2018-07-10T14:12:32Z

IGNITE-8900 : Hotfix for JVM crash.




---

[jira] [Created] (IGNITE-8974) MVCC TX: Vacuum cleanup version obtaining optimization.

[Roman Kondakov (JIRA)]

Roman Kondakov created IGNITE-8974:
--

 Summary: MVCC TX: Vacuum cleanup version obtaining optimization.
 Key: IGNITE-8974
 URL: https://issues.apache.org/jira/browse/IGNITE-8974
 Project: Ignite
  Issue Type: Improvement
  Components: cache, sql
Reporter: Roman Kondakov


At the moment vacuum process obtains cleanup version as the same way as 
transactions do. It implies some unnecessary complications and even minor 
performance drop due to calculation entire tx snapshot instead of just a 
cleanup version number or sending unnsecessary tx end acks back to the 
coordinator. Possible solutions are:
 * Local caching cleanup version from the last obtained tx snapshot and use it 
in vacuum process. But in this way not all outdated versions could be cleaned 
(i.e. keys updated by this last tx).
 * Implement a special method for calculating cleanup version on the 
coordinator state and Request and Response messages for vacuum runned on 
non-coordinator side.



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

[GitHub] ignite pull request #4343: Ignite 2.4.6 p1

[slukyano]

GitHub user slukyano opened a pull request:

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

Ignite 2.4.6 p1



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

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

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

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


commit debc906a25d3e2d65db58e16307fae6f08460eeb
Author: devozerov 
Date:   2018-02-27T09:13:52Z

Revert "IGNITE-7253: JDBC thin streaming: fixed default local buffer size, 
improved error messages in case of unsupported SQL statements."

This reverts commit d53504adb1d4276f79ede2401e2d1512fe0287ec.

commit d8cf9e042c0e9afe65508c006d9d1c39779d78b9
Author: devozerov 
Date:   2018-02-27T09:14:21Z

Revert "IGNITE-7253: Streaming mode for JDBC thin driver. This closes 
#3499."

This reverts commit bc331f9de716c30d6f733e28821ab44da7ed0cf7.

commit 975a7cdb68cb89da74ec78c3cf23f644050918ff
Author: devozerov 
Date:   2018-02-27T09:49:44Z

Merge branch 'ignite-2.4' into ignite-2.4.3

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FsyncModeFileWriteAheadLogManager.java
#   parent/pom.xml

commit 74a54d23913bd7195c525d8e222b4e4047515843
Author: Ilya Lantukh 
Date:   2018-02-28T07:08:54Z

IGNITE-7836 Fixed handling of state change message when forceReassignment 
is false

commit 2a70ede048f59753061973495f83927f47452d66
Author: Andrey Novikov 
Date:   2018-01-19T03:05:03Z

IGNITE-6920 Web Console: Create default account for direct-install package.

(cherry picked from commit e5005d9)

commit 2f1ea2cdb76863008d4514f26845457bdeb7d6ed
Author: Andrey Novikov 
Date:   2018-01-19T04:35:30Z

IGNITE-6920 Minor fix.

(cherry picked from commit 9cc7cbf)

commit 62652f3fb1563ba149dcbccb80928d50b822ff36
Author: alexdel 
Date:   2018-01-25T08:49:28Z

IGNITE-7064 Web Console: Implemented basic E2E tests.

(cherry picked from commit ce96e4f)

commit 06e891f1161af598e0aa4665f7a6047637d1c476
Author: Dmitriy Shabalin 
Date:   2018-01-25T09:51:44Z

IGNITE-7522 Web Console: Fixed cluster selector state after cluster restart.

(cherry picked from commit ac3cfb8)

commit 291cb2c88118ccffebcf3383db629647faec1eee
Author: Dmitriy Shabalin 
Date:   2018-01-25T10:33:13Z

IGNITE-7529 Web Console: Refactor UIGrid column filters.

(cherry picked from commit 08658ea)

commit 443eafc718685e66c9a60058bd0ab56d88f9f0a6
Author: alexdel 
Date:   2018-01-25T14:38:36Z

IGNITE-7064 Web Console: Minor test fix.

(cherry picked from commit 4b6d9ad)

commit 6f1df5c40100363b5922734223a774ff1d6a008e
Author: Ilya Borisov 
Date:   2018-01-26T09:07:47Z

IGNITE-7031 Web Console: Refactored confirmation cancellation logic.

(cherry picked from commit 92ae3fe)

commit 16982825fb06ff2724ba4583781cc15443c4f46d
Author: Alexey Kuznetsov 
Date:   2018-02-02T10:07:57Z

IGNITE-7610 Web Console: Profile page refactored to component.

(cherry picked from commit 958975e)

commit 9c6a52250e058c4546aef0d0ecee977c07076a1a
Author: Alexey Kuznetsov 
Date:   2018-02-02T10:09:37Z

IGNITE-7612 Web Console: Refactored mongoose schemas to separate module.

(cherry picked from commit 71db707)

commit 89e15830dedcb46f24d9cc9b922ba3b013331a18
Author: Vasiliy Sisko 
Date:   2018-02-12T10:22:10Z

Web Agent: Fixed wrong config of IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE in 
demo startup.

(cherry picked from commit 1a6e544)

commit 18966673570425192e1b89fbb2c63d164b47eaca
Author: Vasiliy Sisko 
Date:   2018-02-12T13:24:30Z

IGNITE-7578 Actualized client connector configuration.

(cherry picked from commit 819d746)

commit 237063efa35c54bb9e9800ecf63ea223ec20a9ef
Author: alexdel 
Date:   2018-02-19T04:25:24Z

IGNITE-7650 Extracted signin/signup form to separate page, improved landing 
page.

(cherry picked from commit 1925674)

commit 679aeca7a3ff60a9dd478966d3949107d302d5db
Author: Andrey Novikov 
Date:   2018-02-19T07:56:07Z

IGNITE-7650 Fixed headers.

(cherry picked from commit 67922b3)

commit 5d5a6a05ec49f895e8a5edd505e496dcfe58a208
Author: Vasiliy Sisko 
Date:   2018-02-21T04:21:02Z

IGNITE-6094 Web Agent: Enabled persistent in demo mode.

(cherry picked from commit 3c35900)

commit e35d8cfb06f52765959fc2e1883bf70fe0259f45
Author: Alexander Kalinin 
Date:   2018-02-21T07:03:20Z

IGNITE-7320 Web Console - Fixed table headers for Safari.

(cherry picked from commit 04a025b)

commit 20cb1439f48b9a3c985f65784af36ef2c6f45e4f
Author: Andrey Novikov 
Date:   2018-02-22T02:54:05Z

IGNITE-7650 Fixed counties codes.

(cherry picked from commit fc40261)

commit 50d1389cd60e1480

[jira] [Created] (IGNITE-8973) Need to support dump for idle_verify

[Dmitriy Govorukhin (JIRA)]

Dmitriy Govorukhin created IGNITE-8973:
--

 Summary: Need to support dump for idle_verify 
 Key: IGNITE-8973
 URL: https://issues.apache.org/jira/browse/IGNITE-8973
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Govorukhin


In a current implementation, idle_verify checking consistency between primary 
and backup partitions will be useful to have ability dump current state for all 
partition to file. This dump can help an investigation of some kind of problem 
with partition counters or sizes because it is a cluster partition hash 
snapshot by some partition state (hash include all keys in the partition).

idle_verify --dump - calculate partition hash and print into standard output
idle_verify --dump {path} - calculate partition hash and write output to file




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

[GitHub] ignite pull request #4293: IGNITE-8907: Using vectors in featureExtractor

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Automatic Handling of Long Stop-the-World Pauses

[Andrey Gura]

Denis,

we have LongJVMPauseDetector. But it is Java thread that will be in
safe-point during stop-the-world pause and therefore will not make any
progress. So only external process can detect SW pause.
On Mon, Jul 2, 2018 at 10:34 PM Denis Magda  wrote:
>
> Pavel,
>
> We already can monitor the state of individual nodes and show it through
> metrics. Now I'd like to see how to go further and automate a decision on
> if a node should be kicked off from the cluster or not.
>
> --
> Denis
>
> On Mon, Jul 2, 2018 at 12:28 PM Pavel Kovalenko  wrote:
>
> > Denis,
> >
> > I think, JVM can't easily help to itself if it's in SW pause. Most
> > solutions what I saw about handling such situations are checking heartbeats
> > on other nodes or run in parallel supervisor process which can detect that
> > JVM with Ignite in SW.
> >
> > 2018-07-02 20:54 GMT+03:00 Denis Magda :
> >
> > > Igniters,
> > >
> > > Pulling this discussion up. Any thoughts?
> > >
> > > --
> > > Denis
> > >
> > > On Thu, Jun 21, 2018 at 3:52 PM Denis Magda  wrote:
> > >
> > > > Igniters,
> > > >
> > > > It's a pleasure to see how our project is evolving in a directing of
> > > being
> > > > a self-healing solution:
> > > >
> > > >- Ignite can already handle critical failures such as OOM, File I/O
> > > >issues, etc. [1]
> > > >- There is an endeavor to fix cluster lock-ins due to partition map
> > > >exchange issues. [2]
> > > >
> > > > There is one more notorious problem that might affect Ignite
> > deployments
> > > > which is long stop-the-world GC pauses.
> > > >
> > > > I know we did a little progress in this direction [3] by providing
> > > > particular metrics that help to monitor the pauses. Why don't we keep
> > the
> > > > pace and teach Ignite to help itself if it sees there is a node that
> > > brings
> > > > down overall cluster performance due to an STP?
> > > >
> > > > I would create policies similar to the critical failures policies [4]
> > or
> > > > just add a long STP to the list of critical failures and reuse existing
> > > > functionality.
> > > >
> > > > Thoughts? Anyone who'd like to implement the feature?
> > > >
> > > > [1] https://apacheignite.readme.io/docs/critical-failures-handling
> > > > [2]
> > > > http://apache-ignite-developers.2346864.n4.nabble.
> > > com/IEP-25-Partition-Map-Exchange-hangs-resolving-td31819.html
> > > > [3] https://issues.apache.org/jira/browse/IGNITE-6171
> > > > [4]
> > > > https://apacheignite.readme.io/docs/critical-failures-
> > > handling#section-failure-handling
> > > >
> > >
> >

[jira] [Created] (IGNITE-8972) CPP Thin: Add thin client example

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-8972:
---

 Summary: CPP Thin: Add thin client example
 Key: IGNITE-8972
 URL: https://issues.apache.org/jira/browse/IGNITE-8972
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Affects Versions: 2.5
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.7


Add thin C++ client example that shows its basic functionality.



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

[GitHub] ignite pull request #4342: IGNITE-8971 GridRestProcessor should propagate er...

[andrewmed]

GitHub user andrewmed opened a pull request:

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

IGNITE-8971 GridRestProcessor should propagate error message



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

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

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

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


commit 39e586d74d39312485815f840ff0680cf4bd4512
Author: AMedvedev 
Date:   2018-07-10T11:25:48Z

GG-13472: handle disk full error on writing snapshot metadata




---

[jira] [Created] (IGNITE-8971) GridRestProcessor should propagate error message

[Andrew Medvedev (JIRA)]

Andrew Medvedev created IGNITE-8971:
---

 Summary: GridRestProcessor should propagate error message
 Key: IGNITE-8971
 URL: https://issues.apache.org/jira/browse/IGNITE-8971
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Andrew Medvedev


GridRestProcessor should propagate error message (stack trace)



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

[GitHub] ignite pull request #4341: Act deact to

[Mmuzaf]

GitHub user Mmuzaf opened a pull request:

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

Act deact to



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

$ git pull https://github.com/Mmuzaf/ignite act-deact-to

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

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


commit ad168426eca95804f229ac279f0446aca648ab76
Author: Maxim Muzafarov 
Date:   2018-07-09T12:23:58Z

ignite-8905: quick fix

commit 00bb44bc412e30cb69efb1da0d2604372240a67c
Author: Maxim Muzafarov 
Date:   2018-07-09T12:25:45Z

Revert "IGNITE-8737 Improve checkpoint logging information - Fixes #4244."

This reverts commit a727a4c7135e57415de0756e8fdc235ba191109a.




---

Re: Clusterwide settings validation

[Вячеслав Коптилин]

.Hello Ivan,

I think it would be nice to add validation
DataRegionConfiguration#persistenceEnabled property. That property must be
the same across a cluster for the given data region.
Perhaps, different values of `initSize`, `maxSize` etc make sense in case
of a heterogeneous cluster, except  `persistenceEnabled`

Thanks,
S.

вт, 10 июл. 2018 г. в 13:42, Ivan Rakov :

> Guys,
>
> For your information: rebalanceThreadPoolSize validation is already
> implemented and merged to master:
> https://issues.apache.org/jira/browse/IGNITE-8904
> You can overview the commit to see the approach. By the way, we already
> validate some other parameters that can't differ among cluster nodes
> (page size, tx configuration): GridCacheProcessor#checkConsistency.
> We also match necessary part of CacheConfiguration between nodes in
> GridCacheUtils#checkAttributeMismatch method.
>
> Does anyone know another properties mismatch of which can backfire on us?
>
> Best Regards,
> Ivan Rakov
>
> On 10.07.2018 10:47, Andrew Medvedev wrote:
> > Made comment there, c&p here as well
> >
> > Is it going to be a preconfigured set of  settings, or a whole range
> > of settings?
> >
> > If latter :
> >
> > 1) Property names in CacheConfiguration do not always correspond to
> > getters (some follow different naming conventions, some are completely
> > different, as in memPlcName and getDataRegionName()), so inclusion
> > pattern ("get all properties") does not work quite well with them
> >
> > 2) If using manual handling of getter methods, we see that a lot of
> > metrics are returned by methods in CacheConfiguration and below,
> > instead of properties (in TcpCommunicationSpi especially), and getter
> > methods are not properly annotated. (for ex see
> > https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
> > pattern ("get all except metrics etc") forces us to manually exclude
> > those, not quite well too, looks like a hack
> >
> > Plus some properties, although configurable, have their defaults
> > dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE
> >
> > Just to make sure, we compare with coordinator, log locally, and
> > client nodes are excluded?
> >
> > On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov 
> wrote:
> >> Guys, I created ticket for config params validation -
> >> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to
> comment.
> >>
> >> Yakov Zhdanov
> >> www.gridgain.com
> >>
> >> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev  >:
> >>
> >>> Hi Nikolay
> >>>
> >>> No, we have been beaten by
> >>> https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
> >>> 22rebalanceThreadPoolSize%22
> >>> it is not checked on start
> >>>
> >>> Utility I mean check
> >>> org.apache.ignite.configuration.IgniteConfiguration and children
> >>>
> >>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov 
> >>> wrote:
>  Hello, Andrew.
> 
>  Can you clarify your question?
> 
>  What checks do you mean, exactly?
>  Do you mean internal Ignite checks or user-provided checks?
> 
>  Ignite checks configuration consistency on node start [1].
> 
>  Ignite do have consistency check for a joining node. Take a look at
> [2]
> >>> and all of it children.
>  [1] https://github.com/apache/ignite/blob/master/modules/
> >>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>  [2] https://github.com/apache/ignite/blob/master/modules/
> >>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>  В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
> > Hello everybody
> >
> > Our company has lots of nodes in cluster, and we have seen some
> > problems with inconsistent settings on nodes clusterwide. To help us
> > with this, we made an utility to check consistency of settings on
> > running cluster, but it is a hack, better ways seems to be settings
> > validation by each node itself on start/joining topology/etc..
> >
> > 1) Is his needed?
> > 2) Have the implementation details been discussed somewhere?
> >
> > Cheers
>
>

Re: Clusterwide settings validation

[Yakov Zhdanov]

Ivan, I would think of some test that will randomly generate configs for
nodes and run some logic.

--Yakov

Re: Clusterwide settings validation

[Ivan Rakov]

Guys,

For your information: rebalanceThreadPoolSize validation is already 
implemented and merged to master: 
https://issues.apache.org/jira/browse/IGNITE-8904
You can overview the commit to see the approach. By the way, we already 
validate some other parameters that can't differ among cluster nodes 
(page size, tx configuration): GridCacheProcessor#checkConsistency.
We also match necessary part of CacheConfiguration between nodes in 
GridCacheUtils#checkAttributeMismatch method.


Does anyone know another properties mismatch of which can backfire on us?

Best Regards,
Ivan Rakov

On 10.07.2018 10:47, Andrew Medvedev wrote:

Made comment there, c&p here as well

Is it going to be a preconfigured set of  settings, or a whole range
of settings?

If latter :

1) Property names in CacheConfiguration do not always correspond to
getters (some follow different naming conventions, some are completely
different, as in memPlcName and getDataRegionName()), so inclusion
pattern ("get all properties") does not work quite well with them

2) If using manual handling of getter methods, we see that a lot of
metrics are returned by methods in CacheConfiguration and below,
instead of properties (in TcpCommunicationSpi especially), and getter
methods are not properly annotated. (for ex see
https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
pattern ("get all except metrics etc") forces us to manually exclude
those, not quite well too, looks like a hack

Plus some properties, although configurable, have their defaults
dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE

Just to make sure, we compare with coordinator, log locally, and
client nodes are excluded?

On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov  wrote:

Guys, I created ticket for config params validation -
https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment.

Yakov Zhdanov
www.gridgain.com

2018-07-04 10:51 GMT+03:00 Andrew Medvedev :


Hi Nikolay

No, we have been beaten by
https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
22rebalanceThreadPoolSize%22
it is not checked on start

Utility I mean check
org.apache.ignite.configuration.IgniteConfiguration and children

On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov 
wrote:

Hello, Andrew.

Can you clarify your question?

What checks do you mean, exactly?
Do you mean internal Ignite checks or user-provided checks?

Ignite checks configuration consistency on node start [1].

Ignite do have consistency check for a joining node. Take a look at [2]

and all of it children.

[1] https://github.com/apache/ignite/blob/master/modules/

core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825

[2] https://github.com/apache/ignite/blob/master/modules/

core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153

В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:

Hello everybody

Our company has lots of nodes in cluster, and we have seen some
problems with inconsistent settings on nodes clusterwide. To help us
with this, we made an utility to check consistency of settings on
running cluster, but it is a hack, better ways seems to be settings
validation by each node itself on start/joining topology/etc..

1) Is his needed?
2) Have the implementation details been discussed somewhere?

Cheers

[jira] [Created] (IGNITE-8970) Web Console: Add the Clone action to a new configuration UI

[Pavel Konstantinov (JIRA)]

Pavel Konstantinov created IGNITE-8970:
--

 Summary: Web Console: Add the Clone action to a new configuration 
UI
 Key: IGNITE-8970
 URL: https://issues.apache.org/jira/browse/IGNITE-8970
 Project: Ignite
  Issue Type: Task
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


A new configuration UI has no the Clone action for all cluster's components 
(caches, schemas,...). We need to add that action due to it was on 'old' UI.



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

[GitHub] ignite pull request #4340: IGNITE-8705. Added the way to clean metrics on cl...

[dgarus]

GitHub user dgarus opened a pull request:

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

IGNITE-8705. Added the way to clean metrics on cluster.



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

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

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

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


commit 1677e3cc906c2c3502da7826fa04ddf955593532
Author: Garus Denis 
Date:   2018-07-10T10:22:20Z

IGNITE-8705. Added the way to clean metrics on cluster.




---

[GitHub] ignite pull request #4339: IGNITE-8969 Restore server latches if needed afte...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8969 Restore server latches if needed after node left the topo…

…logy.

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

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

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

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


commit e0f03efc8b10e6c630433f3e6ba5bb7218714b57
Author: Anton Kalashnikov 
Date:   2018-07-10T10:10:14Z

IGNITE-8969 Restore server latches if needed after node left the topology.




---

[jira] [Created] (IGNITE-8969) Unable to await partitions release latch

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-8969:
-

 Summary: Unable to await partitions release latch
 Key: IGNITE-8969
 URL: https://issues.apache.org/jira/browse/IGNITE-8969
 Project: Ignite
  Issue Type: Test
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


 Unable to await partitions release latch within timeout for ClientLatch after 
this node become latch coordinator after old latch coordinator was failed.

Reproduced by 
TcpDiscoverySslSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished, 
TcpDiscoverySslTrustedSelfTest.testNodeShutdownOnRingMessageWorkerStartNotFinished



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

[GitHub] ignite pull request #4337: IGNITE-8869: cancel patch

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Clusterwide settings validation

[Andrew Medvedev]

Made comment there, c&p here as well

Is it going to be a preconfigured set of  settings, or a whole range
of settings?

If latter :

1) Property names in CacheConfiguration do not always correspond to
getters (some follow different naming conventions, some are completely
different, as in memPlcName and getDataRegionName()), so inclusion
pattern ("get all properties") does not work quite well with them

2) If using manual handling of getter methods, we see that a lot of
metrics are returned by methods in CacheConfiguration and below,
instead of properties (in TcpCommunicationSpi especially), and getter
methods are not properly annotated. (for ex see
https://issues.apache.org/jira/browse/IGNITE-8829), so exclusion
pattern ("get all except metrics etc") forces us to manually exclude
those, not quite well too, looks like a hack

Plus some properties, although configurable, have their defaults
dynamically set on startup for ex. DFLT_MEMORY_POLICY_MAX_SIZE

Just to make sure, we compare with coordinator, log locally, and
client nodes are excluded?

On Fri, Jul 6, 2018 at 4:15 PM, Yakov Zhdanov  wrote:
> Guys, I created ticket for config params validation -
> https://issues.apache.org/jira/browse/IGNITE-8951. Feel free to comment.
>
> Yakov Zhdanov
> www.gridgain.com
>
> 2018-07-04 10:51 GMT+03:00 Andrew Medvedev :
>
>> Hi Nikolay
>>
>> No, we have been beaten by
>> https://issues.apache.org/jira/browse/IGNITE-8904?jql=text%20~%20%
>> 22rebalanceThreadPoolSize%22
>> it is not checked on start
>>
>> Utility I mean check
>> org.apache.ignite.configuration.IgniteConfiguration and children
>>
>> On Wed, Jul 4, 2018 at 10:36 AM, Nikolay Izhikov 
>> wrote:
>> > Hello, Andrew.
>> >
>> > Can you clarify your question?
>> >
>> > What checks do you mean, exactly?
>> > Do you mean internal Ignite checks or user-provided checks?
>> >
>> > Ignite checks configuration consistency on node start [1].
>> >
>> > Ignite do have consistency check for a joining node. Take a look at [2]
>> and all of it children.
>> >
>> > [1] https://github.com/apache/ignite/blob/master/modules/
>> core/src/main/java/org/apache/ignite/internal/IgniteKernal.java#L825
>> > [2] https://github.com/apache/ignite/blob/master/modules/
>> core/src/main/java/org/apache/ignite/internal/GridComponent.java#L153
>> >
>> > В Ср, 04/07/2018 в 08:58 +0300, Andrew Medvedev пишет:
>> >> Hello everybody
>> >>
>> >> Our company has lots of nodes in cluster, and we have seen some
>> >> problems with inconsistent settings on nodes clusterwide. To help us
>> >> with this, we made an utility to check consistency of settings on
>> >> running cluster, but it is a hack, better ways seems to be settings
>> >> validation by each node itself on start/joining topology/etc..
>> >>
>> >> 1) Is his needed?
>> >> 2) Have the implementation details been discussed somewhere?
>> >>
>> >> Cheers
>>

Re: .NET tests fail on Linux - need help with TeamCity

[Pavel Tupitsyn]

Petr, looks like TC is back to normal.
I wonder what that was and whether NuGet cache cleanup step actually worked.

Thank you for your help, I will keep an eye on it.

On Fri, Jul 6, 2018 at 8:08 PM Petr Ivanov  wrote:

> Pavel,
>
>
> The only newtonsoft.json found are
> /usr/share/dotnet/sdk/NuGetFallbackFolder/newtonsoft.json (versions 9.0.1
> and 10.0.1) and /usr/share/dotnet/store/x64/netcoreapp2.0/newtonsoft.json
> (version 10.0.1). There is nothing in .nuget/packages.
> The sizes of corresponding Newtonsoft.Json.dll are as follows:
> 625K ::
> /usr/share/dotnet/sdk/NuGetFallbackFolder/newtonsoft.json/10.0.1/lib/netstandard1.3/Newtonsoft.Json.dll
> 1.8M ::
> /usr/share/dotnet/store/x64/netcoreapp2.0/newtonsoft.json/10.0.1/lib/netstandard1.3/Newtonsoft.Json.dll
>
> I’m not sure I should move the /usr/share based directories for tests but
> if it the case, I can do it carefully.
>
>
> BTW, on the agent where all tests are passed the same file exists as
> aforementioned ones, no obvious differences.
>
>
>
>
>
> > On 6 Jul 2018, at 12:15, Pavel Tupitsyn  wrote:
> >
> > Petr,
> >
> > - Get the sources
> > - cd modules/platforms/dotnet/Apache.Ignite.Core.Tests.DotNetCore
> > - dotnet build
> >
> > You should get a warning "warning MSB3246: Resolved file has a bad image,
> > no metadata, or is otherwise inaccessible. Image is too small."
> > If you do, go ahead:
> >
> > - cd ~/.nuget/packages/newtonsoft.json
> > - let me know which versions are there and what are the sizes
> > of lib/netstandard1.3/Newtonsoft.Json.dll files in them
> > - delete the whole newtonsoft.json directory and try the build again,
> will
> > it fail?
> >
> > Thanks,
> > Pavel
> >
> > On Thu, Jul 5, 2018 at 11:38 AM Petr Ivanov  wrote:
> >
> >> I can.
> >>
> >>
> >> Can you prepare reproduce steps so that I’ll be able to pinpoint the
> >> problem faster, please?
> >>
> >>
> >>> On 5 Jul 2018, at 11:25, Pavel Tupitsyn  wrote:
> >>>
> >>> Igniters,
> >>>
> >>> I need help with TeamCity.
> >>> .NET Linux Tests [1] fail for a very weird reason:
> >>> Newtonsoft.Json.dll seems to be corrupted or empty " *Image is too
> >> small.*
> >>> ".
> >>> I tried adding a step to clean NuGet caches, but it does not help.
> >>>
> >>> On my Ubuntu box tests pass. And there were no changes to .NET lately,
> so
> >>> this failure seems to be TC-related only.
> >>>
> >>> Can someone with TeamCity agent access help me with this and check
> where
> >>> that file comes from and what does it look like?
> >>>
> >>> Thanks,
> >>> Pavel
> >>>
> >>> [1]
> >>>
> >>
> https://ci.ignite.apache.org/viewLog.html?buildId=1454493&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformNetCoreLinux
> >>
> >>
>
>

Re: About readme.io's latest docs

[Dmitry Pavlov]

Great, thanks for letting me know.

вт, 10 июл. 2018 г. в 4:01, 李玉珏@163 <18624049...@163.com>:

> I have received the attachments.
>
> 在 2018/7/10 上午6:23, Prachi Garg 写道:
> > I already sent him the export, but the attachments were huge. I think
> > that's why the email reply was not received by the dev list.
> >
> > -P
> >
> > On Mon, Jul 9, 2018 at 2:33 PM, Dmitry Pavlov 
> wrote:
> >
> >> Igniters, was this question solved? Is it possible to do such export?
> >>
> >> пт, 1 июн. 2018 г. в 19:40, 李玉珏@163 <18624049...@163.com>:
> >>
> >>> Prachi,
> >>>
> >>>
> >>> Can you help to export all the latest version of all documents to me?
> >>> I am ready to make a synchronization of the chinese version of the
> >>> document.
> >>>
> >>> thanks!
> >>>
> >>>
> >>> 在 2017/11/24 下午1:33, Prachi Garg 写道:
>  Attached.
> 
>  On Wed, Nov 15, 2017 at 4:41 AM, 李玉珏@163 <18624049...@163.com
>  > wrote:
> 
>   Prachi,
> 
> 
>   Can you help me to export all the latest version of all documents
>   to me?
>   I am ready to make a synchronization of the chinese version of
> the
>   document.
> 
>   thanks!
> 
>   在 2017/8/17 上午2:05, Prachi Garg 写道:
> >  Please see attached.
> >
> >  -P
> >
> >  On Wed, Aug 9, 2017 at 11:19 AM, Denis Magda <
> dma...@gridgain.com
> >  > wrote:
> >
> >  Hi!
> >
> >  Prachi is on vacation and will send you the latest version
> as
> >  soon as she is back to work.
> >
> >  —
> >  Denis
> >
> >>  On Aug 7, 2017, at 5:33 AM, 李玉珏@163 <18624049...@163.com
> >>  > wrote:
> >>
> >>
> >>  Prachi,
> >>
> >>
> >>  Can you help me to export all the latest version of all
> >>  documents to me?
> >>  I am ready to make a synchronization of the chinese version
> >>  of the document.
> >>
> >>  thanks!
> >>
> >>
> >>  在 2017/5/13 上午12:48, Prachi Garg 写道:
> >>>  See attached for cpp, .net and integrations documentation.
> >>>
> >>>  -P
> >>>
> >>>  On Fri, May 12, 2017 at 9:47 AM, Prachi Garg
> >>>  mailto:pg...@gridgain.com>> wrote:
> >>>
> >>>  See attached for java, file-system, and tools
> >>>  documentation.
> >>>
> >>>  -P
> >>>
> >>>  On Fri, May 12, 2017 at 5:39 AM, 李玉珏@163
> >>>  <18624049...@163.com >
> >>> wrote:
> >>>  Prachi,
> >>>
> >>>
> >>>  Can you help me to export all the latest version
> of
> >>>  all documents to me?
> >>>  I am ready to make a synchronization of the
> chinese
> >>>  version of the document.
> >>>
> >>>  thanks!
> >>>
> >>>
> >>>  在 2017/3/18 04:54, Prachi Garg 写道:
>   Hi,
> 
>   Please see attached.
> 
>   -P
> 
>   On Fri, Mar 17, 2017 at 4:56 AM, 李玉珏@163
>   <18624049...@163.com  >>
>   wrote:
> 
>   Prachi,
> 
> 
>   Can you help me to export all the latest
>   version of all documents to me?
>   I am ready to make a synchronization of the
>   chinese version of the document.
> 
> 
>   在 2016/12/21 00:55, Prachi Garg 写道:
> >  Hi,
> >  I have attached the documentation for
> >  Hadoop/Spark and Integrations.
> >
> >  -Prachi
> >
> >  On Tue, Dec 20, 2016 at 6:50 AM, 李玉珏@163
> >  <18624049...@163.com
> >  > wrote:
> >
> >  Hi,
> >
> >
> >  Hadoop Accelerator，about MapR env's
> >  install and config,is this part of the
> >  document missing?
> >
> >
> >  在 2016/12/19 11:24, Denis Magda 写道:
> >>  Hi,
> >>
> >>  Yes, the documentation is stable.
> >>  Prachi, could you help out with the
> >