[GitHub] ignite pull request #3694: IGNITE-5819: SQL: add support for TRUNCATE TABLE ...

[shroman]

Github user shroman closed the pull request at:

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


---

Re: Apache Ignite 2.5 release

[Dmitriy Setrakyan]

On Fri, Apr 27, 2018 at 6:38 AM, Ivan Rakov  wrote:

> Folks,
>
> I have a fix for a critical issue related to WAL compaction:
> https://issues.apache.org/jira/browse/IGNITE-8393
> In short, if part of WAL archive is broken, attempt to compress it may
> result in spamming warnings in infinite loop.
> I think it's also worth being included in 2.5 release.
>

Let's include it, especially given that the fix is done.

Ivan, on another note, is WAL compaction described anywhere? What do we do
internally to compact WAL and by what factor are we able to reduce the WAL
file size?

D.

Re: Apache Ignite 2.5 release

[Ivan Rakov]

Folks,

I have a fix for a critical issue related to WAL compaction: 
https://issues.apache.org/jira/browse/IGNITE-8393
In short, if part of WAL archive is broken, attempt to compress it may 
result in spamming warnings in infinite loop.

I think it's also worth being included in 2.5 release.

Best Regards,
Ivan Rakov

On 26.04.2018 19:54, Igor Sapego wrote:

Cool, I've cherry-picked it to ignite-2.5 from master.

Best Regards,
Igor

On Thu, Apr 26, 2018 at 7:48 PM, Andrey Gura  wrote:


Igor,

Feel free to target ticket to 2.5 release.

Thanks!

On Thu, Apr 26, 2018 at 7:45 PM, Igor Sapego  wrote:

Hi guys,
I also have fix for a critical bug [1] which I'd like to include
in this release. It is OK?

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

Best Regards,
Igor

On Wed, Apr 25, 2018 at 8:19 PM, Andrey Gura  wrote:


Pavel,

looks like painful problem. I've targeted it to 2.5 release.

Thanks!

On Wed, Apr 25, 2018 at 8:15 PM, Dmitry Pavlov 
wrote:

Hi Pavel,

+1 from me, assertion in GridCachePartitionExchangeManager is to be

fixed

before release.

Sincerely,
Dmitriy Pavlov

ср, 25 апр. 2018 г. в 20:13, Pavel Kovalenko :


Igniters,

I've found blocker issue https://issues.apache.org/

jira/browse/IGNITE-8390

Cause of the problem is incorrect assertion that could be fixed very
quickly.
I would like to add this issue to 2.5 release.

2018-04-25 17:38 GMT+03:00 Andrey Gura :


Igniters,

We have about 30 JIRA issues that still aren't resolved. So it's
possible that release date will be changed.

But I think that it's time for scope freeze. Please, don't target

any

issues to 2.5 version without community approve.

Thanks.

On Fri, Apr 13, 2018 at 11:30 AM, Anton Vinogradov 

wrote:

Andrey, thanks for control :)

So, You'll fix broken versions eventually?

BTW, I don't think it's a good idea to merge issues with fix

version

2.5

to

ignite-2.5. Good way is to fix version to 2.6 instead.

2018-04-12 21:34 GMT+03:00 Andrey Gura :


Anton,

all is under control.

Branches will be compared and changes that should be included

to AI

2.5 will be identified.

On Thu, Apr 12, 2018 at 6:19 PM, Petr Ivanov <

mr.wei...@gmail.com>

wrote:

Possibly it is Andrey Gura — he initiated this thread and

created

corresponding branch.



On 12 Apr 2018, at 17:39, Anton Vinogradov 

wrote:

Release manager is responsible for this change.
Do we have release manager for 2.5?

2018-04-12 17:35 GMT+03:00 Dmitry Pavlov <

dpavlov@gmail.com

:

I've changed my ticket version assignment, and a lot of

Igniters

changed.

Filter for double-check tickets related to you
*https://issues.apache.org/jira/issues/?jql=project%
3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
20reporter%3DcurrentUser())
*


чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov <

a...@apache.org>:

Folks,
I see a lot of issues resolved as 2.5 but not merged to

ignite-2.5

branch.

Who is in charge of release 2.5, why (first time in

history)

nobody

changes

all 2.5 to 2.6?

2018-04-06 10:19 GMT+03:00 Petr Ivanov <

mr.wei...@gmail.com>:

Added corresponding triggers for ignite-2.5 in Ignite

Tests

2.4+

project

in TC.




On 5 Apr 2018, at 21:55, Denis Magda 

wrote:

Thanks Andrey!

Folks, if you'd like to add anything to 2.5 please make

sure it

gets

merged

into 2.5 branch.

--
Denis

On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura <

ag...@apache.org

wrote:

Hi,

I've created branch ignite-2.5 for Apache Ignite 2.5

release.

As always please follow the rules below when merging new

commits to

master:

1) If ticket is targeted for 2.5 release, please merge

to

master,

then

cherry-pick to ignite-2.5
2) Otherwise just merge to master.



On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura <

ag...@apache.org

wrote:

Igniters,

It's time to create branch for upcoming Apache Ignite

2.5

release

in

order to start stabilization process.

If there are no any objections I'll create ignite-2.5

branch

tomorrow.

Also please check JIRA issues assigned to you and move

it

to

the

next

version if this issues shouldn't be included to 2.5

release.

Release page on wiki [1] contains all issues targeted

to

2.5

(fix

version field).

[1] https://cwiki.apache.org/

confluence/display/IGNITE/

Apache+Ignite+2.5

Re: IEP-19: Optimize SQL indexes

[Dmitriy Setrakyan]

On Thu, Apr 26, 2018 at 9:09 PM, Vladimir Ozerov 
wrote:

> It is impossible to estimate what is more critical because it would require
> prototypes for every idea to estimate the impact. Instead, we should start
> working on the simplest things, such as IGINTE-8386 [1] or IGNITE-8384 [2].
> And then gradually swtich to more and more complex changes.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-8386
> [2] https://issues.apache.org/jira/browse/IGNITE-8384


Vladimir, there is no way for me to tell how his tickets affect any Ignite
users. What will change for our users.

I completely disagree about  about not prioritizing. We should identify how
critical the issues are for our users and start working on them in that
order.

D.

[jira] [Created] (IGNITE-8406) Update IgniteDataStreamer.flush() javadoc

[Andrey Kuznetsov (JIRA)]

Andrey Kuznetsov created IGNITE-8406:


 Summary: Update IgniteDataStreamer.flush() javadoc
 Key: IGNITE-8406
 URL: https://issues.apache.org/jira/browse/IGNITE-8406
 Project: Ignite
  Issue Type: Task
  Components: streaming
Affects Versions: 2.4
Reporter: Andrey Kuznetsov
 Fix For: 2.6


Current {{flush()}} implementation can throw {{CacheException}} if one or more 
futures previously returned by {{addData()}} have been completed exceptionally. 
This behavior should be described in {{IgniteDataStreamer}} javadoc.



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

[GitHub] ignite pull request #3929: IGNITE-8405 Update partition owners during exchan...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8405 Update partition owners during exchange in 1 operation



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

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

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

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


commit 158fa123464426a8188f60a6af0bfb04752a487d
Author: Pavel Kovalenko 
Date:   2018-04-26T17:55:57Z

IGNITE-8405 Update partition owners during exchange in 1 operation.




---

[jira] [Created] (IGNITE-8405) Sql query may see intermediate results of topology changes and do mapping incorrectly

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8405:
---

 Summary: Sql query may see intermediate results of topology 
changes and do mapping incorrectly
 Key: IGNITE-8405
 URL: https://issues.apache.org/jira/browse/IGNITE-8405
 Project: Ignite
  Issue Type: Bug
  Components: cache, sql
Affects Versions: 2.4
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko


Affected test: IgniteStableBaselineCacheQueryNodeRestartsSelfTest

Sql query do mapping in following way:
1) If there is at least 1 moving partition query will be mapped to current 
partition owners
2) In other case affinity mapping will be used.

In case of first approach query may see not final partition state if mapping 
happens during PME. There is "setOwners()" method which does partition movement 
one-by-one, each time obtaining topology write lock. If query mapping happens 
in this time it may see that there is some moving partition and performed 
mapping to OWNING partition which will be moved to MOVING on next "setOwners()" 
invocation.

As result we may query from invalid partitions.

As intermediate solution "setOwners()" method should be refactored in a batch 
way to perform ALL partitions state changes to MOVING in one operation.

As general solution query mapping should be revisited, especially 
"isPreloadingActive" method, to take into account given topology version.



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

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

[alamar]

GitHub user alamar opened a pull request:

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

Ignite client reassign



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

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

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

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


commit ef0a874ceb5c8bfa53e16337f6fd1699afaf2a39
Author: nikolay_tikhonov 
Date:   2017-06-30T17:39:01Z

Fixed CacheSerializableTransactionsTest#testTxConflictRemoveWithOldValue 
test.

Signed-off-by: nikolay_tikhonov 

commit 4dce965ea86374cba7265cb5d22e975aeac7d480
Author: nikolay_tikhonov 
Date:   2017-06-30T18:36:02Z

Fixed org.jsr107.tck.PutTest tests.

Signed-off-by: nikolay_tikhonov 

commit 32f1e394c222a6f4a2c111d6b6284c8626442b68
Author: Andrey V. Mashenkov 
Date:   2017-07-03T09:28:12Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

commit 50887fed508e03a8b7df32569afb6d84ab3eb670
Author: Igor Sapego 
Date:   2017-07-04T17:01:01Z

IGNITE-5663: ODBC: Closing cursor do not reset prepared statement anymore

commit da290cee855ef45a90ad539515e039f2826a6c00
Author: Igor Sapego 
Date:   2017-07-05T10:21:12Z

IGNITE-5663: Fix for test

commit 024a01d6bf91b4f301c4aee7f4a747e810a9a30b
Author: nikolay_tikhonov 
Date:   2017-07-05T15:58:00Z

Merged 1.7.12 into 1.8.9

Signed-off-by: nikolay_tikhonov 

commit 3536a58982e4c264bb72b2ccc1953049d2b5c67f
Author: Alexey Kukushkin 
Date:   2017-07-05T16:36:41Z

IGNITE-4901 Decrease logging level for DataStremer retry

commit 6d3a3ff2d99697882232070e715928336a9180cd
Author: Alexey Kukushkin 
Date:   2017-07-05T17:05:02Z

Fixed merge conflicts

commit aedc6aa8b17a39a6460c4b7f69255cd07d635bfb
Author: nikolay_tikhonov 
Date:   2017-07-05T17:42:15Z

Merge branch 'ignite-1.7.12' into ignite-1.9.4

Signed-off-by: nikolay_tikhonov 

commit acfc400b22738fa46397d392f88d49614e687969
Author: nikolay_tikhonov 
Date:   2017-07-05T17:42:48Z

Merge branch 'ignite-1.7.12' into ignite-1.9.4

Signed-off-by: nikolay_tikhonov 

commit 8dea19ba41bb9eda16f47933b2c46a081116d5f7
Author: Andrey V. Mashenkov 
Date:   2017-07-06T09:02:07Z

Minor fix.

commit f208f434f944196d531a1b51066dfe8d6394d739
Author: Andrey V. Mashenkov 
Date:   2017-07-06T12:17:50Z

Test fixed "IGNITE-5390: Bug in 
IgniteCacheTxStoreSessionWriteBehindCoalescingTest."

commit 355a5283559c885f57c4557bba2c6d9170a9b5fc
Author: mcherkasov 
Date:   2017-06-30T17:23:55Z

IGNITE-5554 ServiceProcessor may process failed reassignments in timeout 
thread

commit 92aa7c6e3c0d9b5cc68002433861b175d54f9421
Author: agura 
Date:   2017-07-04T13:56:40Z

ignite-5685 JDBC prepared statement shouldn't clear parameters after 
execution

commit 9165a0f93b5173b543cc6b4fad5fde37bd215f91
Author: Slava Koptilin 
Date:   2017-07-07T12:35:33Z

ignite-5562: assert statements were changed to the 'if' blocks

commit d9fc20a61d5ac0a6e63b26faa7fa0af753b2fa06
Author: Dmitriy Govorukhin 
Date:   2017-04-07T11:28:22Z

IGNITE-4889 - Changed Hibernate integration to use custom keys

(cherry picked from commit 6b62a20)

commit 16067300c9124b79bfee42139eb881ae585c0914
Author: Dmitriy Govorukhin 
Date:   2017-04-07T11:28:22Z

IGNITE-4889 - Changed Hibernate integration to use custom keys

(cherry picked from commit 6b62a20)

commit c82e25d67a2f6825a27d26933199a436f6eabba2
Author: Dmitriy Govorukhin 
Date:   2017-04-07T11:28:22Z

IGNITE-4889 - Changed Hibernate integration to use custom keys

(cherry picked from commit 6b62a20)

commit a352951d91edde9c0029a8bf435d61b4a7cd8c11
Author: Andrey V. Mashenkov 
Date:   2017-07-04T17:24:52Z

IGNITE-4831: Add an option to disable MBeans.

commit e4d141e97ab4ec34b5fe6a7bc599413223944438
Author: dkarachentsev 
Date:   2017-07-14T11:40:02Z

IGNITE-5103 - Server drops client node from cluster when no heartbeat 
messages received in interval heartBeatsFrequency * maxMissedClientHeartBeats.

commit 45573945066113fd29548699f23c2bc9f22cef36
Author: Tikhonov Nikolay 
Date:   2017-06-21T14:55:05Z

ignite-5489 Fixed possible connection leaks when loadPreviousValue set to 
true

commit 37535634ef3325aaf9923fd17d24038dfd5cee38
Author: agura 
Date:   

[GitHub] ignite pull request #3927: IGNITE-8393 Unexpected error during WAL compressi...

[glukos]

GitHub user glukos opened a pull request:

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

IGNITE-8393 Unexpected error during WAL compression



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

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

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

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


commit 216c18e9e1b46b019283f54e724c28e437715b58
Author: Ivan Rakov 
Date:   2018-04-26T17:12:29Z

IGNITE-8393 Unexpected error during WAL compression




---

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

[Vladimir Ozerov]

Guys,

I would start with estimating efforts rather than with release numbers. I
am not aware of any pressure or deadlines for AI 2.5. On the other hand
current behavior causes a lot of difficulties to our users and it is better
to focus on how to restore original behavior in the product ASAP. It could
be either AI 2.5 release if we understand that things could be fixed
quickly, or quick AI 2.6 release in a matter of month. What do you think?

As far as public API I would like to highlight the following important
points:
1) Affinity reassignment is critical for cluster stability so it should be
possible to change proposed settings in runtime
2) We should avoid exposing cache groups to API unless we agree on destiny
of thie feature. Hopefully, they would be removed.
3) From our previous experience we know that users typically having hard
times with multiple timeouts. If it possible to keep a single timeout, this
would be ideal
4) Another Ignite's pain point is interface - it is hard to deploy and
manage them in the cluster. For this reason I would avoid custom policy
altogether. Instead, use can listen for discovery events or poll cluster
state form MBeans or metrics and force AT reassignment manually.

Simmarizing all the points I would propose to have the following API:

interface IgniteCluster {
*boolean affinityTopologyAutoReassignmentEnabled;*
*long affinityTopologyAutoReassignmentTimeout;*

void setAffinityTopology(long topVer);
void setAffinityTopology(Collection nodes);
}

That is, only two new porperties are added. In order to force affinity
topology change to latest value user should do the following from any place
(event listener, monitoring thread, MXBean, control.sh, etc.):
setAffinityTopologyVersion(topologyVersion());

Thoughts?

Vladimir.

On Thu, Apr 26, 2018 at 7:27 PM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:

> Igniters,
>
> Ok, I want to share my thoughts about "affinity topology (AT) changing
> policies".
>
>
> There would be three major option:
> -auto;
> -manual;
> -custom.
>
> 1. Automatic change.
> A user could set timeouts for:
> a. change AT on any topology change after some timeout (setATChangeTimeout
> in seconds);
> b. change AT on node left after some timeout (setATChangeOnNodeLeftTimeout
> in seconds);
> c. change AT on node join after some timeout (setATChangeOnNodeJoinTimeout
> in seconds).
>
> b and c are more specific, so they would override a.
>
> Also, I want to introduce a mechanism of merging AT changes, which would be
> turned on by default.
> Other words, if we reached timeout than we would change AT to current
> topology, not that one which was on timeout schedule.
>
> 2. Manual change.
>
> Current behavior. A user change AT himself by console tools or web console.
>
> 3. Custom.
>
> We would give the option to set own realization of changing policy (class
> name in config).
> We should pass as incoming parameters:
> - current topology (collection of cluster nodes);
> - current AT (affinity topology);
> - map of GroupId to minimal alive backup number;
> - list of configuration (1.a, 1.b, 1.c);
> - scheduler.
>
> Plus to these configurations, I propose orthogonal option.
> 4. Emergency affinity topology change.
> It would change AT even MANUAL option is set if at least one cache group
> backup factor goes below  or equal chosen one (by default 0).
> So, if we came to situation when after node left there was only primary
> partion (without backups) for some cache group we would change AT
> immediately.
>
>
> Thank you for your attention.
>
>
> On Thu, Apr 26, 2018 at 6:57 PM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
>
> > Dmitriy,
> >
> > I also think that we should think about 2.6 as the target.
> >
> >
> > On Thu, Apr 26, 2018 at 3:27 PM, Alexey Goncharuk <
> > alexey.goncha...@gmail.com> wrote:
> >
> >> Dmitriy,
> >>
> >> I doubt we will be able to fit this in 2.5 given that we did not even
> >> agree
> >> on the policy interface. Forcing in-memory caches to use baseline
> topology
> >> will be an easy technical fix, however, we will need to update and
> >> probably
> >> fix lots of failover tests, add new ones.
> >>
> >> I think it makes sense to target this change to 2.6.
> >>
> >> 2018-04-25 22:25 GMT+03:00 Ilya Lantukh :
> >>
> >> > Eduard,
> >> >
> >> > I'm not sure I understand what you mean by "policy". Is it an
> interface
> >> > that will have a few default implementations and user will be able to
> >> > create his own one? If so, could you please write an example of such
> >> > interface (how you see it) and how and when it's methods will be
> >> invoked.
> >> >
> >> > On Wed, Apr 25, 2018 at 10:10 PM, Eduard Shangareev <
> >> > eduard.shangar...@gmail.com> wrote:
> >> >
> >> > > Igniters,
> >> > > I have described the issue with current approach in "New definition
> >> for
> >> > > affinity node (issues with baseline)" topic[1].
> >> > >
> >> > > Now we have 2 different affinity 

Re: Apache Ignite 2.5 release

[Igor Sapego]

Cool, I've cherry-picked it to ignite-2.5 from master.

Best Regards,
Igor

On Thu, Apr 26, 2018 at 7:48 PM, Andrey Gura  wrote:

> Igor,
>
> Feel free to target ticket to 2.5 release.
>
> Thanks!
>
> On Thu, Apr 26, 2018 at 7:45 PM, Igor Sapego  wrote:
> > Hi guys,
> > I also have fix for a critical bug [1] which I'd like to include
> > in this release. It is OK?
> >
> > [1] - https://issues.apache.org/jira/browse/IGNITE-8394
> >
> > Best Regards,
> > Igor
> >
> > On Wed, Apr 25, 2018 at 8:19 PM, Andrey Gura  wrote:
> >
> >> Pavel,
> >>
> >> looks like painful problem. I've targeted it to 2.5 release.
> >>
> >> Thanks!
> >>
> >> On Wed, Apr 25, 2018 at 8:15 PM, Dmitry Pavlov 
> >> wrote:
> >> > Hi Pavel,
> >> >
> >> > +1 from me, assertion in GridCachePartitionExchangeManager is to be
> >> fixed
> >> > before release.
> >> >
> >> > Sincerely,
> >> > Dmitriy Pavlov
> >> >
> >> > ср, 25 апр. 2018 г. в 20:13, Pavel Kovalenko :
> >> >
> >> >> Igniters,
> >> >>
> >> >> I've found blocker issue https://issues.apache.org/
> >> jira/browse/IGNITE-8390
> >> >> Cause of the problem is incorrect assertion that could be fixed very
> >> >> quickly.
> >> >> I would like to add this issue to 2.5 release.
> >> >>
> >> >> 2018-04-25 17:38 GMT+03:00 Andrey Gura :
> >> >>
> >> >> > Igniters,
> >> >> >
> >> >> > We have about 30 JIRA issues that still aren't resolved. So it's
> >> >> > possible that release date will be changed.
> >> >> >
> >> >> > But I think that it's time for scope freeze. Please, don't target
> any
> >> >> > issues to 2.5 version without community approve.
> >> >> >
> >> >> > Thanks.
> >> >> >
> >> >> > On Fri, Apr 13, 2018 at 11:30 AM, Anton Vinogradov 
> >> >> wrote:
> >> >> > > Andrey, thanks for control :)
> >> >> > >
> >> >> > > So, You'll fix broken versions eventually?
> >> >> > >
> >> >> > > BTW, I don't think it's a good idea to merge issues with fix
> version
> >> >> 2.5
> >> >> > to
> >> >> > > ignite-2.5. Good way is to fix version to 2.6 instead.
> >> >> > >
> >> >> > > 2018-04-12 21:34 GMT+03:00 Andrey Gura :
> >> >> > >
> >> >> > >> Anton,
> >> >> > >>
> >> >> > >> all is under control.
> >> >> > >>
> >> >> > >> Branches will be compared and changes that should be included
> to AI
> >> >> > >> 2.5 will be identified.
> >> >> > >>
> >> >> > >> On Thu, Apr 12, 2018 at 6:19 PM, Petr Ivanov <
> mr.wei...@gmail.com>
> >> >> > wrote:
> >> >> > >> > Possibly it is Andrey Gura — he initiated this thread and
> created
> >> >> > >> corresponding branch.
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >> On 12 Apr 2018, at 17:39, Anton Vinogradov 
> >> wrote:
> >> >> > >> >>
> >> >> > >> >> Release manager is responsible for this change.
> >> >> > >> >> Do we have release manager for 2.5?
> >> >> > >> >>
> >> >> > >> >> 2018-04-12 17:35 GMT+03:00 Dmitry Pavlov <
> dpavlov@gmail.com
> >> >:
> >> >> > >> >>
> >> >> > >> >>> I've changed my ticket version assignment, and a lot of
> >> Igniters
> >> >> > >> changed.
> >> >> > >> >>>
> >> >> > >> >>> Filter for double-check tickets related to you
> >> >> > >> >>> *https://issues.apache.org/jira/issues/?jql=project%
> >> >> > >> >>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
> >> >> > >> >>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
> >> >> > >> >>> 20reporter%3DcurrentUser())
> >> >> > >> >>>  >> >> > >> >>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
> >> >> > >> >>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
> >> >> > >> >>> 20reporter%3DcurrentUser())>*
> >> >> > >> >>>
> >> >> > >> >>>
> >> >> > >> >>> чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov <
> a...@apache.org>:
> >> >> > >> >>>
> >> >> > >>  Folks,
> >> >> > >>  I see a lot of issues resolved as 2.5 but not merged to
> >> >> ignite-2.5
> >> >> > >> >>> branch.
> >> >> > >> 
> >> >> > >>  Who is in charge of release 2.5, why (first time in
> history)
> >> >> nobody
> >> >> > >> >>> changes
> >> >> > >>  all 2.5 to 2.6?
> >> >> > >> 
> >> >> > >>  2018-04-06 10:19 GMT+03:00 Petr Ivanov <
> mr.wei...@gmail.com>:
> >> >> > >> 
> >> >> > >> > Added corresponding triggers for ignite-2.5 in Ignite
> Tests
> >> 2.4+
> >> >> > >> >>> project
> >> >> > >> > in TC.
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >
> >> >> > >> >> On 5 Apr 2018, at 21:55, Denis Magda 
> >> >> wrote:
> >> >> > >> >>
> >> >> > >> >> Thanks Andrey!
> >> >> > >> >>
> >> >> > >> >> Folks, if you'd like to add anything to 2.5 please make
> >> sure it
> >> >> > gets
> >> >> > >> > merged
> >> >> > >> >> into 2.5 branch.
> >> >> > >> >>
> >> >> > >> >> --
> >> >> > >> >> Denis
> >> >> > >> >>
> >> >> > >> >> On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura 

Re: Apache Ignite 2.5 release

[Andrey Gura]

Igor,

Feel free to target ticket to 2.5 release.

Thanks!

On Thu, Apr 26, 2018 at 7:45 PM, Igor Sapego  wrote:
> Hi guys,
> I also have fix for a critical bug [1] which I'd like to include
> in this release. It is OK?
>
> [1] - https://issues.apache.org/jira/browse/IGNITE-8394
>
> Best Regards,
> Igor
>
> On Wed, Apr 25, 2018 at 8:19 PM, Andrey Gura  wrote:
>
>> Pavel,
>>
>> looks like painful problem. I've targeted it to 2.5 release.
>>
>> Thanks!
>>
>> On Wed, Apr 25, 2018 at 8:15 PM, Dmitry Pavlov 
>> wrote:
>> > Hi Pavel,
>> >
>> > +1 from me, assertion in GridCachePartitionExchangeManager is to be
>> fixed
>> > before release.
>> >
>> > Sincerely,
>> > Dmitriy Pavlov
>> >
>> > ср, 25 апр. 2018 г. в 20:13, Pavel Kovalenko :
>> >
>> >> Igniters,
>> >>
>> >> I've found blocker issue https://issues.apache.org/
>> jira/browse/IGNITE-8390
>> >> Cause of the problem is incorrect assertion that could be fixed very
>> >> quickly.
>> >> I would like to add this issue to 2.5 release.
>> >>
>> >> 2018-04-25 17:38 GMT+03:00 Andrey Gura :
>> >>
>> >> > Igniters,
>> >> >
>> >> > We have about 30 JIRA issues that still aren't resolved. So it's
>> >> > possible that release date will be changed.
>> >> >
>> >> > But I think that it's time for scope freeze. Please, don't target any
>> >> > issues to 2.5 version without community approve.
>> >> >
>> >> > Thanks.
>> >> >
>> >> > On Fri, Apr 13, 2018 at 11:30 AM, Anton Vinogradov 
>> >> wrote:
>> >> > > Andrey, thanks for control :)
>> >> > >
>> >> > > So, You'll fix broken versions eventually?
>> >> > >
>> >> > > BTW, I don't think it's a good idea to merge issues with fix version
>> >> 2.5
>> >> > to
>> >> > > ignite-2.5. Good way is to fix version to 2.6 instead.
>> >> > >
>> >> > > 2018-04-12 21:34 GMT+03:00 Andrey Gura :
>> >> > >
>> >> > >> Anton,
>> >> > >>
>> >> > >> all is under control.
>> >> > >>
>> >> > >> Branches will be compared and changes that should be included to AI
>> >> > >> 2.5 will be identified.
>> >> > >>
>> >> > >> On Thu, Apr 12, 2018 at 6:19 PM, Petr Ivanov 
>> >> > wrote:
>> >> > >> > Possibly it is Andrey Gura — he initiated this thread and created
>> >> > >> corresponding branch.
>> >> > >> >
>> >> > >> >
>> >> > >> >> On 12 Apr 2018, at 17:39, Anton Vinogradov 
>> wrote:
>> >> > >> >>
>> >> > >> >> Release manager is responsible for this change.
>> >> > >> >> Do we have release manager for 2.5?
>> >> > >> >>
>> >> > >> >> 2018-04-12 17:35 GMT+03:00 Dmitry Pavlov > >:
>> >> > >> >>
>> >> > >> >>> I've changed my ticket version assignment, and a lot of
>> Igniters
>> >> > >> changed.
>> >> > >> >>>
>> >> > >> >>> Filter for double-check tickets related to you
>> >> > >> >>> *https://issues.apache.org/jira/issues/?jql=project%
>> >> > >> >>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
>> >> > >> >>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
>> >> > >> >>> 20reporter%3DcurrentUser())
>> >> > >> >>> > >> > >> >>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
>> >> > >> >>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
>> >> > >> >>> 20reporter%3DcurrentUser())>*
>> >> > >> >>>
>> >> > >> >>>
>> >> > >> >>> чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov :
>> >> > >> >>>
>> >> > >>  Folks,
>> >> > >>  I see a lot of issues resolved as 2.5 but not merged to
>> >> ignite-2.5
>> >> > >> >>> branch.
>> >> > >> 
>> >> > >>  Who is in charge of release 2.5, why (first time in history)
>> >> nobody
>> >> > >> >>> changes
>> >> > >>  all 2.5 to 2.6?
>> >> > >> 
>> >> > >>  2018-04-06 10:19 GMT+03:00 Petr Ivanov :
>> >> > >> 
>> >> > >> > Added corresponding triggers for ignite-2.5 in Ignite Tests
>> 2.4+
>> >> > >> >>> project
>> >> > >> > in TC.
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> >> On 5 Apr 2018, at 21:55, Denis Magda 
>> >> wrote:
>> >> > >> >>
>> >> > >> >> Thanks Andrey!
>> >> > >> >>
>> >> > >> >> Folks, if you'd like to add anything to 2.5 please make
>> sure it
>> >> > gets
>> >> > >> > merged
>> >> > >> >> into 2.5 branch.
>> >> > >> >>
>> >> > >> >> --
>> >> > >> >> Denis
>> >> > >> >>
>> >> > >> >> On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura <
>> ag...@apache.org
>> >> >
>> >> > >> >>> wrote:
>> >> > >> >>
>> >> > >> >>> Hi,
>> >> > >> >>>
>> >> > >> >>> I've created branch ignite-2.5 for Apache Ignite 2.5
>> release.
>> >> > >> >>>
>> >> > >> >>> As always please follow the rules below when merging new
>> >> > commits to
>> >> > >> > master:
>> >> > >> >>>
>> >> > >> >>> 1) If ticket is targeted for 2.5 release, please merge to
>> >> > master,
>> >> > 

[GitHub] ignite pull request #3925: IGNITE-8394: ODBC: Fixed async establishing of SS...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Apache Ignite 2.5 release

[Igor Sapego]

Hi guys,
I also have fix for a critical bug [1] which I'd like to include
in this release. It is OK?

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

Best Regards,
Igor

On Wed, Apr 25, 2018 at 8:19 PM, Andrey Gura  wrote:

> Pavel,
>
> looks like painful problem. I've targeted it to 2.5 release.
>
> Thanks!
>
> On Wed, Apr 25, 2018 at 8:15 PM, Dmitry Pavlov 
> wrote:
> > Hi Pavel,
> >
> > +1 from me, assertion in GridCachePartitionExchangeManager is to be
> fixed
> > before release.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > ср, 25 апр. 2018 г. в 20:13, Pavel Kovalenko :
> >
> >> Igniters,
> >>
> >> I've found blocker issue https://issues.apache.org/
> jira/browse/IGNITE-8390
> >> Cause of the problem is incorrect assertion that could be fixed very
> >> quickly.
> >> I would like to add this issue to 2.5 release.
> >>
> >> 2018-04-25 17:38 GMT+03:00 Andrey Gura :
> >>
> >> > Igniters,
> >> >
> >> > We have about 30 JIRA issues that still aren't resolved. So it's
> >> > possible that release date will be changed.
> >> >
> >> > But I think that it's time for scope freeze. Please, don't target any
> >> > issues to 2.5 version without community approve.
> >> >
> >> > Thanks.
> >> >
> >> > On Fri, Apr 13, 2018 at 11:30 AM, Anton Vinogradov 
> >> wrote:
> >> > > Andrey, thanks for control :)
> >> > >
> >> > > So, You'll fix broken versions eventually?
> >> > >
> >> > > BTW, I don't think it's a good idea to merge issues with fix version
> >> 2.5
> >> > to
> >> > > ignite-2.5. Good way is to fix version to 2.6 instead.
> >> > >
> >> > > 2018-04-12 21:34 GMT+03:00 Andrey Gura :
> >> > >
> >> > >> Anton,
> >> > >>
> >> > >> all is under control.
> >> > >>
> >> > >> Branches will be compared and changes that should be included to AI
> >> > >> 2.5 will be identified.
> >> > >>
> >> > >> On Thu, Apr 12, 2018 at 6:19 PM, Petr Ivanov 
> >> > wrote:
> >> > >> > Possibly it is Andrey Gura — he initiated this thread and created
> >> > >> corresponding branch.
> >> > >> >
> >> > >> >
> >> > >> >> On 12 Apr 2018, at 17:39, Anton Vinogradov 
> wrote:
> >> > >> >>
> >> > >> >> Release manager is responsible for this change.
> >> > >> >> Do we have release manager for 2.5?
> >> > >> >>
> >> > >> >> 2018-04-12 17:35 GMT+03:00 Dmitry Pavlov  >:
> >> > >> >>
> >> > >> >>> I've changed my ticket version assignment, and a lot of
> Igniters
> >> > >> changed.
> >> > >> >>>
> >> > >> >>> Filter for double-check tickets related to you
> >> > >> >>> *https://issues.apache.org/jira/issues/?jql=project%
> >> > >> >>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
> >> > >> >>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
> >> > >> >>> 20reporter%3DcurrentUser())
> >> > >> >>>  >> > >> >>> 3DIGNITE%20AND%20fixVersion%3D2.5%20and%20resolution%20is%
> >> > >> >>> 20EMPTY%20%20and%20(assignee%3DcurrentUser()%20or%
> >> > >> >>> 20reporter%3DcurrentUser())>*
> >> > >> >>>
> >> > >> >>>
> >> > >> >>> чт, 12 апр. 2018 г. в 17:24, Anton Vinogradov :
> >> > >> >>>
> >> > >>  Folks,
> >> > >>  I see a lot of issues resolved as 2.5 but not merged to
> >> ignite-2.5
> >> > >> >>> branch.
> >> > >> 
> >> > >>  Who is in charge of release 2.5, why (first time in history)
> >> nobody
> >> > >> >>> changes
> >> > >>  all 2.5 to 2.6?
> >> > >> 
> >> > >>  2018-04-06 10:19 GMT+03:00 Petr Ivanov :
> >> > >> 
> >> > >> > Added corresponding triggers for ignite-2.5 in Ignite Tests
> 2.4+
> >> > >> >>> project
> >> > >> > in TC.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >> On 5 Apr 2018, at 21:55, Denis Magda 
> >> wrote:
> >> > >> >>
> >> > >> >> Thanks Andrey!
> >> > >> >>
> >> > >> >> Folks, if you'd like to add anything to 2.5 please make
> sure it
> >> > gets
> >> > >> > merged
> >> > >> >> into 2.5 branch.
> >> > >> >>
> >> > >> >> --
> >> > >> >> Denis
> >> > >> >>
> >> > >> >> On Thu, Apr 5, 2018 at 11:29 AM, Andrey Gura <
> ag...@apache.org
> >> >
> >> > >> >>> wrote:
> >> > >> >>
> >> > >> >>> Hi,
> >> > >> >>>
> >> > >> >>> I've created branch ignite-2.5 for Apache Ignite 2.5
> release.
> >> > >> >>>
> >> > >> >>> As always please follow the rules below when merging new
> >> > commits to
> >> > >> > master:
> >> > >> >>>
> >> > >> >>> 1) If ticket is targeted for 2.5 release, please merge to
> >> > master,
> >> > >> >>> then
> >> > >> >>> cherry-pick to ignite-2.5
> >> > >> >>> 2) Otherwise just merge to master.
> >> > >> >>>
> >> > >> >>>
> >> > >> >>>
> >> > >> >>> On Wed, Apr 4, 2018 at 9:11 PM, Andrey Gura <
> ag...@apache.org
> >> >
> >> > >> >>> wrote:
> >> > >> 

[GitHub] ignite pull request #3818: IGNITE-8237 Ignite blocks on SecurityException in...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8404) NPE when shutting down non-initialized mapped file memory provier

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8404:


 Summary: NPE when shutting down non-initialized mapped file memory 
provier
 Key: IGNITE-8404
 URL: https://issues.apache.org/jira/browse/IGNITE-8404
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk


If a node has mapped file memory provider and node initialization fails, I get 
the following exception:
{code}
java.lang.NullPointerException
at 
org.apache.ignite.internal.mem.file.MappedFileMemoryProvider.shutdown(MappedFileMemoryProvider.java:97)
at 
org.apache.ignite.internal.pagemem.impl.PageMemoryNoStoreImpl.stop(PageMemoryNoStoreImpl.java:239)
at 
org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.stop0(IgniteCacheDatabaseSharedManager.java:649)
at 
org.apache.ignite.internal.processors.cache.GridCacheSharedManagerAdapter.stop(GridCacheSharedManagerAdapter.java:94)
at 
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stop(GridCacheProcessor.java:888)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2109)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:1987)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1074)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1973)
at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1716)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1144)
at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1062)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:948)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:847)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:717)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:686)
at org.apache.ignite.Ignition.start(Ignition.java:347)
at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
{code}

The cause is obvious - we try to access an uninitialized field.



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

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

[Eduard Shangareev]

Igniters,

Ok, I want to share my thoughts about "affinity topology (AT) changing
policies".


There would be three major option:
-auto;
-manual;
-custom.

1. Automatic change.
A user could set timeouts for:
a. change AT on any topology change after some timeout (setATChangeTimeout
in seconds);
b. change AT on node left after some timeout (setATChangeOnNodeLeftTimeout
in seconds);
c. change AT on node join after some timeout (setATChangeOnNodeJoinTimeout
in seconds).

b and c are more specific, so they would override a.

Also, I want to introduce a mechanism of merging AT changes, which would be
turned on by default.
Other words, if we reached timeout than we would change AT to current
topology, not that one which was on timeout schedule.

2. Manual change.

Current behavior. A user change AT himself by console tools or web console.

3. Custom.

We would give the option to set own realization of changing policy (class
name in config).
We should pass as incoming parameters:
- current topology (collection of cluster nodes);
- current AT (affinity topology);
- map of GroupId to minimal alive backup number;
- list of configuration (1.a, 1.b, 1.c);
- scheduler.

Plus to these configurations, I propose orthogonal option.
4. Emergency affinity topology change.
It would change AT even MANUAL option is set if at least one cache group
backup factor goes below  or equal chosen one (by default 0).
So, if we came to situation when after node left there was only primary
partion (without backups) for some cache group we would change AT
immediately.


Thank you for your attention.


On Thu, Apr 26, 2018 at 6:57 PM, Eduard Shangareev <
eduard.shangar...@gmail.com> wrote:

> Dmitriy,
>
> I also think that we should think about 2.6 as the target.
>
>
> On Thu, Apr 26, 2018 at 3:27 PM, Alexey Goncharuk <
> alexey.goncha...@gmail.com> wrote:
>
>> Dmitriy,
>>
>> I doubt we will be able to fit this in 2.5 given that we did not even
>> agree
>> on the policy interface. Forcing in-memory caches to use baseline topology
>> will be an easy technical fix, however, we will need to update and
>> probably
>> fix lots of failover tests, add new ones.
>>
>> I think it makes sense to target this change to 2.6.
>>
>> 2018-04-25 22:25 GMT+03:00 Ilya Lantukh :
>>
>> > Eduard,
>> >
>> > I'm not sure I understand what you mean by "policy". Is it an interface
>> > that will have a few default implementations and user will be able to
>> > create his own one? If so, could you please write an example of such
>> > interface (how you see it) and how and when it's methods will be
>> invoked.
>> >
>> > On Wed, Apr 25, 2018 at 10:10 PM, Eduard Shangareev <
>> > eduard.shangar...@gmail.com> wrote:
>> >
>> > > Igniters,
>> > > I have described the issue with current approach in "New definition
>> for
>> > > affinity node (issues with baseline)" topic[1].
>> > >
>> > > Now we have 2 different affinity topology (one for in-memory, another
>> for
>> > > persistent caches).
>> > >
>> > > It causes problems:
>> > > - we lose (in general) co-location between different caches;
>> > > - we can't avoid PME when non-BLAT node joins cluster;
>> > > - implementation should consider 2 different approaches to affinity
>> > > calculation.
>> > >
>> > > So, I suggest unifying behavior of in-memory and persistent caches.
>> > > They should all use BLAT.
>> > >
>> > > Their behaviors were different because we couldn't guarantee the
>> safety
>> > of
>> > > in-memory data.
>> > > It should be fixed by a new mechanism of BLAT changing policy which
>> was
>> > > already discussed there - "Triggering rebalancing on timeout or
>> manually
>> > if
>> > > the baseline topology is not reassembled" [2].
>> > >
>> > > And we should have a policy by default which similar to current one
>> > > (add nodes, remove nodes automatically but after some reasonable delay
>> > > [seconds]).
>> > >
>> > > After this change, we could stop using the term 'BLAT', Basline and so
>> > on.
>> > > Because there would not be an alternative. So, it would be only one
>> > > possible Affinity Topology.
>> > >
>> > >
>> > > [1]
>> > > http://apache-ignite-developers.2346864.n4.nabble.
>> > com/New-definition-for-
>> > > affinity-node-issues-with-baseline-td29868.html
>> > > [2]
>> > > http://apache-ignite-developers.2346864.n4.nabble.
>> > > com/Triggering-rebalancing-on-timeout-or-manually-if-the-
>> > > baseline-topology-is-not-reassembled-td29299.html#none
>> > >
>> >
>> >
>> >
>> > --
>> > Best regards,
>> > Ilya
>> >
>>
>
>

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

[Eduard Shangareev]

Dmitriy,

I also think that we should think about 2.6 as the target.


On Thu, Apr 26, 2018 at 3:27 PM, Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Dmitriy,
>
> I doubt we will be able to fit this in 2.5 given that we did not even agree
> on the policy interface. Forcing in-memory caches to use baseline topology
> will be an easy technical fix, however, we will need to update and probably
> fix lots of failover tests, add new ones.
>
> I think it makes sense to target this change to 2.6.
>
> 2018-04-25 22:25 GMT+03:00 Ilya Lantukh :
>
> > Eduard,
> >
> > I'm not sure I understand what you mean by "policy". Is it an interface
> > that will have a few default implementations and user will be able to
> > create his own one? If so, could you please write an example of such
> > interface (how you see it) and how and when it's methods will be invoked.
> >
> > On Wed, Apr 25, 2018 at 10:10 PM, Eduard Shangareev <
> > eduard.shangar...@gmail.com> wrote:
> >
> > > Igniters,
> > > I have described the issue with current approach in "New definition for
> > > affinity node (issues with baseline)" topic[1].
> > >
> > > Now we have 2 different affinity topology (one for in-memory, another
> for
> > > persistent caches).
> > >
> > > It causes problems:
> > > - we lose (in general) co-location between different caches;
> > > - we can't avoid PME when non-BLAT node joins cluster;
> > > - implementation should consider 2 different approaches to affinity
> > > calculation.
> > >
> > > So, I suggest unifying behavior of in-memory and persistent caches.
> > > They should all use BLAT.
> > >
> > > Their behaviors were different because we couldn't guarantee the safety
> > of
> > > in-memory data.
> > > It should be fixed by a new mechanism of BLAT changing policy which was
> > > already discussed there - "Triggering rebalancing on timeout or
> manually
> > if
> > > the baseline topology is not reassembled" [2].
> > >
> > > And we should have a policy by default which similar to current one
> > > (add nodes, remove nodes automatically but after some reasonable delay
> > > [seconds]).
> > >
> > > After this change, we could stop using the term 'BLAT', Basline and so
> > on.
> > > Because there would not be an alternative. So, it would be only one
> > > possible Affinity Topology.
> > >
> > >
> > > [1]
> > > http://apache-ignite-developers.2346864.n4.nabble.
> > com/New-definition-for-
> > > affinity-node-issues-with-baseline-td29868.html
> > > [2]
> > > http://apache-ignite-developers.2346864.n4.nabble.
> > > com/Triggering-rebalancing-on-timeout-or-manually-if-the-
> > > baseline-topology-is-not-reassembled-td29299.html#none
> > >
> >
> >
> >
> > --
> > Best regards,
> > Ilya
> >
>

Re: Apache Ignite nightly release builds

[Petr Ivanov]

Hi, Igniters!


Some more news about Apache Ignite Nightly build:
 - added docker image in form of compressed image tar.gz archive;
 - added DEB and RPM packages.

All latest artifacts as always available here: [1]


Enjoy!


[1] 
https://ci.ignite.apache.org/viewLog.html?buildId=lastSuccessful=Releases_NightlyRelease_RunApacheIgniteNightlyRelease=artifacts=1




> On 16 Apr 2018, at 11:49, Petr Ivanov  wrote:
> 
> Hi, Igniters!
> 
> 
> I’m glad to inform that starting today Apache Ignite Nightly Builds provide 
> Nuget and Maven stagings at MyGet [1].
> 
> Instructions on connecting to these feeds are here:
>  — Nuget [2]
>  — Maven [3]
> 
> 
> Enjoy.
> 
> 
> [1] https://www.myget.org/gallery/apache-ignite-nightly 
> 
> [2] http://docs.myget.org/docs/walkthrough/getting-started-with-nuget 
> 
> [3] http://docs.myget.org/docs/walkthrough/getting-started-with-maven 
> 
> 
>> On 24 Mar 2018, at 11:42, Dmitriy Setrakyan > > wrote:
>> 
>> Thanks, Denis. It should be added to the download page, I updated the ticket.
>> 
>> On Sat, Mar 24, 2018 at 5:48 AM, Denis Magda > > wrote:
>> Created a JIRA ticket for that:
>> https://issues.apache.org/jira/browse/IGNITE-8040 
>> 
>> 
>> --
>> Denis
>> 
>> On Fri, Mar 23, 2018 at 1:27 AM, Dmitriy Setrakyan > >
>> wrote:
>> 
>> > Awesome! Finally instead of asking our users to build from the master, we
>> > can provide a link to the nightly build instead.
>> >
>> > Denis, can you please add these links to the website?
>> >
>> > D.
>> >
>> > On Thu, Mar 22, 2018 at 1:27 PM, Petr Ivanov > > > wrote:
>> >
>> >> It works, thanks!
>> >>
>> >>
>> >> Here is updated links for Artifacts and Changes respectively with silent
>> >> guest login (can be added to bookmarks):
>> >> * https://ci.ignite.apache.org/viewLog.html?buildId=lastSucces 
>> >> 
>> >> sful=Releases_NightlyRelease_RunApacheIgnite
>> >> NightlyRelease=artifacts=1
>> >> * https://ci.ignite.apache.org/viewLog.html?buildId=lastSucces 
>> >> 
>> >> sful=Releases_NightlyRelease_RunApacheIgnite
>> >> NightlyRelease=buildChangesDiv=1
>> >>
>> >>
>> >>
>> >> > On 22 Mar 2018, at 13:06, Vitaliy Osipov > >> > > wrote:
>> >> >
>> >> > 
>> >>
>> >>
>> >
>> 
> 

[GitHub] ignite pull request #3669: Ignite-2.3.3.b2

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---

[GitHub] ignite pull request #3022: Ignite-1.9.8.b1

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---

[GitHub] ignite pull request #3786: Ignite 2.4.4.b2

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---

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

[AMashenkov]

Github user AMashenkov closed the pull request at:

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


---

[GitHub] ignite pull request #3926: Ignite 640

[amirakhmedov]

GitHub user amirakhmedov opened a pull request:

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

Ignite 640



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

$ git pull https://github.com/amirakhmedov/ignite IGNITE-640

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

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


commit 4823e87142c6458a96dea876a6d9d30338867cc2
Author: Amir Akhmedov 
Date:   2018-04-05T03:07:23Z

IGNITE-640: multimap initial commit

commit c3110c1bcb2a04affcf13a82bfae1ad34ab172d8
Author: Amir Akhmedov 
Date:   2018-04-18T03:53:59Z

IGNITE-640: multimap get and getAll implementation

commit 1b0396ea8c58ec5cafef740169a80f7dfc786c6c
Author: Amir Akhmedov 
Date:   2018-04-18T04:04:33Z

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

commit 8e7747ad3791dec8214d0b0e6e03f9e531dfee07
Author: Amir Akhmedov 
Date:   2018-04-26T14:36:37Z

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

commit 1a581c52407f00a52474c4a3abe7e59c86f76e6a
Author: Amir Akhmedov 
Date:   2018-04-26T14:39:33Z

IGNITE-640: ignite multimap implementation (first iteration)




---

[GitHub] ignite pull request #3925: ODBC: Fixed async establishing of SSL connection ...

[isapego]

GitHub user isapego opened a pull request:

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

ODBC: Fixed async establishing of SSL connection to remote host



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

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

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

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






---

[GitHub] ignite pull request #3924: IGNITE-8403: Added Logistic Regression

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-8403: Added Logistic Regression

Also fixed a few examples with out-of-date information

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

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

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

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


commit d60ace95c3b6bc24b0d5087962ac18a4c1613a16
Author: zaleslaw 
Date:   2018-04-19T16:09:01Z

LogRegression

commit d98b122cca699dd91378b784e1aad85d8afaef84
Author: zaleslaw 
Date:   2018-04-26T14:12:59Z

Fixed LogRegression and added tests

commit 4b628f8f6b40e1b1cd514232bd553f92037a2ea2
Author: zaleslaw 
Date:   2018-04-26T14:15:10Z

Merge branch 'master' into ignite-8403




---

[jira] [Created] (IGNITE-8403) [ML] Add Binary Logistic Regression based on partitioned datasets and MLP

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8403:


 Summary: [ML] Add Binary Logistic Regression based on partitioned 
datasets and MLP
 Key: IGNITE-8403
 URL: https://issues.apache.org/jira/browse/IGNITE-8403
 Project: Ignite
  Issue Type: New Feature
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[jira] [Created] (IGNITE-8402) Long running transaction JMX

[Ivan Kapralov (JIRA)]

Ivan Kapralov created IGNITE-8402:
-

 Summary: Long running transaction JMX
 Key: IGNITE-8402
 URL: https://issues.apache.org/jira/browse/IGNITE-8402
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.4
Reporter: Ivan Kapralov
 Fix For: None


Facing necessity in Long Running Transactions JMX metric implementation.

Needed: transaction start time, node ID, duration, cache ID, originator ID 
comma separated in the same string. Info about transactions that are hung up 
for more than 600 sec.

 



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

[GitHub] ignite pull request #3923: IGNITE-6528 Print warnings when actual data type ...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-6528 Print warnings when actual data type not equal to expected 
Indexed Type.



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

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

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

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


commit 925ad48468f82053005031f3b5b5eca85323b019
Author: Ilya Kasnacheev 
Date:   2018-04-26T13:40:27Z

IGNITE-6528 Print warnings when actual data type not equal to expected 
Indexed Type.




---

[GitHub] ignite pull request #3922: IGNITE-8400 IgniteTopologyValidatorGridSplitCache...

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-8400 IgniteTopologyValidatorGridSplitCacheTest.testTopologyVal…

…idatorWithCacheGroup node failure fix

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

$ git pull https://github.com/alex-plekhanov/ignite ignite-8400

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

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


commit 7c68ac55dd9ec9957b7bf0769811ee7a0663325a
Author: Aleksey Plekhanov 
Date:   2018-04-26T13:27:51Z

IGNITE-8400 
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup 
node failure fix (50 times)




---

[GitHub] ignite pull request #3917: IGNITE-8390 Fixed incorrect assertion during WAL ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: IEP-19: Optimize SQL indexes

[Vladimir Ozerov]

It is impossible to estimate what is more critical because it would require
prototypes for every idea to estimate the impact. Instead, we should start
working on the simplest things, such as IGINTE-8386 [1] or IGNITE-8384 [2].
And then gradually swtich to more and more complex changes.

[1] https://issues.apache.org/jira/browse/IGNITE-8386
[2] https://issues.apache.org/jira/browse/IGNITE-8384

On Wed, Apr 25, 2018 at 10:02 PM, Dmitriy Setrakyan 
wrote:

> Thanks, Vladimir!
>
> Looking at this IEP, it is not clear which tickets are more critical than
> others. Also, the complexity of each ticket is unknown. Is there a way to
> provide this information?
>
> D.
>
> On Wed, Apr 25, 2018 at 10:21 PM, Vladimir Ozerov 
> wrote:
>
> > Igniters,
> >
> > I heard a lot of complains around performance of our SQL indexes.
> Notably -
> > slow updates and slow execution of CREATE INDEX command on large data
> sets.
> > I summarized all known possible optimizations under a single IEP [1]. We
> > need to start working in this direction, starting from the most simple
> and
> > obvious things.
> >
> > Please feel free to review IEP tickets and share additional suggestions
> or
> > comments or what else could be done to make our indexes faster.
> >
> > Vladimir.
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 19%3A+SQL+index+update+optimizations
> >
>

[jira] [Created] (IGNITE-8401) Assertion error ocurred in JettyRestProcessorAuthenticationWithCredsSelfTest

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-8401:
--

 Summary: Assertion error ocurred in 
JettyRestProcessorAuthenticationWithCredsSelfTest
 Key: IGNITE-8401
 URL: https://issues.apache.org/jira/browse/IGNITE-8401
 Project: Ignite
  Issue Type: Improvement
Reporter: Dmitriy Pavlov
Assignee: Stanilovsky Evgeny


Following tests began to fail after merge 

https://issues.apache.org/jira/browse/IGNITE-8066

with assertion added in this ticket.

*IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testDeactivateActivate[ (fail 
rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2035731000398727816=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testRemove[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5513793448643455005=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testRemoveAll[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-1721357182035817455=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithCredsSelfTest.testVisorGateway[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-2028785123619746743=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testDeactivateActivate[ (fail 
rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-334626288130660999=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testRemove[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-5504915680838168777=%3Cdefault%3E=testDetails]*
      *IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testRemoveAll[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1220211038727255366=%3Cdefault%3E=testDetails]*
 
*IgniteClientTestSuite: 
JettyRestProcessorAuthenticationWithTokenSelfTest.testVisorGateway[ (fail rate 
11,1%)|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=2613252696282859254=%3Cdefault%3E=testDetails]*
 



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

Re: IEP-4, Phase 2. Using BL(A)T for in-memory caches.

[Alexey Goncharuk]

Dmitriy,

I doubt we will be able to fit this in 2.5 given that we did not even agree
on the policy interface. Forcing in-memory caches to use baseline topology
will be an easy technical fix, however, we will need to update and probably
fix lots of failover tests, add new ones.

I think it makes sense to target this change to 2.6.

2018-04-25 22:25 GMT+03:00 Ilya Lantukh :

> Eduard,
>
> I'm not sure I understand what you mean by "policy". Is it an interface
> that will have a few default implementations and user will be able to
> create his own one? If so, could you please write an example of such
> interface (how you see it) and how and when it's methods will be invoked.
>
> On Wed, Apr 25, 2018 at 10:10 PM, Eduard Shangareev <
> eduard.shangar...@gmail.com> wrote:
>
> > Igniters,
> > I have described the issue with current approach in "New definition for
> > affinity node (issues with baseline)" topic[1].
> >
> > Now we have 2 different affinity topology (one for in-memory, another for
> > persistent caches).
> >
> > It causes problems:
> > - we lose (in general) co-location between different caches;
> > - we can't avoid PME when non-BLAT node joins cluster;
> > - implementation should consider 2 different approaches to affinity
> > calculation.
> >
> > So, I suggest unifying behavior of in-memory and persistent caches.
> > They should all use BLAT.
> >
> > Their behaviors were different because we couldn't guarantee the safety
> of
> > in-memory data.
> > It should be fixed by a new mechanism of BLAT changing policy which was
> > already discussed there - "Triggering rebalancing on timeout or manually
> if
> > the baseline topology is not reassembled" [2].
> >
> > And we should have a policy by default which similar to current one
> > (add nodes, remove nodes automatically but after some reasonable delay
> > [seconds]).
> >
> > After this change, we could stop using the term 'BLAT', Basline and so
> on.
> > Because there would not be an alternative. So, it would be only one
> > possible Affinity Topology.
> >
> >
> > [1]
> > http://apache-ignite-developers.2346864.n4.nabble.
> com/New-definition-for-
> > affinity-node-issues-with-baseline-td29868.html
> > [2]
> > http://apache-ignite-developers.2346864.n4.nabble.
> > com/Triggering-rebalancing-on-timeout-or-manually-if-the-
> > baseline-topology-is-not-reassembled-td29299.html#none
> >
>
>
>
> --
> Best regards,
> Ilya
>

[GitHub] ignite pull request #3894: Ignite 8086: add manual rebalace method

[Mmuzaf]

Github user Mmuzaf closed the pull request at:

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


---

[jira] [Created] (IGNITE-8400) Flaky failure of IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup (Grid is in invalid state)

[Aleksey Plekhanov (JIRA)]

Aleksey Plekhanov created IGNITE-8400:
-

 Summary: Flaky failure of 
IgniteTopologyValidatorGridSplitCacheTest.testTopologyValidatorWithCacheGroup 
(Grid is in invalid state)
 Key: IGNITE-8400
 URL: https://issues.apache.org/jira/browse/IGNITE-8400
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov


Test fails sometimes on TeamCity with exception:

{noformat}
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=cache.IgniteTopologyValidatorGridSplitCacheTest6, 
state=STOPPED]
{noformat}

Before this exception node is dropped out of topology by coordinator:

{noformat}
[tcp-disco-msg-worker-#7831%cache.IgniteTopologyValidatorGridSplitCacheTest6%][IgniteCacheTopologySplitAbstractTest$SplitTcpDiscoverySpi]
 Node is out of topology (probably, due to short-time network problems).
{noformat}




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

[jira] [Created] (IGNITE-8399) Add documentation for kNN classification (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8399:


 Summary: Add documentation for kNN classification (release 2.5)
 Key: IGNITE-8399
 URL: https://issues.apache.org/jira/browse/IGNITE-8399
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have added a SVM Binary and Multi-class classification 
working on top of partition based dataset and now we need to update 
documentation for this feature.

Add page [https://dash.readme.io/project/apacheignite/v2.4/docs/svm-25]

Add page 
[https://dash.readme.io/project/apacheignite/v2.4/docs/svm-multi-class-classification-25]

 

 



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

[jira] [Created] (IGNITE-8398) Update documentation for KMeans clustering (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8398:


 Summary: Update documentation for KMeans clustering (release 2.5)
 Key: IGNITE-8398
 URL: https://issues.apache.org/jira/browse/IGNITE-8398
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have changed a kMeans clustering and remove FuzzyCMeans 
working on top of partition based dataset and now we need to update 
documentation for this feature.

 

Previous version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering]

update with

New version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-means-clustering-25]

 

IMPORTANT: Remove page 
[https://dash.readme.io/project/apacheignite/v2.4/docs/fuzzy-c-means-clustering]

 



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

[jira] [Created] (IGNITE-8397) Update documentation for kNN regression (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8397:


 Summary: Update documentation for kNN regression (release 2.5)
 Key: IGNITE-8397
 URL: https://issues.apache.org/jira/browse/IGNITE-8397
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have changed a kNN regression working on top of 
partition based dataset and now we need to update documentation for this 
feature.

 

Previous version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/knn-regression]

update with

New version: 
[https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-regression-25|http://example.com]



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

[jira] [Created] (IGNITE-8396) Add documentation for kNN classification (release 2.5)

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8396:


 Summary: Add documentation for kNN classification (release 2.5)
 Key: IGNITE-8396
 URL: https://issues.apache.org/jira/browse/IGNITE-8396
 Project: Ignite
  Issue Type: Improvement
  Components: documentation, ml
Affects Versions: 2.5
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


In Apache Ignite 2.5 we have added a normalization preprocessor working on top 
of partition based dataset and now we need to add documentation for this 
feature.

 

Previous version: 
https://dash.readme.io/project/apacheignite/v2.4/docs/knn-classification

update with

New version: 
https://dash.readme.io/project/apacheignite/v2.4/docs/k-nn-classification-25

 



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

[GitHub] ignite pull request #3921: IGNITE-7883 add check property "key configuration...

[a-polyakov]

GitHub user a-polyakov opened a pull request:

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

IGNITE-7883 add check property "key configuration" in cache configuration

…tions

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

$ git pull https://github.com/a-polyakov/ignite IGNITE-7883

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

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


commit ed326d0e83699095e3694795350abb213986594e
Author: a-polyakov 
Date:   2018-04-26T10:57:06Z

IGNITE-7883 add check property "key configuration" in cache configurations




---

[jira] [Created] (IGNITE-8395) Test framework counts non-empty parameters methods as test methods

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-8395:


 Summary: Test framework counts non-empty parameters methods as 
test methods
 Key: IGNITE-8395
 URL: https://issues.apache.org/jira/browse/IGNITE-8395
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Goncharuk


For example, if a test class has a method {{public void testMyFunction(String 
param)}}, then test counters will be off by one and {{afterTestsStopped}} will 
not be executed.



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

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

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8394) ODBC: Can not establish SSL connection to remote host.

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-8394:
---

 Summary: ODBC: Can not establish SSL connection to remote host.
 Key: IGNITE-8394
 URL: https://issues.apache.org/jira/browse/IGNITE-8394
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Affects Versions: 2.4
Reporter: Igor Sapego
Assignee: Igor Sapego
 Fix For: 2.6


Driver connects to the local server, but when connecting to remote server 
client sometimes returns error when trying to establish async connection, 
though the connection established successfully, if the error is ignored.



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

[GitHub] ignite pull request #2652: IGNITE-6260 rename setDistributedJoins to setNonC...

[vk23]

Github user vk23 closed the pull request at:

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


---

[jira] [Created] (IGNITE-8393) Unexpected error during WAL compression java.io.EOFException: EOF at position [0] expected to read [29] bytes

[Sergey Filatov (JIRA)]

Sergey Filatov created IGNITE-8393:
--

 Summary:  Unexpected error during WAL compression 
java.io.EOFException: EOF at position [0] expected to read [29] bytes
 Key: IGNITE-8393
 URL: https://issues.apache.org/jira/browse/IGNITE-8393
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Reporter: Sergey Filatov


2018-04-26 11:35:25.152 
[ERROR][wal-file-compressor%DPL_GRID%DplGridNodeName][o.a.i.i.p.c.p.w.FileWriteAheadLogManager]
 Unexpected error during WAL compression
java.io.EOFException: EOF at position [0] expected to read [29] bytes
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileInput.ensure(FileInput.java:126)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager.readSerializerVersionAndCompactedFlag(FileWriteAheadLogManager.java:2144)
   at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.compressSegmentToFile(FileWriteAheadLogManager.java:1917)
  at 
org.apache.ignite.internal.processors.cache.persistence.wal.FileWriteAheadLogManager$FileCompressor.run(FileWriteAheadLogManager.java:1884)
2018-04-26 11:35:25.391 [INFO 
][node-stopper][o.a.i.i.m.d.GridDeploymentLocalStore] Removed undeployed class: 
GridDeployment [ts=1524730971870, depMode=SHARED, 
clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@7ee81f01,
 clsLdrId=7114b010361-b9172884-ab39-4b1c-94ed-6208828f27fe, userVer=0, 
loc=true, 
sampleClsName=org.apache.ignite.internal.processors.cache.GridCacheProcessor$RemovedItemsCleanupTask$1,
 pendingUndeploy=false, undeployed=true, usage=0]
2018-04-26 11:35:25.400 [INFO 
][node-stopper][o.a.i.i.IgniteKernal%DPL_GRID%DplGridNodeName]
...
2018-04-26 11:40:00.004 [ERROR][RMI TCP 
Connection(276)-10.116.206.1][com.sbt.dpl.gridgain.mbean.GridNode] Не удалось 
определить общее количество узлов. Сброшен флаг доступности.
java.lang.IllegalStateException: Grid is in invalid state to perform this 
operation. It either not started yet or has already being or have stopped 
[igniteInstanceName=DPL_GRID%DplGridNodeName, state=STOPPED]



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

[GitHub] ignite pull request #3920: zk-fix-test

[sergey-chugunov-1985]

GitHub user sergey-chugunov-1985 opened a pull request:

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

zk-fix-test



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

$ git pull https://github.com/gridgain/apache-ignite 
ignite-zk-timeout-fix-attempt

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

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


commit 5a5f50b2a908ff7ec33e0a7e90e16e81793b274c
Author: Sergey Chugunov 
Date:   2018-04-26T09:56:50Z

zk-fix-test




---

[GitHub] ignite pull request #3701: IGNITE-8052: Clear error message when using a non...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3893: IGNITE-8342: When creating an index, unexpected n...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Orphaned, duplicate, and main-class tests!

[Dmitriy Govorukhin]

Ilya,

I guess we can remove all these suites

GridActivationAtomicCacheSuit
GridActivationCacheAbstractTestSuit
GridActivationLocalAndNearCacheSuit
GridActivationPartitionedCacheSuit
GridActivationReplicatedCacheSuit

They became not relevant after standby mode became part of the basic
functionality.

On Tue, Apr 24, 2018 at 6:33 PM, Vladimir Ozerov 
wrote:

> Yakov,
>
> Agree.
>
> On Tue, Apr 24, 2018 at 6:11 AM, Yakov Zhdanov 
> wrote:
>
> > Alexey Goncharuk, Vladimir Ozerov, what do you think about these tests?
> >
> > I believe they were created as a part of variuos optimization and
> profiling
> > activities. I also think we can remove them since nobody cares about them
> > for too long.
> >
> > Thoughts?
> >
> > Yakov Zhdanov
> >
> > ср, 18 апр. 2018 г., 16:42 Ilya Kasnacheev :
> >
> > > Hello!
> > >
> > > I've decided to return to this task after a break.
> > >
> > > Can you please tell me why do we have main-class tests? Such as
> > >
> > > GridBasicPerformanceTest.class,
> > > GridBenchmarkCacheGetLoadTest.class,
> > > GridBoundedConcurrentLinkedHashSetLoadTest.class,
> > > GridCacheDataStructuresLoadTest.class,
> > > GridCacheReplicatedPreloadUndeploysTest.class,
> > > GridCacheLoadTest.class,
> > > GridCacheMultiNodeDataStructureTest.class,
> > > GridCapacityLoadTest.class,
> > > GridContinuousOperationsLoadTest.class,
> > > GridFactoryVmShutdownTest.class,
> > > GridFutureListenPerformanceTest.class,
> > > GridFutureQueueTest.class,
> > > GridGcTimeoutTest.class,
> > > GridJobExecutionSingleNodeLoadTest.class,
> > > GridJobExecutionSingleNodeSemaphoreLoadTest.class,
> > > GridJobLoadTest.class,
> > > GridMergeSortLoadTest.class,
> > > GridNioBenchmarkTest.class,
> > > GridThreadPriorityTest.class,
> > > GridSystemCurrentTimeMillisTest.class,
> > > BlockingQueueTest.class,
> > > MultipleFileIOTest.class,
> > > GridSingleExecutionTest.class
> > >
> > >
> > > If nobody wants them, how about we delete them in master branch? Start
> > > afresh?
> > >
> > > --
> > > Ilya Kasnacheev
> > >
> > > 2018-02-13 17:02 GMT+03:00 Ilya Kasnacheev  >:
> > >
> > > > Anton,
> > > >
> > > > >Tests should be attached to appropriate suites
> > > >
> > > > This I can do
> > > >
> > > > > and muted if necessary, Issues should be created on each mute.
> > > >
> > > > This is roughly a week of work. I can't spare that right now. I doubt
> > > > anyone can.
> > > >
> > > > Can we approach this by smaller steps?
> > > >
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > > > 2018-02-06 19:55 GMT+03:00 Anton Vinogradov <
> avinogra...@gridgain.com
> > >:
> > > >
> > > >> Val,
> > > >>
> > > >> Tests should be attached to appropriate suites and muted if
> necessary,
> > > >> Issues should be created on each mute.
> > > >>
> > > >> On Tue, Feb 6, 2018 at 7:23 PM, Valentin Kulichenko <
> > > >> valentin.kuliche...@gmail.com> wrote:
> > > >>
> > > >> > Anton,
> > > >> >
> > > >> > I tend to agree with Ilya that identifying and fixing all the
> > possible
> > > >> > broken tests in one go is not feasible. What is the proper way in
> > your
> > > >> > view? What are you suggesting?
> > > >> >
> > > >> > -Val
> > > >> >
> > > >> > On Mon, Feb 5, 2018 at 2:18 AM, Anton Vinogradov <
> > > >> avinogra...@gridgain.com
> > > >> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Ilya,
> > > >> > >
> > > >> > > 1) Still see no reason for such changes. Does this break
> > something?
> > > >> > >
> > > >> > > 2) Looks like you're trying to add Trash*TestSuite.java which
> will
> > > >> never
> > > >> > be
> > > >> > > refactored.
> > > >> > > We should do everything in proper way now, not sometime.
> > > >> > >
> > > >> > > 3) Your comments looks odd to me.
> > > >> > > Issue should be resolved in proper way.
> > > >> > >
> > > >> > > On Mon, Feb 5, 2018 at 1:07 PM, Ilya Kasnacheev <
> > > >> > ilya.kasnach...@gmail.com
> > > >> > > >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Anton,
> > > >> > > >
> > > >> > > > 1) We already have ~100 files named "*AbstractTest.java".
> > Renaming
> > > >> > these
> > > >> > > > several files will help checking for orphaned tests in the
> > future,
> > > >> as
> > > >> > > well
> > > >> > > > as increasing code base consistency.
> > > >> > > >
> > > >> > > > 2) This is huge work that is not doable by any single
> developer.
> > > >> While
> > > >> > > > IgniteLostAndFoundTestSuite can be slowly refactored away
> > > >> > > > This is unless you are OK with putting all these tests, most
> of
> > > >> which
> > > >> > are
> > > >> > > > red and some are hanging, in production test suites and
> > therefore
> > > >> > > breaking
> > > >> > > > productivity for a couple months while this gets sorted.
> > > >> > > > Are you OK with that? Anybody else?
> > > >> > > >
> > > >> > > > 3) I think I *could* put them in some test suite or 

[GitHub] ignite pull request #3919: Ignite 2.4.2 p10

[zstan]

GitHub user zstan opened a pull request:

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

Ignite 2.4.2 p10



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

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

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

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


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
Author: Ilya Lantukh 
Date:   2017-11-18T12:39:19Z

Fixed Ignite.active(true) returning control too early.

commit 1bcdd76aae78665e2bbd49034fb46a1b91ef8389
Author: Ilya Lantukh 
Date:   2017-11-18T13:33:01Z

Fixed baseline topology changes from client/daemon nodes.

commit e3bbecd9f133251818a4b43afa44f46e66dd0325
Author: Alexey Goncharuk 
Date:   2017-11-18T14:16:39Z

Fixed licenses

commit b0d73fe45a8bb89ef82fce561f702095241c0405
Author: Alexey Goncharuk 
Date:   2017-11-18T14:33:49Z

Do not dump entries to log

commit a822e78e2ab7b4dc2b9477f3b6a966b1fd46df54
Author: EdShangGG