date:20180802

Re: [MTCGA]: new failures in builds [1576943] needs to be handled

2018-08-02 Thread Maxim Muzafarov

Hi Igniters,

this test was failed with link to

*https://issues.apache.org/jira/browse/IGNITE-9170
*I'm working on it. Will
be fixed soon.

On Fri, 3 Aug 2018 at 02:27  wrote:

> Hi Ignite Developer,
>
> I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed.
> I hope you can help.
>
>  *New Critical Failure in master Platform .NET (Long Running)
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning=%3Cdefault%3E=buildTypeStatusDiv
>  No changes in build
>
> - If your changes can led to this failure(s), please create issue
> with label MakeTeamCityGreenAgain and assign it to you.
> -- If you have fix, please set ticket to PA state and write to dev
> list fix is ready
> -- For case fix will require some time please mute test and set
> label Muted_Test to issue
> - If you know which change caused failure please contact change
> author directly
> - If you don't know which change caused failure please send
> message to dev list to find out
> Should you have any questions please contact dpav...@apache.org or write
> to dev.list
> Best Regards,
> MTCGA.Bot
> Notification generated at Fri Aug 03 02:27:40 MSK 2018
>
-- 
--
Maxim Muzafarov

[jira] [Created] (IGNITE-9177) Web console: full screen UI issues under Edge

2018-08-02 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-9177:
--

 Summary: Web console: full screen UI issues under Edge
 Key: IGNITE-9177
 URL: https://issues.apache.org/jira/browse/IGNITE-9177
 Project: Ignite
  Issue Type: Sub-task
Reporter: Pavel Konstantinov
Assignee: Dmitriy Shabalin






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

[jira] [Created] (IGNITE-9176) Web console: show authorization exception if user hasn't permission to activate a cluster

2018-08-02 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-9176:
--

 Summary: Web console: show authorization exception if user hasn't 
permission to activate a cluster
 Key: IGNITE-9176
 URL: https://issues.apache.org/jira/browse/IGNITE-9176
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov


I've faced with an issue that we don't show any error if a user has no 
permission to activate a cluster.



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

[MTCGA]: new failures in builds [1576943] needs to be handled

2018-08-02 Thread dpavlov . tasks

Hi Ignite Developer,

I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I 
hope you can help.

 *New Critical Failure in master Platform .NET (Long Running) 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning=%3Cdefault%3E=buildTypeStatusDiv
 No changes in build

- If your changes can led to this failure(s), please create issue with 
label MakeTeamCityGreenAgain and assign it to you.
-- If you have fix, please set ticket to PA state and write to dev list 
fix is ready 
-- For case fix will require some time please mute test and set label 
Muted_Test to issue 
- If you know which change caused failure please contact change author 
directly
- If you don't know which change caused failure please send message to 
dev list to find out
Should you have any questions please contact dpav...@apache.org or write to 
dev.list 
Best Regards,
MTCGA.Bot 
Notification generated at Fri Aug 03 02:27:40 MSK 2018

Re: Removing "fabric" from Ignite binary package name

2018-08-02 Thread Dmitriy Setrakyan

Anton, Petr,

Thanks for your readiness to assist. Can this be done for 2.7 release?

D.

On Thu, Aug 2, 2018 at 1:32 AM, Anton Vinogradov  wrote:

> What I see is that we spent almost a year discussing how to do this.
> I'm pretty sure we had enough time to do everything properly.
>
> So, proposal is to stop this discussion and start refactoring.
>
> I do not see any pitfalls and ready to assist if necessary.
>
> чт, 2 авг. 2018 г. в 5:14, Dmitriy Setrakyan :
>
> > I vote to remove the fabric from the build in the easiest way possible.
> Can
> > other Igniters comment?
> >
> > D.
> >
> > On Wed, Aug 1, 2018 at 12:46 PM, Petr Ivanov 
> wrote:
> >
> > > My concern here is exactly about internal build processes — removing
> > > fabric from the name of binary archive (with any way) will break lots
> of
> > > them.
> > > There will be no sacrifices, just lots of work for fixing build
> processes
> > > (where we won’t be able to introduce changes proactively).
> > >
> > > Therefore only fabric removal implementation (quick with some legacy
> left
> > > or full refactoring) is on the agenda.
> > > And this matter should be jugged by the community: currently we have
> (if
> > > our voices are equal) 1:1 with Anton about it.
> > >
> > >
> > >
> > >
> > > > On 1 Aug 2018, at 22:28, Dmitriy Setrakyan 
> > > wrote:
> > > >
> > > > Let's focus on what is important here. Our users do not care about
> our
> > > > internal build process.If we could remove the word fabric from the
> next
> > > > release without any significant sacrifices in the build process or
> > making
> > > > it less maintainable, I suggest we do it.
> > > >
> > > > D.
> > > >
> > > > On Wed, Aug 1, 2018 at 12:24 PM, Petr Ivanov 
> > > wrote:
> > > >
> > > >> Simple way with some hack and legacy maintenance: accept patch as it
> > is
> > > >> implemented now.
> > > >> Hard way: full assembly refactoring and hadoop rejection.
> > > >>
> > > >> Anyway, after this is merged to master — complete automation systems
> > > >> revision (TeamCity for example) is required due to heavy hardcode of
> > > >> “fabric” in such systems.
> > > >>
> > > >>
> > > >>> On 1 Aug 2018, at 21:55, Dmitriy Setrakyan 
> > > >> wrote:
> > > >>>
> > > >>> OK, so what is the plan? How do we get rid of the fabric name?
> > > >>>
> > > >>> D.
> > > >>>
> > > >>> On Wed, Aug 1, 2018 at 2:21 AM, Anton Vinogradov 
> > > wrote:
> > > >>>
> > >  Since you proposing patch to the community, you are the very man
> :)
> > > 
> > >  ср, 1 авг. 2018 г. в 12:16, Petr Ivanov :
> > > 
> > > > You are convincing the wrong person.
> > > >
> > > >
> > > >
> > > >> On 1 Aug 2018, at 12:05, Anton Vinogradov 
> wrote:
> > > >>
> > > >> Peter,
> > > >>
> > > >> We had a discussion about how to do this properly.
> > > >> Proposed solution cannot be merged, since it makes code harder
> > than
> > > it
> > > > was.
> > > >>
> > > >> The only case is to perform complete refactoring and get rid of
> > all
> > > >> postfixes and other weird stuff.
> > > >>
> > > >> For example
> > > >> - 
> > > >> - 
> > > >> should be definetely removed from code.
> > > >>
> > > >>
> > > >> ср, 1 авг. 2018 г. в 9:39, Peter Ivanov :
> > > >>
> > > >>> The task was ready long ago, but community failed to review and
> > > merge
> > >  it
> > > >>> ¯\_(ツ)_/¯
> > > >>> Not being a committer, my capabilities of introducing such
> > changes
> > > >> are
> > > >>> limited.
> > > >>>
> > > >>> I will update code during this week and will pass for review
> once
> > >  again.
> > > >>>
> > > >>>
> > > >>> On Wed, 1 Aug 2018 at 00:24, Dmitriy Setrakyan <
> > > >> dsetrak...@apache.org
> > > >
> > > >>> wrote:
> > > >>>
> > >  Yes, agree, fabric has to be removed. If it is done in 2.7,
> > would
> > > be
> > > >>> great!
> > > 
> > >  On Tue, Jul 31, 2018 at 2:18 PM, Denis Magda <
> dma...@apache.org
> > >
> > > > wrote:
> > > 
> > > > Peter, folks,
> > > >
> > > > It's weird, but we have been failing to introduce this minor
> > > change
> > > >>> since
> > > > December. Can we get it done for 2.7 that is being discussed
> at
> > > the
> > >  moment?
> > > > Are there any technical issues that block you from merging
> the
> > > > changes?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Thu, Jun 7, 2018 at 10:03 PM Peter Ivanov <
> > > mr.wei...@gmail.com>
> > >  wrote:
> > > >
> > > >> Ok, then I will update issue code and start preparation for
> > > build
> > > >> configuration changes.
> > > >>
> > > >>
> > > >> On Thu, 7 Jun 2018 at 23:41, Denis Magda  >
> > >  wrote:
> > > >>
> > > 
> > >  With which one — current implementation in issue?
> > >

Re: Ignite as distributed file storage

2018-08-02 Thread Dmitriy Setrakyan

On Thu, Aug 2, 2018 at 1:08 AM, Pavel Kovalenko  wrote:

> Dmitriy,
>
> I still don't understand why do you think that it will be file system?
> In all my previous messages I emphasized that this storage shouldn't be
> considered as a file system. It's just a large data storage, whose entities
> can be easily accessed using key/link (internally, or externally using
> web/binary protocol interfaces).
>
> > Instead, if we must focus on large blobs, I would solve the problem of
> supporting large blobs in regular Ignite caches, as I suggested before.
>
> This is impossible. Our page memory can't handle efficiently it by design.
>

But our API does. What is stopping us from creating a cache as a BLOB cache
and using whatever storage we need?

Re: Upgrading Ignite to JCache 1.1

2018-08-02 Thread Dmitriy Setrakyan

Thanks to everyone for making it happen!

On Thu, Aug 2, 2018 at 6:52 AM, Dmitriy Pavlov 
wrote:

> Hi Anton, Alexander, Denis, Nikita, Pavel,
>
> It is very good contribution. It resolved license issue with JCache 1.0.
>
> Thank you guys for making this happen.
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 2 авг. 2018 г. в 16:37, Anton Vinogradov :
>
> > Igniters,
> >
> > We officially support JCache 1.1 now [1].
> >
> > Huge thanks to everyone who hepled us:
> > - Alexander Menshikov
> > - Denis Garus
> > - Amelchev Nikita
> > - Pavel Pereslegin
> >
> > [1]
> >
> > https://ci.ignite.apache.org/viewLog.html?buildId=1578758;
> tab=queuedBuildOverviewTab
> >
> > чт, 19 июл. 2018 г. в 16:12, Vyacheslav Daradur :
> >
> > > Hi, Alex!
> > >
> > > Could you also help with the ticket [1]? If you have time.
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-9020
> > >
> > > On Tue, Jul 17, 2018 at 4:50 PM Denis Magda  wrote:
> > > >
> > > > Pavel,
> > > >
> > > > Could you chime in please?
> > > >
> > > > --
> > > > Denis
> > > >
> > > > On Tue, Jul 17, 2018 at 6:43 AM Nikita Amelchev <
> nsamelc...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi, Igniters.
> > > > >
> > > > > I'm implementing new version TCK 1.1 and I found the problem [1] in
> > the
> > > > > .NET module.
> > > > >
> > > > > In brief, .NET creates cache entry event based on values exist
> > > checking.
> > > > >
> > > > > TCK 1.1 says that getValue() not null for REMOVE/EXPIRED events if
> > old
> > > > > value required and it breaks logic.
> > > > >
> > > > > I'm looking for a .net contributor. Anyone ready to help?
> > > > >
> > > > > 1. https://issues.apache.org/jira/browse/IGNITE-9020
> > > > >
> > > > > 2018-06-15 14:35 GMT+03:00 Александр Меньшиков <
> sharple...@gmail.com
> > >:
> > > > >
> > > > > > Denis, I think we can include it to a minor release. Because the
> > > network
> > > > > > protocol, API, binary compatibility will be saved. And all
> behavior
> > > > > > changes, in fact, make implementation closer to the documentation
> > of
> > > > > JCache
> > > > > > 1.0. Because TCK 1.1.0 in general fixes differents between
> > > documentation
> > > > > > and tests in 1.0.
> > > > > >
> > > > > > 2018-06-14 21:41 GMT+03:00 Denis Magda :
> > > > > >
> > > > > > > Guys, are you targeting this for the next big Ignite release?
> > > Should be
> > > > > > in
> > > > > > > 3 m from now.
> > > > > > >
> > > > > > > --
> > > > > > > Denis
> > > > > > >
> > > > > > > On Thu, Jun 14, 2018 at 2:58 AM Anton Vinogradov <
> a...@apache.org>
> > > > > wrote:
> > > > > > >
> > > > > > > > Corrected IEP URL:
> > > > > > > >
> > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > > > 21%3A+JCache+1.1+support
> > > > > > > >
> > > > > > > > чт, 14 июн. 2018 г. в 12:48, Александр Меньшиков <
> > > > > sharple...@gmail.com
> > > > > > >:
> > > > > > > >
> > > > > > > > > Igniters,
> > > > > > > > >
> > > > > > > > > I've prepared IEP-21 [1] for this JCache updating task.
> > > > > > > > > It will help us to manage the issues and see the progress
> in
> > > one
> > > > > > place.
> > > > > > > > > Also, we have finally added tests for TCK 1.1.0 [2] to our
> TC
> > > which
> > > > > > can
> > > > > > > > be
> > > > > > > > > run on any branch.
> > > > > > > > > Both tests cases (for 1.0.1 and for 1.1.0) will coexist
> until
> > > > > IEP-21
> > > > > > > > > finish.
> > > > > > > > >
> > > > > > > > > [1]
> > > > > > > >
> > > > >
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-21:+JCache+1.1
> > > > > > > > > [2]
> > > > > > > > >
> > > > > > > > >
> > > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=
> > > > > > > IgniteTests24Java8_JCacheTck11
> > > > > > > > >
> > > > > > > > > 2018-06-06 0:49 GMT+03:00 Denis Magda  >:
> > > > > > > > >
> > > > > > > > > > Agree, I see zero benefits of being compliant with both
> > > > > > specification
> > > > > > > > > > versions. Let’s just focus on the latest one.
> > > > > > > > > >
> > > > > > > > > > Denis
> > > > > > > > > >
> > > > > > > > > > On Tuesday, June 5, 2018, Dmitriy Setrakyan <
> > > > > dsetrak...@apache.org
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Alex,
> > > > > > > > > > >
> > > > > > > > > > > I think it is OK to break TCK 1.0.1 tests in favor of
> TCK
> > > 1.1.
> > > > > > Once
> > > > > > > > we
> > > > > > > > > > > finish the migration, I would remove the TCK 1.0.1 test
> > > suite
> > > > > > > > > altogether.
> > > > > > > > > > >
> > > > > > > > > > > D.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Jun 5, 2018 at 11:13 AM, Александр Меньшиков <
> > > > > > > > > > sharple...@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Okay. There are tests results:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > https://ci.ignite.apache.org/viewLog.html?buildId=1361493;
> > > > > > > > > > > >
> > > > >

[GitHub] ignite pull request #4479: IGNITE-9170: fix resVer for local caches

2018-08-02 Thread Mmuzaf

GitHub user Mmuzaf opened a pull request:

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

IGNITE-9170: fix resVer for local caches



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

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

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

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


commit 03306835a3b6bc7e837d34eaf2ddc1b4870e3f6b
Author: Maxim Muzafarov 
Date:   2018-08-02T18:32:25Z

IGNITE-9170: fix resVer for local caches




---

[jira] [Created] (IGNITE-9175) AssertionError on simultaneous nodes stop

2018-08-02 Thread Eduard Shangareev (JIRA)

Eduard Shangareev created IGNITE-9175:
-

 Summary: AssertionError on simultaneous nodes stop
 Key: IGNITE-9175
 URL: https://issues.apache.org/jira/browse/IGNITE-9175
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev


{code}
[2018-08-02 
20:28:06,639][ERROR][tcp-disco-msg-worker-#6163%grid-tester-3%][TcpDiscoverySpi]
 TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node in 
order to prevent cluster wide instability.
java.lang.AssertionError
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.sendMessageAcrossRing(ServerImpl.java:2922)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processNodeLeftMessage(ServerImpl.java:4846)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2810)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2604)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7115)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2688)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7059)
at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
{code}



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

Re: async operation is not fair async

2018-08-02 Thread Dmitriy Govorukhin

Folks,
Any comments?
I will start to implement withFairAsync(); decorator soon.

On Wed, Aug 1, 2018 at 12:22 PM Dmitriy Pavlov 
wrote:

> Igniters,
>
> I've re-read this thread in brief. As far as I know this change is not
> coming from some company, so this change will be at least good for healthy
> community building.
>
> And I didn't find any obstacles why not to implement approach with new mode
> .withFairAsync() for cases user is completely aware of consequences.
>
> It could be not public API to avoid anyone will use it. It could be
> used,e.g. in integrations and by qualified users to gain as much
> throutghput as it is possible.
>
> So I would like to be an sponsor here. If anyone or Dmitriy G. will
> contribute this change, I will merge it. I hope PMCs are agree here and
> will not veto this change.
>
> Sincerely,
> Dmitriy Pavlov
>
> чт, 24 мая 2018 г. в 15:13, Yakov Zhdanov :
>
> > Alexey Goncharuk, I remember we started working on async connection
> > establishment. This should fix latency issue related to network which I
> > believe gives the most contribution to overall latency. Mapping logic and
> > other stuff can be ignored as it can very rarely be an issue at least on
> > stable tolopogies. What is the status with async connections? That would
> > really be a huge improvement!
> >
> > Also please remember that uncontrolled async operations may lead to OOME,
> > therefore at some point when there are too many uncompleted async
> > operations newly invoked async operations should become synchronous, i.e.
> > we should return completed future, ignoring the fact that user expected
> us
> > to be async.
> >
> > I would like to have very strong reasons to start reapproaching this.
> >
> > --Yakov
> >
>

[jira] [Created] (IGNITE-9173) Null value for decimal column is shown as the empty string in sqlline

2018-08-02 Thread Sergey Kozlov (JIRA)

Sergey Kozlov created IGNITE-9173:
-

 Summary: Null value for decimal column is shown as the empty 
string in sqlline
 Key: IGNITE-9173
 URL: https://issues.apache.org/jira/browse/IGNITE-9173
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Sergey Kozlov


{noformat}
0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int not null, b decimal, 
primary ke
No rows affected (0,016 seconds)
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,NULL);
1 row affected (0,002 seconds)
0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
+++
|   A|   B|
+++
| 1  ||
+++
1 row selected (0,006 seconds)
{noformat}



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

[GitHub] ignite pull request #4277: IGNITE-8869: Retrieves nodes directly from topolo...

2018-08-02 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[GitHub] ignite pull request #4478: IGNITE-9160 Fix equals() methods

2018-08-02 Thread zzzadruga

GitHub user zzzadruga opened a pull request:

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

IGNITE-9160 Fix equals() methods



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

$ git pull https://github.com/zzzadruga/ignite IGINTE-9160

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

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


commit 04d85b874f3626739cab02e501db58e2cbe39fce
Author: zzzadruga 
Date:   2018-08-02T15:25:49Z

IGNITE-9160 Fix equals() methods




---

[GitHub] ignite pull request #4477: Cache (Deadlock Detection) suite hangs

2018-08-02 Thread BiryukovVA

GitHub user BiryukovVA opened a pull request:

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

Cache (Deadlock Detection) suite hangs



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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-9169

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

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


commit d14e6bbd462f83a3d90323757eebe3d6fc40ecd2
Author: Vitaliy Biryukov 
Date:   2018-08-02T15:29:25Z

IGNITE-9169: Eating IgniteInterruptedCheckedException in thread prevented.




---

[GitHub] ignite pull request #4444: IGNITE-9073 Use jackson2 dependency instead of ja...

2018-08-02 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9172) IgniteEx.cachex doesn't return existing cache

2018-08-02 Thread Nikolay Izhikov (JIRA)

Nikolay Izhikov created IGNITE-9172:
---

 Summary: IgniteEx.cachex doesn't return existing cache
 Key: IGNITE-9172
 URL: https://issues.apache.org/jira/browse/IGNITE-9172
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov


{{IgniteEx.cachex}} method doesn't return an existing cache from a client node.

Reproducer:

{code:java}
public class ClientNodeTest extends GridCommonAbstractTest {
/** {@inheritDoc} */
@Override protected IgniteConfiguration getConfiguration(String name) 
throws Exception {
IgniteConfiguration cfg = super.getConfiguration(name);

cfg.setClientMode(name.equals("client"));

if (name.equals("client") || name.equals(GRID_0))
cfg.setCacheConfiguration(new CacheConfiguration("cache-1"));
else
cfg.setCacheConfiguration(new CacheConfiguration("cache-2"));

return cfg;
}

public void testClient() throws Exception {
cleanPersistenceDir();

IgniteEx grid0 = startGrid(GRID_0);

IgniteEx grid1 = startGrid(GRID_1);

IgniteEx client = startGrid("client");

grid0.cluster().active(true);

awaitPartitionMapExchange();

boolean cachex1 = client.cachex("cache-1") != null;
boolean cachex2 = client.cachex("cache-2") != null;
boolean cache1 = client.cache("cache-2") != null;
boolean cache2 = client.cache("cache-2") != null;

System.out.println("cachex1 = " + cachex1);
System.out.println("cachex2 = " + cachex2);
System.out.println("cache1 = " + cache1);
System.out.println("cache2 = " + cache2);

assertTrue(cachex1);
assertTrue(cachex2);
assertTrue(cache1);
assertTrue(cache2);
}
}
{code}



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

[jira] [Created] (IGNITE-9171) Use lazy mode with results pre-fetch

2018-08-02 Thread Taras Ledkov (JIRA)

Taras Ledkov created IGNITE-9171:


 Summary: Use lazy mode with results pre-fetch
 Key: IGNITE-9171
 URL: https://issues.apache.org/jira/browse/IGNITE-9171
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 2.6
Reporter: Taras Ledkov
Assignee: Taras Ledkov


Current implementation of the {{lazy}} mode always starts separate thread for 
{{MapQueryLazyWorker}}. It  causes excessive overhead for requests that 
produces small results set.

We have to begin execute query at the {{QUERY_POOL}} thread pool and fetch 
first page of the results. In case results set is bigger than one page 
{{MapQueryLazyWorker}} is started and link with {{MapNodeResults}} to handle 
next pages lazy.



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

Re: [MTCGA]: new failures in builds [1575775] needs to be handled

2018-08-02 Thread Maxim Muzafarov

Folks,

Seems like rebalancing changes leads us to hanging TestRebalance() test for
.NET.
Created issue [1], I will try to investigate it.

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

On Thu, 2 Aug 2018 at 17:12  wrote:

> Hi Ignite Developer,
>
> I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed.
> I hope you can help.
>
>  *New Critical Failure in master Platform .NET (Long Running)
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning=%3Cdefault%3E=buildTypeStatusDiv
>  Changes may led to failure were done by
>  - sboikov
> http://ci.ignite.apache.org/viewModification.html?modId=827278=false
>  - saikat.maitra
> http://ci.ignite.apache.org/viewModification.html?modId=827276=false
>  - maxmuzaf
> http://ci.ignite.apache.org/viewModification.html?modId=827268=false
>  - biryukovvitaliy92
> http://ci.ignite.apache.org/viewModification.html?modId=827267=false
>  - alkuznetsov.sb
> http://ci.ignite.apache.org/viewModification.html?modId=827258=false
>  - ilantukh
> http://ci.ignite.apache.org/viewModification.html?modId=827250=false
>
> - If your changes can led to this failure(s), please create issue
> with label MakeTeamCityGreenAgain and assign it to you.
> -- If you have fix, please set ticket to PA state and write to dev
> list fix is ready
> -- For case fix will require some time please mute test and set
> label Muted_Test to issue
> - If you know which change caused failure please contact change
> author directly
> - If you don't know which change caused failure please send
> message to dev list to find out
> Should you have any questions please contact dpav...@apache.org or write
> to dev.list
> Best Regards,
> MTCGA.Bot
> Notification generated at Thu Aug 02 17:12:39 MSK 2018
>
-- 
--
Maxim Muzafarov

[jira] [Created] (IGNITE-9170) .NET: Test CacheAbstractTest.TestRebalance hangs

2018-08-02 Thread Maxim Muzafarov (JIRA)

Maxim Muzafarov created IGNITE-9170:
---

 Summary: .NET: Test CacheAbstractTest.TestRebalance hangs
 Key: IGNITE-9170
 URL: https://issues.apache.org/jira/browse/IGNITE-9170
 Project: Ignite
  Issue Type: Test
Reporter: Maxim Muzafarov


Test hangs 
{{CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance}}

{code}
[Apache.Ignite.Core.Tests.exe] 
Apache.Ignite.Core.Tests.Cache.CachePartitionedAtomicNearEnabledTest.CacheAbstractTest.TestRebalance
 (1h:57m:24s)
{code}

https://ci.ignite.apache.org/viewLog.html?tab=buildLog=tree=debug=all=1575775&_focus=4725#_state=



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

[jira] [Created] (IGNITE-9169) Cache (Deadlock Detection) hangs

2018-08-02 Thread Vitaliy Biryukov (JIRA)

Vitaliy Biryukov created IGNITE-9169:


 Summary: Cache (Deadlock Detection) hangs
 Key: IGNITE-9169
 URL: https://issues.apache.org/jira/browse/IGNITE-9169
 Project: Ignite
  Issue Type: Bug
Affects Versions: 2.6
Reporter: Vitaliy Biryukov
Assignee: Vitaliy Biryukov
 Fix For: 2.7






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

[MTCGA]: new failures in builds [1575775] needs to be handled

2018-08-02 Thread dpavlov . tasks

Hi Ignite Developer,

I am MTCGA.Bot, and I've detected some issue on TeamCity to be addressed. I 
hope you can help.

 *New Critical Failure in master Platform .NET (Long Running) 
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformNetLongRunning=%3Cdefault%3E=buildTypeStatusDiv
 Changes may led to failure were done by 
 - sboikov 
http://ci.ignite.apache.org/viewModification.html?modId=827278=false
 - saikat.maitra 
http://ci.ignite.apache.org/viewModification.html?modId=827276=false
 - maxmuzaf 
http://ci.ignite.apache.org/viewModification.html?modId=827268=false
 - biryukovvitaliy92 
http://ci.ignite.apache.org/viewModification.html?modId=827267=false
 - alkuznetsov.sb 
http://ci.ignite.apache.org/viewModification.html?modId=827258=false
 - ilantukh 
http://ci.ignite.apache.org/viewModification.html?modId=827250=false

- If your changes can led to this failure(s), please create issue with 
label MakeTeamCityGreenAgain and assign it to you.
-- If you have fix, please set ticket to PA state and write to dev list 
fix is ready 
-- For case fix will require some time please mute test and set label 
Muted_Test to issue 
- If you know which change caused failure please contact change author 
directly
- If you don't know which change caused failure please send message to 
dev list to find out
Should you have any questions please contact dpav...@apache.org or write to 
dev.list 
Best Regards,
MTCGA.Bot 
Notification generated at Thu Aug 02 17:12:39 MSK 2018

Re: Upgrading Ignite to JCache 1.1

2018-08-02 Thread Dmitriy Pavlov

Hi Anton, Alexander, Denis, Nikita, Pavel,

It is very good contribution. It resolved license issue with JCache 1.0.

Thank you guys for making this happen.

Sincerely,
Dmitriy Pavlov

чт, 2 авг. 2018 г. в 16:37, Anton Vinogradov :

> Igniters,
>
> We officially support JCache 1.1 now [1].
>
> Huge thanks to everyone who hepled us:
> - Alexander Menshikov
> - Denis Garus
> - Amelchev Nikita
> - Pavel Pereslegin
>
> [1]
>
> https://ci.ignite.apache.org/viewLog.html?buildId=1578758=queuedBuildOverviewTab
>
> чт, 19 июл. 2018 г. в 16:12, Vyacheslav Daradur :
>
> > Hi, Alex!
> >
> > Could you also help with the ticket [1]? If you have time.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9020
> >
> > On Tue, Jul 17, 2018 at 4:50 PM Denis Magda  wrote:
> > >
> > > Pavel,
> > >
> > > Could you chime in please?
> > >
> > > --
> > > Denis
> > >
> > > On Tue, Jul 17, 2018 at 6:43 AM Nikita Amelchev 
> > > wrote:
> > >
> > > > Hi, Igniters.
> > > >
> > > > I'm implementing new version TCK 1.1 and I found the problem [1] in
> the
> > > > .NET module.
> > > >
> > > > In brief, .NET creates cache entry event based on values exist
> > checking.
> > > >
> > > > TCK 1.1 says that getValue() not null for REMOVE/EXPIRED events if
> old
> > > > value required and it breaks logic.
> > > >
> > > > I'm looking for a .net contributor. Anyone ready to help?
> > > >
> > > > 1. https://issues.apache.org/jira/browse/IGNITE-9020
> > > >
> > > > 2018-06-15 14:35 GMT+03:00 Александр Меньшиков  >:
> > > >
> > > > > Denis, I think we can include it to a minor release. Because the
> > network
> > > > > protocol, API, binary compatibility will be saved. And all behavior
> > > > > changes, in fact, make implementation closer to the documentation
> of
> > > > JCache
> > > > > 1.0. Because TCK 1.1.0 in general fixes differents between
> > documentation
> > > > > and tests in 1.0.
> > > > >
> > > > > 2018-06-14 21:41 GMT+03:00 Denis Magda :
> > > > >
> > > > > > Guys, are you targeting this for the next big Ignite release?
> > Should be
> > > > > in
> > > > > > 3 m from now.
> > > > > >
> > > > > > --
> > > > > > Denis
> > > > > >
> > > > > > On Thu, Jun 14, 2018 at 2:58 AM Anton Vinogradov 
> > > > wrote:
> > > > > >
> > > > > > > Corrected IEP URL:
> > > > > > >
> > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > > 21%3A+JCache+1.1+support
> > > > > > >
> > > > > > > чт, 14 июн. 2018 г. в 12:48, Александр Меньшиков <
> > > > sharple...@gmail.com
> > > > > >:
> > > > > > >
> > > > > > > > Igniters,
> > > > > > > >
> > > > > > > > I've prepared IEP-21 [1] for this JCache updating task.
> > > > > > > > It will help us to manage the issues and see the progress in
> > one
> > > > > place.
> > > > > > > > Also, we have finally added tests for TCK 1.1.0 [2] to our TC
> > which
> > > > > can
> > > > > > > be
> > > > > > > > run on any branch.
> > > > > > > > Both tests cases (for 1.0.1 and for 1.1.0) will coexist until
> > > > IEP-21
> > > > > > > > finish.
> > > > > > > >
> > > > > > > > [1]
> > > > > > >
> > > >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-21:+JCache+1.1
> > > > > > > > [2]
> > > > > > > >
> > > > > > > >
> > > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=
> > > > > > IgniteTests24Java8_JCacheTck11
> > > > > > > >
> > > > > > > > 2018-06-06 0:49 GMT+03:00 Denis Magda :
> > > > > > > >
> > > > > > > > > Agree, I see zero benefits of being compliant with both
> > > > > specification
> > > > > > > > > versions. Let’s just focus on the latest one.
> > > > > > > > >
> > > > > > > > > Denis
> > > > > > > > >
> > > > > > > > > On Tuesday, June 5, 2018, Dmitriy Setrakyan <
> > > > dsetrak...@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Alex,
> > > > > > > > > >
> > > > > > > > > > I think it is OK to break TCK 1.0.1 tests in favor of TCK
> > 1.1.
> > > > > Once
> > > > > > > we
> > > > > > > > > > finish the migration, I would remove the TCK 1.0.1 test
> > suite
> > > > > > > > altogether.
> > > > > > > > > >
> > > > > > > > > > D.
> > > > > > > > > >
> > > > > > > > > > On Tue, Jun 5, 2018 at 11:13 AM, Александр Меньшиков <
> > > > > > > > > sharple...@gmail.com
> > > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Okay. There are tests results:
> > > > > > > > > > >
> > > > > > > > > > >
> > https://ci.ignite.apache.org/viewLog.html?buildId=1361493;
> > > > > > > > > > >
> > > > tab=buildResultsDiv=IgniteTests24Java8_JCacheTck11
> > > > > > > > > > >
> > > > > > > > > > > It's the same as locally.
> > > > > > > > > > >
> > > > > > > > > > > Also, I have created sub-tasks for all problems we
> have:
> > > > > > > > > > >
> > > > > > > > > > > 1) CacheManagerTest.getUnsafeTypedCacheRequest failed.
> > > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8704
> > > > > > > > > > >
> > > > > > > > > > > 2) CacheMBStatisticsBeanTest.testClear failed.
> > > > > > > > > > >

Re: IP finder in tests

2018-08-02 Thread Denis Mekhanikov

Yakov,

Almost every test in the project uses the Vm IP finder anyway.
It has become a convention to use it in all tests.
So, I'm trying to reduce the amount of copy-pasted code and improve test's
isolation.

Also tests may be run outside TeamCity during development process.
Multicast Ip Finder makes developers disconnect from their networks to
guarantee, that no other nodes will get in the way.
So, I don't see any advantages of multicast IP finder over Vm in context of
tests.

Denis

чт, 2 авг. 2018 г. в 1:46, Pavel Kovalenko :

> Hi Yakov,
>
> Currently TC agents defended by Docker virtual network, that's why we don't
> see intersection between several clusters, but in case of any step aside
> (running several suites on one agent, running several tests on one machine
> and so on) we will have problems and return back to this conversation.
> I'm voting for simplifying and speeding up testing process. It will also
> reduce the number of copy-paste in ton of tests, where Vm Ip Finder is used
> explicitly. As developer I'm confusing when I see in a test VmIpFinder and
> in other test Multicast without any reason or comment.
> If you care about test coverage of MulticastIpFinder you can pick several
> suites where number of starting/stopping is most frequent and leave
> multicast there, but in general it's not necessary to have it everywhere.
>
> 2018-08-02 0:54 GMT+03:00 Yakov Zhdanov :
>
> > It should be true, otherwise we would have nodes from all agents
> > intersecting. No?
> >
> > And multicast IP finder is the defailt one, so I would not reduce its
> test
> > volume.
> >
> > Yakov Zhdanov
> > www.gridgain.com
> >
> > 2018-08-02 0:32 GMT+03:00 Dmitriy Pavlov :
> >
> > > Hi Yakov,
> > >
> > > Regarding Each TC agent use own multicast: I'm not sure it is true, TC
> > > admins tried to do so, but not succeded.
> > >
> > > One more reason is speed of tests run. Why do we need to scan something
> > if
> > > we always will connect localhost. TC tests do not use multicast in
> almost
> > > every test.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > чт, 2 авг. 2018 г. в 0:27, Yakov Zhdanov :
> > >
> > > > I disagree. Probably, no change required. Each TC agent use own
> > multicast
> > > > group so nodes do not intersect. If any of the test does not properly
> > > clean
> > > > up and leaves nodes running this dhould be flagged as test fail which
> > is
> > > > the case.
> > > >
> > > > Please provide strong reasons to start with this.
> > > >
> > > > --Yakov
> > > >
> > >
> >
>

Re: Upgrading Ignite to JCache 1.1

2018-08-02 Thread Anton Vinogradov

Igniters,

We officially support JCache 1.1 now [1].

Huge thanks to everyone who hepled us:
- Alexander Menshikov
- Denis Garus
- Amelchev Nikita
- Pavel Pereslegin

[1]
https://ci.ignite.apache.org/viewLog.html?buildId=1578758=queuedBuildOverviewTab

чт, 19 июл. 2018 г. в 16:12, Vyacheslav Daradur :

> Hi, Alex!
>
> Could you also help with the ticket [1]? If you have time.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9020
>
> On Tue, Jul 17, 2018 at 4:50 PM Denis Magda  wrote:
> >
> > Pavel,
> >
> > Could you chime in please?
> >
> > --
> > Denis
> >
> > On Tue, Jul 17, 2018 at 6:43 AM Nikita Amelchev 
> > wrote:
> >
> > > Hi, Igniters.
> > >
> > > I'm implementing new version TCK 1.1 and I found the problem [1] in the
> > > .NET module.
> > >
> > > In brief, .NET creates cache entry event based on values exist
> checking.
> > >
> > > TCK 1.1 says that getValue() not null for REMOVE/EXPIRED events if old
> > > value required and it breaks logic.
> > >
> > > I'm looking for a .net contributor. Anyone ready to help?
> > >
> > > 1. https://issues.apache.org/jira/browse/IGNITE-9020
> > >
> > > 2018-06-15 14:35 GMT+03:00 Александр Меньшиков :
> > >
> > > > Denis, I think we can include it to a minor release. Because the
> network
> > > > protocol, API, binary compatibility will be saved. And all behavior
> > > > changes, in fact, make implementation closer to the documentation of
> > > JCache
> > > > 1.0. Because TCK 1.1.0 in general fixes differents between
> documentation
> > > > and tests in 1.0.
> > > >
> > > > 2018-06-14 21:41 GMT+03:00 Denis Magda :
> > > >
> > > > > Guys, are you targeting this for the next big Ignite release?
> Should be
> > > > in
> > > > > 3 m from now.
> > > > >
> > > > > --
> > > > > Denis
> > > > >
> > > > > On Thu, Jun 14, 2018 at 2:58 AM Anton Vinogradov 
> > > wrote:
> > > > >
> > > > > > Corrected IEP URL:
> > > > > >
> > > > > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > > > > 21%3A+JCache+1.1+support
> > > > > >
> > > > > > чт, 14 июн. 2018 г. в 12:48, Александр Меньшиков <
> > > sharple...@gmail.com
> > > > >:
> > > > > >
> > > > > > > Igniters,
> > > > > > >
> > > > > > > I've prepared IEP-21 [1] for this JCache updating task.
> > > > > > > It will help us to manage the issues and see the progress in
> one
> > > > place.
> > > > > > > Also, we have finally added tests for TCK 1.1.0 [2] to our TC
> which
> > > > can
> > > > > > be
> > > > > > > run on any branch.
> > > > > > > Both tests cases (for 1.0.1 and for 1.1.0) will coexist until
> > > IEP-21
> > > > > > > finish.
> > > > > > >
> > > > > > > [1]
> > > > > >
> > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-21:+JCache+1.1
> > > > > > > [2]
> > > > > > >
> > > > > > >
> > > > > > https://ci.ignite.apache.org/viewType.html?buildTypeId=
> > > > > IgniteTests24Java8_JCacheTck11
> > > > > > >
> > > > > > > 2018-06-06 0:49 GMT+03:00 Denis Magda :
> > > > > > >
> > > > > > > > Agree, I see zero benefits of being compliant with both
> > > > specification
> > > > > > > > versions. Let’s just focus on the latest one.
> > > > > > > >
> > > > > > > > Denis
> > > > > > > >
> > > > > > > > On Tuesday, June 5, 2018, Dmitriy Setrakyan <
> > > dsetrak...@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Alex,
> > > > > > > > >
> > > > > > > > > I think it is OK to break TCK 1.0.1 tests in favor of TCK
> 1.1.
> > > > Once
> > > > > > we
> > > > > > > > > finish the migration, I would remove the TCK 1.0.1 test
> suite
> > > > > > > altogether.
> > > > > > > > >
> > > > > > > > > D.
> > > > > > > > >
> > > > > > > > > On Tue, Jun 5, 2018 at 11:13 AM, Александр Меньшиков <
> > > > > > > > sharple...@gmail.com
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Okay. There are tests results:
> > > > > > > > > >
> > > > > > > > > >
> https://ci.ignite.apache.org/viewLog.html?buildId=1361493;
> > > > > > > > > >
> > > tab=buildResultsDiv=IgniteTests24Java8_JCacheTck11
> > > > > > > > > >
> > > > > > > > > > It's the same as locally.
> > > > > > > > > >
> > > > > > > > > > Also, I have created sub-tasks for all problems we have:
> > > > > > > > > >
> > > > > > > > > > 1) CacheManagerTest.getUnsafeTypedCacheRequest failed.
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8704
> > > > > > > > > >
> > > > > > > > > > 2) CacheMBStatisticsBeanTest.testClear failed.
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8705
> > > > > > > > > >
> > > > > > > > > > 3) CacheManagerTest.close_cachesEmpty failed.
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8708
> > > > > > > > > >
> > > > > > > > > > 4) CacheMBStatisticsBeanTest.testPutIfAbsent failed.
> > > > > > > > > > https://issues.apache.org/jira/browse/IGNITE-8709
> > > > > > > > > >
> > > > > > > > > > 5) CacheEntryEvent.getOldValue should be available.
> > > > > > > > > > Two tests fail because of it.
> > > > > > > > > >
> > > > > > > > > > Looks like

[jira] [Created] (IGNITE-9168) AssertionError on local join when coordinator leaves cluster

2018-08-02 Thread Eduard Shangareev (JIRA)

Eduard Shangareev created IGNITE-9168:
-

 Summary: AssertionError on local join when coordinator leaves 
cluster
 Key: IGNITE-9168
 URL: https://issues.apache.org/jira/browse/IGNITE-9168
 Project: Ignite
  Issue Type: Bug
Reporter: Eduard Shangareev






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

Backup queue for local continuous query

2018-08-02 Thread Denis Mekhanikov

Igniters,

I noticed, that local continuous queries store queues with backup entries.
And since the queries are local, other nodes never send acknowledges.

It has two negative effects:
1) Backup queue may grow indefinitely and cause OOME.
2) When topology changes, the backup queue is flushed, and old
notifications are delivered to the listener, even if they happened long
time ago.

I prepared a fix for it. You can find it in the ticket: IGNITE-9009

It makes local continuous queries ignore backup entries and not put them
into the backup queues.

Nikolay, Semyon,
You are the people, who implemented this piece of functionality.
Could you review these changes and share your opinion?

I can think of another way to fix it: we could register
*CacheContinuousQueryHandlers* on all nodes even for a local CQ, and make
them send backup notifications to the subscriber node.
It will help in cases, when you create local listeners on all nodes and
want all nodes to process changes, that happen on their primary partitions.
In this case backup entries may help not to lose updates. But actually it
will leave a time window between sending a backup acknowledge and notifying
the local listener. And such use-case will generate quadratic number of
handlers and pollute the network communication.

So, I prefer the first option.

What do you think?

Denis

[jira] [Created] (IGNITE-9167) Wrong output for binary column in SELECT

2018-08-02 Thread Sergey Kozlov (JIRA)

Sergey Kozlov created IGNITE-9167:
-

 Summary: Wrong output for binary column in SELECT
 Key: IGNITE-9167
 URL: https://issues.apache.org/jira/browse/IGNITE-9167
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Sergey Kozlov


1. Start Ignite node
2. Start sqlline and make table with BINARY col then insert and select:
{noformat}
sqlline version 1.3.0
0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int not null, b binary, 
primary key(a));
No rows affected (0,127 seconds)
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 (a,b) values (1, NULL);
1 row affected (0,04 seconds)
0: jdbc:ignite:thin://127.0.0.1/> insert into t1 (a,b) values (2, X'00FF');
1 row affected (0 seconds)
0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
+++
|   A|   B|
+++
| 1  ||
| 2  | [B@6276ae34|
+++
2 rows selected (0,038 seconds)
{noformat}


H2 output (for comparison):
{noformat}
0: jdbc:h2:mem:test> create table t1 (a int not null, b binary, primary key(a));
No rows affected (0,003 seconds)
0: jdbc:h2:mem:test> insert into t1 (a,b) values (2, X'00FF');
1 row affected (0 seconds)
0: jdbc:h2:mem:test> select b from t1;
+---+
| B |
+---+
| 00ff |
+---+
{noformat}



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

[jira] [Created] (IGNITE-9166) Web console: do not disable the Save button on changing password in user profile

2018-08-02 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-9166:
--

 Summary: Web console: do not disable the Save button on changing 
password in user profile
 Key: IGNITE-9166
 URL: https://issues.apache.org/jira/browse/IGNITE-9166
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov
 Attachments: screenshot-1.png





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

[jira] [Created] (IGNITE-9165) FindBugs: Methods may fail to close stream in core module

2018-08-02 Thread Nikolai Kulagin (JIRA)

Nikolai Kulagin created IGNITE-9165:
---

 Summary: FindBugs: Methods may fail to close stream in core module
 Key: IGNITE-9165
 URL: https://issues.apache.org/jira/browse/IGNITE-9165
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.6
Reporter: Nikolai Kulagin
Assignee: Nikolai Kulagin
 Fix For: 2.7
 Attachments: 
findbugs-result-apache-ignite[ignite-core]_2018_08_02_12_38_02.html

The method creates an IO stream object, does not assign it to any fields, pass 
it to other methods that might close it, or return it, and does not appear to 
close the stream on all paths out of the method.  This may result in a file 
descriptor leak.

Example:

 
{code:java}
// GridCacheAbstractLoadTest#GridCacheAbstractLoadTest()

try {
 props.load(new FileReader(GridTestUtils.resolveIgnitePath(
 "modules/tests/config/cache-load.properties")));
}
catch (IOException e) {
 throw new RuntimeException(e);
}{code}
 
One of possible solutions:
{code:java}
try(Reader reader = new FileReader(GridTestUtils.resolveIgnitePath(
"modules/tests/config/cache-load.properties"))) {
props.load(reader);
}
catch (IOException e) {
throw new RuntimeException(e);
}{code}
List of classes in "core" module:
 
+org.apache.ignite.internal:+ *   *BinaryContext*#classesInPackage(String) , 
line 583
 *   *GridClientJdkMarshalle*r#marshal(Object, int), line 61
 *   
*IgniteExplicitImplicitDeploymentSelfTest*$GridDeploymentResourceTestJob#execute(),
 line 474
 *   *OptimizedObjectStreamSelfTest*#testReadLine(), line 793
 *   *PageIdDistributionTest*#_testRealHistory(), line 220
 *   *HttpIgniteUpdatesChecker*#getUpdates(boolean), line 69
 *   *IpcSharedMemoryNativeLoaderSelfTest*#readStreams(Process), line 207

 
+org.apache.ignite:+
  *GridCacheAbstractLoadTest*#GridCacheAbstractLoadTest(), line 123
  *GridTestUtils*.sslContext(), line 1674



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

[jira] [Created] (IGNITE-9164) Web console: issue with cluster authentication

2018-08-02 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-9164:
--

 Summary: Web console: issue with cluster authentication 
 Key: IGNITE-9164
 URL: https://issues.apache.org/jira/browse/IGNITE-9164
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov
 Attachments: screenshot-1.png

Start a cluster with authentication Enabled = true
Open Monitoring - authentication modal has appeared 
Click Cancel - it is impossible to switch to another cluster if a user forgot a 
password (for example)



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

[jira] [Created] (IGNITE-9163) Web console: incorrect cluster state for clusters of version 7.x

2018-08-02 Thread Pavel Konstantinov (JIRA)

Pavel Konstantinov created IGNITE-9163:
--

 Summary: Web console: incorrect cluster state for clusters of 
version 7.x
 Key: IGNITE-9163
 URL: https://issues.apache.org/jira/browse/IGNITE-9163
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Konstantinov
Assignee: Alexey Kuznetsov
 Attachments: screenshot-1.png





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

[jira] [Created] (IGNITE-9162) Query returns ICE: org.h2.table.TableView cannot be cast

2018-08-02 Thread Sergey Kozlov (JIRA)

Sergey Kozlov created IGNITE-9162:
-

 Summary: Query returns ICE: org.h2.table.TableView cannot be cast
 Key: IGNITE-9162
 URL: https://issues.apache.org/jira/browse/IGNITE-9162
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.4
Reporter: Sergey Kozlov


1. Start 1 Ignite node {{bin/ignite.sh server.xml -v -J-DCONSISTENT_ID=node1}}
2. Start sqlline {{bin/sqlline.sh -u 
jdbc:ignite:thin://127.0.0.1/?distributedJoins=true}}
3. Execute statements:

{noformat}
0: jdbc:ignite:thin://127.0.0.1/> CREATE TABLE t1 ( id INT NOT NULL, int_col1 
INT NOT NULL, PRIMARY KEY (id)) WITH "TEMPLATE=partitioned";
No rows affected (0,151 seconds)
0: jdbc:ignite:thin://127.0.0.1/> INSERT INTO t1 (id,int_col1) VALUES 
(1,0),(2,0),(3,0),(4,0);
4 rows affected (0,052 seconds)
0: jdbc:ignite:thin://127.0.0.1/> SELECT * FROM ( SELECT * FROM t1 WHERE 
int_col1  > 0 ORDER BY id ) WHERE int_col1  = 1
 ORDER BY id;
Error: javax.cache.CacheException: class 
org.apache.ignite.IgniteCheckedException: org.h2.table.TableView cannot be cast
 to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table 
(state=5,code=0)
0: jdbc:ignite:thin://127.0.0.1/>
{noformat}

Node log:
{noformat}
[12:39:38,162][SEVERE][client-connector-#50][JdbcRequestHandler] Failed to 
execute SQL query [reqId=0, req=JdbcQueryExecuteRequest [schemaName=PUBLIC, 
pageSize=1024, maxRows=0, sqlQry=SELECT * FROM ( SELECT * FROM t1 WHERE 
int_col1  > 0 ORDER BY id ) WHERE int_col1  = 1 ORDER BY id, args=[], 
stmtType=ANY_STATEMENT_TYPE]]
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: 
org.h2.table.TableView cannot be cast to 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2047)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:456)
at 
org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:203)
at 
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:160)
at 
org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:44)
at 
org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
at 
org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
at 
org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
at 
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
at 
org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: class org.apache.ignite.IgniteCheckedException: 
org.h2.table.TableView cannot be cast to 
org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2601)
at 
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
... 12 more
Caused by: java.lang.ClassCastException: org.h2.table.TableView cannot be cast 
to org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2336)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2268)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2250)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQueryModel(GridSqlQuerySplitter.java:1227)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:306)
at 
org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:224)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.split(IgniteH2Indexing.java:1936)
at 
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1898)
at

Re: Ignite as distributed file storage

2018-08-02 Thread Dmitriy Pavlov

Hi Dmitriy,

I appreciate members which are concentrated on code and selecting best
option.  But as community members we should drive community to grow
accoring 'Community first' principle. And then good project and codebase
will come by magic.

In the same time I suggest to concentrate on investment to comfortable
technical discussion first. For doing this I suggest to support every
member which want to contribute instead of "not accepting things". If first
proposal does not make sence, we, as community, can make this proposal
better together.

If entusiast, which is willing to contribute, requires advocate in the
Community, that indicates that something is going wrong.

I hope it make sence to you and to all of us.

Sincerely,
Dmitriy Pavlov

чт, 2 авг. 2018 г. в 6:12, Dmitriy Setrakyan :

> Dmitriy, Pavel,
>
> Everything that gets accepted into the project has to make sense. I agree
> with Vladimir - we do not need more than one file system in Ignite. Given
> the number of usage and questions we get about IGFS, I would question
> whether Ignite needs a file system at all.
>
> As community members we should drive the community towards improving the
> project instead of advocating that no change will be rejected, no matter
> what it is. In this case, I am not convinced this is a real problem for
> users and why should Ignite even try to solve it.
>
> Instead, if we must focus on large blobs, I would solve the problem of
> supporting large blobs in regular Ignite caches, as I suggested before.
>
> D.
>
> On Wed, Aug 1, 2018 at 2:50 AM, Dmitriy Pavlov 
> wrote:
>
> > Hi Vladimir,
> >
> > I think not accepting by community is possible only if PMC will veto
> > change. I didn't find any reasons why not to do this change and why it
> can
> > be vetoed..
> >
> > I would appreciate if you will become mentor of this change and will
> assist
> > to Pavel or other community member to make this happen.
> >
> > To my mind, the Apache Way is not abot rejecting things, it is about
> > sharing knowlege. If you will be able to share you experience to grow
> > community it would be good donation.
> >
> > If you have any disagreements about this change, can we set up voice call
> > where you will explain how to do this proposal as good as it is possible.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 6 июл. 2018 г. в 10:35, Vladimir Ozerov :
> >
> > > Pavel,
> > >
> > > I do not think it is a good idea to delay discussions and decisions.
> > > Because it puts your efforts at risk being not accepted by community in
> > the
> > > end. Our ultimate goal is not having as much features as possible, but
> to
> > > have a consistent product which is easy to understand and use. Having
> > both
> > > IGFS and another one "not-IGFS" which is in fact the same IGFS but with
> > > different name is not a good idea, because it would cause more harm
> than
> > > value.
> > >
> > > Approaches which seems reasonable to me:
> > > 1) Integrate your ideas into IGFS, which is really flexible in how to
> > > process data and where to store it. PROXY mode is not a "crutch" as you
> > > said, but a normal mode which was used in real deployments.
> > > 2) Replace IGFS with your solution but with clear explanation how it is
> > > better than IGFS and why we need to drop thousands lines of
> battle-tested
> > > code with something new, what does virtually the same thing
> > > 3) Just drop IGFS from the product, and do not implement any
> replacement
> > at
> > > all - personally, I am all for this decision.
> > >
> > > If you want I can guide you through IGFS architecture so that we better
> > > understand what should be done to integrate your ideas into it.
> > >
> > > Lat, but not least - we need objective facts why proposed solution is
> > > better in terms of performance - concrete use cases and performance
> > numbers
> > > (or at least estimations).
> > >
> > > On Fri, Jul 6, 2018 at 1:45 AM Pavel Kovalenko 
> > wrote:
> > >
> > > > Vladimir,
> > > >
> > > > I just want to add to my words, that we can implement BLOB storage
> and
> > > > then, if community really wants it, we can adapt this storage to use
> as
> > > > underlying file system in IGFS. But IGFS shouldn't be entry point for
> > > BLOB
> > > > storage. I think this conclusion can satisfy both of us.
> > > >
> > > > 2018-07-06 0:47 GMT+03:00 Pavel Kovalenko :
> > > >
> > > > > Vladimir,
> > > > >
> > > > > I didn't say that it stores data in on-heap, I said that it
> performs
> > a
> > > > lot
> > > > > of operations with byte[] arrays in on-heap as I see in , which
> will
> > > lead
> > > > > to frequent GCs and unnecessary data copying.
> > > > > "But the whole idea around mmap sounds like premature optimisation
> to
> > > me"
> > > > > - this is not premature optimisation, this is on of the key
> > performance
> > > > > features. E.g. Apache Kafka wouldn't be so fast and extremely
> > > performant
> > > > > without zero-copy.
> > > > > If we can do better, why not just do it?

Re: Removing "fabric" from Ignite binary package name

2018-08-02 Thread Anton Vinogradov

What I see is that we spent almost a year discussing how to do this.
I'm pretty sure we had enough time to do everything properly.

So, proposal is to stop this discussion and start refactoring.

I do not see any pitfalls and ready to assist if necessary.

чт, 2 авг. 2018 г. в 5:14, Dmitriy Setrakyan :

> I vote to remove the fabric from the build in the easiest way possible. Can
> other Igniters comment?
>
> D.
>
> On Wed, Aug 1, 2018 at 12:46 PM, Petr Ivanov  wrote:
>
> > My concern here is exactly about internal build processes — removing
> > fabric from the name of binary archive (with any way) will break lots of
> > them.
> > There will be no sacrifices, just lots of work for fixing build processes
> > (where we won’t be able to introduce changes proactively).
> >
> > Therefore only fabric removal implementation (quick with some legacy left
> > or full refactoring) is on the agenda.
> > And this matter should be jugged by the community: currently we have (if
> > our voices are equal) 1:1 with Anton about it.
> >
> >
> >
> >
> > > On 1 Aug 2018, at 22:28, Dmitriy Setrakyan 
> > wrote:
> > >
> > > Let's focus on what is important here. Our users do not care about our
> > > internal build process.If we could remove the word fabric from the next
> > > release without any significant sacrifices in the build process or
> making
> > > it less maintainable, I suggest we do it.
> > >
> > > D.
> > >
> > > On Wed, Aug 1, 2018 at 12:24 PM, Petr Ivanov 
> > wrote:
> > >
> > >> Simple way with some hack and legacy maintenance: accept patch as it
> is
> > >> implemented now.
> > >> Hard way: full assembly refactoring and hadoop rejection.
> > >>
> > >> Anyway, after this is merged to master — complete automation systems
> > >> revision (TeamCity for example) is required due to heavy hardcode of
> > >> “fabric” in such systems.
> > >>
> > >>
> > >>> On 1 Aug 2018, at 21:55, Dmitriy Setrakyan 
> > >> wrote:
> > >>>
> > >>> OK, so what is the plan? How do we get rid of the fabric name?
> > >>>
> > >>> D.
> > >>>
> > >>> On Wed, Aug 1, 2018 at 2:21 AM, Anton Vinogradov 
> > wrote:
> > >>>
> >  Since you proposing patch to the community, you are the very man :)
> > 
> >  ср, 1 авг. 2018 г. в 12:16, Petr Ivanov :
> > 
> > > You are convincing the wrong person.
> > >
> > >
> > >
> > >> On 1 Aug 2018, at 12:05, Anton Vinogradov  wrote:
> > >>
> > >> Peter,
> > >>
> > >> We had a discussion about how to do this properly.
> > >> Proposed solution cannot be merged, since it makes code harder
> than
> > it
> > > was.
> > >>
> > >> The only case is to perform complete refactoring and get rid of
> all
> > >> postfixes and other weird stuff.
> > >>
> > >> For example
> > >> - 
> > >> - 
> > >> should be definetely removed from code.
> > >>
> > >>
> > >> ср, 1 авг. 2018 г. в 9:39, Peter Ivanov :
> > >>
> > >>> The task was ready long ago, but community failed to review and
> > merge
> >  it
> > >>> ¯\_(ツ)_/¯
> > >>> Not being a committer, my capabilities of introducing such
> changes
> > >> are
> > >>> limited.
> > >>>
> > >>> I will update code during this week and will pass for review once
> >  again.
> > >>>
> > >>>
> > >>> On Wed, 1 Aug 2018 at 00:24, Dmitriy Setrakyan <
> > >> dsetrak...@apache.org
> > >
> > >>> wrote:
> > >>>
> >  Yes, agree, fabric has to be removed. If it is done in 2.7,
> would
> > be
> > >>> great!
> > 
> >  On Tue, Jul 31, 2018 at 2:18 PM, Denis Magda  >
> > > wrote:
> > 
> > > Peter, folks,
> > >
> > > It's weird, but we have been failing to introduce this minor
> > change
> > >>> since
> > > December. Can we get it done for 2.7 that is being discussed at
> > the
> >  moment?
> > > Are there any technical issues that block you from merging the
> > > changes?
> > >
> > > --
> > > Denis
> > >
> > > On Thu, Jun 7, 2018 at 10:03 PM Peter Ivanov <
> > mr.wei...@gmail.com>
> >  wrote:
> > >
> > >> Ok, then I will update issue code and start preparation for
> > build
> > >> configuration changes.
> > >>
> > >>
> > >> On Thu, 7 Jun 2018 at 23:41, Denis Magda 
> >  wrote:
> > >>
> > 
> >  With which one — current implementation in issue?
> > >>>
> > >>>
> > >>> That's the answer to your question:
> > >>>
> > >>> 1. quickly fix all of them (can be solved by preliminary
> >  preparations —
> > >>> searching for -fabric- usages in build configuration);
> > >>>  2. update all branches to master because otherwise old
> branch
> >  will
> > >> stop
> > >>> building.
> > >>>
> > >>>
> > >>> --
> > >>> Denis
> >

Re: Ignite as distributed file storage

2018-08-02 Thread Pavel Kovalenko

Dmitriy,

I still don't understand why do you think that it will be file system?
In all my previous messages I emphasized that this storage shouldn't be
considered as a file system. It's just a large data storage, whose entities
can be easily accessed using key/link (internally, or externally using
web/binary protocol interfaces).

> Instead, if we must focus on large blobs, I would solve the problem of
supporting large blobs in regular Ignite caches, as I suggested before.

This is impossible. Our page memory can't handle efficiently it by design.


2018-08-02 6:11 GMT+03:00 Dmitriy Setrakyan :

> Dmitriy, Pavel,
>
> Everything that gets accepted into the project has to make sense. I agree
> with Vladimir - we do not need more than one file system in Ignite. Given
> the number of usage and questions we get about IGFS, I would question
> whether Ignite needs a file system at all.
>
> As community members we should drive the community towards improving the
> project instead of advocating that no change will be rejected, no matter
> what it is. In this case, I am not convinced this is a real problem for
> users and why should Ignite even try to solve it.
>
> Instead, if we must focus on large blobs, I would solve the problem of
> supporting large blobs in regular Ignite caches, as I suggested before.
>
> D.
>
> On Wed, Aug 1, 2018 at 2:50 AM, Dmitriy Pavlov 
> wrote:
>
> > Hi Vladimir,
> >
> > I think not accepting by community is possible only if PMC will veto
> > change. I didn't find any reasons why not to do this change and why it
> can
> > be vetoed..
> >
> > I would appreciate if you will become mentor of this change and will
> assist
> > to Pavel or other community member to make this happen.
> >
> > To my mind, the Apache Way is not abot rejecting things, it is about
> > sharing knowlege. If you will be able to share you experience to grow
> > community it would be good donation.
> >
> > If you have any disagreements about this change, can we set up voice call
> > where you will explain how to do this proposal as good as it is possible.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 6 июл. 2018 г. в 10:35, Vladimir Ozerov :
> >
> > > Pavel,
> > >
> > > I do not think it is a good idea to delay discussions and decisions.
> > > Because it puts your efforts at risk being not accepted by community in
> > the
> > > end. Our ultimate goal is not having as much features as possible, but
> to
> > > have a consistent product which is easy to understand and use. Having
> > both
> > > IGFS and another one "not-IGFS" which is in fact the same IGFS but with
> > > different name is not a good idea, because it would cause more harm
> than
> > > value.
> > >
> > > Approaches which seems reasonable to me:
> > > 1) Integrate your ideas into IGFS, which is really flexible in how to
> > > process data and where to store it. PROXY mode is not a "crutch" as you
> > > said, but a normal mode which was used in real deployments.
> > > 2) Replace IGFS with your solution but with clear explanation how it is
> > > better than IGFS and why we need to drop thousands lines of
> battle-tested
> > > code with something new, what does virtually the same thing
> > > 3) Just drop IGFS from the product, and do not implement any
> replacement
> > at
> > > all - personally, I am all for this decision.
> > >
> > > If you want I can guide you through IGFS architecture so that we better
> > > understand what should be done to integrate your ideas into it.
> > >
> > > Lat, but not least - we need objective facts why proposed solution is
> > > better in terms of performance - concrete use cases and performance
> > numbers
> > > (or at least estimations).
> > >
> > > On Fri, Jul 6, 2018 at 1:45 AM Pavel Kovalenko 
> > wrote:
> > >
> > > > Vladimir,
> > > >
> > > > I just want to add to my words, that we can implement BLOB storage
> and
> > > > then, if community really wants it, we can adapt this storage to use
> as
> > > > underlying file system in IGFS. But IGFS shouldn't be entry point for
> > > BLOB
> > > > storage. I think this conclusion can satisfy both of us.
> > > >
> > > > 2018-07-06 0:47 GMT+03:00 Pavel Kovalenko :
> > > >
> > > > > Vladimir,
> > > > >
> > > > > I didn't say that it stores data in on-heap, I said that it
> performs
> > a
> > > > lot
> > > > > of operations with byte[] arrays in on-heap as I see in , which
> will
> > > lead
> > > > > to frequent GCs and unnecessary data copying.
> > > > > "But the whole idea around mmap sounds like premature optimisation
> to
> > > me"
> > > > > - this is not premature optimisation, this is on of the key
> > performance
> > > > > features. E.g. Apache Kafka wouldn't be so fast and extremely
> > > performant
> > > > > without zero-copy.
> > > > > If we can do better, why not just do it? Especially if it costs
> > nothing
> > > > > for us (This is OS level).
> > > > > As I said in my first message, our end target is handling video and
> > > > > streaming, copying every chunk of it

[GitHub] ignite pull request #4476: IGNITE-9161: Optimization for C++ (copy elision)

2018-08-02 Thread isapego

GitHub user isapego opened a pull request:

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

IGNITE-9161: Optimization for C++ (copy elision)



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

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

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

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


commit 29cbdee193750df2b13ac0e37acccf6d5ef82be8
Author: Igor Sapego 
Date:   2018-08-02T07:35:50Z

IGNITE-9161: Optimization for C++ (copy elision)




---

[jira] [Created] (IGNITE-9161) CPP:

2018-08-02 Thread Igor Sapego (JIRA)

Igor Sapego created IGNITE-9161:
---

 Summary: CPP: 
 Key: IGNITE-9161
 URL: https://issues.apache.org/jira/browse/IGNITE-9161
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Sapego






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

[GitHub] ignite pull request #4475: IGNITE-9138: ZookeeperDiscoverySpiTest#checkInter...

2018-08-02 Thread BiryukovVA

GitHub user BiryukovVA opened a pull request:

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

IGNITE-9138: ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails 
if zk cluster was stpped before nodes.



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

$ git pull https://github.com/BiryukovVA/ignite IGNITE-9138

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

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


commit 2a1a36b5775a3c5573e70cfdaa318824ecea36ef
Author: Vitaliy Biryukov 
Date:   2018-07-31T08:51:51Z

IGNITE-9138: ZookeeperDiscoverySpiTest#checkInternalStructuresCleanup fails 
if zk cluster was stpped before nodes.




---

[jira] [Created] (IGNITE-9160) NPE and CCE on equals() methods

2018-08-02 Thread Nikolai Kulagin (JIRA)

Nikolai Kulagin created IGNITE-9160:
---

 Summary: NPE and CCE on equals() methods
 Key: IGNITE-9160
 URL: https://issues.apache.org/jira/browse/IGNITE-9160
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.6
Reporter: Nikolai Kulagin
Assignee: Nikolai Kulagin
 Fix For: 2.7


Next classes have exceptions in equals() method:

*GridDhtPartitionFullMap -* NPE
*GridDhtPartitionMap* - NPE
*GridNearOptimisticTxPrepareFuture* - NPE and CCE
*GridCacheMvccCandidate* - CCE
*GridDhtPartitionExchangeId* - CCE
*GridTuple6* - CCE



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

39 matches

Mail list logo