Re: Class field ThreadLocal. Why not static?

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

Guys,

As we know ThreadLocal is an instrument which should be used with great
care. And I recently faced with problems related to proper cleanup of
ThreadLocal which is not needed anymore. In my opinion the best thing (in
ideal world) is to get rid of ThreadLocal where possible, but I guess that
it is quite hard (in real world).

Also, a question comes to my mind. As ThreadLocal is so common in our code,
could you suggest some guidance or code fragments which address proper
ThreadLocal
 lifecycle control and especially cleanup?

2018-09-10 12:46 GMT+03:00 Alexey Goncharuk :

> Maxim,
>
> Ignite supports starting multiple instances of Ignite in the same VM, so
> having static thread locals for the fields you mentioned does not work.
>
> Generally, I think thread-local should be bound to the lifespan of the
> component it describes. Static thread-locals are hard to clean-up and they
> often lead to leaks, so I would rather changed existing static
> thread-locals to be non-static.
>
> --AG
>
> пн, 10 сент. 2018 г. в 11:54, Maxim Muzafarov :
>
> > Igniters,
> >
> > According to javadoc [1] class ThreadLocal:
> > `ThreadLocal instances are typically private *static* fields in classes
> > that wish to associate state with a thread (e.g., a user ID or
> Transaction
> > ID).`
> >
> > So, AFAIK non-static ThreadLocal usage means as `per thread - per class
> > instance`. What the real cases of using non-static ThreadLocal class
> fields
> > in Ignite code project? When we need it?
> >
> > In Ignite code project I've found ThreadLocal usage as:
> >  - non-static - 67
> >  - static  - 68
> >
> > Back to my example, I've checked FileWriteAheadLogManager. It has:
> > 1) private final ThreadLocal interrupted [2]
> > 2) private final ThreadLocal lastWALPtr [3]
> > I think both of these fields should be set and used as `static`. Can
> anyone
> > confirm it?
> >
> >
> > [1] https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html
> > [2]
> >
> > https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/processors/
> cache/persistence/wal/FileWriteAheadLogManager.java#L253
> > [3]
> >
> > https://github.com/apache/ignite/blob/master/modules/
> core/src/main/java/org/apache/ignite/internal/processors/
> cache/persistence/wal/FileWriteAheadLogManager.java#L340
> > --
> > --
> > Maxim Muzafarov
> >
>



-- 
Best regards,
Ivan Pavlukhin

[jira] [Created] (IGNITE-9528) Web Console: PageConfigure service incorrectly process error

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-9528:


 Summary: Web Console: PageConfigure service incorrectly process 
error
 Key: IGNITE-9528
 URL: https://issues.apache.org/jira/browse/IGNITE-9528
 Project: Ignite
  Issue Type: Bug
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov


PageConfigure service incorrectly process LOAD_COMPLETE_CONFIGURATION_ERR 
action, it should extract error before process it.



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

Re: Apache Ignite 2.7 release

[Roman Shtykh]

Ilya,
The "latest" version is the default, and resolved by 
https://ignite.apache.org/latest which is used by our web site when a user 
download the latest Ignite version. And I think this is the authority to judge 
of the latest official release (pom.xml you suggest can have SNAPSHOTs 
etc.).Also, as I explained during our review sessions, ignite-mesos-2.6.0 is a 
driver and doesn't mean you need to have Ignite 2.6.0. User can run any version 
of Ignite he/she specifies. By default, it's "latest" but a user can specify 
any version needed, even from a non-archive URL.
In short, what we have now1. mesos driver (ignite-mesos-x.x.x) will use 
"latest" version by default -> it will try to resolve the latest officially 
releases version of Apache Ignite, find the closest mirror and download Ignite 
in a minute. If the version resolution fails, we fall back to the slow apache 
archive (as you suggest; in my opinion we better fail-fast instead of waiting 
for hours to download, so the user can choose another download option (3))2. If 
the user specifies the version explicitly, it goes to the slow apache archive.
3. The user can put ignite zip file on his/her http server and provide the URL 
as a parameter to the driver, if options 1 and 2 don't work.
As you see, there are 3 options. And I just fix the 1st one with 
https://issues.apache.org/jira/browse/IGNITE-9388 and don't change the original 
logic (which I find reasonable) documented on our site -- I don't see how it 
blocks anything.

Roman Shtykh 

On Monday, September 10, 2018, 6:16:15 p.m. GMT+9, Ilya Kasnacheev 
 wrote:  
 
 Hello!
There's still two issues with the submission.
The first one is that we're downloading "latest" version from preferred mirror 
but a specified version, such as "2.6", we're also going to download from 
"slow" archive.apache.org/dist.That's a great limitation for this change, since 
most real deployments of Apache Ignite will have their Ignite version pegged to 
a specific release. But in this case there's no win in download speed.In my 
opinion it is a blocker.

The second one is that we can't download anything when we failed to resolve 
"latest". My idea is that we should try and download last known version in this 
case, which can be pushed to source from pom.xml, as we already do with URLs. 
So if you could not resolve "latest" you will download 2.7.0.
Buuut, maybe it's not necessary, maybe we should just discourage "latest", 
which is in my opinion almost always a bad idea.
WDYT?

Regards,
-- 
Ilya Kasnacheev


вс, 9 сент. 2018 г. в 5:47, Roman Shtykh :

Hi Ilya,
Sorry, missed that.
Added now.

--
Roman Shtykh 

On Thursday, September 6, 2018, 6:16:58 p.m. GMT+9, Ilya Kasnacheev 
 wrote:  
 
 Hello!
The last of my requests still standing is that we should fall-back to single 
URL download in case of error with 'latest' version. Everything else looks good 
to me.
Can we do that? I'm really worried that Apache API will go sour.

Regards,
-- 
Ilya Kasnacheev


чт, 6 сент. 2018 г. в 8:56, Roman Shtykh :

Hi Ilya,
Thanks again.
1) Done.2) Used catch() for latest version.

Please see my comments on github.
--
Roman Shtykh 

On Wednesday, September 5, 2018, 11:30:10 p.m. GMT+9, Ilya Kasnacheev 
 wrote:  
 
 Hello!
I've left a new wave of replies.
Basically, 1) let's keep DOWNLOAD_URL_PATTERN string value inlined so that it 
will work even if build process is broken (would be useful for e.g. developing 
out of IDE)
And also I urge you to catch() around new fragile Apache JSON API resolving, 
and download the 'current' version instead, as defined by ignite-mesos version.
This is because this module is not under continuouos scrutiny so extra care 
should be applied.-- 
Ilya Kasnacheev


вт, 4 сент. 2018 г. в 13:42, Roman Shtykh :

Thanks, Ilya!I will check your comments, and discuss it at JIRA.

--
Roman Shtykh 

On Tuesday, September 4, 2018, 7:17:53 p.m. GMT+9, Ilya Kasnacheev 
 wrote:  
 
 Hello!
IGNITE-9408 looks good to me and may be merged right away.
IGNITE-9388 needs more work in my opinion, I have commented the PR. I also 
advice having test for this functionality.

Regards,
-- 
Ilya Kasnacheev


вт, 4 сент. 2018 г. в 6:52, Roman Shtykh :

Igniters,
I would like Mesos integration update be included in the upcoming release.Can 
anyone review prs for the following issues?
IGNITE-9388: mesos IgniteProvider tries to access obsolete ignite.run or 
download from slow archiveIGNITE-9408: Update mesos version

Roman Shtykh 

    On Thursday, August 30, 2018, 9:25:43 p.m. GMT+9, Vyacheslav Daradur 
 wrote:  

 Hi Igniters!

I'm working on the following Service Grid tasks:
- IGNITE-8361 Use discovery messages for service deployment
- IGNITE-8362 Collect service deployment results asynchronously on coordinator
- IGNITE-8363 Handle topology changes during service deployment
- IGNITE-8364 Propagate deployed services to joining nodes
- IGNITE-8365 Introduce service failure events
- IGNITE-3392 Propagate service deployment 

[jira] [Created] (IGNITE-9527) NPE in CacheLateAffinityAssignmentTest#testNoForceKeysRequests test

[Mikhail Cherkasov (JIRA)]

Mikhail Cherkasov created IGNITE-9527:
-

 Summary: NPE in 
CacheLateAffinityAssignmentTest#testNoForceKeysRequests test
 Key: IGNITE-9527
 URL: https://issues.apache.org/jira/browse/IGNITE-9527
 Project: Ignite
  Issue Type: Bug
Reporter: Mikhail Cherkasov
Assignee: Mikhail Cherkasov


The wrong assertion was removed by the following ticket: 
https://issues.apache.org/jira/browse/IGNITE-5510, however, NPE exception can 
be observed in logs, so if [~sboikov] said that this method can be called 
concurrently and it's valid to have null here, then I think we should remove 
NPE from logs.



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

Re: PHP thin client

[Alexey Kosenchuk]

Hi Igor,

thanks for the review.

Pls see below...

>> 1. Main page for documentation is empty.

What is the main page for documentation?

As wrote,
the auto-generated API spec is here:
https://rawgit.com/nobitlost/ignite/ignite-7783-docs/modules/platforms/php/api_docs/html/index.html

All other docs are here:
https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md
Going to be placed on readme.io by Prachi (thanks!)
https://issues.apache.org/jira/browse/IGNITE-9523

>> 2. More output for Auth example is needed. This is not a test, after 
all, but example.


Will add a log when a connection happens with the details of the 
connection. Nothing else to output in this trivial example.
In fact, the real profit for a user here is the source code with an 
example of TLS/auth cfg for the client.


>> 3. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1, 
they fail


Do you mean 10800 should be the default port when not specified by a user?
Will add.

>> 4. If I try run test with 
APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1:10800, they fail


Double checked exactly in the same environment you have. It works.

Please try again.
Do you use a server with all default settings? Did not you try with the 
server after the Auth example?

Do other examples work with the same server?
If you still see the problem with the tests, please send the server's 
log to us. And/or switch the client's debug on - call setDebug(true) - 
and share the client's output.


>> 5. When "maven package" command is executed on Ignite, no php 
directory appears


Need a help from experts / release engineer.

Thanks,
-Alexey

10.09.2018 15:34, Igor Sapego пишет:

By the way, I used Ubuntu 18.04, PHP 7.2.7 and what seems
to be PhpUnit 7.3 (not sure here).

Best Regards,
Igor


On Mon, Sep 10, 2018 at 3:28 PM Igor Sapego  wrote:


Guys, I've reviewed the API (which looks good), run tests and examples and
here are my commments:

1. Main page for documentation is empty.

2. More output for Auth example is needed. This is not a test, after all,
but example.

3. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1, they
fail with the following message:
Apache\Ignite\Exception\NoConnectionException: [127.0.0.1] Failed to parse
address "127.0.0.1" in
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php:107
Stack trace:
#0
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(54):
Apache\Ignite\Internal\Connection\ClientFailoverSocket->failoverConnect()
#1
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Client.php(61):
Apache\Ignite\Internal\Connection\ClientFailoverSocket->connect(Object(Apache\Ignite\ClientConfiguration))
#2
/home/isapego/work/ignite/modules/platforms/php/tests/TestingHelper.php(52):
Apache\Ignite\Client->connect(Object(Apache\Ignite\ClientConfiguration))
#3
/home/isapego/work/ignite/modules/platforms/php/tests/SqlQueryTest.php(49):
Apache\Ignite\Tests\TestingHelper::init()
#4
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(703):
Apache\Ignite\Tests\SqlQueryTestCase::setUpBeforeClass()
#5
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(750):
PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#6
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(587):
PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#7
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(203):
PHPUnit\TextUI\TestRunner->doRun(Object(PHPUnit\Framework\TestSuite),
Array, true)
#8
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(159):
PHPUnit\TextUI\Command->run(Array, true)
#9
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/phpunit(53):
PHPUnit\TextUI\Command::main()
#10 {main}

4. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1:10800,
they fail with the following message:
Apache\Ignite\Exception\OperationStatusUnknownException: Error while
reading data from the server in
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php:168
Stack trace:
#0
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(178):
Apache\Ignite\Internal\Connection\ClientSocket->receive(Object(Apache\Ignite\Internal\Binary\MessageBuffer),
4)
#1
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(159):
Apache\Ignite\Internal\Connection\ClientSocket->processResponse(Object(Apache\Ignite\Internal\Binary\Request))
#2
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(107):
Apache\Ignite\Internal\Connection\ClientSo

Re: affinityBackupFilter for AWS Availability Zones

[Dave Harvey]

Submitted a patch for this https://issues.apache.org/jira/browse/IGNITE-9365



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

Re: Workflow improvement

[Dmitrii Ryabov]

Hi, Dmitriy,

I made PRs in my fork for test purposes. Real PRs were made to the GitHub
mirror, and one of them is already merged by D. Govorukhin. PR with GitHub
statuses [1] is ready for review. PR with JIRA comment will be ready in a
few days.

[1] https://github.com/apache/ignite-teamcity-bot/pull/5

2018-09-10 23:00 GMT+03:00 Dmitriy Pavlov :

> Hi Dmitrii,
>
> I deployed change with blockers summary of failures at the top of PR result
> page. The Bot is migrating entries now, I hope it will be done in 1-4
> hours.
>
> I noticed your PRs are created in your own fork, not in
> https://github.com/apache/ignite-teamcity-bot
> Could you please create unmerged PR in GitHub mirror so it could be merged
> after reviewing by the apply-pr script.
>
> Sincerely,
> Dmitriy Pavlov
>
> пн, 3 сент. 2018 г. в 18:20, Dmitrii Ryabov :
>
> > Hi, Dmitriy,
> >
> > I created a table with possible blockers [1] for the page with the latest
> > build analysis. Anton K. has reviewed it. Can you check and merge it?
> >
> > Also, I created a button to notify PR about analisis results [2]. I used
> > GitHub statuses (example [3]), but to work it needs a token with push
> > permission. As Apache PMC, can you acquire such token? I think statuses
> are
> > much more notable than comments.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-9376
> > [2] https://issues.apache.org/jira/browse/IGNITE-9377
> > [3] https://github.com/SomeFire/ignite-teamcity-bot/pulls
> >
> > 2018-08-25 1:04 GMT+03:00 Dmitriy Pavlov :
> >
> > > Not sure I understood what bot statistic reduction means.
> > >
> > > As far as I understood, you also mean locating failure automatically
> with
> > > re-runs on specific git revisions (hashes). I found it will be a good
> > > contribution to TC Bot for both flaky and non-flaky failures detection.
> > E.g
> > > failure occurred after 10 commits merged to master. How to find out bad
> > > commit? Automatic location (analog of bisecting, but using TC test)
> will
> > be
> > > really helpful. But it is not a simple contribution.
> > >
> > > пт, 24 авг. 2018 г. в 18:35, Dmitrii Ryabov :
> > >
> > > > Hi, Dmitriy,
> > > >
> > > > Good, I'll create tickets for this steps.
> > > >
> > > > Stable suites are a good idea, but also we need to do some actions
> > when a
> > > > flaky test will appear in stable suite of master branch run. To find
> > out
> > > a
> > > > guilty commit, we should run previous commits on empty TeamCity's
> > queue.
> > > > This runs will reduce bot's statistics for the latest commits.
> > > >
> > > > 2018-08-24 16:32 GMT+03:00 Dmitriy Pavlov :
> > > >
> > > > > Hi Dmitriy,
> > > > >
> > > > > Sounds like a plan ;) I totally agree.
> > > > > Just one proposal: I would like to avoid hiding any test failures.
> 2
> > > > > separate tables named 'Possible Blockers' and 'Other failures'
> should
> > > be
> > > > > completely clear. Comment to PR can contain only first category.
> > > > >
> > > > > We had a private discussion with Anton K. and he proposed a very
> > > > > interesting thing, I would like to bring it here. We can add
> > > > configuration
> > > > > into TC bot and mark some tests and some suites as 'Known Stable'
> It
> > > > means
> > > > > that suite or test failure should be considered as a blocker for
> > merge
> > > > > every time it fails, even if fail rate is non-zero. Very first list
> > of
> > > > such
> > > > > suites are
> > > > >  - Build Apache Ignite
> > > > >  - License check
> > > > > And tests:
> > > > >  - .Net API Parity check
> > > > > Please share your vision.
> > > > >
> > > > > Meanwhile, I've updated the TC bot.
> > > > > - Underlying Apache Ignite DB was refactored to use lower
> partitions
> > > > count,
> > > > > so restart should be faster.
> > > > > - Now 100 builds are saved as our failure rate statistics basis.
> > > > Flakiness
> > > > > border was not changed, so more test now will be considered as
> flaky.
> > > > > - Now 4 builds required to be failed or timed out in a row before
> > > > > notification is sent.
> > > > >
> > > > > Sincerely,
> > > > > Dmitriy Pavlov
> > > > >
> > > > > чт, 23 авг. 2018 г. в 17:09, Dmitrii Ryabov  >:
> > > > >
> > > > > > Hi, Dmitriy,
> > > > > >
> > > > > > I propose the next steps:
> > > > > >
> > > > > > 1. Show current 0% tests in a separate table at the top of the
> > > analysis
> > > > > > results page. Thus, we'll see most suspicious (new or very flaky)
> > > tests
> > > > > > firstly. Or we can hide other tests under "More >>" button, like
> > top
> > > > long
> > > > > > running tests.
> > > > > > 2. Create a button by clicking on which the info about 0% tests
> > will
> > > be
> > > > > > written in the PR.
> > > > > > 3. Replace button by webhook for TeamCity (for Run All), which
> will
> > > > start
> > > > > > analysis on TCH and write results in the PR.
> > > > > > 4. ...
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > >
> > > > > > 2018-08-22 8:55 GMT+03:00 Dmitrii Ryabov  >:
> > > >

Re: IGNITE-7482 Cursor in TextQuery fetches all data in first call to next() or hasNext()

[Tâm Nguyễn Mạnh]

Hi,

I just registered. Here is my jira account: nguyenmanhtam...@gmail.com

Thank you,
Tamnm

On Mon, Sep 10, 2018 at 3:25 PM Alexey Goncharuk 
wrote:

> Hi,
>
> Please send your jira account ID so we can add you to the contributors
> list. Then you will be able to assign tickets to yourself and contribute to
> the project according to the process.
>
> You can get more info here:
>
> https://cwiki.apache.org/confluence/display/IGNITE/Development+Process
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> --AG
>
> пн, 10 сент. 2018 г. в 9:16, Tâm Nguyễn Mạnh :
>
> > Hi,
> > I have not been assigned yet. But i really want to.
> >
> > On Fri, Sep 7, 2018 at 4:13 PM Ilya Kasnacheev <
> ilya.kasnach...@gmail.com>
> > wrote:
> >
> > > Hello!
> > >
> > > Can you please frame it as Github pull request as per our process? Do
> you
> > > have ticket for that?
> > >
> > > Regards,
> > > --
> > > Ilya Kasnacheev
> > >
> > >
> > > пт, 7 сент. 2018 г. в 5:08, Tâm Nguyễn Mạnh <
> nguyenmanhtam...@gmail.com
> > >:
> > >
> > > >
> > > >
> > >
> >
> modules\indexing\src\main\java\org\apache\ignite\internal\processors\query\h2\opt\GridLuceneIndex.java
> > > > ```java
> > > > /*
> > > >  * Licensed to the Apache Software Foundation (ASF) under one or more
> > > >  * contributor license agreements.  See the NOTICE file distributed
> > with
> > > >  * this work for additional information regarding copyright
> ownership.
> > > >  * The ASF licenses this file to You under the Apache License,
> Version
> > > 2.0
> > > >  * (the "License"); you may not use this file except in compliance
> with
> > > >  * the License.  You may obtain a copy of the License at
> > > >  *
> > > >  *  http://www.apache.org/licenses/LICENSE-2.0
> > > >  *
> > > >  * Unless required by applicable law or agreed to in writing,
> software
> > > >  * distributed under the License is distributed on an "AS IS" BASIS,
> > > >  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > > implied.
> > > >  * See the License for the specific language governing permissions
> and
> > > >  * limitations under the License.
> > > >  */
> > > >
> > > > package org.apache.ignite.internal.processors.query.h2.opt;
> > > >
> > > > import java.io.IOException;
> > > > import java.util.Collection;
> > > > import java.util.concurrent.atomic.AtomicLong;
> > > > import org.apache.ignite.IgniteCheckedException;
> > > > import org.apache.ignite.internal.GridKernalContext;
> > > > import org.apache.ignite.internal.processors.cache.CacheObject;
> > > > import
> org.apache.ignite.internal.processors.cache.CacheObjectContext;
> > > > import
> > > > org.apache.ignite.internal.processors.cache.version.GridCacheVersion;
> > > > import
> > > > org.apache.ignite.internal.processors.query.GridQueryIndexDescriptor;
> > > > import
> > > org.apache.ignite.internal.processors.query.GridQueryTypeDescriptor;
> > > > import org.apache.ignite.internal.util.GridAtomicLong;
> > > > import org.apache.ignite.internal.util.GridCloseableIteratorAdapter;
> > > > import org.apache.ignite.internal.util.lang.GridCloseableIterator;
> > > > import
> org.apache.ignite.internal.util.offheap.unsafe.GridUnsafeMemory;
> > > > import org.apache.ignite.internal.util.typedef.internal.U;
> > > > import org.apache.ignite.lang.IgniteBiTuple;
> > > > import org.apache.ignite.spi.indexing.IndexingQueryFilter;
> > > > import org.apache.ignite.spi.indexing.IndexingQueryCacheFilter;
> > > > import org.apache.lucene.analysis.standard.StandardAnalyzer;
> > > > import org.apache.lucene.document.Document;
> > > > import org.apache.lucene.document.Field;
> > > > import org.apache.lucene.document.LongField;
> > > > import org.apache.lucene.document.StoredField;
> > > > import org.apache.lucene.document.StringField;
> > > > import org.apache.lucene.document.TextField;
> > > > import org.apache.lucene.index.DirectoryReader;
> > > > import org.apache.lucene.index.IndexReader;
> > > > import org.apache.lucene.index.IndexWriter;
> > > > import org.apache.lucene.index.IndexWriterConfig;
> > > > import org.apache.lucene.index.Term;
> > > > import org.apache.lucene.queryparser.classic.MultiFieldQueryParser;
> > > > import org.apache.lucene.search.BooleanClause;
> > > > import org.apache.lucene.search.BooleanQuery;
> > > > import org.apache.lucene.search.IndexSearcher;
> > > > import org.apache.lucene.search.NumericRangeQuery;
> > > > import org.apache.lucene.search.Query;
> > > > import org.apache.lucene.search.ScoreDoc;
> > > > import org.apache.lucene.search.TopDocs;
> > > > import org.apache.lucene.util.BytesRef;
> > > > import org.h2.util.JdbcUtils;
> > > > import org.jetbrains.annotations.Nullable;
> > > >
> > > > import static
> > > >
> org.apache.ignite.internal.processors.query.QueryUtils.KEY_FIELD_NAME;
> > > > import static
> > > >
> org.apache.ignite.internal.processors.query.QueryUtils.VAL_FIELD_NAME;
> > > >
> > > > /**
> > > >  * Lucene fulltext index.
> > > >  */
> > > > public class Grid

Re: Workflow improvement

[Dmitriy Pavlov]

Hi Dmitrii,

I deployed change with blockers summary of failures at the top of PR result
page. The Bot is migrating entries now, I hope it will be done in 1-4 hours.

I noticed your PRs are created in your own fork, not in
https://github.com/apache/ignite-teamcity-bot
Could you please create unmerged PR in GitHub mirror so it could be merged
after reviewing by the apply-pr script.

Sincerely,
Dmitriy Pavlov

пн, 3 сент. 2018 г. в 18:20, Dmitrii Ryabov :

> Hi, Dmitriy,
>
> I created a table with possible blockers [1] for the page with the latest
> build analysis. Anton K. has reviewed it. Can you check and merge it?
>
> Also, I created a button to notify PR about analisis results [2]. I used
> GitHub statuses (example [3]), but to work it needs a token with push
> permission. As Apache PMC, can you acquire such token? I think statuses are
> much more notable than comments.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-9376
> [2] https://issues.apache.org/jira/browse/IGNITE-9377
> [3] https://github.com/SomeFire/ignite-teamcity-bot/pulls
>
> 2018-08-25 1:04 GMT+03:00 Dmitriy Pavlov :
>
> > Not sure I understood what bot statistic reduction means.
> >
> > As far as I understood, you also mean locating failure automatically with
> > re-runs on specific git revisions (hashes). I found it will be a good
> > contribution to TC Bot for both flaky and non-flaky failures detection.
> E.g
> > failure occurred after 10 commits merged to master. How to find out bad
> > commit? Automatic location (analog of bisecting, but using TC test) will
> be
> > really helpful. But it is not a simple contribution.
> >
> > пт, 24 авг. 2018 г. в 18:35, Dmitrii Ryabov :
> >
> > > Hi, Dmitriy,
> > >
> > > Good, I'll create tickets for this steps.
> > >
> > > Stable suites are a good idea, but also we need to do some actions
> when a
> > > flaky test will appear in stable suite of master branch run. To find
> out
> > a
> > > guilty commit, we should run previous commits on empty TeamCity's
> queue.
> > > This runs will reduce bot's statistics for the latest commits.
> > >
> > > 2018-08-24 16:32 GMT+03:00 Dmitriy Pavlov :
> > >
> > > > Hi Dmitriy,
> > > >
> > > > Sounds like a plan ;) I totally agree.
> > > > Just one proposal: I would like to avoid hiding any test failures. 2
> > > > separate tables named 'Possible Blockers' and 'Other failures' should
> > be
> > > > completely clear. Comment to PR can contain only first category.
> > > >
> > > > We had a private discussion with Anton K. and he proposed a very
> > > > interesting thing, I would like to bring it here. We can add
> > > configuration
> > > > into TC bot and mark some tests and some suites as 'Known Stable' It
> > > means
> > > > that suite or test failure should be considered as a blocker for
> merge
> > > > every time it fails, even if fail rate is non-zero. Very first list
> of
> > > such
> > > > suites are
> > > >  - Build Apache Ignite
> > > >  - License check
> > > > And tests:
> > > >  - .Net API Parity check
> > > > Please share your vision.
> > > >
> > > > Meanwhile, I've updated the TC bot.
> > > > - Underlying Apache Ignite DB was refactored to use lower partitions
> > > count,
> > > > so restart should be faster.
> > > > - Now 100 builds are saved as our failure rate statistics basis.
> > > Flakiness
> > > > border was not changed, so more test now will be considered as flaky.
> > > > - Now 4 builds required to be failed or timed out in a row before
> > > > notification is sent.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > чт, 23 авг. 2018 г. в 17:09, Dmitrii Ryabov :
> > > >
> > > > > Hi, Dmitriy,
> > > > >
> > > > > I propose the next steps:
> > > > >
> > > > > 1. Show current 0% tests in a separate table at the top of the
> > analysis
> > > > > results page. Thus, we'll see most suspicious (new or very flaky)
> > tests
> > > > > firstly. Or we can hide other tests under "More >>" button, like
> top
> > > long
> > > > > running tests.
> > > > > 2. Create a button by clicking on which the info about 0% tests
> will
> > be
> > > > > written in the PR.
> > > > > 3. Replace button by webhook for TeamCity (for Run All), which will
> > > start
> > > > > analysis on TCH and write results in the PR.
> > > > > 4. ...
> > > > >
> > > > > What do you think?
> > > > >
> > > > >
> > > > > 2018-08-22 8:55 GMT+03:00 Dmitrii Ryabov :
> > > > >
> > > > > > I think we should check not N last runs, but all runs in last N
> > days.
> > > > > >
> > > > > > A simple rule to detect flaky fails by hands - get test history
> > > ordered
> > > > > > by TEST_STATUS_DESC and check its date. As I see, we can get list
> > of
> > > > > > failures from TC. We don't need to check successfull runs,
> because
> > > they
> > > > > are
> > > > > > uninformative for our needs.
> > > > > >
> > > > > > 2018-08-21 20:24 GMT+03:00 Dmitriy Pavlov  >:
> > > > > >
> > > > > >> Hi Dmitriy,
> > > > > >>
> > > > > >> The Bot is able to detect a frequent change of test status, bu

Re: Support TextQuery for ThinClient

[Tâm Nguyễn Mạnh]

Hi,
Yes, im going to add into .Net Thin Client.
I Already looked into implementation of other Thin Client’s methods. Its
quite easy to implement TextQuery for .Net Thi Client.
Actually I did it on my personal branch and I would love to push it into
Ignite git.




Vào Th 3, 11 thg 9, 2018 lúc 2:47 SA Pavel Tupitsyn 
đã viết:

> Hi,
>
> Text query should be easy to implement in thin client protocol, all the
> plumbing is there for cursors and so on.
> We just need a new operation similar to existing ones.
>
> Are you going to add it to .NET Thin Client?
>
> Pavel
>
> On Mon, Sep 10, 2018 at 8:22 PM Dmitriy Pavlov 
> wrote:
>
> > Hi, sure, feel free to open a ticket.  About implementation, I personally
> > do not mind, but I can't represent an opinion of all community members.
> >
> > I hope TextQuery/Thin Client developers and maintainers will step in and
> > share their vision.
> >
> > пн, 10 сент. 2018 г. в 16:31, Tâm Nguyễn Mạnh <
> nguyenmanhtam...@gmail.com
> > >:
> >
> > > Hi,
> > > I would like to implement this feature. Can we open a ticket for that ?
> > >
> > > Vào Th 2, 10 thg 9, 2018 lúc 8:27 CH Dmitriy Pavlov <
> > dpavlov@gmail.com
> > > >
> > > đã viết:
> > >
> > > > Hi,
> > > >
> > > > I've didn't heard about such plans. TextQuery is not widely used, as
> > far
> > > as
> > > > I know.
> > > >
> > > > Hope this helps.
> > > >
> > > > Sincerely,
> > > > Dmitriy Pavlov
> > > >
> > > > пт, 7 сент. 2018 г. в 4:57, Tâm Nguyễn Mạnh <
> > nguyenmanhtam...@gmail.com
> > > >:
> > > >
> > > > > Hi,
> > > > >
> > > > > Is there any plan about support TextQuery for ThinClient ?
> > > > >
> > > > > --
> > > > > Thanks & Best Regards
> > > > >
> > > > > Tam, Nguyen Manh
> > > > >
> > > >
> > > --
> > > Thanks & Best Regards
> > >
> > > Tam, Nguyen Manh
> > >
> >
>
-- 
Thanks & Best Regards

Tam, Nguyen Manh

Re: Support TextQuery for ThinClient

[Pavel Tupitsyn]

Hi,

Text query should be easy to implement in thin client protocol, all the
plumbing is there for cursors and so on.
We just need a new operation similar to existing ones.

Are you going to add it to .NET Thin Client?

Pavel

On Mon, Sep 10, 2018 at 8:22 PM Dmitriy Pavlov 
wrote:

> Hi, sure, feel free to open a ticket.  About implementation, I personally
> do not mind, but I can't represent an opinion of all community members.
>
> I hope TextQuery/Thin Client developers and maintainers will step in and
> share their vision.
>
> пн, 10 сент. 2018 г. в 16:31, Tâm Nguyễn Mạnh  >:
>
> > Hi,
> > I would like to implement this feature. Can we open a ticket for that ?
> >
> > Vào Th 2, 10 thg 9, 2018 lúc 8:27 CH Dmitriy Pavlov <
> dpavlov@gmail.com
> > >
> > đã viết:
> >
> > > Hi,
> > >
> > > I've didn't heard about such plans. TextQuery is not widely used, as
> far
> > as
> > > I know.
> > >
> > > Hope this helps.
> > >
> > > Sincerely,
> > > Dmitriy Pavlov
> > >
> > > пт, 7 сент. 2018 г. в 4:57, Tâm Nguyễn Mạnh <
> nguyenmanhtam...@gmail.com
> > >:
> > >
> > > > Hi,
> > > >
> > > > Is there any plan about support TextQuery for ThinClient ?
> > > >
> > > > --
> > > > Thanks & Best Regards
> > > >
> > > > Tam, Nguyen Manh
> > > >
> > >
> > --
> > Thanks & Best Regards
> >
> > Tam, Nguyen Manh
> >
>

[jira] [Created] (IGNITE-9526) Allow explicitly setting index inline size for Java objects

[Stanislav Lukyanov (JIRA)]

Stanislav Lukyanov created IGNITE-9526:
--

 Summary: Allow explicitly setting index inline size for Java 
objects
 Key: IGNITE-9526
 URL: https://issues.apache.org/jira/browse/IGNITE-9526
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Stanislav Lukyanov
Assignee: Stanislav Lukyanov


Currently Ignite never inlines indexed objects when they are POJOs. It makes 
sense, as there is currently no way of inlining a POJO other than by inlining 
the binary object, and the headers of the binary objects (i.e. their first 24 
bytes) are usually the same for the same indexed field.

However, this approach has downsides.
Silently ignoring the specified inline size might be surprising for a user 
willing to trade (a lot of) memory for speed and setting a large inline size 
for that purpose.
On the other hand, inlining headers and just several first bytes of POJOs in 
binary format has proven to be beneficial. It is especially beneficial in case 
page replacements are happening, as this greatly reduces the number of data 
pages required to traverse an index tree.

The proposal is to allow POJO inlining in case the inline size is given for the 
specific POJO field. So, unlike strings and byte arrays, POJOs will not use the 
max inline size by default - as in most cases inlining POJOs isn't going to 
help.



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

Re: Critical worker threads liveness checking drawbacks

[David Harvey]

When I've done this before,I've needed to find the oldest  thread, and kill
the node running that.   From a language standpoint, Maxim's "without
progress" better than "heartbeat".   For example, what I'm most interested
in on a distributed system is which thread started the work it has not
completed the earliest, and when did that thread last make forward
process. You don't want to kill a node because a thread is waiting on a
lock held by a thread that went off-node and has not gotten a response.
If you don't understand the dependency relationships, you will make
incorrect recovery decisions.

On Mon, Sep 10, 2018 at 4:08 AM Maxim Muzafarov  wrote:

> I think we should find exact answers to these questions:
>  1. What `critical` issue exactly is?
>  2. How can we find critical issues?
>  3. How can we handle critical issues?
>
> First,
>  - Ignore uninterruptable actions (e.g. worker\service shutdown)
>  - Long I/O operations (should be a configurable timeout for each type of
> usage)
>  - Infinite loops
>  - Stalled\deadlocked threads (and\or too many parked threads, exclude I/O)
>
> Second,
>  - The working queue is without progress (e.g. disco, exchange queues)
>  - Work hasn't been completed since the last heartbeat (checking
> milestones)
>  - Too many system resources used by a thread for the long period of time
> (allocated memory, CPU)
>  - Timing fields associated with each thread status exceeded a maximum time
> limit.
>
> Third (not too many options here),
>  - `log everything` should be the default behaviour in all these cases,
> since it may be difficult to find the cause after the restart.
>  - Wait some interval of time and kill the hanging node (cluster should be
> configured stable enough)
>
> Questions,
>  - Not sure, but can workers miss their heartbeat deadlines if CPU loads up
> to 80%-90%? Bursts of momentary overloads can be
> expected behaviour as a normal part of system operations.
>  - Why do we decide that critical thread should monitor each other? For
> instance, if all the tasks were blocked and unable to run,
> node reset would never occur. As for me, a better solution is to use a
> separate monitor thread or pool (maybe both with software
> and hardware checks) that not only checks heartbeats but monitors the
> other system as well.
>
> On Mon, 10 Sep 2018 at 00:07 David Harvey  wrote:
>
> > It would be safer to restart the entire cluster than to remove the last
> > node for a cache that should be redundant.
> >
> > On Sun, Sep 9, 2018, 4:00 PM Andrey Gura  wrote:
> >
> > > Hi,
> > >
> > > I agree with Yakov that we can provide some option that manage worker
> > > liveness checker behavior in case of observing that some worker is
> > > blocked too long.
> > > At least it will  some workaround for cases when node fails is too
> > > annoying.
> > >
> > > Backups count threshold sounds good but I don't understand how it will
> > > help in case of cluster hanging.
> > >
> > > The simplest solution here is alert in cases of blocking of some
> > > critical worker (we can improve WorkersRegistry for this purpose and
> > > expose list of blocked workers) and optionally call system configured
> > > failure processor. BTW, failure processor can be extended in order to
> > > perform any checks (e.g. backup count) and decide whether it should
> > > stop node or not.
> > > On Sat, Sep 8, 2018 at 3:42 PM Andrey Kuznetsov 
> > wrote:
> > > >
> > > > David, Yakov, I understand your fears. But liveness checks deal with
> > > > _critical_ conditions, i.e. when such a condition is met we conclude
> > the
> > > > node as totally broken, and there is no sense to keep it alive
> > regardless
> > > > the data it contains. If we want to give it a chance, then the
> > condition
> > > > (long fsync etc.) should not considered as critical at all.
> > > >
> > > > сб, 8 сент. 2018 г. в 15:18, Yakov Zhdanov :
> > > >
> > > > > Agree with David. We need to have an opporunity set backups count
> > > threshold
> > > > > (at runtime also!) that will not allow any automatic stop if there
> > > will be
> > > > > a data loss. Andrey, what do you think?
> > > > >
> > > > > --Yakov
> > > > >
> > > >
> > > >
> > > > --
> > > > Best regards,
> > > >   Andrey Kuznetsov.
> > >
> >
> --
> --
> Maxim Muzafarov
>

[jira] [Created] (IGNITE-9525) Ignite + Informatica Integration

[Prachi Garg (JIRA)]

Prachi Garg created IGNITE-9525:
---

 Summary: Ignite + Informatica Integration
 Key: IGNITE-9525
 URL: https://issues.apache.org/jira/browse/IGNITE-9525
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Prachi Garg
Assignee: Prachi Garg
 Fix For: 2.7


Mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Required+Docs



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

[jira] [Created] (IGNITE-9524) Ignite Spring Session Integration

[Prachi Garg (JIRA)]

Prachi Garg created IGNITE-9524:
---

 Summary: Ignite Spring Session Integration
 Key: IGNITE-9524
 URL: https://issues.apache.org/jira/browse/IGNITE-9524
 Project: Ignite
  Issue Type: Task
  Components: documentation
Reporter: Prachi Garg
Assignee: Prachi Garg
 Fix For: 2.7


Mentioned in https://cwiki.apache.org/confluence/display/IGNITE/Required+Docs

 

[https://github.com/antkr/spring-session-ignite] and 
[https://github.com/antkr/spring-session-ignite-rest] - to be merged to Ignite

 

[https://apacheignite-mix.readme.io/docs] under "Spring" section with a 
reference from "web session clustering" section. Ignite web site needs to be 
updated as well - 
[https://ignite.apache.org/use-cases/caching/web-session-clustering.html]



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

[jira] [Created] (IGNITE-9523) Document PHP thin client

[Prachi Garg (JIRA)]

Prachi Garg created IGNITE-9523:
---

 Summary: Document PHP thin client
 Key: IGNITE-9523
 URL: https://issues.apache.org/jira/browse/IGNITE-9523
 Project: Ignite
  Issue Type: Task
Reporter: Prachi Garg
Assignee: Prachi Garg
 Fix For: 2.7


Jira with the scope of work - [1].

Implementation, examples, tests:
  PR - [2],
  repository - [3].

API spec - [4].

Readme (how to for the client, instructions for the examples and tests, etc.) - 
[5].


[1] https://issues.apache.org/jira/browse/IGNITE-7783
[2] [https://github.com/apache/ignite/pull/4649]
[3] [https://github.com/nobitlost/ignite/tree/ignite-7783/modules/platforms/php]
[4] 
[https://rawgit.com/nobitlost/ignite/ignite-7783-docs/modules/platforms/php/api_docs/html/index.html]
[5] 
[https://github.com/nobitlost/ignite/blob/ignite-7783-docs/modules/platforms/php/README.md]
 



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

[jira] [Created] (IGNITE-9522) Document Python thin client

[Prachi Garg (JIRA)]

Prachi Garg created IGNITE-9522:
---

 Summary: Document Python thin client
 Key: IGNITE-9522
 URL: https://issues.apache.org/jira/browse/IGNITE-9522
 Project: Ignite
  Issue Type: Task
Reporter: Prachi Garg
Assignee: Prachi Garg
 Fix For: 2.7


Bring documentation from here - 
[https://apache-ignite-binary-protocol-client.readthedocs.io/en/latest/readme.html]
 into readme.io



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

[jira] [Created] (IGNITE-9521) Ignite TC bot: remove duplicates in PR analysis branch selection

[Dmitriy Pavlov (JIRA)]

Dmitriy Pavlov created IGNITE-9521:
--

 Summary: Ignite TC bot: remove duplicates in PR analysis branch 
selection
 Key: IGNITE-9521
 URL: https://issues.apache.org/jira/browse/IGNITE-9521
 Project: Ignite
  Issue Type: Bug
Reporter: Dmitriy Pavlov
Assignee: Dmitriy Pavlov


A number of branches are shown in PR analysis section in the Bot

Check branch/PR: 
Server: 
apache
Chain: 
IgniteTests24Java8_RunAll
 



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

Re: Support TextQuery for ThinClient

[Dmitriy Pavlov]

Hi, sure, feel free to open a ticket.  About implementation, I personally
do not mind, but I can't represent an opinion of all community members.

I hope TextQuery/Thin Client developers and maintainers will step in and
share their vision.

пн, 10 сент. 2018 г. в 16:31, Tâm Nguyễn Mạnh :

> Hi,
> I would like to implement this feature. Can we open a ticket for that ?
>
> Vào Th 2, 10 thg 9, 2018 lúc 8:27 CH Dmitriy Pavlov  >
> đã viết:
>
> > Hi,
> >
> > I've didn't heard about such plans. TextQuery is not widely used, as far
> as
> > I know.
> >
> > Hope this helps.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> > пт, 7 сент. 2018 г. в 4:57, Tâm Nguyễn Mạnh  >:
> >
> > > Hi,
> > >
> > > Is there any plan about support TextQuery for ThinClient ?
> > >
> > > --
> > > Thanks & Best Regards
> > >
> > > Tam, Nguyen Manh
> > >
> >
> --
> Thanks & Best Regards
>
> Tam, Nguyen Manh
>

Re: Apache Ignite Hackathon: Open Source contribution is simple

[Dmitriy Pavlov]

Denis, Konstantin, Thank you for your feedback.

After a private discussion with Ksenia, we've created a new idea of how to
name the event: 'Apache Ignite Day, Workshop: Open Source contribution is
simple'.
It can be slightly better because we don't want competition between
members, just fun and a few practical steps in the world of open source and
Apache.

I will start some additional communication in Russian.

I would strongly appreciate any additional ideas and replies from
committers, which potentially can participate locally or remotely.

With best regards,
Dmitriy Pavlov

сб, 25 авг. 2018 г. в 11:59, Denis Magda :

> Some of us have been doing meetups and workshops in San Francisco Bay Area
> for a while but have never tried the hackathon format. Worth trying, thanks
> for putting out the idea, Dmitriy!
>
> Let's start with Russia first and then I can assist with the hackathon
> arrangement here in the Silicon Valley.
>
> --
> Denis
>
> On Fri, Aug 24, 2018 at 3:22 PM Dmitriy Pavlov 
> wrote:
>
>> Hi Ignite Users, Developers, and Enthusiasts,
>>
>> It's natural to assume that a newcomer has little to offer the Apache
>> Ignite. However, you can be surprised at how much each newcomer can help,
>> even now.
>>
>> I would propose to run a hackathon on the next Apache Ignite meetup. In
>> parallel with talks, an attendee can pick up a simple ticket and run full
>> patch submission process during meetup and make open source contribution.
>> Ignite experts will be there and will be able to help everyone interested.
>>
>> The first place to run - Ignite meetup in Saint Petersburg, Russia,
>> because I know that several committers live there.
>>
>> - If you're a user or a contributor, would you like to join such
>> activity?
>> - If you're a committer, will you be able to come and help with review
>> and merge?
>> - Would you propose a simple ticket(s) which can be done in one hour or
>> even several minutes?
>>
>> Any feedback is very welcome.
>>
>> Sincerely,
>> Dmitriy Pavlov
>>
>

Re: Python thin client

[Igor Sapego]

Guys, I've cloned your repository, run pip3 install -e .
then run pip3 install -r requirements/* over all the requirements,
and finally run python ./setup.py pytest, but get the following output:

running pytest
Searching for attrs==18.1.0
Best match: attrs 18.1.0

Using /home/isapego/.local/lib/python3.6/site-packages
running egg_info
writing pyignite.egg-info/PKG-INFO
writing dependency_links to pyignite.egg-info/dependency_links.txt
writing requirements to pyignite.egg-info/requires.txt
writing top-level names to pyignite.egg-info/top_level.txt
reading manifest file 'pyignite.egg-info/SOURCES.txt'
writing manifest file 'pyignite.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
  File "./setup.py", line 98, in 
'Operating System :: OS Independent',
  File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/__init__.py",
line 140, in setup
return distutils.core.setup(**attrs)
  File "/usr/lib/python3.6/distutils/core.py", line 148, in setup
dist.run_commands()
  File "/usr/lib/python3.6/distutils/dist.py", line 955, in run_commands
self.run_command(cmd)
  File "/usr/lib/python3.6/distutils/dist.py", line 974, in run_command
cmd_obj.run()
  File "/home/isapego/.local/lib/python3.6/site-packages/ptr.py", line 175,
in run
with self.project_on_sys_path():
  File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
return next(self.gen)
  File
"/home/isapego/.local/lib/python3.6/site-packages/setuptools/command/test.py",
line 166, in project_on_sys_path
require('%s==%s' % (ei_cmd.egg_name, ei_cmd.egg_version))
  File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 895, in require
needed = self.resolve(parse_requirements(requirements))
  File
"/home/isapego/.local/lib/python3.6/site-packages/pkg_resources/__init__.py",
line 786, in resolve
raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (attrs 18.2.0
(/home/isapego/.local/lib/python3.6/site-packages),
Requirement.parse('attrs==18.1.0'), {'pyignite'})

What am I doing wrong?

Best Regards,
Igor


On Wed, Sep 5, 2018 at 3:19 AM Dmitriy Setrakyan 
wrote:

> Got it, sounds good!
>
> On Tue, Sep 4, 2018 at 10:54 AM, Dmitry Melnichuk <
> dmitry.melnic...@nobitlost.com> wrote:
>
> > Dmitriy,
> >
> > It would be quite messy to implement with Python modular system.
> >
> > First of all, Python 2 and Python 3 are different languages with a small
> > common subset of syntax rules. That's why what we see in a stack trace
> is a
> > syntax error, and not a “missing feature” error.
> >
> > Second, there is no single entry point in Python code. User is allowed to
> > import any name, from any module, in any order. In fact the module is run
> > when it first discovered by CPython during any `import` operation, and
> that
> > is how the imported entities are created and initialized: by the chain of
> > imports.
> >
> > It means for us, that implementing even a simple compatibility message in
> > Python 2 requires any module in our program (or at least all the modules,
> > that represent the public API of our library) to consist entirely of a
> > valid Python 2 code.
> >
> > It can be achieved by writing stubs with a version check, putting said
> > stubs in place of real modules, and proxying all the calls through the
> > conditional imports. It would take a small effort once, but make code
> less
> > readable and harder to maintain for the rest of its life cycle. Should
> we,
> > for example, provide two testing environments − for the main program and
> > for Python 2-compatible stubs?
> >
> > As far as I know, no Python developer is making such efforts nowadays.
> > There are some projects with a long history, that achieve
> 2/3-compatibility
> > through the use of restricted syntax and external packages like `six`, or
> > simply support two separate versions. Most of the new projects are
> creating
> > with the latest Python 3, pip and virtualenv in mind.
> >
> > I took the idea of my `setup.py` solution from the Django project, which
> > is dropped Python 2 support not long ago. Its setup relies on
> `setuptools`
> > 9+ option, or otherwise displays a simple banner; the banner is likely to
> > be buried under the further cryptic output of old setuptools, but it is
> > better than nothing.
> >
> >
> > On 9/5/18 2:21 AM, Dmitriy Setrakyan wrote:
> >
> >> Dmitriy,
> >>
> >> setuptools sounds like an installation step. Does it make sense to add a
> >> check during startup of a client?
> >>
> >> D.
> >>
> >> On Tue, Sep 4, 2018 at 7:25 AM, Dmitry Melnichuk <
> >> dmitry.melnic...@nobitlost.com> wrote:
> >>
> >> Nikolay,
> >>>
> >>> There is indeed a feature in `setuptools` I just learned about, which
> >>> would help in this case (and I believe the case you demonstrated can be
> >>> quite typical, thank you for pointing it out). It gives user a clever
> >>> message in the end of a stack trace like
> >>>
> >>> Unsu

Re: Bots on dev list

[Dmitriy Pavlov]

Hi Vladimir,

In general, I agree with these ideas, but it will be a lot of work to be
done to make personal notification even possible. We need to match each TC
and GitHub, GitHub account with email, this could become huge manual work.
We need to develop personal notifications code. Would you like to make a
contribution to these changes?

So I found more realistic to
A. group by suite and/or
B. implement some digest-like notification (to avoid mass emails).
C. Fix this strange bug with several notifications about one suite timeout
(I will do my absolute best to find out why it happens).

About point 1 I'm not sure I agree because
1. Nobody will read a separate list,
2. and it not possible to discuss failure with the rest of the community.
Please note that healthy practice is that someone will reply to failure
thread and email one more time when failure is fixed.

So I suggest concentrating on avoiding of failing a test, so the bot will
be silent :).

Sincerely,
Dmitriy Pavlov

пн, 10 сент. 2018 г. в 18:34, Vladimir Ozerov :

> Folks,
>
> If there will be a single thread for all failures, nobody will read it.
> Simply because it will be always "unread", with tons of messages, where it
> would be impossible to find a failure I am responsible for.
> Several threads - on per suite - makes situation a bit better, but still
> nobody will read it. What is worse, there will be a lot of fat threads atop
> of all other threads, so e.g. the very first page of GMail will always be
> filled with failure messages.
>
> In order to make things comfortable and efficient, we should strive to make
> messages as specific as possible, instead of grouping unrelated failures
> into one thread. IMO we can solve the problem as follows:
> 1) Move bot messages to separate mailing list
> 2) Add personal contributor email addresses to that messages for easy
> filtering
> 3) If needed - add *aggregate* email, sent once a day (or several days) to
> dev list with all the issues.
>
> This way, we first reach contributor directly. Then we send reminder to the
> dev list, without flooding.
>
> Thoughts?
>
>
> On Mon, Sep 10, 2018 at 5:11 PM Alexey Kuznetsov 
> wrote:
>
> >  Dmitriy,
> >
> > I like your idea to add suite name.
> >
> > On Mon, Sep 10, 2018 at 5:42 PM Dmitriy Pavlov 
> > wrote:
> >
> > > Hi Alexey,
> > >
> > > Thank you for that brilliant idea. Build ID was added intentionally to
> > > separate topics. But for timeout failures, it creates odd topics.
> > >
> > > I would like to suggest a modification of the idea: What if we will
> > include
> > > a suite name instead of build ID. It will keep the context of suite
> > > failures and fixes in one topic. E.g. recent problematic suite:
> Zookeeper
> > > will originate 1 or 2 topics, and human reply to it will be kept
> together
> > > with suite failure context. Please share your vision.
> > >
> > > Sincerely.
> > > Dmitriy Pavlov
> > >
> > > пт, 7 сент. 2018 г. в 8:25, Alexey Kuznetsov :
> > >
> > > > Dmitriy,
> > > >
> > > > How about to change e-mail subject
> > > > from *[MTCGA]: new failures in builds [n] needs to be handled*
> > > > to *[MTCGA]: new failures in builds needs to be handled* ?
> > > >
> > > > If subject will be the same it will not produce lots of threads on
> dev
> > > list
> > > > and it will be a single thread.
> > > > What do you think?
> > > >
> > > > --
> > > > Alexey Kuznetsov
> > > >
> > >
> >
> >
> > --
> > Alexey Kuznetsov
> >
>

[jira] [Created] (IGNITE-9520) Investigate fuzzy free lists

[Alexey Goncharuk (JIRA)]

Alexey Goncharuk created IGNITE-9520:


 Summary: Investigate fuzzy free lists
 Key: IGNITE-9520
 URL: https://issues.apache.org/jira/browse/IGNITE-9520
 Project: Ignite
  Issue Type: Task
Reporter: Alexey Goncharuk


We have several data structures (free list, reuse list) associated with each 
partition. For these structures a major part of their state is maintained 
on-heap and persisted during checkpoints.
This yields a lot of random disk accesses during checkpoints which 
significantly increases checkpoint mark phase (done under checkpoint write lock 
and essentially blocks all tx ops on the node).

Need to investigate if we can implement some sort of a data structure which is 
updated lazily and may be out-of date, then we can update these data structures 
outside of checkpoint mark phases.



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

[GitHub] akalash commented on a change in pull request #3: IGNITE-9333 Add statistics page

[GitBox]

akalash commented on a change in pull request #3: IGNITE-9333 Add statistics 
page
URL: https://github.com/apache/ignite-teamcity-bot/pull/3#discussion_r216379313
 
 

 ##
 File path: 
ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
 ##
 @@ -258,7 +263,7 @@ private IgnitePersistentTeamcity(Ignite ignite, 
IgniteTeamcityHelper teamcity) {
 try {
 apply = loadWithMerge.apply(key, persistedBuilds != null ? 
persistedBuilds.getData() : null);
 
-final Expirable newVal = new 
Expirable<>(System.currentTimeMillis(), apply);
+final Expirable newVal = new 
Expirable<>(System.currentTimeMillis(), cnt.get(), apply);
 
 Review comment:
   AtomicLong looks too difficult to understanding. I think will be better if 
we will change V to List and will calculate size of it right here. We can do 
it because we know that V is always list.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] akalash commented on a change in pull request #3: IGNITE-9333 Add statistics page

[GitBox]

akalash commented on a change in pull request #3: IGNITE-9333 Add statistics 
page
URL: https://github.com/apache/ignite-teamcity-bot/pull/3#discussion_r216378674
 
 

 ##
 File path: 
ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/IgnitePersistentTeamcity.java
 ##
 @@ -261,7 +263,7 @@ private IgnitePersistentTeamcity(Ignite ignite, 
IgniteTeamcityHelper teamcity) {
 try {
 apply = loadWithMerge.apply(key, persistedBuilds != null ? 
persistedBuilds.getData() : null);
 
-final Expirable newVal = new 
Expirable<>(System.currentTimeMillis(), cnt, apply);
+final Expirable newVal = new 
Expirable<>(System.currentTimeMillis(), cnt.get(), apply);
 
 Review comment:
   AtomicLong looks too difficult to understanding. I think will be better if 
we will change V to List and will calculate size of it right here. We can do 
it because we know that V is always list. 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] ignite pull request #4719: Availability zones via spring

[DaveWHarvey]

GitHub user DaveWHarvey opened a pull request:

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

Availability zones via spring



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

$ git pull https://github.com/percipiomedia/ignite 
availability_zones_via_spring

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

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


commit 00d02cf6c073a28f2e26b2c1a572695c0df4476f
Author: Dave Harvey 
Date:   2018-08-28T19:49:11Z

IGNITE-9365
Add class ClusterNodeAttributeAffinityFilter which can be configured to 
force backups and primaries into different groups of nodes.
Add self tests for ClusterNodeAttributeAffinityBackupFilter and improved 
documentation.

commit 0a1e61cab73aa2e7ba00765155f326d5715556fc
Author: Dave Harvey 
Date:   2018-09-10T15:55:52Z

IGNITE-9365 Add class to enabling Spring configuration of cache template
to force primary and backups to different availabilty zones.




---

[GitHub] ignite pull request #4708: IGNITE-9445 Use valid tag for page write unlock w...

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9519) PK as complex type should can be keep at inline index

[Yury Gerzhedovich (JIRA)]

Yury Gerzhedovich created IGNITE-9519:
-

 Summary: PK as complex type should can be keep at inline index
 Key: IGNITE-9519
 URL: https://issues.apache.org/jira/browse/IGNITE-9519
 Project: Ignite
  Issue Type: Task
  Components: sql
Affects Versions: 2.6
Reporter: Yury Gerzhedovich
Assignee: Yury Gerzhedovich


Currently in case PK is complex type it can not be keep at inline index.

This is critical performance issue due to for any put or get operation it cant' 
be fully comparable and require read full object from the heap or even disk 
storage.

To mitigate the problem we need add ability keep complex type (java object) at 
inline indexes.



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

Re: Bots on dev list

[Vladimir Ozerov]

Folks,

If there will be a single thread for all failures, nobody will read it.
Simply because it will be always "unread", with tons of messages, where it
would be impossible to find a failure I am responsible for.
Several threads - on per suite - makes situation a bit better, but still
nobody will read it. What is worse, there will be a lot of fat threads atop
of all other threads, so e.g. the very first page of GMail will always be
filled with failure messages.

In order to make things comfortable and efficient, we should strive to make
messages as specific as possible, instead of grouping unrelated failures
into one thread. IMO we can solve the problem as follows:
1) Move bot messages to separate mailing list
2) Add personal contributor email addresses to that messages for easy
filtering
3) If needed - add *aggregate* email, sent once a day (or several days) to
dev list with all the issues.

This way, we first reach contributor directly. Then we send reminder to the
dev list, without flooding.

Thoughts?


On Mon, Sep 10, 2018 at 5:11 PM Alexey Kuznetsov 
wrote:

>  Dmitriy,
>
> I like your idea to add suite name.
>
> On Mon, Sep 10, 2018 at 5:42 PM Dmitriy Pavlov 
> wrote:
>
> > Hi Alexey,
> >
> > Thank you for that brilliant idea. Build ID was added intentionally to
> > separate topics. But for timeout failures, it creates odd topics.
> >
> > I would like to suggest a modification of the idea: What if we will
> include
> > a suite name instead of build ID. It will keep the context of suite
> > failures and fixes in one topic. E.g. recent problematic suite: Zookeeper
> > will originate 1 or 2 topics, and human reply to it will be kept together
> > with suite failure context. Please share your vision.
> >
> > Sincerely.
> > Dmitriy Pavlov
> >
> > пт, 7 сент. 2018 г. в 8:25, Alexey Kuznetsov :
> >
> > > Dmitriy,
> > >
> > > How about to change e-mail subject
> > > from *[MTCGA]: new failures in builds [n] needs to be handled*
> > > to *[MTCGA]: new failures in builds needs to be handled* ?
> > >
> > > If subject will be the same it will not produce lots of threads on dev
> > list
> > > and it will be a single thread.
> > > What do you think?
> > >
> > > --
> > > Alexey Kuznetsov
> > >
> >
>
>
> --
> Alexey Kuznetsov
>

[GitHub] ignite pull request #4718: IGNITE-9487 Introduce IGNITE_REST_GETALL_KEY_VALU...

[alamar]

GitHub user alamar opened a pull request:

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

IGNITE-9487 Introduce IGNITE_REST_GETALL_KEY_VALUE to change getall output 
format.



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

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

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

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


commit 88ce8b28fa941cd97436612fcc637ed8a1483d02
Author: Ilya Kasnacheev 
Date:   2018-09-10T15:23:21Z

IGNITE-9487 Introduce IGNITE_REST_GETALL_KEY_VALUE to change getall output 
format.




---

[GitHub] ignite pull request #4717: IGNITE-9518 getPagesFillFactor returns NaN for em...

[ibessonov]

GitHub user ibessonov opened a pull request:

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

IGNITE-9518 getPagesFillFactor returns NaN for empty cache



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

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

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

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


commit e606a740c100f8551b44d85d1a7a17204419b369
Author: ibessonov 
Date:   2018-09-10T15:06:42Z

IGNITE-9518 Fix of DataRegionMetrics#getPagesFillFactor implementation so 
it doesn't return NaN anymore




---

[GitHub] ignite pull request #4716: IGNITE-9500 SQL system view for list of caches

[alex-plekhanov]

GitHub user alex-plekhanov opened a pull request:

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

IGNITE-9500 SQL system view for list of caches



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

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

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

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


commit 4e309ecb63beb56d7222e2f3542053daa64401ff
Author: Aleksey Plekhanov 
Date:   2018-09-10T14:57:03Z

IGNITE-9500 SQL system view for list of caches




---

[jira] [Created] (IGNITE-9518) getPagesFillFactor returns NaN for empty cache

[Ivan Bessonov (JIRA)]

Ivan Bessonov created IGNITE-9518:
-

 Summary: getPagesFillFactor returns NaN for empty cache
 Key: IGNITE-9518
 URL: https://issues.apache.org/jira/browse/IGNITE-9518
 Project: Ignite
  Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov


PagesFillFactor attribute of DataRegionMetrics / DataStorageMetrics MX bean 
returns NaN for empty cache.



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

Re: Minor version changes and server/client compatibility

[Dmitriy Pavlov]

Hi Taras, thank you for your comments. I totally agree.

пн, 10 сент. 2018 г. в 17:14, Taras Ledkov :

> Dmitry, my short comment about maintains compatibilities.
>
> Ignite should be maintains (according to review checklist [1]):
>
> - binary compatibility for persistence store between minor releases;
> - JDBC and ODBC and thin client protocol forward and backward
> compatibility  between two consecutive minor releases;
>
> [1]. https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist
>
>
> On 10.09.2018 16:29, Dmitriy Pavlov wrote:
> > Hi David,
> >
> > Ignite does not maintain compatibility between different versions. It is
> > not easy to do in a general case.
> >
> > But if you would like to hear about it from other users, you can also ask
> > on the user list.
> >
> > Sincerely,
> > Dmitriy Pavlov
> >
> >
> > ср, 5 сент. 2018 г. в 18:18, David Harvey :
> >
> >> We have needed to do a couple of  simple bug fixes to ignite proper,
> where
> >> there is no change to interfaces or internode communications.   When we
> do
> >> this, we end up with these choices:
> >>
> >> - Coordinate client and server code bases so that they are in lock
> >> step.   Tedious with multiple clusters and test/dev versions.
> >> - Force the prior version number on the new builds, making it more
> >> tedious to understand what versions we are running.
> >>
> >> A standard practice would to ignore the last field in the version when
> >> doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be
> considered
> >> compatible.Is there some reason ignite requires and exact match?
> >>   How do other Ignite users handle this problem?
> >>
> >> Thanks,
> >>
> >> -DH
> >>
>
> --
> Taras Ledkov
> Mail-To: tled...@gridgain.com
>
>

[jira] [Created] (IGNITE-9517) Replace uses of ConcurrentHashSet with GridConcurrentHashSet in tests

[Ilya Kasnacheev (JIRA)]

Ilya Kasnacheev created IGNITE-9517:
---

 Summary: Replace uses of ConcurrentHashSet with 
GridConcurrentHashSet in tests
 Key: IGNITE-9517
 URL: https://issues.apache.org/jira/browse/IGNITE-9517
 Project: Ignite
  Issue Type: Improvement
Reporter: Ilya Kasnacheev


There are numerous tests where org.eclipse.jetty.util.ConcurrentHashSet is used.

We should not refer to jetty's utils and use our GridConcurrentHashSet instead.



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

[GitHub] ignite pull request #4715: IGNITE-9158

[zaleslaw]

GitHub user zaleslaw opened a pull request:

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

IGNITE-9158

Added Pipeline

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

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

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

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


commit 235020abdbfa90ab91b018f0cb4da9359d975567
Author: Zinoviev Alexey 
Date:   2018-09-07T14:43:34Z

Pipeline Draft

commit 036f4838992d471a4f1e9ad8873dbdf9d3e04152
Author: Zinoviev Alexey 
Date:   2018-09-10T14:32:49Z

Added pipeline and tests

commit f04ef4d09419ac719257d21892826cd52f1c600f
Author: Zinoviev Alexey 
Date:   2018-09-10T14:33:32Z

Added pipeline and tests




---

Re: IoC/DI support in Apache Ignite.NEt

[Pavel Tupitsyn]

Hi Artyom,

Ticket already exists: https://issues.apache.org/jira/browse/IGNITE-9299
Feel free to grab it.

But before diving deep into coding, can you please provide a short overview
of the proposed implementation?
Either on dev list or in JIRA ticket directly.

Thanks,
Pavel

On Mon, Sep 10, 2018 at 11:29 AM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:

> Hello Artyom,
>
> Welcome to the Apache Ignite community! I've added you to the list of
> contributors, you should now be able to assign tickets to yourself.
>
> Get familiar with Apache Ignite development process described here:
> https://cwiki.apache.org/confluence/display/IGNITE/Development+Process
>
> Instructions on how to contribute can be found here:
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
>
> Project setup in Intellij IDEA:
> https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup
>
> --AG
>
> вс, 9 сент. 2018 г. в 15:20, Artyom Sokolov :
>
> > Hello,
> >
> > I would like to start implementing IoC/DI support (Autofac, Castle
> Windsor,
> > etc.) in Apache Ignite.NET.
> >
> > Please add me as a contributor in JIRA, so I could create ticket and
> start
> > working on this.
> >
> > My JIRA username is applicazza.
> >
> > Cheers,
> > Artyom.
> >
>

Re: Minor version changes and server/client compatibility

[Taras Ledkov]

Dmitry, my short comment about maintains compatibilities.

Ignite should be maintains (according to review checklist [1]):

- binary compatibility for persistence store between minor releases;
- JDBC and ODBC and thin client protocol forward and backward 
compatibility  between two consecutive minor releases;


[1]. https://cwiki.apache.org/confluence/display/IGNITE/Review+Checklist


On 10.09.2018 16:29, Dmitriy Pavlov wrote:

Hi David,

Ignite does not maintain compatibility between different versions. It is
not easy to do in a general case.

But if you would like to hear about it from other users, you can also ask
on the user list.

Sincerely,
Dmitriy Pavlov


ср, 5 сент. 2018 г. в 18:18, David Harvey :


We have needed to do a couple of  simple bug fixes to ignite proper, where
there is no change to interfaces or internode communications.   When we do
this, we end up with these choices:

- Coordinate client and server code bases so that they are in lock
step.   Tedious with multiple clusters and test/dev versions.
- Force the prior version number on the new builds, making it more
tedious to understand what versions we are running.

A standard practice would to ignore the last field in the version when
doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be considered
compatible.Is there some reason ignite requires and exact match?
  How do other Ignite users handle this problem?

Thanks,

-DH



--
Taras Ledkov
Mail-To: tled...@gridgain.com

Re: Bots on dev list

[Alexey Kuznetsov]

 Dmitriy,

I like your idea to add suite name.

On Mon, Sep 10, 2018 at 5:42 PM Dmitriy Pavlov 
wrote:

> Hi Alexey,
>
> Thank you for that brilliant idea. Build ID was added intentionally to
> separate topics. But for timeout failures, it creates odd topics.
>
> I would like to suggest a modification of the idea: What if we will include
> a suite name instead of build ID. It will keep the context of suite
> failures and fixes in one topic. E.g. recent problematic suite: Zookeeper
> will originate 1 or 2 topics, and human reply to it will be kept together
> with suite failure context. Please share your vision.
>
> Sincerely.
> Dmitriy Pavlov
>
> пт, 7 сент. 2018 г. в 8:25, Alexey Kuznetsov :
>
> > Dmitriy,
> >
> > How about to change e-mail subject
> > from *[MTCGA]: new failures in builds [n] needs to be handled*
> > to *[MTCGA]: new failures in builds needs to be handled* ?
> >
> > If subject will be the same it will not produce lots of threads on dev
> list
> > and it will be a single thread.
> > What do you think?
> >
> > --
> > Alexey Kuznetsov
> >
>


-- 
Alexey Kuznetsov

Re: .Net MethodVisitor ambiguous exception during get StringMethod "Contains"

[Pavel Tupitsyn]

Can you provide a reproducer please?

On Mon, Sep 10, 2018 at 9:15 AM Tâm Nguyễn Mạnh 
wrote:

> Hi Paven,
>
> This is not compile error, this is runtime error. I got this while i try to
> use linq to query name contains (.NET core)
>
> On Sun, Sep 9, 2018 at 5:29 PM Pavel Tupitsyn 
> wrote:
>
> > Hi,
> >
> > Do you mean that you can't compile the code?
> > It certainly compiles (under full .NET, .NET Core, and Mono, on Windows
> and
> > Linux), so it seems like some issue with your environment.
> > Can you do a fresh git checkout, then run `build.bat`?
> >
> > Pavel
> >
> > On Fri, Sep 7, 2018 at 5:16 AM Tâm Nguyễn Mạnh <
> nguyenmanhtam...@gmail.com
> > >
> > wrote:
> >
> > > Hi,
> > >
> > > There are more than 1 Contains method for string, that lead into
> > Ambiguous
> > > exception
> > >
> > > modules\platforms\dotnet\Apache.Ignite.Linq\Impl\MethodVisitor.cs:57
> > > ``` C#
> > > GetStringMethod("Contains", del: (e, v) => VisitSqlLike(e, v, "'%' || ?
> > ||
> > > '%'")),
> > > ```
> > >
> > > I think it should be:
> > > ``` C#
> > > GetStringMethod("Contains", del: (e, v) => VisitSqlLike(e, v, "'%' || ?
> > ||
> > > '%'"), argTypes:new []{typeof(string)}),
> > > ```
> > >
> > > --
> > > Thanks & Best Regards
> > >
> > > Tam, Nguyen Manh
> > >
> >
>
>
> --
> Thanks & Best Regards
>
> Tam, Nguyen Manh
>

Re: Support TextQuery for ThinClient

[Tâm Nguyễn Mạnh]

Hi,
I would like to implement this feature. Can we open a ticket for that ?

Vào Th 2, 10 thg 9, 2018 lúc 8:27 CH Dmitriy Pavlov 
đã viết:

> Hi,
>
> I've didn't heard about such plans. TextQuery is not widely used, as far as
> I know.
>
> Hope this helps.
>
> Sincerely,
> Dmitriy Pavlov
>
> пт, 7 сент. 2018 г. в 4:57, Tâm Nguyễn Mạnh :
>
> > Hi,
> >
> > Is there any plan about support TextQuery for ThinClient ?
> >
> > --
> > Thanks & Best Regards
> >
> > Tam, Nguyen Manh
> >
>
-- 
Thanks & Best Regards

Tam, Nguyen Manh

Re: Minor version changes and server/client compatibility

[Dmitriy Pavlov]

Hi David,

Ignite does not maintain compatibility between different versions. It is
not easy to do in a general case.

But if you would like to hear about it from other users, you can also ask
on the user list.

Sincerely,
Dmitriy Pavlov


ср, 5 сент. 2018 г. в 18:18, David Harvey :

> We have needed to do a couple of  simple bug fixes to ignite proper, where
> there is no change to interfaces or internode communications.   When we do
> this, we end up with these choices:
>
>- Coordinate client and server code bases so that they are in lock
>step.   Tedious with multiple clusters and test/dev versions.
>- Force the prior version number on the new builds, making it more
>tedious to understand what versions we are running.
>
> A standard practice would to ignore the last field in the version when
> doing a compatibility test, e.g., 2.5.0 and 2.5.foobar would be considered
> compatible.Is there some reason ignite requires and exact match?
>  How do other Ignite users handle this problem?
>
> Thanks,
>
> -DH
>

Re: Support TextQuery for ThinClient

[Dmitriy Pavlov]

Hi,

I've didn't heard about such plans. TextQuery is not widely used, as far as
I know.

Hope this helps.

Sincerely,
Dmitriy Pavlov

пт, 7 сент. 2018 г. в 4:57, Tâm Nguyễn Mạnh :

> Hi,
>
> Is there any plan about support TextQuery for ThinClient ?
>
> --
> Thanks & Best Regards
>
> Tam, Nguyen Manh
>

[GitHub] ignite pull request #4714: Ignite 9441-2

[ibessonov]

GitHub user ibessonov opened a pull request:

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

Ignite 9441-2



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

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

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

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


commit 0756226a49677df3ebc31ecb69470215a6071341
Author: ibessonov 
Date:   2018-09-10T09:40:41Z

IGNITE-9441 Improved behaviour when CRC is zero for some record during 
standalone iteration.

commit a1fbb6ccca8535d453e32672316291b515a49a46
Author: ibessonov 
Date:   2018-09-10T13:12:56Z

IGNITE-9441 Improved zero CRC handling for replay iterator in 
FileWriteAheadLogManager.RecordsIterator




---

[jira] [Created] (IGNITE-9516) Vaccum cannot complete after rebalance

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-9516:
--

 Summary: Vaccum cannot complete after rebalance
 Key: IGNITE-9516
 URL: https://issues.apache.org/jira/browse/IGNITE-9516
 Project: Ignite
  Issue Type: Bug
  Components: mvcc
Reporter: Ivan Pavlukhin


In mvcc tests we wait for full Vacuum cleanup in {{afterTest}} method in a sake 
of tests isolation. 
{{org.apache.ignite.internal.processors.cache.mvcc.CacheMvccTransactionsTest#testRebalanceSimple}}
 hangs waiting Vacuum to complete. Most likely it was broken after implementing 
{{Cache.size}} for SQL operations over mvcc caches. Size for Cache API was not 
implemented properly (see related ticket).



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

[jira] [Created] (IGNITE-9515) OBDC: Do not quote PUBLIC schema in ODBC metadata

[Igor Sapego (JIRA)]

Igor Sapego created IGNITE-9515:
---

 Summary: OBDC: Do not quote PUBLIC schema in ODBC metadata
 Key: IGNITE-9515
 URL: https://issues.apache.org/jira/browse/IGNITE-9515
 Project: Ignite
  Issue Type: Improvement
Reporter: Igor Sapego


PUBLIC schema does not require quoting so do not add quotes for it. Also, 
check, maybe it makes sense to avoid quoting whenever schema is in upper case 
and does not contain special characters.



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

[jira] [Created] (IGNITE-9514) [ML] Reduce time for the updating models on many partitions

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-9514:


 Summary: [ML] Reduce time for the updating models on many 
partitions
 Key: IGNITE-9514
 URL: https://issues.apache.org/jira/browse/IGNITE-9514
 Project: Ignite
  Issue Type: Task
  Components: ml
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev






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

Re: PHP thin client

[Igor Sapego]

By the way, I used Ubuntu 18.04, PHP 7.2.7 and what seems
to be PhpUnit 7.3 (not sure here).

Best Regards,
Igor


On Mon, Sep 10, 2018 at 3:28 PM Igor Sapego  wrote:

> Guys, I've reviewed the API (which looks good), run tests and examples and
> here are my commments:
>
> 1. Main page for documentation is empty.
>
> 2. More output for Auth example is needed. This is not a test, after all,
> but example.
>
> 3. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1, they
> fail with the following message:
> Apache\Ignite\Exception\NoConnectionException: [127.0.0.1] Failed to parse
> address "127.0.0.1" in
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php:107
> Stack trace:
> #0
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(54):
> Apache\Ignite\Internal\Connection\ClientFailoverSocket->failoverConnect()
> #1
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Client.php(61):
> Apache\Ignite\Internal\Connection\ClientFailoverSocket->connect(Object(Apache\Ignite\ClientConfiguration))
> #2
> /home/isapego/work/ignite/modules/platforms/php/tests/TestingHelper.php(52):
> Apache\Ignite\Client->connect(Object(Apache\Ignite\ClientConfiguration))
> #3
> /home/isapego/work/ignite/modules/platforms/php/tests/SqlQueryTest.php(49):
> Apache\Ignite\Tests\TestingHelper::init()
> #4
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(703):
> Apache\Ignite\Tests\SqlQueryTestCase::setUpBeforeClass()
> #5
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(750):
> PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
> #6
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(587):
> PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
> #7
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(203):
> PHPUnit\TextUI\TestRunner->doRun(Object(PHPUnit\Framework\TestSuite),
> Array, true)
> #8
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(159):
> PHPUnit\TextUI\Command->run(Array, true)
> #9
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/phpunit(53):
> PHPUnit\TextUI\Command::main()
> #10 {main}
>
> 4. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1:10800,
> they fail with the following message:
> Apache\Ignite\Exception\OperationStatusUnknownException: Error while
> reading data from the server in
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php:168
> Stack trace:
> #0
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(178):
> Apache\Ignite\Internal\Connection\ClientSocket->receive(Object(Apache\Ignite\Internal\Binary\MessageBuffer),
> 4)
> #1
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(159):
> Apache\Ignite\Internal\Connection\ClientSocket->processResponse(Object(Apache\Ignite\Internal\Binary\Request))
> #2
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(107):
> Apache\Ignite\Internal\Connection\ClientSocket->processRequest(Object(Apache\Ignite\Internal\Binary\Request))
> #3
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(96):
> Apache\Ignite\Internal\Connection\ClientSocket->connect()
> #4
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(54):
> Apache\Ignite\Internal\Connection\ClientFailoverSocket->failoverConnect()
> #5
> /home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Client.php(61):
> Apache\Ignite\Internal\Connection\ClientFailoverSocket->connect(Object(Apache\Ignite\ClientConfiguration))
> #6
> /home/isapego/work/ignite/modules/platforms/php/tests/TestingHelper.php(52):
> Apache\Ignite\Client->connect(Object(Apache\Ignite\ClientConfiguration))
> #7
> /home/isapego/work/ignite/modules/platforms/php/tests/SqlQueryTest.php(49):
> Apache\Ignite\Tests\TestingHelper::init()
> #8
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(703):
> Apache\Ignite\Tests\SqlQueryTestCase::setUpBeforeClass()
> #9
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(750):
> PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
> #10
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(587):
> PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
> #11
> /home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.ph

[jira] [Created] (IGNITE-9513) [ML] Unify all preprocessors trainers' generics

[Aleksey Zinoviev (JIRA)]

Aleksey Zinoviev created IGNITE-9513:


 Summary: [ML] Unify all preprocessors trainers' generics
 Key: IGNITE-9513
 URL: https://issues.apache.org/jira/browse/IGNITE-9513
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksey Zinoviev
Assignee: Aleksey Zinoviev


Currently we have

EncoderTrainer implements PreprocessingTrainer

and

BinarizationTrainer implements PreprocessingTrainer

It will helps with raw types in OneVsRest or in Pipeline and CV processes



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

Re: PHP thin client

[Igor Sapego]

Guys, I've reviewed the API (which looks good), run tests and examples and
here are my commments:

1. Main page for documentation is empty.

2. More output for Auth example is needed. This is not a test, after all,
but example.

3. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1, they
fail with the following message:
Apache\Ignite\Exception\NoConnectionException: [127.0.0.1] Failed to parse
address "127.0.0.1" in
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php:107
Stack trace:
#0
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(54):
Apache\Ignite\Internal\Connection\ClientFailoverSocket->failoverConnect()
#1
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Client.php(61):
Apache\Ignite\Internal\Connection\ClientFailoverSocket->connect(Object(Apache\Ignite\ClientConfiguration))
#2
/home/isapego/work/ignite/modules/platforms/php/tests/TestingHelper.php(52):
Apache\Ignite\Client->connect(Object(Apache\Ignite\ClientConfiguration))
#3
/home/isapego/work/ignite/modules/platforms/php/tests/SqlQueryTest.php(49):
Apache\Ignite\Tests\TestingHelper::init()
#4
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(703):
Apache\Ignite\Tests\SqlQueryTestCase::setUpBeforeClass()
#5
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(750):
PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#6
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(587):
PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#7
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(203):
PHPUnit\TextUI\TestRunner->doRun(Object(PHPUnit\Framework\TestSuite),
Array, true)
#8
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(159):
PHPUnit\TextUI\Command->run(Array, true)
#9
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/phpunit(53):
PHPUnit\TextUI\Command::main()
#10 {main}

4. If I try run test with APACHE_IGNITE_CLIENT_ENDPOINTS=127.0.0.1:10800,
they fail with the following message:
Apache\Ignite\Exception\OperationStatusUnknownException: Error while
reading data from the server in
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php:168
Stack trace:
#0
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(178):
Apache\Ignite\Internal\Connection\ClientSocket->receive(Object(Apache\Ignite\Internal\Binary\MessageBuffer),
4)
#1
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(159):
Apache\Ignite\Internal\Connection\ClientSocket->processResponse(Object(Apache\Ignite\Internal\Binary\Request))
#2
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientSocket.php(107):
Apache\Ignite\Internal\Connection\ClientSocket->processRequest(Object(Apache\Ignite\Internal\Binary\Request))
#3
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(96):
Apache\Ignite\Internal\Connection\ClientSocket->connect()
#4
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Internal/Connection/ClientFailoverSocket.php(54):
Apache\Ignite\Internal\Connection\ClientFailoverSocket->failoverConnect()
#5
/home/isapego/work/ignite/modules/platforms/php/src/Apache/Ignite/Client.php(61):
Apache\Ignite\Internal\Connection\ClientFailoverSocket->connect(Object(Apache\Ignite\ClientConfiguration))
#6
/home/isapego/work/ignite/modules/platforms/php/tests/TestingHelper.php(52):
Apache\Ignite\Client->connect(Object(Apache\Ignite\ClientConfiguration))
#7
/home/isapego/work/ignite/modules/platforms/php/tests/SqlQueryTest.php(49):
Apache\Ignite\Tests\TestingHelper::init()
#8
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(703):
Apache\Ignite\Tests\SqlQueryTestCase::setUpBeforeClass()
#9
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/Framework/TestSuite.php(750):
PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#10
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/TestRunner.php(587):
PHPUnit\Framework\TestSuite->run(Object(PHPUnit\Framework\TestResult))
#11
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(203):
PHPUnit\TextUI\TestRunner->doRun(Object(PHPUnit\Framework\TestSuite),
Array, true)
#12
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/src/TextUI/Command.php(159):
PHPUnit\TextUI\Command->run(Array, true)
#13
/home/isapego/work/ignite/modules/platforms/php/vendor/phpunit/phpunit/phpunit(53):
PHPUnit\TextUI\Com

[GitHub] ignite pull request #4713: Ignite-9465: Node.js client: improve complex obje...

[ekaterina-nbl]

GitHub user ekaterina-nbl opened a pull request:

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

Ignite-9465: Node.js client: improve complex object flags processing



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

$ git pull https://github.com/nobitlost/ignite ignite-9465

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

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


commit 4b444dff62c04b97bc2cdb0676ad52880374
Author: ekaterina-nbl 
Date:   2018-03-20T21:12:21Z

initial implementation

commit d1e8014c80f698028d23e09cafd7ea190ac3e929
Author: ekaterina-nbl 
Date:   2018-03-20T21:32:52Z

initial implementation

commit f79229e233ffa7bff1e7c22f04749924af6d712a
Author: ekaterina-nbl 
Date:   2018-03-22T09:39:32Z

initial implementation

commit 658d60b58840080b664e02815f4ba6aac76e5804
Author: ekaterina-nbl 
Date:   2018-03-22T16:52:18Z

minor update

commit 617cef12ad72791c7e7e67179e1b0c3f7f3ae6bb
Author: ekaterina-nbl 
Date:   2018-03-25T13:33:27Z

api spec

commit d9729585f5a901977e2a2e40e86a2b715fab79fa
Author: alexey-nbl 
Date:   2018-03-25T21:27:11Z

link to api_spec added

commit ea847eba62e556fa81cbf9838ffe17af60f464e4
Author: ekaterina-nbl 
Date:   2018-03-31T22:07:50Z

error types modified

commit c2ad53fe625cc3a05155eeef318421538830
Author: ekaterina-nbl 
Date:   2018-03-31T23:41:56Z

client states

commit 6d2233864b4d891361d38a7143846570bd6c0ef6
Author: ekaterina-nbl 
Date:   2018-04-01T13:11:27Z

object types improvement

commit 52fbc5f87143da068596141cb59b17b684fd2c1f
Author: ekaterina-nbl 
Date:   2018-04-02T16:59:52Z

complex objects

commit cae5a28e7e0d610434debcc140738e2f48d061cf
Author: ekaterina-nbl 
Date:   2018-04-02T20:13:00Z

object types improvement

commit 3165405d4eae09519dc9b5f40f162eb74a9b3c5d
Author: ekaterina-nbl 
Date:   2018-04-02T21:21:26Z

client states

commit fdbb8f86b32fe4c038d38620a80921be3038f31f
Author: alexey-nbl 
Date:   2018-04-03T08:26:04Z

Ignite client states described

commit 04b946885db0ea2f6fe56a75e28302641dad5f61
Author: alexey-nbl 
Date:   2018-04-03T09:35:49Z

minor update

commit f4aaf1c3f23c82ba7974b4c571a9984748e5e82e
Author: alexey-nbl 
Date:   2018-04-03T12:47:54Z

Update ObjectType.js

commit e4c8279f4e83b3ed13383420ab3d1417b090a3fa
Author: ekaterina-nbl 
Date:   2018-04-03T13:46:19Z

minor updates + api spec

commit ed2e4ee830ca40a28dc31958665f52fab6a0bcdd
Author: alexey-nbl 
Date:   2018-04-04T14:34:52Z

Update ObjectType.js

commit 7e1666eb5df82b622a028c0ea949fa21c79e66c2
Author: alexey-nbl 
Date:   2018-04-04T15:14:00Z

Update ObjectType.js

commit 7b0270d65b597dc1b0d164e78f07c3a21c37ca67
Author: ekaterina-nbl 
Date:   2018-04-08T17:16:43Z

sql queries, key value ops

commit fe90f53fd08f77add17fbf06d014f9a9b0a11c65
Author: alexey-nbl 
Date:   2018-04-08T18:31:47Z

Update IgniteClient.js

commit 04137bf5ec3b7077e194edd0100a01bb43f7933a
Author: alexey-nbl 
Date:   2018-04-08T18:37:04Z

Update CacheConfiguration.js

commit b63ad5980718da1b0c44fa4ca138c6e85e47aef3
Author: alexey-nbl 
Date:   2018-04-08T19:11:11Z

Update ObjectType.js

commit 756b908c9dc38ae497e4d7d740f836dabed93e48
Author: alexey-nbl 
Date:   2018-04-08T22:41:54Z

Update CacheClient.js

commit e96ffee17298dd25d26a7029738132478271cf92
Author: ekaterina-nbl 
Date:   2018-04-08T23:23:33Z

object array, minor updates

commit c050e671f74232c4efc41f51c2018d08b152cbbc
Author: alexey-nbl 
Date:   2018-04-09T21:04:35Z

Update CacheClient.js

commit 25052a4e93d6fcc0b0c4789fdd5a1eb85413b5a2
Author: alexey-nbl 
Date:   2018-04-09T22:43:50Z

Update ObjectType.js

commit c516b4147c10398d4f34d78a8830dd0fcb5f28f4
Author: alexey-nbl 
Date:   2018-04-10T11:50:13Z

Update CacheClient.js

commit 0e9924a0df8a1d41718fb929698b8e4416f2efa2
Author: ekaterina-nbl 
Date:   2018-04-10T13:21:16Z

cache key value operations tests

commit e09ee0e7969bffd6f4cfd11579f6d0ff9b486c99
Author: ekaterina-nbl 
Date:   2018-04-10T13:21:50Z

Merge branch 'master' of https://github.com/nobitlost/ignite

commit 15d2abce41b4f1c9d4d5fecd44a99a5393177482
Author: alexey-nbl 
Date:   2018-04-10T14:38:57Z

Update Query.js




---

[GitHub] ignite pull request #4712: Ignite 9478

[SGrimstad]

GitHub user SGrimstad opened a pull request:

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

Ignite 9478



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

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

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

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


commit 26543e10f8143dbc2d313b870081d633baf4cd05
Author: SGrimstad 
Date:   2018-08-14T11:21:13Z

IGNITE-9141  Implemented

commit ee631080782fe17a007e10117a96fc1a72990854
Author: devozerov 
Date:   2018-08-14T12:54:32Z

Merge branch 'master' into ignite-9141

commit 4587bfc24f25045fd7fc2197076797cc6ca54e32
Author: devozerov 
Date:   2018-08-14T13:23:19Z

Review.

commit 1511eb31b644113091be156d872f5adb2daecb84
Author: SGrimstad 
Date:   2018-08-14T11:21:13Z

IGNITE-9141  Implemented

commit 0425a32a3d490165b29bcf9236a49a48f7761666
Author: devozerov 
Date:   2018-08-14T13:23:19Z

Review.

commit a7209f870148f984cdbf3e6437337c7b665defb5
Author: SGrimstad 
Date:   2018-08-20T11:56:11Z

IGNITE-9141 Modified according to review comments. Integration tests added

commit 08e196ad4503d4487fda0da2b61406ef3bd84cbf
Author: SGrimstad 
Date:   2018-08-20T12:28:46Z

IGNITE-9141 javadoc added

commit b006a8dba4ae4319aa78a0d3c6fd6eef47bb1da8
Author: SGrimstad 
Date:   2018-08-20T12:29:46Z

IGNITE-9141 javadoc added

commit 0ed04a7ca655866685841b2ec9c2ed64797bf233
Author: devozerov 
Date:   2018-08-28T08:05:04Z

Merge branch 'master' into ignite-9141

commit 02db267355a8405c64c45d51c81e342df664d612
Author: devozerov 
Date:   2018-08-28T08:45:55Z

Review comments.

commit 0c4301cdc0d6108ed5b51173144e19d3ad450e63
Author: SGrimstad 
Date:   2018-08-28T11:08:47Z

IGNITE-9141 Fixes according to review

commit cef6e572e87503442e5b59fa147669b1f451fa13
Author: SGrimstad 
Date:   2018-08-30T11:28:20Z

ШПТШЕУ-9141 removed fair testing, will be enabled back in IGNITE-8913

commit abac3c53030433a4d47d0ea74f55d46394eda4eb
Author: devozerov 
Date:   2018-08-31T14:32:54Z

Merge branch 'master' into ignite-9141

# Conflicts:
#   
modules/core/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/messages/GridQueryNextPageResponse.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/GridReduceQueryExecutor.java
#   
modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/twostep/ReduceQueryRun.java

commit 038a007c793d8f077509ce33f30d71885ac78672
Author: devozerov 
Date:   2018-08-31T14:47:44Z

Minors.

commit c39bf96daa4df36dfe9599f3a1c9f40320be7921
Author: devozerov 
Date:   2018-08-31T15:11:53Z

Cleanup.

commit b2c8702a2cfa44031eacee7b2f315cd757e5d3e4
Author: devozerov 
Date:   2018-08-31T15:50:10Z

WIP.

commit b12b7317f3e124968070f3fb69926e380d3c4883
Author: devozerov 
Date:   2018-08-31T15:52:30Z

Review.

commit 4cfce62b8f284b78356793d989ea9573d66e5faf
Author: SGrimstad 
Date:   2018-09-03T10:18:14Z

IGNITE-9141 review fix

commit 4076ddf41c0061985e2a8ea38457be0db9d7fe8e
Author: SGrimstad 
Date:   2018-09-04T09:40:38Z

IGNITE-6195 partition proper co-location check

commit 66d99eebbf7b34e3925a5e0b9c931ee202b452e8
Author: SGrimstad 
Date:   2018-09-04T11:40:13Z

IGNITE-6195 log in case of call added

commit af44781656bb8f5e1ca652800c276fe5bcdff17a
Author: SGrimstad 
Date:   2018-09-04T13:31:05Z

IGNITE-6195 test fail message verbosed

commit 9baab18588a820e8b2c28c9ee8cf65918b903d97
Author: SGrimstad 
Date:   2018-09-05T06:48:19Z

IGNITE-6195 test fail on TC verbose

commit e420466312d11009e7ea33a5150d679173d4ed42
Author: SGrimstad 
Date:   2018-09-05T09:00:02Z

IGNITE-6195 test fail on TC fix

commit fe1642da6a35e4ad21ffdb5d213c2136ea056f46
Author: SGrimstad 
Date:   2018-09-10T12:13:26Z

IGNITE-9478 implemented. Additional hard-to-reproduce tests are required.




---

[GitHub] ignite pull request #4150: IGNITE-8509 Fix cache 6 suite flaky tests.

[asfgit]

Github user asfgit closed the pull request at:

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


---

[jira] [Created] (IGNITE-9512) testRollbackOnTopologyLockPessimistic still fails on master.

[Alexei Scherbakov (JIRA)]

Alexei Scherbakov created IGNITE-9512:
-

 Summary: testRollbackOnTopologyLockPessimistic still fails on 
master.
 Key: IGNITE-9512
 URL: https://issues.apache.org/jira/browse/IGNITE-9512
 Project: Ignite
  Issue Type: Bug
Reporter: Alexei Scherbakov
Assignee: Alexei Scherbakov


Looks like fix in [1] was incomplete.

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



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

[jira] [Created] (IGNITE-9511) Update styling for modal windows

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-9511:
-

 Summary: Update styling for modal windows
 Key: IGNITE-9511
 URL: https://issues.apache.org/jira/browse/IGNITE-9511
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin


Currently we have two way of styles - modern (confirmation, etc) and old styled 
(getting started, messages ect).

The modals have to be consistent. Let's update them with new style.



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

Re: Bots on dev list

[Dmitriy Pavlov]

Hi Alexey,

Thank you for that brilliant idea. Build ID was added intentionally to
separate topics. But for timeout failures, it creates odd topics.

I would like to suggest a modification of the idea: What if we will include
a suite name instead of build ID. It will keep the context of suite
failures and fixes in one topic. E.g. recent problematic suite: Zookeeper
will originate 1 or 2 topics, and human reply to it will be kept together
with suite failure context. Please share your vision.

Sincerely.
Dmitriy Pavlov

пт, 7 сент. 2018 г. в 8:25, Alexey Kuznetsov :

> Dmitriy,
>
> How about to change e-mail subject
> from *[MTCGA]: new failures in builds [n] needs to be handled*
> to *[MTCGA]: new failures in builds needs to be handled* ?
>
> If subject will be the same it will not produce lots of threads on dev list
> and it will be a single thread.
> What do you think?
>
> --
> Alexey Kuznetsov
>

[jira] [Created] (IGNITE-9510) Add vertical cursor to ignite-chart component, fix tooltip positionin.

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-9510:
-

 Summary: Add vertical cursor to ignite-chart component, fix 
tooltip positionin.
 Key: IGNITE-9510
 URL: https://issues.apache.org/jira/browse/IGNITE-9510
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin


Current version of ignite chart doesn't highlight current horizontal selection. 
We should add one.

Also there are issues with tooltips positioning, that also shoud be fixed.



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

[jira] [Created] (IGNITE-9509) Created one facade for exising ui-grid tables.

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-9509:
-

 Summary: Created one facade for exising ui-grid tables.
 Key: IGNITE-9509
 URL: https://issues.apache.org/jira/browse/IGNITE-9509
 Project: Ignite
  Issue Type: Improvement
Reporter: Alexander Kalinin
Assignee: Alexander Kalinin


We have various custom implementation where ui-grid is used with lots of 
duplicated code for selection\update etc.

It would be better to encapsulate this cases under one component facade.



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

[GitHub] ignite pull request #4711: IGNITE 6346

[xtern]

GitHub user xtern opened a pull request:

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

IGNITE 6346



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

$ git pull https://github.com/xtern/ignite IGNITE-6346

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

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


commit 2efaac326aa6b0a4120fa3b1f845db54dd313fce
Author: kaligula...@gmail.com 
Date:   2017-09-26T19:15:04Z

IGNITE-6346 Fix: distributed set does not work in REPLICATED mode

Changes:
1. Fixed bug
2. Added tests

commit 9d24708537ec47baac989d1a747cc716093457b4
Author: pereslegin-pa 
Date:   2018-09-10T09:56:49Z

IGNITE-6346 Code cleanup.




---

[GitHub] ignite pull request #4710: IGNITE-9495 Update version for org.apache.lucene

[Max-Pudov]

GitHub user Max-Pudov opened a pull request:

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

IGNITE-9495 Update version for org.apache.lucene

org.apache.lucene is updated to 7.4.0

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

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

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

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


commit 5cd5dec10aa08b8db2033f4486a1d28021c5d565
Author: Max-Pudov 
Date:   2018-09-10T09:54:29Z

IGNITE-9495 Update version for org.apache.lucene




---

[jira] [Created] (IGNITE-9508) Remove legacy configuration mixin

[Alexander Kalinin (JIRA)]

Alexander Kalinin created IGNITE-9508:
-

 Summary: Remove legacy configuration mixin
 Key: IGNITE-9508
 URL: https://issues.apache.org/jira/browse/IGNITE-9508
 Project: Ignite
  Issue Type: Task
Reporter: Alexander Kalinin


We have lots of unstructured pug mixins in web console frontend. Some of them 
are not used, some are just facades for new mixins. Let's remove old mixins.



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

Re: Class field ThreadLocal. Why not static?

[Alexey Goncharuk]

Maxim,

Ignite supports starting multiple instances of Ignite in the same VM, so
having static thread locals for the fields you mentioned does not work.

Generally, I think thread-local should be bound to the lifespan of the
component it describes. Static thread-locals are hard to clean-up and they
often lead to leaks, so I would rather changed existing static
thread-locals to be non-static.

--AG

пн, 10 сент. 2018 г. в 11:54, Maxim Muzafarov :

> Igniters,
>
> According to javadoc [1] class ThreadLocal:
> `ThreadLocal instances are typically private *static* fields in classes
> that wish to associate state with a thread (e.g., a user ID or Transaction
> ID).`
>
> So, AFAIK non-static ThreadLocal usage means as `per thread - per class
> instance`. What the real cases of using non-static ThreadLocal class fields
> in Ignite code project? When we need it?
>
> In Ignite code project I've found ThreadLocal usage as:
>  - non-static - 67
>  - static  - 68
>
> Back to my example, I've checked FileWriteAheadLogManager. It has:
> 1) private final ThreadLocal interrupted [2]
> 2) private final ThreadLocal lastWALPtr [3]
> I think both of these fields should be set and used as `static`. Can anyone
> confirm it?
>
>
> [1] https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html
> [2]
>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java#L253
> [3]
>
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java#L340
> --
> --
> Maxim Muzafarov
>

Re: Apache Ignite 2.7 release

[Ilya Kasnacheev]

Hello!

There's still two issues with the submission.

The first one is that we're downloading "latest" version from preferred
mirror but a specified version, such as "2.6", we're also going to download
from "slow" archive.apache.org/dist.
That's a great limitation for this change, since most real deployments of
Apache Ignite will have their Ignite version pegged to a specific release.
But in this case there's no win in download speed.
*In my opinion it is a blocker.*

The second one is that we can't download anything when we failed to resolve
"latest". My idea is that we should try and download last known version in
this case, which can be pushed to source from pom.xml, as we already do
with URLs. So if you could not resolve "latest" you will download 2.7.0.

Buuut, maybe it's not necessary, maybe we should just *discourage "latest"*,
which is in my opinion almost always a bad idea.

WDYT?

Regards,
-- 
Ilya Kasnacheev


вс, 9 сент. 2018 г. в 5:47, Roman Shtykh :

> Hi Ilya,
>
> Sorry, missed that.
> Added now.
>
> --
> Roman Shtykh
>
>
> On Thursday, September 6, 2018, 6:16:58 p.m. GMT+9, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>
> Hello!
>
> The last of my requests still standing is that we should fall-back to
> single URL download in case of error with 'latest' version. Everything else
> looks good to me.
>
> Can we do that? I'm really worried that Apache API will go sour.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> чт, 6 сент. 2018 г. в 8:56, Roman Shtykh :
>
> Hi Ilya,
>
> Thanks again.
>
> 1) Done.
> 2) Used catch() for latest version.
>
> Please see my comments on github.
> --
> Roman Shtykh
>
>
> On Wednesday, September 5, 2018, 11:30:10 p.m. GMT+9, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>
> Hello!
>
> I've left a new wave of replies.
>
> Basically, 1) let's keep DOWNLOAD_URL_PATTERN string value inlined so
> that it will work even if build process is broken (would be useful for e.g.
> developing out of IDE)
> And also I urge you to catch() around new fragile Apache JSON API
> resolving, and download the 'current' version instead, as defined by
> ignite-mesos version.
>
> This is because this module is not under continuouos scrutiny so extra
> care should be applied.
> --
> Ilya Kasnacheev
>
>
> вт, 4 сент. 2018 г. в 13:42, Roman Shtykh :
>
> Thanks, Ilya!
> I will check your comments, and discuss it at JIRA.
>
> --
> Roman Shtykh
>
>
> On Tuesday, September 4, 2018, 7:17:53 p.m. GMT+9, Ilya Kasnacheev <
> ilya.kasnach...@gmail.com> wrote:
>
>
> Hello!
>
> IGNITE-9408  looks
> good to me and may be merged right away.
>
> IGNITE-9388  needs
> more work in my opinion, I have commented the PR. I also advice having test
> for this functionality.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 4 сент. 2018 г. в 6:52, Roman Shtykh :
>
> Igniters,
> I would like Mesos integration update be included in the upcoming
> release.Can anyone review prs for the following issues?
> IGNITE-9388: mesos IgniteProvider tries to access obsolete ignite.run or
> download from slow archiveIGNITE-9408: Update mesos version
>
> Roman Shtykh
>
> On Thursday, August 30, 2018, 9:25:43 p.m. GMT+9, Vyacheslav Daradur <
> daradu...@gmail.com> wrote:
>
>  Hi Igniters!
>
> I'm working on the following Service Grid tasks:
> - IGNITE-8361 Use discovery messages for service deployment
> - IGNITE-8362 Collect service deployment results asynchronously on
> coordinator
> - IGNITE-8363 Handle topology changes during service deployment
> - IGNITE-8364 Propagate deployed services to joining nodes
> - IGNITE-8365 Introduce service failure events
> - IGNITE-3392 Propagate service deployment results from assigned nodes
> to initiator
>
> Let's call them *phase 1* because the should be implemented together
> (atomically).
>
> I do my best to finish phase 1 for including to 2.7 release.
>
> But I'm not sure that the solution will be fully completed till the
> beginning of October.
>
> On Wed, Aug 29, 2018 at 7:18 PM Nikolay Izhikov 
> wrote:
> >
> > Hell, Yakov
> >
> > I'm ok with your proposal.
> >
> >* Scope freeze - September 17 - We should have a full list of
> tickets for 2.7 here.
> >* Code freeze - October 01 - We should merge all 2.7 tickets to
> master here.
> >* Vote on RC1 - October 11.
> >* Vote on release - October 15.
> >
> > В Ср, 29/08/2018 в 12:39 +0300, Yakov Zhdanov пишет:
> > > Nikolay,
> > >
> > > I think we should have 2 weeks after code freeze which by the way may
> > > include RC1 voting stage. This way I would like us to agree that
> release
> > > candidate should be sent to vote on Oct, 11th and we can release on
> Oct,
> > > 15th.
> > >
> > > What do you think?
> > >
> > > --Yakov
>
>
>
> --
> Best Regards, Vyacheslav D.
>
>

[jira] [Created] (IGNITE-9507) .NET: AsCacheQueryable, invalid results when TValue is polymorfic type

[Pavel Poltoratskiy (JIRA)]

Pavel Poltoratskiy created IGNITE-9507:
--

 Summary: .NET: AsCacheQueryable, invalid results when TValue is 
polymorfic type
 Key: IGNITE-9507
 URL: https://issues.apache.org/jira/browse/IGNITE-9507
 Project: Ignite
  Issue Type: Bug
Reporter: Pavel Poltoratskiy
 Attachments: IgniteBug2.rar

If TValue is base class and derived instance was stored in cache, 
AsCacheQueryable() will always empty.

In attached files, there is the project,  that reproduces the problem.

Also, you can comment this string

_queryEntity0, /* comment here to make it work! */_

to make it work.



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

Class field ThreadLocal. Why not static?

[Maxim Muzafarov]

Igniters,

According to javadoc [1] class ThreadLocal:
`ThreadLocal instances are typically private *static* fields in classes
that wish to associate state with a thread (e.g., a user ID or Transaction
ID).`

So, AFAIK non-static ThreadLocal usage means as `per thread - per class
instance`. What the real cases of using non-static ThreadLocal class fields
in Ignite code project? When we need it?

In Ignite code project I've found ThreadLocal usage as:
 - non-static - 67
 - static  - 68

Back to my example, I've checked FileWriteAheadLogManager. It has:
1) private final ThreadLocal interrupted [2]
2) private final ThreadLocal lastWALPtr [3]
I think both of these fields should be set and used as `static`. Can anyone
confirm it?


[1] https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html
[2]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java#L253
[3]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/wal/FileWriteAheadLogManager.java#L340
-- 
--
Maxim Muzafarov

[GitHub] ignite pull request #4709: IGNITE-9342: Fix two-step queries cache for multi...

[tledkov-gridgain]

GitHub user tledkov-gridgain opened a pull request:

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

IGNITE-9342: Fix two-step queries cache for multiple statements query



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

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

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

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


commit e70158b6c7e6535ceb434927a834be7a8cb1876f
Author: tledkov-gridgain 
Date:   2018-09-10T08:51:33Z

IGNITE-9342: Fix two-step queries cache for multiple statements query




---

[jira] [Created] (IGNITE-9506) Timeout object with mutable end time breaks GridTimeoutProcessor behavior

[Ivan Pavlukhin (JIRA)]

Ivan Pavlukhin created IGNITE-9506:
--

 Summary: Timeout object with mutable end time breaks 
GridTimeoutProcessor behavior
 Key: IGNITE-9506
 URL: https://issues.apache.org/jira/browse/IGNITE-9506
 Project: Ignite
  Issue Type: Bug
  Components: cache
Reporter: Ivan Pavlukhin


Current transaction API provides setter method for transaction timeout. It is 
possible to run transaction as follows:
{code:java}
try (Transaction tx = ign.transactions().txStart()) {
tx.timeout(TimeUnit.SECONDS.toMillis(10));
...
}{code}



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

[GitHub] ignite pull request #4708: IGNITE-9445 Use valid tag for page write unlock w...

[ascherbakoff]

GitHub user ascherbakoff opened a pull request:

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

IGNITE-9445 Use valid tag for page write unlock while reading cold page 
from disk



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

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

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

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


commit 8754af65f6ad5f5cae0f78f0b16bf61c7712d862
Author: ascherbakoff 
Date:   2018-09-02T16:53:33Z

IGNITE-9445 wip.

commit 988caf6f21d89742fd13b2cec3be3d88d5389220
Author: ascherbakoff 
Date:   2018-09-02T17:03:58Z

IGNITE-9445 wip.

commit 2abb9ade558f7146cc5fd292119a5c74692482cd
Author: Aleksei Scherbakov 
Date:   2018-09-06T13:50:05Z

IGNITE-9445 wip.

commit 6750579ad6b0c1f1788d3b9fb60a50d516e64b4e
Author: Aleksei Scherbakov 
Date:   2018-09-07T16:49:43Z

IGNITE-9445 wip.

commit 29fe6c775e490bcd5e15c2655c2aca69f6164623
Author: Aleksei Scherbakov 
Date:   2018-09-10T07:29:59Z

IGNITE-9445 wip.

commit ecfb812302f8bc7a13c2fce14a49cd6395efb597
Author: Aleksei Scherbakov 
Date:   2018-09-10T07:30:30Z

IGNITE-9445 wip.




---

Re: IoC/DI support in Apache Ignite.NEt

[Alexey Goncharuk]

Hello Artyom,

Welcome to the Apache Ignite community! I've added you to the list of
contributors, you should now be able to assign tickets to yourself.

Get familiar with Apache Ignite development process described here:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Instructions on how to contribute can be found here:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

Project setup in Intellij IDEA:
https://cwiki.apache.org/confluence/display/IGNITE/Project+Setup

--AG

вс, 9 сент. 2018 г. в 15:20, Artyom Sokolov :

> Hello,
>
> I would like to start implementing IoC/DI support (Autofac, Castle Windsor,
> etc.) in Apache Ignite.NET.
>
> Please add me as a contributor in JIRA, so I could create ticket and start
> working on this.
>
> My JIRA username is applicazza.
>
> Cheers,
> Artyom.
>

Re: IGNITE-7482 Cursor in TextQuery fetches all data in first call to next() or hasNext()

[Alexey Goncharuk]

Hi,

Please send your jira account ID so we can add you to the contributors
list. Then you will be able to assign tickets to yourself and contribute to
the project according to the process.

You can get more info here:

https://cwiki.apache.org/confluence/display/IGNITE/Development+Process
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute

--AG

пн, 10 сент. 2018 г. в 9:16, Tâm Nguyễn Mạnh :

> Hi,
> I have not been assigned yet. But i really want to.
>
> On Fri, Sep 7, 2018 at 4:13 PM Ilya Kasnacheev 
> wrote:
>
> > Hello!
> >
> > Can you please frame it as Github pull request as per our process? Do you
> > have ticket for that?
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > пт, 7 сент. 2018 г. в 5:08, Tâm Nguyễn Mạnh  >:
> >
> > >
> > >
> >
> modules\indexing\src\main\java\org\apache\ignite\internal\processors\query\h2\opt\GridLuceneIndex.java
> > > ```java
> > > /*
> > >  * Licensed to the Apache Software Foundation (ASF) under one or more
> > >  * contributor license agreements.  See the NOTICE file distributed
> with
> > >  * this work for additional information regarding copyright ownership.
> > >  * The ASF licenses this file to You under the Apache License, Version
> > 2.0
> > >  * (the "License"); you may not use this file except in compliance with
> > >  * the License.  You may obtain a copy of the License at
> > >  *
> > >  *  http://www.apache.org/licenses/LICENSE-2.0
> > >  *
> > >  * Unless required by applicable law or agreed to in writing, software
> > >  * distributed under the License is distributed on an "AS IS" BASIS,
> > >  * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> > implied.
> > >  * See the License for the specific language governing permissions and
> > >  * limitations under the License.
> > >  */
> > >
> > > package org.apache.ignite.internal.processors.query.h2.opt;
> > >
> > > import java.io.IOException;
> > > import java.util.Collection;
> > > import java.util.concurrent.atomic.AtomicLong;
> > > import org.apache.ignite.IgniteCheckedException;
> > > import org.apache.ignite.internal.GridKernalContext;
> > > import org.apache.ignite.internal.processors.cache.CacheObject;
> > > import org.apache.ignite.internal.processors.cache.CacheObjectContext;
> > > import
> > > org.apache.ignite.internal.processors.cache.version.GridCacheVersion;
> > > import
> > > org.apache.ignite.internal.processors.query.GridQueryIndexDescriptor;
> > > import
> > org.apache.ignite.internal.processors.query.GridQueryTypeDescriptor;
> > > import org.apache.ignite.internal.util.GridAtomicLong;
> > > import org.apache.ignite.internal.util.GridCloseableIteratorAdapter;
> > > import org.apache.ignite.internal.util.lang.GridCloseableIterator;
> > > import org.apache.ignite.internal.util.offheap.unsafe.GridUnsafeMemory;
> > > import org.apache.ignite.internal.util.typedef.internal.U;
> > > import org.apache.ignite.lang.IgniteBiTuple;
> > > import org.apache.ignite.spi.indexing.IndexingQueryFilter;
> > > import org.apache.ignite.spi.indexing.IndexingQueryCacheFilter;
> > > import org.apache.lucene.analysis.standard.StandardAnalyzer;
> > > import org.apache.lucene.document.Document;
> > > import org.apache.lucene.document.Field;
> > > import org.apache.lucene.document.LongField;
> > > import org.apache.lucene.document.StoredField;
> > > import org.apache.lucene.document.StringField;
> > > import org.apache.lucene.document.TextField;
> > > import org.apache.lucene.index.DirectoryReader;
> > > import org.apache.lucene.index.IndexReader;
> > > import org.apache.lucene.index.IndexWriter;
> > > import org.apache.lucene.index.IndexWriterConfig;
> > > import org.apache.lucene.index.Term;
> > > import org.apache.lucene.queryparser.classic.MultiFieldQueryParser;
> > > import org.apache.lucene.search.BooleanClause;
> > > import org.apache.lucene.search.BooleanQuery;
> > > import org.apache.lucene.search.IndexSearcher;
> > > import org.apache.lucene.search.NumericRangeQuery;
> > > import org.apache.lucene.search.Query;
> > > import org.apache.lucene.search.ScoreDoc;
> > > import org.apache.lucene.search.TopDocs;
> > > import org.apache.lucene.util.BytesRef;
> > > import org.h2.util.JdbcUtils;
> > > import org.jetbrains.annotations.Nullable;
> > >
> > > import static
> > > org.apache.ignite.internal.processors.query.QueryUtils.KEY_FIELD_NAME;
> > > import static
> > > org.apache.ignite.internal.processors.query.QueryUtils.VAL_FIELD_NAME;
> > >
> > > /**
> > >  * Lucene fulltext index.
> > >  */
> > > public class GridLuceneIndex implements AutoCloseable {
> > > /** Field name for string representation of value. */
> > > public static final String VAL_STR_FIELD_NAME = "_gg_val_str__";
> > >
> > > /** Field name for value version. */
> > > public static final String VER_FIELD_NAME = "_gg_ver__";
> > >
> > > /** Field name for value expiration time. */
> > > public static final String EXPIRATION_TIME_FIELD_NAME =
> > > "_gg_expires__";
> > >
> > >  

Re: Critical worker threads liveness checking drawbacks

[Maxim Muzafarov]

I think we should find exact answers to these questions:
 1. What `critical` issue exactly is?
 2. How can we find critical issues?
 3. How can we handle critical issues?

First,
 - Ignore uninterruptable actions (e.g. worker\service shutdown)
 - Long I/O operations (should be a configurable timeout for each type of
usage)
 - Infinite loops
 - Stalled\deadlocked threads (and\or too many parked threads, exclude I/O)

Second,
 - The working queue is without progress (e.g. disco, exchange queues)
 - Work hasn't been completed since the last heartbeat (checking milestones)
 - Too many system resources used by a thread for the long period of time
(allocated memory, CPU)
 - Timing fields associated with each thread status exceeded a maximum time
limit.

Third (not too many options here),
 - `log everything` should be the default behaviour in all these cases,
since it may be difficult to find the cause after the restart.
 - Wait some interval of time and kill the hanging node (cluster should be
configured stable enough)

Questions,
 - Not sure, but can workers miss their heartbeat deadlines if CPU loads up
to 80%-90%? Bursts of momentary overloads can be
expected behaviour as a normal part of system operations.
 - Why do we decide that critical thread should monitor each other? For
instance, if all the tasks were blocked and unable to run,
node reset would never occur. As for me, a better solution is to use a
separate monitor thread or pool (maybe both with software
and hardware checks) that not only checks heartbeats but monitors the
other system as well.

On Mon, 10 Sep 2018 at 00:07 David Harvey  wrote:

> It would be safer to restart the entire cluster than to remove the last
> node for a cache that should be redundant.
>
> On Sun, Sep 9, 2018, 4:00 PM Andrey Gura  wrote:
>
> > Hi,
> >
> > I agree with Yakov that we can provide some option that manage worker
> > liveness checker behavior in case of observing that some worker is
> > blocked too long.
> > At least it will  some workaround for cases when node fails is too
> > annoying.
> >
> > Backups count threshold sounds good but I don't understand how it will
> > help in case of cluster hanging.
> >
> > The simplest solution here is alert in cases of blocking of some
> > critical worker (we can improve WorkersRegistry for this purpose and
> > expose list of blocked workers) and optionally call system configured
> > failure processor. BTW, failure processor can be extended in order to
> > perform any checks (e.g. backup count) and decide whether it should
> > stop node or not.
> > On Sat, Sep 8, 2018 at 3:42 PM Andrey Kuznetsov 
> wrote:
> > >
> > > David, Yakov, I understand your fears. But liveness checks deal with
> > > _critical_ conditions, i.e. when such a condition is met we conclude
> the
> > > node as totally broken, and there is no sense to keep it alive
> regardless
> > > the data it contains. If we want to give it a chance, then the
> condition
> > > (long fsync etc.) should not considered as critical at all.
> > >
> > > сб, 8 сент. 2018 г. в 15:18, Yakov Zhdanov :
> > >
> > > > Agree with David. We need to have an opporunity set backups count
> > threshold
> > > > (at runtime also!) that will not allow any automatic stop if there
> > will be
> > > > a data loss. Andrey, what do you think?
> > > >
> > > > --Yakov
> > > >
> > >
> > >
> > > --
> > > Best regards,
> > >   Andrey Kuznetsov.
> >
>
-- 
--
Maxim Muzafarov