[GitHub] ignite pull request #4034: Ignite 7766

[ezagumennov]

GitHub user ezagumennov opened a pull request:

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

Ignite 7766



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

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

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

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


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

ignite-blt-merge -> ignite-2.4.1

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

merge ignite-pitr-rc1 -> ignite-2.4.1

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

ignite-gg-12877 Compact consistent ID in WAL

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

Fixed javadoc.

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

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

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

IGNITE-5850 failover tests for cache operations during BaselineTopology 
changes

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

TX read logging if PITR is enabled.

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

TX read logging if PITR is enabled.

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

ignite-2.4.1 optimization for store full set node more compacted

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

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

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

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

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

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

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

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

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

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

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

IGNITE-5850 BaselineTopology should not change on cluster deactivation

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

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

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

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

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

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

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

IGNITE-5850 tests for queries in presence of BaselineTopology

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

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

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

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

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

hack with sleep

commit b5bffc7580a4a8ffbcc06f60c282e73979179578
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

[jira] [Created] (IGNITE-8535) WebConsole configuration over HTTPs guide should be documented

[Andrey Aleksandrov (JIRA)]

Andrey Aleksandrov created IGNITE-8535:
--

 Summary: WebConsole configuration over HTTPs guide should be 
documented 
 Key: IGNITE-8535
 URL: https://issues.apache.org/jira/browse/IGNITE-8535
 Project: Ignite
  Issue Type: Task
Affects Versions: 2.4
Reporter: Andrey Aleksandrov


Documentation provides the information related to HTTPs connection for web 
console.

[https://apacheignite-tools.readme.io/v2.4/docs/getting-started#section-https]

But there is no guide how it could be configured. I believe it should be added.



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

[GitHub] ignite pull request #4035: IGNITE-7766 test should retry, not fail

[ezagumennov]

GitHub user ezagumennov opened a pull request:

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

IGNITE-7766 test should retry, not fail



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

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

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

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


commit 0900e0aee3c82595881a268b9b7b9080e9b350b4
Author: ezagumennov 
Date:   2018-05-21T07:34:11Z

IGNITE-7766 test should retry, not fail




---

[GitHub] ignite pull request #4034: Ignite 7766

[ezagumennov]

Github user ezagumennov closed the pull request at:

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


---

[jira] [Created] (IGNITE-8536) DirectMemoryRegion: Introduce checkpoint buffer configuration and improve logging o start

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8536:


 Summary: DirectMemoryRegion: Introduce checkpoint buffer  
configuration and improve logging o start
 Key: IGNITE-8536
 URL: https://issues.apache.org/jira/browse/IGNITE-8536
 Project: Ignite
  Issue Type: Improvement
  Components: persistence
Affects Versions: 2.4
Reporter: Alexey Kuznetsov
Assignee: Alexey Goncharuk


We need to configure data region checkpoint buffer size when we start Ignite on 
computer with  limiter resources, for example AWS t2.micro

In current implementation Ignite will allocate 100Mb buffers, it should be 
configurable.

Also we need to improve message printed in log: 
current message: 
{code}
[2018-05-18T03:43:01,449][INFO ][exchange-worker-#51][PageMemoryImpl] Started 
page memory [memoryAllocated=100.0 MiB, pages=24937, tableSize=1.4 MiB, 
checkpointBuffer=100.0 MiB]
{code}

Lets add region name and rename "checkpointBuffer" to  "data region buffer".




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

[jira] [Created] (IGNITE-8537) Web Console: Proof-read texts

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8537:


 Summary: Web Console: Proof-read texts
 Key: IGNITE-8537
 URL: https://issues.apache.org/jira/browse/IGNITE-8537
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 2.6


We need to revise Web Console texts and improve them.



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

[jira] [Created] (IGNITE-8538) Web Console: Refactor redirecting to default state.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8538:


 Summary: Web Console: Refactor redirecting to default state.
 Key: IGNITE-8538
 URL: https://issues.apache.org/jira/browse/IGNITE-8538
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


We need to refactor and fix redirection to default state from Queries screen, 
40x screens and other similar places.



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

[jira] [Created] (IGNITE-8539) Web Console: add additional checks to prevent unauthorized web-socket connection.

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-8539:


 Summary: Web Console: add additional checks to prevent 
unauthorized web-socket connection.
 Key: IGNITE-8539
 URL: https://issues.apache.org/jira/browse/IGNITE-8539
 Project: Ignite
  Issue Type: Improvement
  Components: wizards
Reporter: Alexey Kuznetsov
Assignee: Andrey Novikov
 Fix For: 2.6


We should add additional check to prevent unauthorized web-socket connection.



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

Re: Cache 6 Suite Execution timeouts

[Dmitry Pavlov]

Hi Maxim,

I observe the same, Cache 6 critical recent fails: 18,0% [9 fails / 50 runs]

I hope Aleksei Scherbakov can help here. Alexey, please step in.

Sincerely,
Dmitriy Pavlov

вс, 20 мая 2018 г. в 20:37, Maxim Muzafarov :

> Hello Igniters,
>
> Have anyone noticed a lot of execution timeouts for Cache 6 Suite?
> Since recently it fails too much on TxRollbackOnTimeoutNearCacheTest with
> "Found long running transaction".
>
> Please refer to TC [1]. It has 4/10 execution timeouts for the last 10
> builds in master.
>
> I've created IGNITE-8509 [2]. Will someone have time to look at? Or I'll
> try when I'm get free.
>
> [1]
>
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Cache6&branch_IgniteTests24Java8=%3Cdefault%3E&tab=buildTypeStatusDiv
> [2] https://issues.apache.org/jira/browse/IGNITE-8509
>

[GitHub] ignite pull request #4036: IGNITE-8446 Ability to check and completely fill ...

[anton-vinogradov]

GitHub user anton-vinogradov opened a pull request:

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

IGNITE-8446 Ability to check and completely fill transactions on crea…

…tion

Signed-off-by: Anton Vinogradov 

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

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

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

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


commit 48949b8f236ec6df6f8a816ee3f9ac827f2f492d
Author: Anton Vinogradov 
Date:   2018-05-21T10:02:41Z

IGNITE-8446 Ability to check and completely fill transactions on creation

Signed-off-by: Anton Vinogradov 




---

[GitHub] ignite pull request #3748: IGNITE-8054 serialize only valuable part of GridL...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Ability to check and completely fill transactions on creation

[Anton Vinogradov]

Igniters,

Fix is ready.
Code checked by Nikolay Izhikov, all issues fixed
Code benchmarked by Ilya Suntsov, no drop found.

Fix *affects public API*, so I'm proposing everyone interested check it.
Issue: https://issues.apache.org/jira/browse/IGNITE-8446
PR: https://github.com/apache/ignite/pull/4036/files

Public API changes:
New EvenType:

EVT_TX_STARTED = 129.

New Event:

TransactionEvent extends EventAdapter {
   private IgniteInternalTx tx;
}

In case there are no objection I'll merge the changes soon.

пт, 6 апр. 2018 г. в 14:12, Anton Vinogradov :

> >> But I have concern
> >> about performance. How can you estimate impact to performance ?
> We have to benchmark result.
>
> >> How about to set label name with some useful info if user does not
> provide
> >> custom name?
> You can set custom listener which will do that
>
> >>  For example thread name + global counter?
> Or even full stacktrace
>
> >>  how the user is expected to use this event?
> Event will be used to validate tx on creation.
> Since listner will be invoked at same thread (Am I right?) it will have
> all requred info for validation.
>
>
> 2018-04-05 22:06 GMT+03:00 Denis Magda :
>
>> Guys,
>>
>> Sorry for a dumb question but how the user is expected to use this event?
>>
>> --
>> Denis
>>
>> On Thu, Apr 5, 2018 at 6:06 AM, Anton Vinogradov  wrote:
>>
>> > Igniters,
>> >
>> > As far as I know we're working on additional 'label' field for
>> transactions
>> > [1].
>> > That's great and will be helpful for customers with huge deploymens to
>> see
>> > reason of each transaction.
>> > But, since 'label' is optional field, there is no way to guarantee it
>> will
>> > be filled.
>> >
>> > I'd like to propose an idea of brand new event EVT_USR_TX_CREATED (local
>> > transaction created).
>> >
>> > Local listener on such event will allow to guarantee tx's 'label' field
>> > filled, timeout is correct and so on.
>> >
>> > Thoughts?
>> >
>> > [1] https://issues.apache.org/jira/browse/IGNITE-6827
>> >
>>
>
>

[jira] [Created] (IGNITE-8540) Slow rebalance with asynchronous eviction

[Anton Kalashnikov (JIRA)]

Anton Kalashnikov created IGNITE-8540:
-

 Summary: Slow rebalance with asynchronous eviction
 Key: IGNITE-8540
 URL: https://issues.apache.org/jira/browse/IGNITE-8540
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.5
Reporter: Anton Kalashnikov
Assignee: Anton Kalashnikov


Node start eviction after join to grid even it is not in baseline.



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

[GitHub] ignite pull request #4037: IGNITE-8540 removing persistent files for joined ...

[akalash]

GitHub user akalash opened a pull request:

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

IGNITE-8540 removing persistent files for joined node if it is not in…

… baseline

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

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

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

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


commit 13749c13bcdf5517e903f66beb34b34f7cd66106
Author: Anton Kalashnikov 
Date:   2018-05-17T16:35:24Z

IGNITE-8540 removing persistent files for joined node if it is not in 
baseline




---

Re: How dose ignite implement concurrent control in transaction？

[Dmitry Pavlov]

Cross-posting to user list.

Hi Folks,

could you please comment?

Sincerely,
Dmitiry Pavlov

пн, 21 мая 2018 г. в 7:41, zhouxy1123 :

>
> hi ， How dose ignite implement concurrent control in transaction？
> Since Ignite support Read Repeat isolation，so in a transaction lock
> protocol
> is tow phase with respect to exclusive lock and well-formed. Does Ignite
> implement tow phase lock and granule lock to prevent phantom read.Besides
> Dose Ignite support granular locks and intend lock?
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[jira] [Created] (IGNITE-8541) Auth: username case sensitive/insensitive behavior is invalid

[Taras Ledkov (JIRA)]

Taras Ledkov created IGNITE-8541:


 Summary: Auth: username case sensitive/insensitive behavior is 
invalid
 Key: IGNITE-8541
 URL: https://issues.apache.org/jira/browse/IGNITE-8541
 Project: Ignite
  Issue Type: Bug
  Components: jdbc, odbc, thin client
Affects Versions: 2.4
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.6


JDBC thin driver, ODBC driver and Java thin client doesn't support case 
insensitive behavior for user name when authentication is enabled.

The user name property already case insensitive.

The username property must be handled as the *scheme* parameter:
- quoted user name is case sensitive.
- nonquoted user name is not case sensitive.



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

How dose ignite implement concurrent control in transaction？

[zhouxy1123]

hi ， How dose ignite implement concurrent control in transaction？ 
Since Ignite support Read Repeat isolation，so in a transaction lock protocol 
is tow phase with respect to exclusive lock and well-formed. Does Ignite 
implement tow phase lock and granule lock to prevent phantom read.Besides 
Dose Ignite support granular locks and intend lock? 



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

Re: How dose ignite implement concurrent control in transaction？

[Dmitry Pavlov]

Hi,

Probably answers can be found here
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Key-Value+Transactions+Architecture

Sincrely,
Dmitriy Pavlov

пн, 21 мая 2018 г. в 14:46, zhouxy1123 :

> hi ， How dose ignite implement concurrent control in transaction？
> Since Ignite support Read Repeat isolation，so in a transaction lock
> protocol
> is tow phase with respect to exclusive lock and well-formed. Does Ignite
> implement tow phase lock and granule lock to prevent phantom read.Besides
> Dose Ignite support granular locks and intend lock?
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

[jira] [Created] (IGNITE-8542) [ML] Add OneVsRest Trainer to handle cases with multiple class labels in dataset

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-8542:


 Summary: [ML] Add OneVsRest Trainer to handle cases with multiple 
class labels in dataset
 Key: IGNITE-8542
 URL: https://issues.apache.org/jira/browse/IGNITE-8542
 Project: Ignite
  Issue Type: Improvement
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

[GitHub] ignite pull request #4008: IGNITE-8511

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8543) Node.js tests count with debug on/off differs

[Peter Ivanov (JIRA)]

Peter Ivanov created IGNITE-8543:


 Summary: Node.js tests count with debug on/off differs
 Key: IGNITE-8543
 URL: https://issues.apache.org/jira/browse/IGNITE-8543
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.5
Reporter: Peter Ivanov
Assignee: Peter Ivanov


Running Node,js thin client tests with debug turned on / off results in 
different total test count 
([64|https://ci.ignite.apache.org/viewLog.html?buildId=1316067&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ThinClientNodeJs]
 and 
[99|https://ci.ignite.apache.org/viewLog.html?buildId=1316268&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_ThinClientNodeJs]
 respectively. Thats not predicted behaviour and require investigation.



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

Re: Ability to check and completely fill transactions on creation

[Yakov Zhdanov]

Anton, I have objections. Please do not merge unless we agree on details.

1. You use internal API in public event, i.e. you cannot have user
accessing to IgniteInternalTx instance through TxEvent.
2. Throwing runtime errors from listener is not documented and I doubt if
it can be fully supported in the pattern you use in TxLabelTest. After
looking at the mentioned test user may think that throwing runtime error
when notified on new node join may prohibit new node joining which is not
true. Do you have any example in Ignite when throwing exception from
listener is valid and documented.
3. TxLabelTest is not included into any suite.
4. EVT_TX_STARTED - does not seems to be a proper and descriptive name

I think that we should think about some other solution instead of altering
event sub-system.

Also I want to ask everyone in community to request explicit approval from
community members before changing anything in transactional logic.

Thanks!

--Yakov

Re: Ability to check and completely fill transactions on creation

[Dmitry Pavlov]

Hi Yakov,

I've checked this code and IgniteCacheTestSuite6 includes TxLabelTest, so
point 3 can be considered as solved.

Sincerely,
Dmitriy Pavlov

пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :

> Anton, I have objections. Please do not merge unless we agree on details.
>
> 1. You use internal API in public event, i.e. you cannot have user
> accessing to IgniteInternalTx instance through TxEvent.
> 2. Throwing runtime errors from listener is not documented and I doubt if
> it can be fully supported in the pattern you use in TxLabelTest. After
> looking at the mentioned test user may think that throwing runtime error
> when notified on new node join may prohibit new node joining which is not
> true. Do you have any example in Ignite when throwing exception from
> listener is valid and documented.
> 3. TxLabelTest is not included into any suite.
> 4. EVT_TX_STARTED - does not seems to be a proper and descriptive name
>
> I think that we should think about some other solution instead of altering
> event sub-system.
>
> Also I want to ask everyone in community to request explicit approval from
> community members before changing anything in transactional logic.
>
> Thanks!
>
> --Yakov
>

[GitHub] ignite pull request #3082: ignite-6977: fix initial size of BitSet

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Ability to check and completely fill transactions on creation

[Yakov Zhdanov]

Ok, then it probably might have been created before this PR. Anyway, I
would not bother too much about pt 3.

--Yakov

2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :

> Hi Yakov,
>
> I've checked this code and IgniteCacheTestSuite6 includes TxLabelTest, so
> point 3 can be considered as solved.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
>
> > Anton, I have objections. Please do not merge unless we agree on details.
> >
> > 1. You use internal API in public event, i.e. you cannot have user
> > accessing to IgniteInternalTx instance through TxEvent.
> > 2. Throwing runtime errors from listener is not documented and I doubt if
> > it can be fully supported in the pattern you use in TxLabelTest. After
> > looking at the mentioned test user may think that throwing runtime error
> > when notified on new node join may prohibit new node joining which is not
> > true. Do you have any example in Ignite when throwing exception from
> > listener is valid and documented.
> > 3. TxLabelTest is not included into any suite.
> > 4. EVT_TX_STARTED - does not seems to be a proper and descriptive name
> >
> > I think that we should think about some other solution instead of
> altering
> > event sub-system.
> >
> > Also I want to ask everyone in community to request explicit approval
> from
> > community members before changing anything in transactional logic.
> >
> > Thanks!
> >
> > --Yakov
> >
>

Re: How dose ignite implement concurrent control in transaction？

[zhouxy1123]

hi Dmitriy Pavlov ,
thanks for your reply, 
I read the doc , and I find that in RR isolation ,there is just one kind of
lock.
So Ignite dose not support share lock ?  And dose Ignite not support granule
lock?




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

[GitHub] ignite pull request #4038: IGNITE-8526 Create web-agent docker image for k8s...

[vveider]

GitHub user vveider opened a pull request:

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

IGNITE-8526 Create web-agent docker image for k8s deployment

 * added web-agent separate docker image build
 * refactored and unified docker specifications layout

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

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

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

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


commit e6cc97a7592f1d5065e6f40dc0c96fc70018039f
Author: Ivanov Petr 
Date:   2018-05-21T14:11:05Z

IGNITE-8526 Create web-agent docker image for k8s deployment
 * added web-agent separate docker image build
 * refactored and unified docker specifications layout




---

Re: Ability to check and completely fill transactions on creation

[Anton Vinogradov]

Yakov, thank's for deep check.

>> I think that we should think about some other solution instead of
altering
>> event sub-system.

Thank's to your comments now I see that solution is not perfect.

How about to create

interface TransactionsValidator {
   boolean validate(IgniteTransactions tx){
  ...
   }
}

and add it's setter to IgniteConfiguration?

icfg.setTransactionsValidator(new CustomTransactionsValidator(...));

In that case we'll gain easy and proper solution allows to check
transaction configuration before real tx creation.

It will be necessary to add some getters to IgniteTransactions:
- label()
- timeout()
- concurrency() (optional)
- isolation() (optional)
- txSize() (optional)

Thoughts?

пн, 21 мая 2018 г. в 16:31, Yakov Zhdanov :

> Ok, then it probably might have been created before this PR. Anyway, I
> would not bother too much about pt 3.
>
> --Yakov
>
> 2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :
>
> > Hi Yakov,
> >
> > I've checked this code and IgniteCacheTestSuite6 includes TxLabelTest, so
> > point 3 can be considered as solved.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
> >
> > > Anton, I have objections. Please do not merge unless we agree on
> details.
> > >
> > > 1. You use internal API in public event, i.e. you cannot have user
> > > accessing to IgniteInternalTx instance through TxEvent.
> > > 2. Throwing runtime errors from listener is not documented and I doubt
> if
> > > it can be fully supported in the pattern you use in TxLabelTest. After
> > > looking at the mentioned test user may think that throwing runtime
> error
> > > when notified on new node join may prohibit new node joining which is
> not
> > > true. Do you have any example in Ignite when throwing exception from
> > > listener is valid and documented.
> > > 3. TxLabelTest is not included into any suite.
> > > 4. EVT_TX_STARTED - does not seems to be a proper and descriptive name
> > >
> > > I think that we should think about some other solution instead of
> > altering
> > > event sub-system.
> > >
> > > Also I want to ask everyone in community to request explicit approval
> > from
> > > community members before changing anything in transactional logic.
> > >
> > > Thanks!
> > >
> > > --Yakov
> > >
> >
>

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

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #3986: IGNITE-8469: release memory in case initializatio...

[asfgit]

Github user asfgit closed the pull request at:

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


---

Re: Ability to check and completely fill transactions on creation

[Dmitriy Setrakyan]

Anton,

The change looks very questionable. We cannot be adding configuration
validators for every piece of Ignite API. What is it you are trying to
achieve?

D.

On Mon, May 21, 2018 at 7:22 AM, Anton Vinogradov  wrote:

> Yakov, thank's for deep check.
>
> >> I think that we should think about some other solution instead of
> altering
> >> event sub-system.
>
> Thank's to your comments now I see that solution is not perfect.
>
> How about to create
>
> interface TransactionsValidator {
>boolean validate(IgniteTransactions tx){
>   ...
>}
> }
>
> and add it's setter to IgniteConfiguration?
>
> icfg.setTransactionsValidator(new CustomTransactionsValidator(...));
>
> In that case we'll gain easy and proper solution allows to check
> transaction configuration before real tx creation.
>
> It will be necessary to add some getters to IgniteTransactions:
> - label()
> - timeout()
> - concurrency() (optional)
> - isolation() (optional)
> - txSize() (optional)
>
> Thoughts?
>
> пн, 21 мая 2018 г. в 16:31, Yakov Zhdanov :
>
> > Ok, then it probably might have been created before this PR. Anyway, I
> > would not bother too much about pt 3.
> >
> > --Yakov
> >
> > 2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :
> >
> > > Hi Yakov,
> > >
> > > I've checked this code and IgniteCacheTestSuite6 includes TxLabelTest,
> so
> > > point 3 can be considered as solved.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
> > >
> > > > Anton, I have objections. Please do not merge unless we agree on
> > details.
> > > >
> > > > 1. You use internal API in public event, i.e. you cannot have user
> > > > accessing to IgniteInternalTx instance through TxEvent.
> > > > 2. Throwing runtime errors from listener is not documented and I
> doubt
> > if
> > > > it can be fully supported in the pattern you use in TxLabelTest.
> After
> > > > looking at the mentioned test user may think that throwing runtime
> > error
> > > > when notified on new node join may prohibit new node joining which is
> > not
> > > > true. Do you have any example in Ignite when throwing exception from
> > > > listener is valid and documented.
> > > > 3. TxLabelTest is not included into any suite.
> > > > 4. EVT_TX_STARTED - does not seems to be a proper and descriptive
> name
> > > >
> > > > I think that we should think about some other solution instead of
> > > altering
> > > > event sub-system.
> > > >
> > > > Also I want to ask everyone in community to request explicit approval
> > > from
> > > > community members before changing anything in transactional logic.
> > > >
> > > > Thanks!
> > > >
> > > > --Yakov
> > > >
> > >
> >
>

[jira] [Created] (IGNITE-8544) WAL disabling during rebalance mechanism uses wrong topology version in case of exchanges merge

[Pavel Kovalenko (JIRA)]

Pavel Kovalenko created IGNITE-8544:
---

 Summary: WAL disabling during rebalance mechanism uses wrong 
topology version in case of exchanges merge
 Key: IGNITE-8544
 URL: https://issues.apache.org/jira/browse/IGNITE-8544
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.5
Reporter: Pavel Kovalenko
Assignee: Pavel Kovalenko
 Fix For: 2.6


After exchange is done, we're using initial exchange version to determine 
topology version on what rebalance should be finished and save it. After 
rebalance finishing we check current topology version and saved version and if 
they are equal, we enable WAL, own partitions and do checkpoint. In other case 
we do nothing, because of topology change. 
In case of exchanges merge we're saving old topology version (before merge) and 
it leads to ignoring logic of enabling WAL and etc, because check on topology 
version will be always false-positive.




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

[GitHub] ignite pull request #4039: IGNITE-8544 Use exchange result topology version ...

[Jokser]

GitHub user Jokser opened a pull request:

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

IGNITE-8544 Use exchange result topology version for local wal state change



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

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

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

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


commit 139a1fe580f777c081d073cca8199369de1878dd
Author: Pavel Kovalenko 
Date:   2018-05-21T15:01:21Z

IGNITE-8544 Use exchange result topology version for local wal state 
management.




---

[GitHub] ignite pull request #4030: IGNITE-8533 Fix timeout collision in Client Nodes...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-8545) If queryParallelism in nodes' caches configurations differ, query may hang, assert or return incomplete results

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8545:
---

 Summary: If queryParallelism in nodes' caches configurations 
differ, query may hang, assert or return incomplete results
 Key: IGNITE-8545
 URL: https://issues.apache.org/jira/browse/IGNITE-8545
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.6
Reporter: Ilya Kasnacheev
 Attachments: IgniteSqlSplitterQueryParallelismTest.java

I imagine it should not. See the attached file.

It happens both with client nodes and with server nodes.



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

Re: Ability to check and completely fill transactions on creation

[Anton Vinogradov]

Dmitriy,

Main idea is to restrict transaction creation in case label or timeout are
not set.
But there can be variations, for example label should fit some regexp or
timeout should be between 30 and 5000 ms.

That's not easy to restrict this at user code when you have dozens of
libraries written by different people in one system using one ignite
cluster.
That solution based on idea of TopologyValidator when you have no chances
to use cluster in case something wrong with nodes.
So, any client should have no chances to create transaction not suitable
for this ignite cluster.

пн, 21 мая 2018 г. в 17:48, Dmitriy Setrakyan :

> Anton,
>
> The change looks very questionable. We cannot be adding configuration
> validators for every piece of Ignite API. What is it you are trying to
> achieve?
>
> D.
>
> On Mon, May 21, 2018 at 7:22 AM, Anton Vinogradov  wrote:
>
> > Yakov, thank's for deep check.
> >
> > >> I think that we should think about some other solution instead of
> > altering
> > >> event sub-system.
> >
> > Thank's to your comments now I see that solution is not perfect.
> >
> > How about to create
> >
> > interface TransactionsValidator {
> >boolean validate(IgniteTransactions tx){
> >   ...
> >}
> > }
> >
> > and add it's setter to IgniteConfiguration?
> >
> > icfg.setTransactionsValidator(new CustomTransactionsValidator(...));
> >
> > In that case we'll gain easy and proper solution allows to check
> > transaction configuration before real tx creation.
> >
> > It will be necessary to add some getters to IgniteTransactions:
> > - label()
> > - timeout()
> > - concurrency() (optional)
> > - isolation() (optional)
> > - txSize() (optional)
> >
> > Thoughts?
> >
> > пн, 21 мая 2018 г. в 16:31, Yakov Zhdanov :
> >
> > > Ok, then it probably might have been created before this PR. Anyway, I
> > > would not bother too much about pt 3.
> > >
> > > --Yakov
> > >
> > > 2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :
> > >
> > > > Hi Yakov,
> > > >
> > > > I've checked this code and IgniteCacheTestSuite6 includes
> TxLabelTest,
> > so
> > > > point 3 can be considered as solved.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
> > > >
> > > > > Anton, I have objections. Please do not merge unless we agree on
> > > details.
> > > > >
> > > > > 1. You use internal API in public event, i.e. you cannot have user
> > > > > accessing to IgniteInternalTx instance through TxEvent.
> > > > > 2. Throwing runtime errors from listener is not documented and I
> > doubt
> > > if
> > > > > it can be fully supported in the pattern you use in TxLabelTest.
> > After
> > > > > looking at the mentioned test user may think that throwing runtime
> > > error
> > > > > when notified on new node join may prohibit new node joining which
> is
> > > not
> > > > > true. Do you have any example in Ignite when throwing exception
> from
> > > > > listener is valid and documented.
> > > > > 3. TxLabelTest is not included into any suite.
> > > > > 4. EVT_TX_STARTED - does not seems to be a proper and descriptive
> > name
> > > > >
> > > > > I think that we should think about some other solution instead of
> > > > altering
> > > > > event sub-system.
> > > > >
> > > > > Also I want to ask everyone in community to request explicit
> approval
> > > > from
> > > > > community members before changing anything in transactional logic.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > >
> >
>

Re: Ability to check and completely fill transactions on creation

[Anton Vinogradov]

One more case is to analize and log tx's creators info without tx creation
restriction.
This is very important feature on huge system trial period when you may
want to check who creates tx, tx content and configuration.
For example you may want to log stacktrace for any tx without meta or with
empty timeout.
This will allow you to find a team responsible for that and make sure that
they will fix their code.

пн, 21 мая 2018 г. в 18:14, Anton Vinogradov :

> Dmitriy,
>
> Main idea is to restrict transaction creation in case label or timeout are
> not set.
> But there can be variations, for example label should fit some regexp or
> timeout should be between 30 and 5000 ms.
>
> That's not easy to restrict this at user code when you have dozens of
> libraries written by different people in one system using one ignite
> cluster.
> That solution based on idea of TopologyValidator when you have no chances
> to use cluster in case something wrong with nodes.
> So, any client should have no chances to create transaction not suitable
> for this ignite cluster.
>
> пн, 21 мая 2018 г. в 17:48, Dmitriy Setrakyan :
>
>> Anton,
>>
>> The change looks very questionable. We cannot be adding configuration
>> validators for every piece of Ignite API. What is it you are trying to
>> achieve?
>>
>> D.
>>
>> On Mon, May 21, 2018 at 7:22 AM, Anton Vinogradov  wrote:
>>
>> > Yakov, thank's for deep check.
>> >
>> > >> I think that we should think about some other solution instead of
>> > altering
>> > >> event sub-system.
>> >
>> > Thank's to your comments now I see that solution is not perfect.
>> >
>> > How about to create
>> >
>> > interface TransactionsValidator {
>> >boolean validate(IgniteTransactions tx){
>> >   ...
>> >}
>> > }
>> >
>> > and add it's setter to IgniteConfiguration?
>> >
>> > icfg.setTransactionsValidator(new CustomTransactionsValidator(...));
>> >
>> > In that case we'll gain easy and proper solution allows to check
>> > transaction configuration before real tx creation.
>> >
>> > It will be necessary to add some getters to IgniteTransactions:
>> > - label()
>> > - timeout()
>> > - concurrency() (optional)
>> > - isolation() (optional)
>> > - txSize() (optional)
>> >
>> > Thoughts?
>> >
>> > пн, 21 мая 2018 г. в 16:31, Yakov Zhdanov :
>> >
>> > > Ok, then it probably might have been created before this PR. Anyway, I
>> > > would not bother too much about pt 3.
>> > >
>> > > --Yakov
>> > >
>> > > 2018-05-21 16:15 GMT+03:00 Dmitry Pavlov :
>> > >
>> > > > Hi Yakov,
>> > > >
>> > > > I've checked this code and IgniteCacheTestSuite6 includes
>> TxLabelTest,
>> > so
>> > > > point 3 can be considered as solved.
>> > > >
>> > > > Sincerely,
>> > > > Dmitriy Pavlov
>> > > >
>> > > > пн, 21 мая 2018 г. в 16:05, Yakov Zhdanov :
>> > > >
>> > > > > Anton, I have objections. Please do not merge unless we agree on
>> > > details.
>> > > > >
>> > > > > 1. You use internal API in public event, i.e. you cannot have user
>> > > > > accessing to IgniteInternalTx instance through TxEvent.
>> > > > > 2. Throwing runtime errors from listener is not documented and I
>> > doubt
>> > > if
>> > > > > it can be fully supported in the pattern you use in TxLabelTest.
>> > After
>> > > > > looking at the mentioned test user may think that throwing runtime
>> > > error
>> > > > > when notified on new node join may prohibit new node joining
>> which is
>> > > not
>> > > > > true. Do you have any example in Ignite when throwing exception
>> from
>> > > > > listener is valid and documented.
>> > > > > 3. TxLabelTest is not included into any suite.
>> > > > > 4. EVT_TX_STARTED - does not seems to be a proper and descriptive
>> > name
>> > > > >
>> > > > > I think that we should think about some other solution instead of
>> > > > altering
>> > > > > event sub-system.
>> > > > >
>> > > > > Also I want to ask everyone in community to request explicit
>> approval
>> > > > from
>> > > > > community members before changing anything in transactional logic.
>> > > > >
>> > > > > Thanks!
>> > > > >
>> > > > > --Yakov
>> > > > >
>> > > >
>> > >
>> >
>>
>

[jira] [Created] (IGNITE-8546) Permission denied while copying OPTION_LIBS on Openshift

[Roman Guseinov (JIRA)]

Roman Guseinov created IGNITE-8546:
--

 Summary: Permission denied while copying OPTION_LIBS on Openshift
 Key: IGNITE-8546
 URL: https://issues.apache.org/jira/browse/IGNITE-8546
 Project: Ignite
  Issue Type: Bug
  Components: build
Affects Versions: 2.4
 Environment: Server https://api.pro-us-east-1.openshift.com:443
openshift v3.9.14
kubernetes v1.9.1+a0ce1bc657
Reporter: Roman Guseinov
 Attachments: Dockerfile

The issue happens when we try to deploy `apacheignite/ignite:2.4.0` on 
Openshift with specified OPTION_LIBS env variable 
"ignite-kubernetes,ignite-rest-http".

There is a workaround how to resolve this issue. Dockerfile is attached.



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

[GitHub] ignite pull request #4040: 1.9 ignite reject threads

[antkr]

GitHub user antkr opened a pull request:

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

1.9 ignite reject threads

For test purposes.

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

$ git pull https://github.com/gridgain/apache-ignite 
1.9-ignite-reject-threads

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

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


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:   2017-07-11T13:24:54Z

ignite-5722 Cache entries stay in onheap after scan query execution for 
OFFHEAP_TIRED cache with expiry policy

commit c3e2eebeccbdc4bb3a7a0a70d09a8a7b63399c2c
Author: Evgenii Zhuravlev 
Date:   2017-07-18T15:50:48Z

IGNITE 5776 Add option to turn on filter reachable addresses in 
TcpCommunicationSpi

commit 97d3f42c1c95a6aafce1d0c300ccfe6708398c17
Author: shtykh_roman 
Date:   2016-09-07T05:35:31Z

IGNITE-3809: Fix for ArrayIndexOutOfBoundsException in GridUnsafeLru.

(cherry picked from commit 31b9bb8)

commit c2062d52a227dda5afee560d80c3bb4dd2ce09eb
Author: dkarachentsev 
Date:   2017-07-19T05:41:46Z

Remove empty test_utils.cpp

commit 45cbba4853bab1ba4ffe2ea0d3add99a9d454aab
Author: dkarachentsev 
Date:   2017-07-19T07:44:04Z

IGNITE-5768 - Retry resolving class name from marshaller cache and 
.classname file.

commit f24969f7e908645444df622642967a5f7fd3db23
Author: Evgenii Zhuravlev 
Date:   2017-07-19T16:30:07Z

IGNITE 5775 JobsProcessor fix bug with delay in compute

commit e5aab82f5629c2705e9bc82a7676f63c7c77062a
Author: dkarachentsev 
Date:   2017-07-20T07:37:08Z

Merge branch 'ignite-1.7.13' into ignite-1.8.9

# Conflicts:
#   
modules/co

[jira] [Created] (IGNITE-8547) Deserialization of Enum values as anonymous classes may cause deadlock

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-8547:
---

 Summary: Deserialization of Enum values as anonymous classes may 
cause deadlock
 Key: IGNITE-8547
 URL: https://issues.apache.org/jira/browse/IGNITE-8547
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.9
Reporter: Ilya Kasnacheev


Due to the following problem:
{code}
package jvmtest;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;

public class LegTypeTest {
public static void main(String[] args) throws InterruptedException, 
BrokenBarrierException {
List threadList = new ArrayList<>();

CyclicBarrier b1 = new CyclicBarrier(16);
CyclicBarrier b2 = new CyclicBarrier(17);

for (int i = 0; i < 16; i++) {
final int ii = i;
Thread thread = new Thread(() -> {
try {
b1.await();

if (ii % 2 == 0)
Class.forName("jvmtest.LegTypeTest$E$1");

if (ii % 2 == 1)
Class.forName("jvmtest.LegTypeTest$E");

b2.await();
} catch (Exception e) {
e.printStackTrace();
}
});
thread.start();
threadList.add(thread);
}

b2.await();

for (Thread thread : threadList) {
thread.join();
}
}

private enum E {
A("A"),
B("B") {
@Override
public String virtual() {
return null;
}
};

private String displayString;

E(String displayString) {
this.displayString = displayString;
}

public String virtual() {
return displayString;
}
}
}
{code}
When doing Class.forName on different enum values deadlock can be caused. And 
that's exactly what OptimizedMarshaller does.

See also the attached test.



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

Re: TeamCity permissions

[Pavel Petroshenko]

It works, thanks Vitaliy!

p.

On Sun, May 20, 2018 at 1:16 PM, Vitaliy Osipov 
wrote:

> Pavel. Hi
>
> The necessary rights have been added. Check please.
>
> On 19 May 2018 at 01:48, Pavel Petroshenko  wrote:
>
>> Thank you, Denis! I need to have a role to be able to temporary rearrange
>> builds in the TC build queue for testing and CI integration purposes.
>>
>> Vitaly, I would appreciate any help.
>>
>> Thanks,
>> P.
>>
>>
>> On Fri, May 18, 2018 at 10:49 AM, Denis Magda  wrote:
>>
>>> Hi Pavel,
>>>
>>> All the accounts are assigned Project developer role on TC that should
>>> provide anything you need to manage builds there.
>>>
>>> What specifically are you looking for? Please elaborate so that Vitaly
>>> can
>>> grant more permissions.
>>>
>>> Vitaly, please keep an eye on the conversation.
>>>
>>> --
>>> Denis
>>>
>>>
>>> On Fri, May 18, 2018 at 9:44 AM, Pavel Petroshenko <
>>> pa...@petroshenko.com>
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > Can anyone please grant TC permissions to manage jobs (reorder, etc)
>>> to:
>>> >
>>> > ekaterina.vergizova
>>> > alexey.kosenchuk
>>> > pavel.petroshenko
>>> >
>>> > Thanks!
>>> > p.
>>> >
>>>
>>
>>
>
>
> --
> Kind Regards
> Vitaliy Osipov
> vosi...@gridgain.com
> *+7 (921) 397 27 68*
>
> *gridgain.com *Powered by Apache® Ignite™
>

[GitHub] ignite pull request #4041: Apache ignite 2.5 release notes

[agura]

GitHub user agura opened a pull request:

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

Apache ignite 2.5 release notes



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

$ git pull https://github.com/agura/incubator-ignite release_notes

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

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


commit 65705474109cd72030994af1de3e064431b00d6f
Author: Andrey Gura 
Date:   2018-05-21T16:43:19Z

Apache Ignite 2.5 release notes




---

[jira] [Created] (IGNITE-8548) Make Apache Ignite JCache 1.1 specification compliant

[Denis Magda (JIRA)]

Denis Magda created IGNITE-8548:
---

 Summary: Make Apache Ignite JCache 1.1 specification compliant
 Key: IGNITE-8548
 URL: https://issues.apache.org/jira/browse/IGNITE-8548
 Project: Ignite
  Issue Type: Task
Reporter: Denis Magda
 Fix For: 2.6


JCache specification's license was changed to Apache 2.0, and 1.1 version was 
released:
https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU

Ignite needs to:
* Upgrade to JCacahe 1.1 in general to use Apache 2.0 license
*  Become JCache 1.1 compliant implementing new interfaces and passing TCK




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

Upgrading Ignite to JCache 1.1

[Denis Magda]

Igniters,

Eventually, JCache was relicensed to Apache 2.0 and released 1.1 version:
https://groups.google.com/forum/#!topic/jsr107/BC1qKqknzKU

Is there anyone interested in upgrading Ignite to the new version for the
next release?
https://issues.apache.org/jira/browse/IGNITE-8548

--
Denis

Re: Request for contributors permissions

[Denis Magda]

Thanks for the details. Please go ahead and implement it if you'd like.

--
Denis

On Sat, May 19, 2018 at 3:42 AM, uday kale  wrote:

> The ELB discovery currently supports classic load balancers only. What I
> want to add is ELB discovery for Application load balancers too. For
> difference between classic and application load balancers you can refer
> these links:
>
> https://docs.aws.amazon.com/elasticloadbalancing/latest/
> classic/introduction.html
> https://docs.aws.amazon.com/elasticloadbalancing/latest/
> application/introduction.html
>
>
> On Sat, May 19, 2018 at 12:19 AM Denis Magda  wrote:
>
> > Hello Uday and welcome!
> >
> > I've added you to the contributors' list in JIRA.
> >
> > Speaking about ELB Target Group based discovery, is it the same as this
> > type of ELB discovery already supported by Ignite?
> >
> > https://apacheignite-mix.readme.io/docs/amazon-aws#
> amazon-elb-based-discovery
> >
> >
> >
> > On Fri, May 18, 2018 at 8:48 AM, uday kale  wrote:
> >
> > > Hi,
> > >
> > > My name is Uday Kale. Username: *uday*. I want to add support for Node
> > > discovery through AWS Application ELB Target Group.
> > >
> > > Best Regards,
> > > Uday
> > >
> >
>

[GitHub] ignite pull request #4042: IGNITE-8547 Use JVM serialization for enum values...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-8547 Use JVM serialization for enum values with OptimizedMarshaller

.., avoid deadlock.

Also IGNITE-5087 Enum comparison fails after marshal-unmarshal with 
BinaryMarshaller.

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

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

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

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


commit beb2409cfe2045789443d47de735d879961d371e
Author: Andrey V. Mashenkov 
Date:   2017-06-23T09:26:06Z

GG-12352: Forcible node drop makes cluster instable in some cases.
Disable forcible node drop by default.

commit 802f18fc250cbae8959192c78bb28dc525ed3cf7
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Fix compilation

commit 39d2dec85a3c571dfdb1cd6189b53ae2413a5d22
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:41:30Z

Merge branch 'ignite-1.7.12-b2' into ignite-1.8.8

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/internal/GridTopic.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoManager.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/GridIoMessageFactory.java
#   
modules/core/src/main/java/org/apache/ignite/internal/managers/communication/IgniteIoTestMessage.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/atomic/GridDhtAtomicCache.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProcessor.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/task/GridTaskThreadContextKey.java
#   
modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 96445156143b46b664f785b353463dd435ac342d
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:42:44Z

Merge remote-tracking branch 'origin/ignite-1.8.8' into ignite-1.8.8

# Conflicts:
#   
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteCacheTestSuite5.java

commit 7c569f15a80ab9301c21011d2c9159e311e46cef
Author: Andrey V. Mashenkov 
Date:   2017-06-23T10:48:10Z

Merge remote-tracking branch 'origin/ignite-1.8.7.p1' into ignite-1.8.8

commit a64339449be8fa602cab3f2868c5f74004a7b747
Author: Igor Sapego 
Date:   2017-06-23T13:57:49Z

IGNITE-4370: Implemented writing of batch of parameters for ODBC.

(cherry picked from commit c10be5780589cc84e7929e234e4411d515166e0b)
(cherry picked from commit d268b32cb252a5f06887d2b803d27ddc20ded95f)

commit cbe5df51c423568782e31245c7f1aa06c9ba3be1
Author: Igor Sapego 
Date:   2017-06-13T16:47:00Z

IGNITE-5478: ODBC: SQLNumParams now returns number of required parameters.

(cherry picked from commit b1c56a1)

(cherry picked from commit 4a8f295)

commit 9ad513e68b89e907f7db36a3f3f0daca0e5986e6
Author: Igor Sapego 
Date:   2017-06-23T14:06:40Z

IGNITE-5478: Fix for cherry pick

(cherry picked from commit a2a4ec1ee9794cb542f146a07c6c67002cad444e)

commit bfec212b1ece0e9e791de6dfb642324834fa77ca
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 1abc14fdc4e39d8245c3e50fb2cf3d183df08021
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit cb95f7aa729fda19b4c3b7a5ada903a1e1bc2eab
Author: Andrey V. Mashenkov 
Date:   2017-06-23T16:08:00Z

Merge remote-tracking branch 'origin/ignite-1.7.12' into ignite-1.7.12

commit f59007f2c1221d8dd22abb0a9692b4abb31e87ad
Author: AMRepo 
Date:   2017-06-22T21:24:57Z

Partially reverted GG-12352.

commit 2c7d3c03cd36aee4f0985e674f550a62fc64d2db
Author: Andrey V. Mashenkov 
Date:   2017-06-23T17:11:00Z

Merge branch 'ignite-1.8.8' into ignite-1.9.4

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCachePreloaderAdapter.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/GridDhtPartitionTopologyImpl.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPreloader.java
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/security/SecurityUtils.java
#   
modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java

[GitHub] ignite pull request #4039: IGNITE-8544 Use exchange result topology version ...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4043: IGNITE-8406

[1vanan]

GitHub user 1vanan opened a pull request:

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

IGNITE-8406



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

$ git pull https://github.com/1vanan/ignite IGNITE-8406

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

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


commit d87793b407fe0f559a15871586961e0b33071733
Author: Fedotov 
Date:   2018-05-08T09:21:05Z

change javaDoc in IgniteDataStreamer




---

[jira] [Created] (IGNITE-8549) Include SSL related parameters for JDBC/ODBC

[Prachi Garg (JIRA)]

Prachi Garg created IGNITE-8549:
---

 Summary: Include SSL related parameters for JDBC/ODBC
 Key: IGNITE-8549
 URL: https://issues.apache.org/jira/browse/IGNITE-8549
 Project: Ignite
  Issue Type: Task
Reporter: Prachi Garg
Assignee: Prachi Garg
 Fix For: 2.5


DRIVER=\{Apache 
Ignite};ADDRESS=13.56.76.37:9954;USER=ignite;PASSWORD=1mSBcc8loX;*SSL_MODE=require;SSL_KEY_FILE=client.pem;SSL_CERT_FILE=client.pem;SSL_CA_FILE=client.pem*
 



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

[jira] [Created] (IGNITE-8550) CacheAbstractJdbcStore expects merge to always return 1 but MySQL may also return 2 or 0

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-8550:
--

 Summary: CacheAbstractJdbcStore expects merge to always return 1 
but MySQL may also return 2 or 0
 Key: IGNITE-8550
 URL: https://issues.apache.org/jira/browse/IGNITE-8550
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Stanislav Lukyanov


CacheAbstractJdbcStore.write attempts to execute a merge update if it is 
available, and expects the merge to always return 1 (as the number of updated 
entries is always 1).

However, MySQL's `INSERT ... ON DUPLICATE KEY UPDATE` 
(https://dev.mysql.com/doc/refman/8.0/en/insert-on-duplicate.html) may return 0 
or 2, depending on what was updated:
{quote}With ON DUPLICATE KEY UPDATE, the affected-rows value per row is 1 if 
the row is inserted as a new row, 2 if an existing row is updated, and 0 if an 
existing row is set to its current values.{quote}
Because of that, CacheAbstractJdbcStore may report a false warning.

Need to consider either removing the warning or special-case the MySQL dialect 
to allow to return values other than 1.



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

Re: NodeJS thin client: full API

[Alexey Kuznetsov]

Hi,

FYI, HZ also has NodeJs client: https://github.com/
hazelcast/hazelcast-nodejs-client
May be it is worth to take a look?

-- 
Alexey Kuznetsov

Discussion: Upgrade Ignite Spark Module's Spark version to 2.3.0

[Ray]

Spark released its newest version 2.3.0 on Feb 28th, so I'd like to open a
discussion about whether we should upgrade Ignite Spark module to to the
latest version.
In the release notes
https://spark.apache.org/releases/spark-release-2-3-0.html, spark 2.3
introduced many useful new features and as well as many performance and
stability changes.

So in the next release, I think we should support the Spark 2.3 in Ignite
Spark module.
I already created a ticket in jira
https://issues.apache.org/jira/browse/IGNITE-8534, and the patch is ready
for review.

Spark 2.3 dropped support for scala 2.10
https://issues.apache.org/jira/browse/SPARK-19810, so we also need to remove
spark-2.10 module if we decide to support Spark 2.3.

Please share your input, Igniters.



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

Re: Request for contributors permissions

[uday kale]

Thanks Denis

On Mon, May 21, 2018 at 10:46 PM Denis Magda  wrote:

> Thanks for the details. Please go ahead and implement it if you'd like.
>
> --
> Denis
>
> On Sat, May 19, 2018 at 3:42 AM, uday kale  wrote:
>
> > The ELB discovery currently supports classic load balancers only. What I
> > want to add is ELB discovery for Application load balancers too. For
> > difference between classic and application load balancers you can refer
> > these links:
> >
> > https://docs.aws.amazon.com/elasticloadbalancing/latest/
> > classic/introduction.html
> > https://docs.aws.amazon.com/elasticloadbalancing/latest/
> > application/introduction.html
> >
> >
> > On Sat, May 19, 2018 at 12:19 AM Denis Magda  wrote:
> >
> > > Hello Uday and welcome!
> > >
> > > I've added you to the contributors' list in JIRA.
> > >
> > > Speaking about ELB Target Group based discovery, is it the same as this
> > > type of ELB discovery already supported by Ignite?
> > >
> > > https://apacheignite-mix.readme.io/docs/amazon-aws#
> > amazon-elb-based-discovery
> > >
> > >
> > >
> > > On Fri, May 18, 2018 at 8:48 AM, uday kale 
> wrote:
> > >
> > > > Hi,
> > > >
> > > > My name is Uday Kale. Username: *uday*. I want to add support for
> Node
> > > > discovery through AWS Application ELB Target Group.
> > > >
> > > > Best Regards,
> > > > Uday
> > > >
> > >
> >
>