[jira] [Created] (IGNITE-9846) Web console: allow to $inject before function definition
Ilya Borisov created IGNITE-9846: Summary: Web console: allow to $inject before function definition Key: IGNITE-9846 URL: https://issues.apache.org/jira/browse/IGNITE-9846 Project: Ignite Issue Type: Improvement Components: wizards Reporter: Ilya Borisov Assignee: Andrey Novikov The issue: DI $inject property can't be set before function definition because of ESLint rules. This makes code harder to maintain and more error-prone. What to do: Loosen ESLint appropriate rules (probably no-use-before-define). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Python thin client
Stepan! Please tell me one thing about how you created the environment for your benchmarks, namely: how did you install the Python client. Did you just do `pip install pyignite`, or did you pull my working branch from the downstream repository and did `pip install -e ignite/modules/platforms/python`? I highly recommend the latter, because PyPI version do not yet include the latest improvements I did thanks to Dmitriy “qvad” Sherstobitov. These improvements can have a noticeable positive effect on speed. Dmitry On 10/10/18 11:06 PM, Степан Пильщиков wrote: Dmitry, Thanks for review Agree with all suggestions. Made and run new benches without any redundant operations (prints, time calculation), only with "put" in "while true" cycle (almost) Case description, environment, results and code in ticket https://issues.apache.org/jira/browse/IGNITE-9824 (last comment) Please review new metrics Because picture is not changed so much, python still have performance issues
[jira] [Created] (IGNITE-9845) Web Console: Add support of two way ssl authentication in Web Console agent
Andrey Novikov created IGNITE-9845: -- Summary: Web Console: Add support of two way ssl authentication in Web Console agent Key: IGNITE-9845 URL: https://issues.apache.org/jira/browse/IGNITE-9845 Project: Ignite Issue Type: Improvement Components: wizards Affects Versions: 2.6 Reporter: Andrey Novikov Fix For: 2.7 RestExecutor should not be shared between different users requests in case of two way ssl authentication: * For each token with ssl we need create separated RestExecutor and set up socketFactory and trustManager. * RestExecutor should be removed if token expired. Add program arguments for passing client certificate, client password, trust store, trust store password for metrics collection task in agent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
hi folks
jus trying 2 understand the proj 4now.. hope i can help soon... ignite is great! cheers
Re: Apache Ignite 2.7. Last Mile
Vladimir Ozerov, Can you help with the unassigned MVCC tickets? D. On Wed, Oct 10, 2018 at 3:32 AM Nikolay Izhikov wrote: > Hello, Igniters. > > I list all contributors that assigned to the 2.7 tickets. > If you can help them to finish that tickets - please, do. > Assigners, if you need any help - please, respond to this thread. > > NOTE: We have 6 Unassigned tickets for 2.7. Let's start work on it! > > Peter Ivanov - IGNITE-9559, IGNITE-9583, IGNITE-9685, IGNITE-9823 > Andrey Kuznetsov - IGNITE-9737, IGNITE-9710 > Taras Ledkov - IGNITE-9171 > Alexey Goncharuk - IGNITE-9784 > Dmitriy Govorukhin - IGNITE-9550 > Igor Seliverstov - IGNITE-9749 > Dmitry Melnichuk - IGNITE-7782 > Alexey Platonov- IGNITE-9726 > Ivan Pavlukhin - IGNITE-5935 > Yury Babak - IGNITE-8670 > Roman Kondakov - IGNITE-7953, IGNITE-9446 > Maxim Pudov- IGNITE-9126 > Alexey Stelmak - IGNITE-9776 > Alexey Kuznetsov - IGNITE-7926 > > Unassigned tickets: > > IGNITE-9781 - JDK11: SSL handshake is failed > IGNITE-9620 - MVCC: select throwing `Transaction is already completed` > exception after mvcc missmatch > IGNITE-9292 - MVCC SQL: Unexpected state exception when updating backup > IGNITE-9663 - MVCC: Data node failure can cause TX hanging. > IGNITE-9724 - MVCC SQL: Test > CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed > hangs sporadically. > IGNITE-9133 - MVCC: Proper empty DHT transactions handling. >
[GitHub] ignite pull request #4951: IGNITE-9583 PHP thin: php directory should be inc...
GitHub user vveider opened a pull request: https://github.com/apache/ignite/pull/4951 IGNITE-9583 PHP thin: php directory should be included in binary release You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9583 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4951.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 #4951 commit d7cb94b0476514394f46b8801fdd5eb3ed1782fe Author: Peter Ivanov Date: 2018-10-10T19:56:29Z IGNITE-9583 PHP thin: php directory should be included in binary release ---
[GitHub] zzzadruga opened a new pull request #34: IGNITE-9833 Update Master Trends metrics
zzzadruga opened a new pull request #34: IGNITE-9833 Update Master Trends metrics URL: https://github.com/apache/ignite-teamcity-bot/pull/34 Update Master Trends metrics: add total run time (duration) and number of runs 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] asfgit closed pull request #33: PR Check stages added to UI
asfgit closed pull request #33: PR Check stages added to UI URL: https://github.com/apache/ignite-teamcity-bot/pull/33 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] dspavlov opened a new pull request #33: PR Check stages added to UI
dspavlov opened a new pull request #33: PR Check stages added to UI URL: https://github.com/apache/ignite-teamcity-bot/pull/33 Phase 1 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
[jira] [Created] (IGNITE-9844) Replace action in pessimistic transaction makes value unwrap and causes ClassNotFoundException
Mikhail Cherkasov created IGNITE-9844:
-
Summary: Replace action in pessimistic transaction makes value
unwrap and causes ClassNotFoundException
Key: IGNITE-9844
URL: https://issues.apache.org/jira/browse/IGNITE-9844
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.6
Reporter: Mikhail Cherkasov
Attachments: SimpleTest.java
The problem can be reproduced only if you replace the existing value in a cache
inside pessimistic transaction and server node doesn't have the class for the
value which the node already has in the cache.
The reproducer is attached, please make sure that you run server node without
model class in class path.
Stack trace:
{code:java}
[2018-10-10 10:16:31,828][ERROR][pub-#52%grid_0%][GridJobWorker] Failed to
execute job [jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
ses=GridJobSessionImpl [ses=GridTaskSessionImpl
[taskName=class_not_found.SimpleTest$Task, dep=GridDeployment
[ts=1539191791633, depMode=SHARED, clsLdr=GridDeploymentClassLoader
[id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
nodeLdrMap=HashMap
{c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false],
clsLdrId=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, userVer=0,
loc=false, sampleClsName=class_not_found.SimpleTest$Task,
pendingUndeploy=false, undeployed=false, usage=1]SharedDeployment [rmv=false,
super=], taskClsName=class_not_found.SimpleTest$Task,
sesId=f6acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b,
startTime=1539191791465, endTime=9223372036854775807,
taskNodeId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
clsLdr=GridDeploymentClassLoader
[id=db2aafe5661-f793ea41-94c4-4ae0-8276-8cc771e48fa9, singleNode=false,
nodeLdrMap=HashMap
{c681a6d3-e7ab-4516-9931-e817e77cac5b=96acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b},
p2pTimeout=5000, usrVer=0, depMode=SHARED, quiet=false], closed=false,
cpSpi=null, failSpi=null, loadSpi=null, usage=1, fullSup=false, internal=false,
topPred=null, subjId=c681a6d3-e7ab-4516-9931-e817e77cac5b,
mapFut=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
hash=550280323]IgniteFuture [orig=], execName=null],
jobId=07acafe5661-c681a6d3-e7ab-4516-9931-e817e77cac5b]]
class org.apache.ignite.IgniteException:
class_not_found.SimpleTest$MyDomainObject
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$C2.execute(GridClosureProcessor.java:1858)
at
org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6797)
at
org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
at
org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at
org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1191)
at
org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1923)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
class_not_found.SimpleTest$MyDomainObject
at
org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:707)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1757)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1716)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:798)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
at
org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
at
org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
at
[GitHub] ignite pull request #4949: IGNITE-9559 Node.js thin: nodejs directory should...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4949 ---
[GitHub] ignite pull request #4950: IGNITE-9247: CPP Thin: implemented operations on ...
GitHub user isapego opened a pull request: https://github.com/apache/ignite/pull/4950 IGNITE-9247: CPP Thin: implemented operations on multiple keys and values You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9247 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4950.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 #4950 commit 95ade4afb96b5f6acd23f8db309500dc1dd65679 Author: Igor Sapego Date: 2018-09-25T15:15:40Z IGNITE-9247: Added a test for iterator GetAll commit 7ae28d2b7f801d3708d0540e52d5f9427a7b9e61 Author: Igor Sapego Date: 2018-09-25T15:22:58Z IGNITE-9247: Added test for GetAll with containers commit d85a1ab074d390fcc0c5e68508918c67060f446b Author: Igor Sapego Date: 2018-09-25T15:37:42Z IGNITE-9247: Implemented GetAll method stubs commit a14889c4cde0f52f492c2b2338e091cd5b378aba Author: Igor Sapego Date: 2018-09-26T09:13:38Z IGNITE-9247: Implemented WritableSequenceImpl commit 1fc4a02130a7a6dcf8838e83d1bd8bfa7a8e27b8 Author: Igor Sapego Date: 2018-09-28T12:29:54Z IGNITE-9247: Implemented ReadableMapImpl commit 5ec708bc01f2bc42eb2d697300e4122ac7ee34f2 Author: Igor Sapego Date: 2018-10-09T13:04:39Z IGNITE-9247: Further progress commit 9fe6504aed85678c5325a256668ddb7a2fb5516d Author: Igor Sapego Date: 2018-10-09T17:18:11Z IGNITE-9247: Implemented GetAll commit dd9b76c5071b4680b7b42a99ca710bf23a6a8f8c Author: Igor Sapego Date: 2018-10-10T13:48:08Z IGNITE-9247: Implemented PutAll() commit 08e06d14cda70f1bada850d1e3f74c81caa8f9a8 Author: Igor Sapego Date: 2018-10-10T15:11:43Z IGNITE-9247: Implemented RemoveAll() commit c025068e7bae4400dec7286316e3ec989663c927 Author: Igor Sapego Date: 2018-10-10T15:22:58Z IGNITE-9247: Implemented ClearAll() commit af482f181c676acad1b6eee758eda5b63e98c3ff Author: Igor Sapego Date: 2018-10-10T15:58:34Z IGNITE-9247: Implemented ContainsKeys() commit 4ed373ad8ef46eaf4546f40f5557ceb7a5fb Author: Igor Sapego Date: 2018-10-10T16:29:08Z IGNITE-9247: Implemented Replace() ---
[jira] [Created] (IGNITE-9843) IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data
Ilya Kasnacheev created IGNITE-9843: --- Summary: IgniteClientReconnectCacheQueriesFailoverTest fails: grid loses type meta without losing data Key: IGNITE-9843 URL: https://issues.apache.org/jira/browse/IGNITE-9843 Project: Ignite Issue Type: Bug Reporter: Ilya Kasnacheev
[jira] [Created] (IGNITE-9842) IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall
Ilya Kasnacheev created IGNITE-9842: --- Summary: IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall Key: IGNITE-9842 URL: https://issues.apache.org/jira/browse/IGNITE-9842 Project: Ignite Issue Type: Bug Reporter: Ilya Kasnacheev
[jira] [Created] (IGNITE-9841) SQL take lost partitions into account when persistence is enabled
Stanislav Lukyanov created IGNITE-9841: -- Summary: SQL take lost partitions into account when persistence is enabled Key: IGNITE-9841 URL: https://issues.apache.org/jira/browse/IGNITE-9841 Project: Ignite Issue Type: Bug Components: sql Reporter: Stanislav Lukyanov Attachments: IgniteSqlQueryWithLostPartitionsTest.java IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't work if persistence is enabled. E.g. if there are lost partitions then `select * from T` fails for in-memory caches (good) and silently ignores the lost partitions for persistent caches (bad). See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4937: Ignite 9606 normalize refactoring
Github user pavel-kuznetsov closed the pull request at: https://github.com/apache/ignite/pull/4937 ---
[GitHub] ignite pull request #4948: IGNITE-9606: JDBC getPrimaryKeys() returns wrong ...
GitHub user pavel-kuznetsov opened a pull request: https://github.com/apache/ignite/pull/4948 IGNITE-9606: JDBC getPrimaryKeys() returns wrong value for COLUMN_NAME You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9606-simple Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4948.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 #4948 commit 5d144b2f57933b96dc4ccb68be119f7c205bb6f7 Author: Pavel Kuznetsov Date: 2018-10-02T14:43:31Z ignite-9606: Added test that reproduces the bug. commit ee16f57dffe52fccaa6f2bba4e4546a343ca1581 Author: Pavel Kuznetsov Date: 2018-10-10T14:54:49Z ignite-9606: updated test. commit 34d70e7135e4a1548dc6a388b68148f29039cb57 Author: Pavel Kuznetsov Date: 2018-10-10T14:56:27Z ignite-9606: fixed column name. Column name now looks in the keyFieldName before returning "_KEY". ---
[GitHub] ignite pull request #4906: IGNITE-9606: JDBC getPrimaryKeys() returns wrong ...
Github user pavel-kuznetsov closed the pull request at: https://github.com/apache/ignite/pull/4906 ---
[jira] [Created] (IGNITE-9840) Possible deadlock on transactional future on client node in case of network problems or long GC pauses
Andrey Aleksandrov created IGNITE-9840:
--
Summary: Possible deadlock on transactional future on client node
in case of network problems or long GC pauses
Key: IGNITE-9840
URL: https://issues.apache.org/jira/browse/IGNITE-9840
Project: Ignite
Issue Type: Bug
Components: clients
Affects Versions: 2.6
Reporter: Andrey Aleksandrov
Fix For: 2.8
Steps to reproduce:
1)Start the server node with next timeouts. DefaultTxTimeout should be greater
than other:
{code:java}
{code}
On the server side you should create a cache with next parameters:
{code:java}
{code}
2)After that start the client with the next code:
{code:java}
IgniteCache cache = dr1Hub.getOrCreateCache("LITARGETINFO");
try (Transaction tx = dr1Hub.transactions().txStart()) {
cache.put("Key", new Object());
System.out.println("Stop me");
//here we will get long GC pause on server side
Thread.sleep(1);
// Commit the transaction.
tx.commitAsync().get();
}
{code}
On step "Stop me" you should suspend all the thread on the server side to
emulate the networking problem or long GC pause on the server side.
Finally, you will face in client node next:
{code:java}
[2018-10-10 16:46:10,157][ERROR][nio-acceptor-tcp-comm-#28%GRIDC1%][root]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
[type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
[name=grid-timeout-worker, igniteInstanceName=GRIDC1, finished=false,
heartbeatTs=1539179057570]]]
{code}
Also, the similar issue could be reproduced in 2.4. In both cases looks like we
have a deadlock during trying to display the TxEntryValueHolder. Looks like
this values are already used by the transaction with long DefaultTxTimeout .
{code:java}
java.lang.Thread.State: WAITING
at sun.misc.Unsafe.park(Unsafe.java:-1)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata0(CacheObjectBinaryProcessorImpl.java:526)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:510)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$2.metadata(CacheObjectBinaryProcessorImpl.java:193)
at
org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1265)
at org.apache.ignite.internal.binary.BinaryUtils.type(BinaryUtils.java:2407)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.rawType(BinaryObjectImpl.java:302)
at
org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:205)
at
org.apache.ignite.internal.binary.BinaryObjectExImpl.toString(BinaryObjectExImpl.java:186)
at
org.apache.ignite.internal.binary.BinaryObjectImpl.toString(BinaryObjectImpl.java:919)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.toString(TxEntryValueHolder.java:161)
...{code}
On the client side, it could be looked like a hanging transaction because we
waiting on:
{code:java}
tx.commitAsync().get();{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] ignite pull request #4909: IGNITE-9126 Update Apache Kafka dependency
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4909 ---
[GitHub] ignite pull request #4947: IGNITE-9550 Get operation returns null for a lost...
GitHub user dgovorukhin opened a pull request: https://github.com/apache/ignite/pull/4947 IGNITE-9550 Get operation returns null for a lost partition with READ_SAFE policy You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9550-dg Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4947.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 #4947 commit 89b4fc6b56743f580a461fe699d318ad142d7012 Author: Dmitriy Govorukhin Date: 2018-10-10T13:54:16Z IGNITE-9550 Fix Get operation returns null for a lost partition with READ_SAFE policy ---
[GitHub] ignite pull request #4946: Ignite 9771
GitHub user SGrimstad opened a pull request: https://github.com/apache/ignite/pull/4946 Ignite 9771 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite IGNITE-9771 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4946.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 #4946 commit 4a832136c752fbf980b5f9a8fdc049b2c17e8fe7 Author: ezhuravl Date: 2018-09-21T08:44:11Z wip commit 1f82d59126f96d62ae02794e6cb658c114c2bf21 Author: SGrimstad Date: 2018-09-28T12:30:03Z Merge branch 'master' into ignite-6677 commit 4386ea363b1735ec4cf177b6b610a7cb39e613f3 Author: SGrimstad Date: 2018-10-09T15:10:55Z IGNITE-6677 implementation commit e8a9d57bdd5fcd90e7345b8c72d92c31e1e1e2b2 Author: SGrimstad Date: 2018-10-09T15:26:26Z Merge branch 'master' into ignite-6677 commit fe58835b14d0fe129affd024f76b984c093d5cd9 Author: SGrimstad Date: 2018-10-10T06:46:29Z Merge branch 'master' into ignite-6677 commit dbd16209f58ebdb281044466566487743782ab0b Author: SGrimstad Date: 2018-10-10T13:42:42Z IGNITE-9771 implementation ---
Re: [Discussion] Create new mailing list notifications@ and forward GitBox comments to it
Ok, let's keep it as is now. If no one is interested in this removal, so probably is not an issue. Anyway, Dmitrii Ryabov, thank you for contacting Infra. ср, 3 окт. 2018 г. в 18:47, Dmitriy Pavlov : > Sorry, the previous email was not clear and not finished: Main repository > related emails from g...@git.apache.org (GitHub) will remain as is, so > regular PRs create and close will be forwarded as is. > > If someone wants to redirect main repo-related PR notifications (as it was > suggested in Remove Bots from dev list), please start a separate > discussion. As part of this discussion, I would like we come to an > agreement about the creation of the list and forwarding TC Bot review > comments there. > > ср, 3 окт. 2018 г. в 18:42, Dmitriy Pavlov : > >> Yes, by Igniters, who will subscribe to it using >> notifications-subscr...@ignite.apache.org . I'm going to subscribe. >> >> I've heard complains about the volume of emails here, so it could be >> useful to remove this one chunk from the dev. >> >> For the record: >> I suggest forwarding only emails from g...@apache.org (GitBox, TC Bot >> repository). >> g...@git.apache.org (GitHub), so regular PRs to Ignite will be forwarded >> as is. >> >> ср, 3 окт. 2018 г. в 18:36, Petr Ivanov : >> >>> Will that list be read at all? >>> >>> >>> >>> > On 3 Oct 2018, at 17:24, Dmitriy Pavlov wrote: >>> > >>> > Hi Ignite Enthusiasts, >>> > >>> > I would like to decrease pressure to dev list by removing GitBox >>> comments >>> > from being forwarded to dev@ >>> > >>> > I suggest we will create new list notificati...@ignite.apache.org and >>> setup >>> > GitBox comments to be sent to it instead of dev list. >>> > >>> > Dmitrii Ryabov contacted Infra about disabling comments >>> > https://issues.apache.org/jira/browse/INFRA-17032 (BTW, thank you, >>> Dmitrii! >>> > ), but it is not possible to just disable, it can be forwarded to a >>> > separate list. >>> > >>> > Please share your vision about this change. I believe Ignite developers >>> > don't need to read each PR comment in TC bot, so separate list for >>> these >>> > notifications may be a solution. >>> > >>> > Sincerely, >>> > Dmitriy Pavlov >>> >>>
Re: [TC Bot] Proposal of improvement
Hi Igniters, I'm glad to announce that one more change is done related to PR easy navigation. Now TC bot detects if there was a runAll and shows button <> only if there is some completed build. It is not a final-state of UI, but currently, I think https://issues.apache.org/jira/browse/IGNITE-9800 is done. In pair with the contribution done by Nikolay Kulagin ( https://issues.apache.org/jira/browse/IGNITE-9770 ), it allows navigating from the main screen to getting bot Visa without tons of data to be entered. I've documented flow as graph here: https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+Teamcity+Bot#ApacheIgniteTeamcityBot-HowtocheckaPRwiththeTCBot - this to be enhanced by automatic scenarios once it is available in simple navigation mode. Thanks to everyone involved. I hope I will have spare cycles to continue to contribute. Sincerely, Dmitriy Pavlov пн, 8 окт. 2018 г. в 15:39, Dmitriy Pavlov : > Hi Nikolay, Igniters, > > Please check the newest version of the Bot. > > It contains huge UI refactoring and simplified navigation to open PR and > its test results. Just couple seconds is needed to find a PR now. > > Thanks to Dmitrii Ryabov, who developed initial GitHub integration. It is > more or less reused, and PRs are cached in the Ignite instance. > > As always, I appreciate the feedback. > > Sincerely, > Dmitriy Pavlov > > вт, 25 сент. 2018 г. в 13:00, Dmitriy Pavlov : > >> JIRA ticket is some elementary change that needs to be reviewed. We don't >> review the patch, we review ticket (with motivation, implementation >> details, history of discussion), so reviewer will look at a ticket first. >> >> PR does not have a mark, that it is ready to be merged. Some PRs are >> created just for research, but Patch Available ticket is something that is >> ready to be in the product. >> >> So if we concentrate on a ticket, from the point of view of a new >> contributor, >> - he or she creates a branch, PR and sets ticket to PA, >> - and the bot will do all necessary mechanic work. >> >> No issues with asking newcomers to run (proper) tests. A newbie needs >> only to follow the first steps in How To Contribute. A reviewer will see a >> ticket with the bot Visa after 2-3 hours after setting of PA state. >> >> But only one concern I have here, I'm not sure I have spare cycles to do >> this project. I'd rather move towards it in step-by-step mode, doing small >> changes in each version. Any assistance is appreciated here. >> >> вт, 25 сент. 2018 г. в 11:25, Nikolay Izhikov : >> >>> Hello, Dmitriy >>> >>> > What about the case when committer creates ignite-9679 branch and >>> tests it> without PR? >>> >>> It means, committer is experienced enough to run tests via Team City >>> interface :). >>> >>> > So scanning seems to be possible only in JIRA >>> >>> I don't understand you here. >>> You can retrieve comments filtered by *date*. >>> You don't have to scan all 1000 PR's one by one. >>> Anyway 1000 PR doesn't sound like big issue for me. >>> >>> My vote goes strong to GiHub user interface. >>> I think we should have closer integration with GitHub, not Jira. >>> >>> Jira is about tickets and project management. >>> GitHub is about code, commits and patches. >>> We test patch, not ticket. >>> >>> >>> В Вт, 25/09/2018 в 00:06 +0300, Dmitriy Pavlov пишет: >>> > Hi Nikolay, >>> > >>> > What about the case when committer creates ignite-9679 branch and >>> tests it >>> > without PR? >>> > >>> > We have 1100+ open PRs and less than 100 open tickets. So scanning >>> seems to >>> > be possible only in JIRA. Mention probably will work for GitHub, but it >>> > needs to be researched. >>> > >>> > Two open PRs is not a valid situation in the majority of cases and How >>> To >>> > Contribute asks to avoid it. The bot can ignore closed PRs and the bot >>> can >>> > expect there is only one open PR per ticket. >>> > >>> > Sincerely, >>> > Dmitriy Pavlov >>> > >>> > пн, 24 сент. 2018 г. в 23:41, Nikolay Izhikov : >>> > >>> > > Hello, Dmitriy. >>> > > >>> > > > But it could be a lot of work to handle mentions (probably from the >>> > > >>> > > email> account and inbox). >>> > > >>> > > Actually, it can be done via GitHub REST API [1]. >>> > > It has 'since' param, so getting new GitHub comments is a very basic >>> task. >>> > > >>> > > > Patch available ticket >>> > > >>> > > I think we shouldn't take a ticket as an entity that should be >>> tested. >>> > > For me, it's a PR. >>> > > >>> > > Moreover, it's a common case when we have several PR in a ticket. >>> > > And it's a common case when both of them has to be tested. >>> > > >>> > > My vote goes to the closer integration with GitHub. >>> > > >>> > > [1] >>> > > >>> https://developer.github.com/v3/pulls/comments/#list-comments-in-a-repository >>> > > >>> > > В Пн, 24/09/2018 в 22:36 +0300, Dmitriy Pavlov пишет: >>> > > > Hi Nikolay, >>> > > > >>> > > > The idea makes perfect sense for me, and we should definitely take >>> the >>> > > >>> > > best >>> > >
Re: Python thin client
Dmitry,
Thanks for review
Agree with all suggestions.
Made and run new benches without any redundant operations (prints, time
calculation), only with "put" in "while true" cycle (almost)
Case description, environment, results and code in ticket
https://issues.apache.org/jira/browse/IGNITE-9824 (last comment)
Please review new metrics
Because picture is not changed so much, python still have performance issues
ср, 10 окт. 2018 г. в 12:30, Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com>:
> Stepan!
>
> Can you please update the benchmarks based on my suggestions earlier in
> this thread: use a cleaner time profiling for the loop, remove
> unnecessary operations (string formatting, rounding operations), stick
> to the primitive int value for put operations (agree with Vladimir,
> let's keep it simple). And let me know the results.
>
> On 10/10/18 5:46 PM, Vladimir Ozerov wrote:
> > Hi Dmitry,
> >
> > I agree with your comments on benchmarking code. As more fair
> > alternative we may measure time of loading N elements into the cache, so
> > that it will be necessary to call time() only twice. However, provided
> > that we have real network here, and according to numbers one PUT in
> > Python client requires about 0.3 msec, I hardly can imagine that call to
> > time() or round() may dominate in that response time. But I said, we can
> > easily rule that out by slight benchmark rewrite.
> >
> > As far as serialization, I would prefer to keep primitive objects at the
> > moment, because AFAIK the purpose of the benchmark was to assess
> > underlying infrastructure, looking for some obvious performance issues.
> > Every platform have sockets which use more or less the same API of
> > underlying OS. To the contrast, performance of serialization mechanics
> > may differ widely between platforms depending on implementation. E.g. in
> > Java we spend a lot of time on fine-grained tuning, applied a lot of
> > speculative optimizations. Add to this JIT nature of Java, and you will
> > hardly ever beat Java serialization engine from any interpreted
> > language. So primitive data types make good sense to me.
> >
> > At this point our goal is not make Python equally fast with other
> > platforms, but rather to understand why is it slower than others. Ignite
> > is a product which brings speed to end users. If they do no have speed,
> > they will not use Ignite. So performance questions are always of great
> > importance for us.
> >
> > Vladimir.
> >
> > On Wed, Oct 10, 2018 at 9:57 AM Dmitry Melnichuk
> > mailto:dmitry.melnic...@nobitlost.com>>
>
> > wrote:
> >
> > Hi, Stepan!
> >
> > I looked at the benchmark code and the overall methodics, discussed
> it
> > with fellow programmers, and came up with basically two remarks.
> >
> > First of all, I think, the key for the good (or, at least,
> > unobjectionable) measurement is to isolate the object being measured
> > from the influence of the measurement tool. The usual pattern we use
> in
> > Python looks like:
> >
> > ```
> > from time import time
> >
> >
> > bench_start = time()
> >
> > for _ in range(number_of_tests):
> > do_test()
> >
> > bench_end = time()
> >
> > print('Performance is {} tests per second'.format(
> > number_of_tests / (bench_end - bench_start)
> > ))
> > ```
> >
> > I think, you got the idea: the measurement consists almost solely of
> > the
> > time taken by our subject function `do_test`. As few other code as
> > possible influence the result.
> >
> > Now, let's take a look at your code:
> >
> > https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
> >
> > Ideally, the `while` loop should include only `cache.put(last_key,
> > some_precomputed_value)`. But instead it also includes:
> >
> > - a series of the `time()` calls, which could be mostly excluded from
> > the measured time, if the measurement done right; each call is
> probably
> > addresses the HPET device, or network time, or both,
> >
> > - some floating-point calculations, including `round()`, which is
> > hardly
> > necessary,
> >
> > - formatting and output of the intermediate result.
> >
> > I suppose the measurement influence can be quite significant here,
> but
> > it is at least more or less constant for each test.
> >
> > But if we look at the other benchmarks:
> >
> > https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
> > [Node.js]
> > https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80
> > [PHP]
> > https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce
> > [Java]
> >
> > The extra code that influence the measurement is not equivalent
> across
> > all platforms. For example, PHP's `time()` is most probably lighter
> > than
> > Python `time()`, since it do not give out milliseconds and may
> address
> > RTC, not
[GitHub] ignite pull request #4945: IGNITE-9685 [ML] Add ignite-tensorflow module to ...
GitHub user vveider opened a pull request: https://github.com/apache/ignite/pull/4945 IGNITE-9685 [ML] Add ignite-tensorflow module to build artifacts You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9685 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4945.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 #4945 commit c96dc89089dd5312234a5832d7fc1a453ec5fe9b Author: Peter Ivanov Date: 2018-10-10T12:56:54Z IGNITE-9685 [ML] Add ignite-tensorflow module to build artifacts ---
[GitHub] ignite pull request #4944: IGNITE-9430 Introduce IGNITE_REBALANCE_THROTTLE_O...
GitHub user macrergate opened a pull request: https://github.com/apache/ignite/pull/4944 IGNITE-9430 Introduce IGNITE_REBALANCE_THROTTLE_OVERRIDE system property You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9430 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4944.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 #4944 commit e6cdcd9cddb9af2de30df8399d84e2f226ac0e48 Author: macrergate Date: 2018-10-10T12:44:31Z IGNITE-9430 Introduce IGNITE_REBALANCE_THROTTLE_OVERRIDE system property ---
[GitHub] ignite pull request #4856: IGNITE-9550 ready future exchange actions
Github user dgovorukhin closed the pull request at: https://github.com/apache/ignite/pull/4856 ---
[GitHub] ignite pull request #4846: IGNITE-9550 Get operation returns null for a lost...
Github user dgovorukhin closed the pull request at: https://github.com/apache/ignite/pull/4846 ---
[GitHub] asfgit closed pull request #31: Ignite 9800 2 - Make navigation more easy, provide buttons only for runned build
asfgit closed pull request #31: Ignite 9800 2 - Make navigation more easy, provide buttons only for runned build URL: https://github.com/apache/ignite-teamcity-bot/pull/31 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
Re: PHP thin client
I am not sure there is an answer. This is just how we handled it before. IMO both approaches works fine. BTW, I already merged Vyacheslav's PR several hours ago. On Wed, Oct 10, 2018 at 1:24 PM Igor Sapego wrote: > Vyacheslav, > > In this case, we should do the same with all existing doxygen > files, not only this one (see files with .dxg extension) > > Vova, Pavel, > > Were there historically any reasons to exclude doxygen files > from check instead of adding a license header? > > Best Regards, > Igor > > > On Tue, Oct 9, 2018 at 11:49 PM Vyacheslav Daradur > wrote: > >> Great work guys, thanks! >> >> I've noticed TC fails in the build plan "Licenses Headers" which Igor >> have fixed already by excluding Doxyfile from checking. >> >> I've filled a ticket [1] and I'd suggest fixing the test in another >> way by adding the license header to Doxyfile. >> >> Igor, please, have a look at prepared PR [2] (tests passed [3]). >> >> [1] https://issues.apache.org/jira/browse/IGNITE-9832 >> [2] https://github.com/apache/ignite/pull/4938/files >> [3] https://ci.ignite.apache.org/viewLog.html?buildId=2046206 >> On Tue, Oct 9, 2018 at 6:31 PM Igor Sapego wrote: >> > >> > As the seem to be everything OK with the code and tests and >> > no one had any comment for quite some time, I've merged the >> > PHP to Ignite's master. >> > >> > Great job, guys! >> > >> > >> > Best Regards, >> > Igor >> > >> > >> > On Wed, Sep 19, 2018 at 1:00 AM Prachi Garg wrote: >> > >> > > Hi Stephan, Alexey >> > > >> > > That's exactly what readme.io contains - installation instructions, >> > > configuration, and examples for key-value, sql, etc. for thin >> clients. For >> > > example, see these documentation pages for Node.js (currently hidden >> in the >> > > latest version of the doc) : >> > > >> > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client >> > > >> > > >> https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-initialization-and-configuration >> > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-key-value >> > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-sql >> > > >> https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-binary-types >> > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-security >> > > >> > > This how Python and PHP thin clients will also be documented on >> readme.io >> > > >> > > -Prachi >> > > >> > > >> > > >> > > >> > > On Tue, Sep 18, 2018 at 3:26 AM, Stepan Pilshchikov < >> > > pilshchikov@gmail.com> wrote: >> > > >> > > > > You know, I'm confused with all this documentation stuff... >> > > > > For nodejs client all docs were moved from the repo to readme.io >> but >> > > > the >> > > > > readme.md keeps the installation instructions (duplicated with >> > > > > readme.io). Probably, that's ok. >> > > > > Will add similar short readme.md to the PHP PR. >> > > > >> > > > Its good >> > > > >> > > > What i think (and how it partially now): >> > > > All user documentation should be on readme.io (how to install, use >> it, >> > > > configurate, description for examples) >> > > > All developers documentation (how to release, how to start develop) >> > > and(!) >> > > > basic description should be in repository >> > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ >> > > > >> > > >> >> >> >> -- >> Best Regards, Vyacheslav D. >> >
[GitHub] asfgit closed pull request #30: IGNITE-9805 Animation v1
asfgit closed pull request #30: IGNITE-9805 Animation v1
URL: https://github.com/apache/ignite-teamcity-bot/pull/30
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/ignite-tc-helper-web/src/main/webapp/comparison.html
b/ignite-tc-helper-web/src/main/webapp/comparison.html
index 7868f64..bc24084 100644
--- a/ignite-tc-helper-web/src/main/webapp/comparison.html
+++ b/ignite-tc-helper-web/src/main/webapp/comparison.html
@@ -4,12 +4,13 @@
Ignite Teamcity - comparison master's branch in the date
interval
-https://code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css;>
-
-https://cdn.jsdelivr.net/jquery/latest/jquery.min.js";>
+https://code.jquery.com/jquery-1.12.4.js";>
+https://code.jquery.com/ui/1.12.1/jquery-ui.js";>
https://cdn.jsdelivr.net/momentjs/latest/moment.min.js";>
https://cdn.jsdelivr.net/npm/daterangepicker/daterangepicker.min.js";>
https://cdn.jsdelivr.net/npm/daterangepicker/daterangepicker.css; />
+
+https://code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css;>
https://d3js.org/d3.v4.min.js";>
@@ -182,6 +183,7 @@
let statistics = {};
let dates = [];
+let buildIds = [];
for (let i = 0; i < prOcc.length; i++) {
statistics[prOcc[i]] = [];
@@ -190,6 +192,7 @@
for (let j = 0; j < map.length; j++) {
dates[j] = parseTime(map[j].startDate);
+buildIds[j] = map[j].buildId;
for (let i = 0; i < prOcc.length; i++) {
statistics[prOcc[i]][j] = map[j].totalProblems[prOcc[i]];
@@ -221,19 +224,19 @@
$('.title' + num).html('min - median - max');
for (let i = 0; i < prOcc.length; i++) {
-fillCellWithStatistics(prOcc[i], num, statistics, dates);
-fillCellWithStatistics(tOcc[i], num, statistics, dates);
+fillCellWithStatistics(prOcc[i], num, statistics, dates, buildIds);
+fillCellWithStatistics(tOcc[i], num, statistics, dates, buildIds);
}
}
-function fillCellWithStatistics(prefix, num, statistics, dates) {
+function fillCellWithStatistics(prefix, num, statistics, dates, buildIds) {
let result = getMinMaxMedian(statistics[prefix]);
$('#' + prefix + num).html(result.min + " - " + result.median + " - "
+ result.max);
compareAndHighlight(prefix, num, result.median);
-drawGraph(prefix, num, dates, statistics[prefix], prefix);
+drawGraph(prefix, num, dates, statistics[prefix], buildIds);
}
function compareAndHighlight(prefix, thisNum, thisMedian){
@@ -346,49 +349,58 @@
});
}
-function drawGraph(prefix, num, dates, counts, text) {
+function drawGraph(prefix, num, dates, counts, buildIds) {
let data = [];
for (let i = 0; i < dates.length; i++) {
data[i] = {};
data[i].date = dates[i];
-data[i].count = counts[i];
+data[i].value = counts[i];
+data[i].buildId = buildIds[i];
}
-svg = d3.select("#graph" + prefix + num).append("svg:svg");
-margin = {top: 20, right: 20, bottom: 30, left: 50};
-width = +500 - margin.left - margin.right;
-height = +200 - margin.top - margin.bottom;
-g = svg.append("g").attr("transform", "translate(" + margin.left + ","
+ margin.top + ")");
-x = d3.scaleTime().range([0, width]);
-y = d3.scaleLinear().range([height, 0]);
+let svg = d3.select("#graph" + prefix + num).append("svg:svg");
+let margin = {top: 20, right: 20, bottom: 30, left: 50};
+let width = +500 - margin.left - margin.right;
+let height = +200 - margin.top - margin.bottom;
+let g = svg.append("g").attr("transform", "translate(" + margin.left +
"," + margin.top + ")");
-line = d3.line()
-.curve(d3.curveBasis)
-.x(function(d) { return x(d.date); })
-.y(function(d) { return y(d.count); });
+let div = d3.select("body").append("div")
+.attr("class", "tooltip")
+.style("opacity", 0);
+
+let formatTime = d3.timeFormat("%d-%m-%Y %H:%M:%S");
+let max = d3.max(data, function(d){return parseInt(d.value)});
+let y = d3.scaleLinear()
+.domain([0, max])
+.range([height, 0]);
+let x = d3.scaleTime()
+.rangeRound([0, width]);
x.domain(d3.extent(data, function(d) { return d.date; }));
-y.domain(d3.extent(data, function(d) { return d.count; }));
-
-g.append("svg:g")
-.attr("transform", "translate(0," + height + ")")
-
[GitHub] asfgit closed pull request #27: IGNITE-9770 Add 'Re-run possible blockers' button
asfgit closed pull request #27: IGNITE-9770 Add 'Re-run possible blockers'
button
URL: https://github.com/apache/ignite-teamcity-bot/pull/27
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildInfo.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildInfo.java
deleted file mode 100644
index 9de4dd3..000
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildInfo.java
+++ /dev/null
@@ -1,81 +0,0 @@
-/*
- * 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.ci.observer;
-
-import org.apache.ignite.ci.tcmodel.result.Build;
-import org.apache.ignite.ci.user.ICredentialsProv;
-
-/**
- *
- */
-public class BuildInfo {
-/** Build. */
-public final Build build;
-
-/** Server id. */
-public final String srvId;
-
-/** */
-public final ICredentialsProv prov;
-
-/** JIRA ticket full name. */
-public final String ticket;
-
-/**
- * @param build Build.
- * @param srvId Server id.
- * @param prov Credentials.
- * @param ticket JIRA ticket name.
- */
-BuildInfo(Build build, String srvId, ICredentialsProv prov, String ticket)
{
-this.build = build;
-this.srvId = srvId;
-this.prov = prov;
-this.ticket = ticket;
-}
-
-/** {@inheritDoc} */
-@Override public boolean equals(Object o) {
-if (this == o)
-return true;
-if (o == null || getClass() != o.getClass())
-return false;
-
-BuildInfo info = (BuildInfo)o;
-
-if (!build.equals(info.build))
-return false;
-if (!srvId.equals(info.srvId))
-return false;
-if (!prov.equals(info.prov))
-return false;
-
-return ticket.equals(info.ticket);
-}
-
-/** {@inheritDoc} */
-@Override public int hashCode() {
-int res = build.hashCode();
-
-res = 31 * res + srvId.hashCode();
-res = 31 * res + prov.hashCode();
-res = 31 * res + ticket.hashCode();
-
-return res;
-}
-}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
index 8603d34..a6d302f 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildObserver.java
@@ -54,12 +54,11 @@ public void stop() {
}
/**
- * @param build Build id.
* @param srvId Server id.
* @param prov Credentials.
* @param ticket JIRA ticket name.
*/
-public void observe(Build build, String srvId, ICredentialsProv prov,
String ticket) {
-observerTask.builds.add(new BuildInfo(build, srvId, prov, ticket));
+public void observe(String srvId, ICredentialsProv prov, String ticket,
Build... builds) {
+observerTask.builds.add(new BuildsInfo(srvId, prov, ticket, builds));
}
}
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
new file mode 100644
index 000..2dd3060
--- /dev/null
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/observer/BuildsInfo.java
@@ -0,0 +1,116 @@
+/*
+ * 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
[jira] [Created] (IGNITE-9839) Web Console: Migrate to new API of RxJS
Alexey Kuznetsov created IGNITE-9839: Summary: Web Console: Migrate to new API of RxJS Key: IGNITE-9839 URL: https://issues.apache.org/jira/browse/IGNITE-9839 Project: Ignite Issue Type: Task Components: wizards Reporter: Alexey Kuznetsov Assignee: Alexander Kalinin We are using old and new API of RxJS. Lets refactor all old usages to new API. New API is more flexible, no more issues with "missing imports" and we will be able to migrate to RxJS 6.x from 5.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9838) TxStateChangeEventTest fails sometimes on TeamCity
Andrey Kuznetsov created IGNITE-9838: Summary: TxStateChangeEventTest fails sometimes on TeamCity Key: IGNITE-9838 URL: https://issues.apache.org/jira/browse/IGNITE-9838 Project: Ignite Issue Type: Test Reporter: Andrey Kuznetsov Fix For: 2.8 Both test methods may fail to acquire transaction lock. Presumably, timeout increasing can be enough to fix. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] asfgit closed pull request #32: add PR title to the PR number for autocomplete TC branch
asfgit closed pull request #32: add PR title to the PR number for autocomplete
TC branch
URL: https://github.com/apache/ignite-teamcity-bot/pull/32
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git a/ignite-tc-helper-web/src/main/webapp/index.html
b/ignite-tc-helper-web/src/main/webapp/index.html
index 3e4909b..4a1c520 100644
--- a/ignite-tc-helper-web/src/main/webapp/index.html
+++ b/ignite-tc-helper-web/src/main/webapp/index.html
@@ -47,7 +47,7 @@
I need to:
Inspect Contribution
Monitor TC state
-See test progres
+See test progress
I like old home page
diff --git a/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
b/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
index b1a925c..613e411 100644
--- a/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
+++ b/ignite-tc-helper-web/src/main/webapp/js/common-1.6.js
@@ -214,13 +214,15 @@ function tcHelperLogout() {
/**
* Change autocomplete filter to show results only when they starts from
written text.
*/
-$.ui.autocomplete.filter = function (array, term) {
-var matcher = new RegExp("^" + $.ui.autocomplete.escapeRegex(term), "i");
+function setAutocompleteFilter() {
+$.ui.autocomplete.filter = function (array, term) {
+var matcher = new RegExp("^" + $.ui.autocomplete.escapeRegex(term),
"i");
-return $.grep(array, function (value) {
-return matcher.test(value.label || value.value || value);
-});
-};
+return $.grep(array, function (value) {
+return matcher.test(value.label || value.value || value);
+});
+};
+}
var callbackRegistry = {};
@@ -278,6 +280,8 @@ function setupAutocompleteList(srvIds) {
for (let srvId of srvIds)
gitUrls.set(srvId, "");
+setAutocompleteFilter();
+
startFillAutocompleteListsProcess();
}
@@ -347,8 +351,11 @@ function _fillBranchAutocompleteList(result) {
branchesForTc[entry[0]] = [{label:"master",
value:"refs/heads/master"}];
-for (let pr of result.data)
-branchesForTc[entry[0]].push({label: pr.number, value: "pull/" +
pr.number + "/head"});
+for (let pr of result.data) {
+branchesForTc[entry[0]].push({label: pr.number + " " + pr.title,
value: "pull/" + pr.number + "/head"});
+branchesForTc[entry[0]].push({label: "pull/" + pr.number + "/head
" + pr.title,
+value: "pull/" + pr.number + "/head"});
+}
$(".branchForTc" + entry[0]).autocomplete({source:
branchesForTc[entry[0]]});
}
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 #4943: IGNITE-9133
GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/4943 IGNITE-9133 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9133 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4943.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 #4943 commit e7e76fd91268a44539f0ae7adf9ea58caaac1b0d Author: devozerov Date: 2018-10-10T10:30:29Z Test. commit 233b2501c931b71f3551ace963b926651af47a6f Author: devozerov Date: 2018-10-10T10:36:37Z WIP. commit 1539e79319ba3fd091fa7e0e4b7601af671976ec Author: devozerov Date: 2018-10-10T10:37:00Z WIP. commit ffb2e4fb617d5af4c1f88542e79dad1f884f95f4 Author: devozerov Date: 2018-10-10T11:26:34Z Done. ---
[GitHub] ignite pull request #4942: IGNITE-8936 Fixed Java version check.
GitHub user vsisko opened a pull request: https://github.com/apache/ignite/pull/4942 IGNITE-8936 Fixed Java version check. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9836 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4942.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 #4942 commit 5b8d5901ad20319f1c3181995bb8c3d6a4e8d9e5 Author: vsisko Date: 2018-10-10T10:16:35Z IGNITE-8936 Fixed Java version check. ---
[GitHub] asfgit closed pull request #29: IGNITE-9815: Muted tests shouldn't considered as blocker
asfgit closed pull request #29: IGNITE-9815: Muted tests shouldn't considered
as blocker
URL: https://github.com/apache/ignite-teamcity-bot/pull/29
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
index dcd18fb..7e49ec0 100644
---
a/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
+++
b/ignite-tc-helper-web/src/main/java/org/apache/ignite/ci/web/model/current/TestFailure.java
@@ -241,6 +241,9 @@ public void initStat(@Nullable final Function runStatSupp
public boolean isNewFailedTest() {
FailureSummary recent = histBaseBranch.recent;
+if (!Strings.isNullOrEmpty(webIssueUrl))
+return false;
+
boolean lowFailureRate = recent != null && recent.failureRate != null
&&
Float.valueOf(recent.failureRate.replace(',', '.')) < 4.;
diff --git a/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
b/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
index b61189b..e1c995c 100644
--- a/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
+++ b/ignite-tc-helper-web/src/main/webapp/js/testfails-2.1.js
@@ -627,8 +627,12 @@ function isNewFailedTest(testFail) {
if(!isDefinedAndFilled(testFail.histBaseBranch))
return true;
+if (testFail.webIssueUrl)
+return false;
+
var hist = testFail.histBaseBranch;
-if(!isDefinedAndFilled(hist.recent))
+
+if (!isDefinedAndFilled(hist.recent))
return true;
var flakyCommentsInBase =
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
Apache Ignite 2.7. Last Mile
Hello, Igniters. I list all contributors that assigned to the 2.7 tickets. If you can help them to finish that tickets - please, do. Assigners, if you need any help - please, respond to this thread. NOTE: We have 6 Unassigned tickets for 2.7. Let's start work on it! Peter Ivanov - IGNITE-9559, IGNITE-9583, IGNITE-9685, IGNITE-9823 Andrey Kuznetsov - IGNITE-9737, IGNITE-9710 Taras Ledkov - IGNITE-9171 Alexey Goncharuk - IGNITE-9784 Dmitriy Govorukhin - IGNITE-9550 Igor Seliverstov - IGNITE-9749 Dmitry Melnichuk - IGNITE-7782 Alexey Platonov- IGNITE-9726 Ivan Pavlukhin - IGNITE-5935 Yury Babak - IGNITE-8670 Roman Kondakov - IGNITE-7953, IGNITE-9446 Maxim Pudov- IGNITE-9126 Alexey Stelmak - IGNITE-9776 Alexey Kuznetsov - IGNITE-7926 Unassigned tickets: IGNITE-9781 - JDK11: SSL handshake is failed IGNITE-9620 - MVCC: select throwing `Transaction is already completed` exception after mvcc missmatch IGNITE-9292 - MVCC SQL: Unexpected state exception when updating backup IGNITE-9663 - MVCC: Data node failure can cause TX hanging. IGNITE-9724 - MVCC SQL: Test CacheMvccSelectForUpdateQueryAbstractTest.testSelectForUpdateDistributed hangs sporadically. IGNITE-9133 - MVCC: Proper empty DHT transactions handling. signature.asc Description: This is a digitally signed message part
Re: PHP thin client
Vyacheslav, In this case, we should do the same with all existing doxygen files, not only this one (see files with .dxg extension) Vova, Pavel, Were there historically any reasons to exclude doxygen files from check instead of adding a license header? Best Regards, Igor On Tue, Oct 9, 2018 at 11:49 PM Vyacheslav Daradur wrote: > Great work guys, thanks! > > I've noticed TC fails in the build plan "Licenses Headers" which Igor > have fixed already by excluding Doxyfile from checking. > > I've filled a ticket [1] and I'd suggest fixing the test in another > way by adding the license header to Doxyfile. > > Igor, please, have a look at prepared PR [2] (tests passed [3]). > > [1] https://issues.apache.org/jira/browse/IGNITE-9832 > [2] https://github.com/apache/ignite/pull/4938/files > [3] https://ci.ignite.apache.org/viewLog.html?buildId=2046206 > On Tue, Oct 9, 2018 at 6:31 PM Igor Sapego wrote: > > > > As the seem to be everything OK with the code and tests and > > no one had any comment for quite some time, I've merged the > > PHP to Ignite's master. > > > > Great job, guys! > > > > > > Best Regards, > > Igor > > > > > > On Wed, Sep 19, 2018 at 1:00 AM Prachi Garg wrote: > > > > > Hi Stephan, Alexey > > > > > > That's exactly what readme.io contains - installation instructions, > > > configuration, and examples for key-value, sql, etc. for thin clients. > For > > > example, see these documentation pages for Node.js (currently hidden > in the > > > latest version of the doc) : > > > > > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client > > > > > > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-initialization-and-configuration > > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-key-value > > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-sql > > > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-binary-types > > > https://apacheignite.readme.io/v2.6/docs/nodejs-thin-client-security > > > > > > This how Python and PHP thin clients will also be documented on > readme.io > > > > > > -Prachi > > > > > > > > > > > > > > > On Tue, Sep 18, 2018 at 3:26 AM, Stepan Pilshchikov < > > > pilshchikov@gmail.com> wrote: > > > > > > > > You know, I'm confused with all this documentation stuff... > > > > > For nodejs client all docs were moved from the repo to readme.io > but > > > > the > > > > > readme.md keeps the installation instructions (duplicated with > > > > > readme.io). Probably, that's ok. > > > > > Will add similar short readme.md to the PHP PR. > > > > > > > > Its good > > > > > > > > What i think (and how it partially now): > > > > All user documentation should be on readme.io (how to install, use > it, > > > > configurate, description for examples) > > > > All developers documentation (how to release, how to start develop) > > > and(!) > > > > basic description should be in repository > > > > > > > > > > > > > > > > > > > > -- > > > > Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/ > > > > > > > > > > > -- > Best Regards, Vyacheslav D. >
[GitHub] ignite pull request #4941: IGNITE-9680 Status output component
GitHub user Klaster1 opened a pull request: https://github.com/apache/ignite/pull/4941 IGNITE-9680 Status output component [See the issue](https://issues.apache.org/jira/browse/IGNITE-9680). You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-wc-592 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4941.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 #4941 commit edf2db5b692d99774c8525794762559f01ccade3 Author: Andrey Novikov Date: 2017-11-17T11:05:41Z WC-300 WIP. commit 085d8d2c916e1cd182818dae45459f70c09025f2 Author: Andrey Novikov Date: 2017-11-20T02:59:17Z WC-300 Merge master into ignite-wc-300-2. commit 65ec87bcac21ccc8ac28b1f6b59a1d277138441f Author: Andrey Novikov Date: 2017-11-20T07:03:33Z WC-300 Added ng-message. commit 80e343dde01db8992e1bba5f6b1e3d35b6b71c17 Author: Andrey Novikov Date: 2017-11-20T08:12:13Z WC-300 Copy svg. commit 25eaeb8f1203c44a7479f1b6ef665f50ae57be9a Author: Andrey Novikov Date: 2017-11-21T03:58:11Z WC-300 Fixed plus icon. commit 7c4b38c4e03109339deafa4ffee52c3a3cf351db Author: Ilya Borisov Date: 2017-11-21T03:33:30Z WC-300 Introduce DefaultState provider/service. commit de06b61d1f5e637e9932bc2c1262c6937b3ef379 Author: Ilya Borisov Date: 2017-11-21T03:36:24Z WC-300 Use "default-state" instead of explicit default state. Do not mention default state name when redirecting to it. commit 46e53e43d923ceec68b2f381e1291eb4220f5aba Author: Ilya Borisov Date: 2017-11-22T08:18:59Z WC-300 Replace missed default-state transition. commit c7007d0ecd697c601fe65f673aae40161df6fbfa Author: Alexey Kuznetsov Date: 2017-11-22T12:28:02Z WC-300 WIP cluster name. commit 78492ba08d8b0a0710fbe792749d2829ffdc Author: Alexey Kuznetsov Date: 2017-11-22T17:17:16Z WC-300 Added support for cluster name. commit 86bdb2737a172178c481e6678cb63e6a9c156a25 Author: Andrey Novikov Date: 2017-11-22T10:21:34Z WC-300 Use account _id as agent token. commit 91d40d4a6f551b610e0d1d0a315c2cadb46dcb57 Author: Alexey Kuznetsov Date: 2017-11-23T06:13:16Z Merge branches 'ignite-wc-300-2' and 'ignite-wc-300-cluster-name'. commit 29fd82a3c42d20cbdb210a7ebe066a853f99cc23 Author: Andrey Novikov Date: 2017-11-23T11:25:53Z WC-300 Fixed uptime. commit f742502f37a5e5290e7eb3c95f71b8b7c7bf9c1d Author: Andrey Novikov Date: 2017-11-23T11:29:41Z Merge branch 'ignite-wc-300-cluster-name' of https://github.com/gridgain/apache-ignite into ignite-wc-300-2 commit f314db36d4b40f0bd624ce81cac13eba8a5260ce Author: Andrey Novikov Date: 2017-12-06T07:22:07Z WC-300 Merged master branch. commit 25a22d4dc7681e2ea3e3736c8e484b587e7dd488 Author: Ilya Borisov Date: 2017-12-01T03:41:03Z WC-361 Move breadcrumbs to Ignite. (cherry picked from commit 154177b) commit fd68f9a28778419567319e0e6a096e657163e01f Author: Ilya Borisov Date: 2017-12-06T07:25:30Z WC-361 WIP. commit e317e34da709e68b9c78aae7ee176d16871fb85e Author: Andrey Novikov Date: 2017-12-06T09:46:59Z WC-300 Merged master branch. commit 58061d7a703c25eac71e8f4ec5737c4d2ccdc4b1 Author: Dmitriy Shabalin Date: 2017-12-06T10:03:50Z WC-300 added icons commit 0c97cc64c90e6ab934b85943ce28133fc785cc33 Author: Andrey Novikov Date: 2017-12-07T03:05:23Z WC-300 Minor ui fix. commit 11411609f81e4c16e6693fb187d1dd7d7e9aff68 Author: Andrey Novikov Date: 2017-12-07T08:14:12Z Merge branch 'master' of https://git-wip-us.apache.org/repos/asf/ignite into ignite-wc-300-2 commit 5fa41cf7284ff99a9beef94e46de570fdad30dd3 Author: Ilya Borisov Date: 2017-12-07T10:09:34Z WC-300 Animate .ignite-form-field error messages. commit 63afe406dfcc0a21f85bd46036025bd6379f41a8 Author: Dmitriy Shabalin Date: 2017-12-07T14:24:18Z WC-300 support extern icons commit fe5db2ee18ed73b11d9fe0148dc30b0f25e5c429 Author: Ilya Borisov Date: 2017-12-12T03:17:03Z WC-300 Move page-profile component definition into separate file, use non-URL template. commit 45bfcc888057fea55197b620b85eed0e9df375e8 Author: Ilya Borisov Date: 2017-12-12T06:59:08Z WC-361 Add "home" icon. commit 526547fcbc6d6cdc5ed370aac7d2649d1637593c Author: Ilya Borisov Date: 2017-12-12T07:00:24Z WC-361 Transclude breadcrumbs "home" image into first element, use svg icon instead of an asset. commit 7be95304e0ddb87373e91fdad7e7389b528c5801 Author: Andrey Novikov Date: 2017-12-12T10:40:05Z Merge branch master into ignite-wc-300-2 commit d003dc9491aa78702df1310a39138ef19658944f Author: Andrey Novikov Date: 2017-12-12T14:11:20Z Merge branch master into ignite-wc-300-2 commit 39892ade9ff935762f42fb41bc3b136f9a7c3522 Author: Andrey Novikov Date:
Re: Apache Ignite 2.7 release
Hello, Igniters. Today is a code freeze date but we still have 29 not merged tickets mapped to 2.7 release [1] It means: 1. We should continue work on 2.7 release and merge remaining tickets 2. Anyone who can help with #1, please, do it. 3. RC1 and further release builds will be created after all tickets will be merged. I will inform you about the progress on a daily basis. [1] https://issues.apache.org/jira/browse/IGNITE-8803?jql=(project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.7%27)%20AND%20status%20NOT%20IN%20(Resolved%2C%20Closed)%20and%20(component%20is%20null%20or%20component%20not%20in%20(documentation)))%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20%20%20%20%20%20 В Ср, 03/10/2018 в 14:02 +0300, Nikolay Izhikov пишет: > Alexey. > > Sorry, I lost link to IGNITE-9760 in this thread :) > > Thanks, for a clarification. > > > В Ср, 03/10/2018 в 13:58 +0300, Alexey Goncharuk пишет: > > Nikolay, both commits fixed a regression compared to ignite-2.6. First one > > was mentioned by Anton Kalashnikov before (java-level deadlock during WAL > > flush), another - by Andrey Kuznetsov (NPE during a concurrent WAL flush). > > > > --AG > > > > ср, 3 окт. 2018 г. в 13:38, Nikolay Izhikov : > > > Hello, Igniters. > > > > > > Release scope is frozen. > > > Please, if you include some new issues in release - discuss it in this > > > thread. > > > > > > Alexey, can you, please, comment on including fix for IGNITE-9760, > > > IGNITE-9761 in 2.7 branch. > > > > > > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=commit;h=3355201f3e8cafd23b2250aaf3b91b8b8ed1 > > > https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=commit;h=9d6e6ff394c05ddf7ef31a9d9ed1b492d9eeba69 > > > > > > В Ср, 03/10/2018 в 13:24 +0300, Vladimir Ozerov пишет: > > > > Nobody vetos anything, let's stop use this term unless some really > > > > important problem is discussed. > > > > > > > > At this point we are in situation when new tickets are still included > > > > into > > > > the scope. All want to ask is to stop including new tickets without > > > > explaining on why they should be in AI 2.7. Regression between is AI 2.6 > > > > and AI 2.7 is enough. But "I found new NPE" is not. > > > > > > > > On Wed, Oct 3, 2018 at 11:10 AM Dmitriy Pavlov > > > > wrote: > > > > > > > > > Nikolay, > > > > > > > > > > this has nothing about scaring someone. Let me explain about Apache > > > > > Way. > > > > > > > > > > Voting -1 to release does not mean blocking it, release can't be > > > > > vetoed. > > > > > Approving release is done by policy: majority approval. 3+1 binding > > > > > and > > > > > more +1 than -1. Consensus approval is better but not mandatory. > > > > > > > > > > Instead, if PMC says -1 to code modification it means veto and can't > > > > > be > > > > > bypassed to anyone. This is a very strong statement, which should be > > > > > applied reasonably and with technical justification. Lack of > > > > > understanding is not a justification. > > > > > > > > > > So my point instead of vetoing bugfix let's veto commits where the > > > > > bugs > > > > > were introduced. I feel a number of bugs reported recently are all > > > > > connected to WalManager, and these bugs may come from just a couple of > > > > > fixes. PDS tests were quite stable last time, so I think it is > > > > > possible to > > > > > find out why WAL crashes and hangs. > > > > > > > > > > Sincerely, > > > > > Dmitriy Pavlov > > > > > > > > > > ср, 3 окт. 2018 г. в 10:05, Andrey Kuznetsov : > > > > > > > > > > > Vladimir, Nikolay, > > > > > > > > > > > > For sure, I'm not an experienced Ignite contributor, so I'm sorry > > > > > > for > > > > > > intervening. I've just run the reproducer from [1] against > > > > > > ignite-2.6 > > > > > > branch and it has passed. So, it's not an legacy bug, we've brought > > > > > > it > > > > > > > > > > with > > > > > > some change of 2.7 scope. Is it still ok to ignore the bug? > > > > > > > > > > > > [1] https://issues.apache.org/jira/browse/IGNITE-9776 > > > > > > > > > > > > ср, 3 окт. 2018 г. в 2:07, Nikolay Izhikov : > > > > > > > > > > > > > Hello, Dmitriy. > > > > > > > > > > > > > > I'm sorry, but I don't understand your concern. > > > > > > > > > > > > > > Vladimir just asks experienced Ignite contributor to *explain > > > > > > > impact* > > > > > > > > > > of > > > > > > a > > > > > > > bug. > > > > > > > > > > > > > > Why are you scaring us with your "-1"? > > > > > > > Is it Apache Way to do so? > > > > > > > What should be done for you to return to a constructive > > > > > > > discussion? > > > > > > > > > > > > > > В Ср, 03/10/2018 в 00:23 +0300, Dmitriy Pavlov пишет: > > > > > > > > Hi Igniters, Vladimir, > > > > > > > > > > > > > > > > NPEs or hangs in WAL is a completely non-functional grid (if > > > > > > > > > > > > persistence > > > > > > > > enabled). > > > > > > > > > > > > > > > > I see no
[GitHub] ignite pull request #4938: IGNITE-9832 MTCGA: AL header added to Doxyfile
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4938 ---
[GitHub] ignite pull request #4904: IGNITE-9783: MVCC: Track all nodes participating ...
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4904 ---
[jira] [Created] (IGNITE-9837) Test BinaryMetadataUpdatesFlowTest.testConcurrentMetadataUpdates is flaky in master.
Amelchev Nikita created IGNITE-9837: --- Summary: Test BinaryMetadataUpdatesFlowTest.testConcurrentMetadataUpdates is flaky in master. Key: IGNITE-9837 URL: https://issues.apache.org/jira/browse/IGNITE-9837 Project: Ignite Issue Type: Bug Reporter: Amelchev Nikita Assignee: Amelchev Nikita The test _BinaryMetadataUpdatesFlowTest.testConcurrentMetadataUpdates_ is flaky in master. Sometimes it fails by timeout (5min). [Example of fail.|https://ci.ignite.apache.org/viewLog.html?buildId=2042133=buildResultsDiv=IgniteTests24Java8_BinaryObjects#testNameId4314129944736732856] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9836) Invalid check of ea java versions
Vasiliy Sisko created IGNITE-9836:
-
Summary: Invalid check of ea java versions
Key: IGNITE-9836
URL: https://issues.apache.org/jira/browse/IGNITE-9836
Project: Ignite
Issue Type: Bug
Reporter: Vasiliy Sisko
Assignee: Vasiliy Sisko
On check of '1.8.0_192-ea' java version in ignite.sh the next messages in
console are printed:
{code:java}
./include/functions.sh: line 81: [: -lt: unary operator expected
./ignite.sh: line 61:
/home/vsisko/Downloads/distr/bin/include/build-classpath.sh: No such file or
directory
./ignite.sh: line 152: [: -eq: unary operator expected
./ignite.sh: line 157: [: -gt: unary operator expected
./ignite.sh: line 170: [: -eq: unary operator expected{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: Python thin client
Stepan!
Can you please update the benchmarks based on my suggestions earlier in
this thread: use a cleaner time profiling for the loop, remove
unnecessary operations (string formatting, rounding operations), stick
to the primitive int value for put operations (agree with Vladimir,
let's keep it simple). And let me know the results.
On 10/10/18 5:46 PM, Vladimir Ozerov wrote:
Hi Dmitry,
I agree with your comments on benchmarking code. As more fair
alternative we may measure time of loading N elements into the cache, so
that it will be necessary to call time() only twice. However, provided
that we have real network here, and according to numbers one PUT in
Python client requires about 0.3 msec, I hardly can imagine that call to
time() or round() may dominate in that response time. But I said, we can
easily rule that out by slight benchmark rewrite.
As far as serialization, I would prefer to keep primitive objects at the
moment, because AFAIK the purpose of the benchmark was to assess
underlying infrastructure, looking for some obvious performance issues.
Every platform have sockets which use more or less the same API of
underlying OS. To the contrast, performance of serialization mechanics
may differ widely between platforms depending on implementation. E.g. in
Java we spend a lot of time on fine-grained tuning, applied a lot of
speculative optimizations. Add to this JIT nature of Java, and you will
hardly ever beat Java serialization engine from any interpreted
language. So primitive data types make good sense to me.
At this point our goal is not make Python equally fast with other
platforms, but rather to understand why is it slower than others. Ignite
is a product which brings speed to end users. If they do no have speed,
they will not use Ignite. So performance questions are always of great
importance for us.
Vladimir.
On Wed, Oct 10, 2018 at 9:57 AM Dmitry Melnichuk
mailto:dmitry.melnic...@nobitlost.com>>
wrote:
Hi, Stepan!
I looked at the benchmark code and the overall methodics, discussed it
with fellow programmers, and came up with basically two remarks.
First of all, I think, the key for the good (or, at least,
unobjectionable) measurement is to isolate the object being measured
from the influence of the measurement tool. The usual pattern we use in
Python looks like:
```
from time import time
bench_start = time()
for _ in range(number_of_tests):
do_test()
bench_end = time()
print('Performance is {} tests per second'.format(
number_of_tests / (bench_end - bench_start)
))
```
I think, you got the idea: the measurement consists almost solely of
the
time taken by our subject function `do_test`. As few other code as
possible influence the result.
Now, let's take a look at your code:
https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
Ideally, the `while` loop should include only `cache.put(last_key,
some_precomputed_value)`. But instead it also includes:
- a series of the `time()` calls, which could be mostly excluded from
the measured time, if the measurement done right; each call is probably
addresses the HPET device, or network time, or both,
- some floating-point calculations, including `round()`, which is
hardly
necessary,
- formatting and output of the intermediate result.
I suppose the measurement influence can be quite significant here, but
it is at least more or less constant for each test.
But if we look at the other benchmarks:
https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
[Node.js]
https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80
[PHP]
https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce
[Java]
The extra code that influence the measurement is not equivalent across
all platforms. For example, PHP's `time()` is most probably lighter
than
Python `time()`, since it do not give out milliseconds and may address
RTC, not HPET. So the platform-to-platform comparison in your benchmark
does not look completely fair to me.
The second remark concerns not the measurement procedure, but the
object
being measured.
The only client operation being used is OP_CACHE_PUT with a payload
of a
primitive type. (BTW the type is `Long` in case of the Python client;
what about the other clients? Is it `Int`?) I afraid that such an
object, even being properly isolated from the measurement tool, would
show mostly the throughput of the underlying platform's sockets
implementation, not the performance of the client's code. To show the
potential of the thin client itself, more varied and fancy tasks
needed,
i. e. serialization/deserialization of the Complex objects.
But it depends on the goal of the benchmarking. If showing off the raw
[GitHub] ignite pull request #4940: IGNITE-9446: Added cache status check before runn...
GitHub user rkondakov opened a pull request: https://github.com/apache/ignite/pull/4940 IGNITE-9446: Added cache status check before running vacuum. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-9446 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4940.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 #4940 commit 6632c69a72fd950bad25b6b1668746d62f2fb461 Author: rkondakov Date: 2018-10-10T09:11:11Z IGNITE-9446: Added cache status check before running vacuum. ---
[jira] [Created] (IGNITE-9835) Document IGNITE.CACHES system view
Vladimir Ozerov created IGNITE-9835: --- Summary: Document IGNITE.CACHES system view Key: IGNITE-9835 URL: https://issues.apache.org/jira/browse/IGNITE-9835 Project: Ignite Issue Type: Task Components: documentation Reporter: Vladimir Ozerov Assignee: Artem Budnikov Fix For: 2.8 New system view has been added to the product - IGNITE.CACHES. Please see it's columns in the source code [1], which is pretty self-descriptive. Most of them are taken from cache configuration. [1] https://github.com/apache/ignite/blob/master/modules/indexing/src/main/java/org/apache/ignite/internal/processors/query/h2/sys/view/SqlSystemViewCaches.java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] ignite pull request #4716: IGNITE-9500 SQL system view for list of caches
Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/4716 ---
[GitHub] SomeFire opened a new pull request #32: add PR title to the PR number for autocomplete TC branch
SomeFire opened a new pull request #32: add PR title to the PR number for autocomplete TC branch URL: https://github.com/apache/ignite-teamcity-bot/pull/32 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
Re: Absence of unsigned integer read/write support in IBinaryRawReader/Writer
On Tue, Oct 9, 2018 at 9:55 PM Raymond Wilson wrote: > > I am curious that unsigned ints would not be a universally supported type > on all platforms. Is that really the case? > I am not aware of any unsigned ints in Java, at least yet. Here is a Stack Overflow thread on this: https://stackoverflow.com/questions/25556017/how-to-use-the-unsigned-integer-in-java-8-and-java-9/32837775
[GitHub] ignite pull request #4939: IGNITE-9834: Cancel tcp-client-disco-msg-worker i...
GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/4939 IGNITE-9834: Cancel tcp-client-disco-msg-worker in normal order after validation error â¦rror You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-gg-9834 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/4939.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 #4939 commit 6259d3e49b962b914fcc89cfdfc3002ace1ceabc Author: Alexey Platonov Date: 2018-10-10T07:53:31Z cancel tcp-client-disco-msg-worker in normal order after validation error ---
[jira] [Created] (IGNITE-9834) ClientImpl shouldn't fail JVM with 130 error code after node validation errors
Alexey Platonov created IGNITE-9834: --- Summary: ClientImpl shouldn't fail JVM with 130 error code after node validation errors Key: IGNITE-9834 URL: https://issues.apache.org/jira/browse/IGNITE-9834 Project: Ignite Issue Type: Bug Reporter: Alexey Platonov Assignee: Alexey Platonov In the current number of Ignite if client (tcp-client-disco-msg-worker) receive validation error message represented by TcpDiscoveryCheckFailedMessage then client fail with 130 error code. Semantically such behavior is invalid. Client must cancel own work in normal order. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Python thin client
Hi Dmitry,
I agree with your comments on benchmarking code. As more fair alternative
we may measure time of loading N elements into the cache, so that it will
be necessary to call time() only twice. However, provided that we have real
network here, and according to numbers one PUT in Python client requires
about 0.3 msec, I hardly can imagine that call to time() or round() may
dominate in that response time. But I said, we can easily rule that out by
slight benchmark rewrite.
As far as serialization, I would prefer to keep primitive objects at the
moment, because AFAIK the purpose of the benchmark was to assess underlying
infrastructure, looking for some obvious performance issues. Every platform
have sockets which use more or less the same API of underlying OS. To the
contrast, performance of serialization mechanics may differ widely between
platforms depending on implementation. E.g. in Java we spend a lot of time
on fine-grained tuning, applied a lot of speculative optimizations. Add to
this JIT nature of Java, and you will hardly ever beat Java serialization
engine from any interpreted language. So primitive data types make good
sense to me.
At this point our goal is not make Python equally fast with other
platforms, but rather to understand why is it slower than others. Ignite is
a product which brings speed to end users. If they do no have speed, they
will not use Ignite. So performance questions are always of great
importance for us.
Vladimir.
On Wed, Oct 10, 2018 at 9:57 AM Dmitry Melnichuk <
dmitry.melnic...@nobitlost.com> wrote:
> Hi, Stepan!
>
> I looked at the benchmark code and the overall methodics, discussed it
> with fellow programmers, and came up with basically two remarks.
>
> First of all, I think, the key for the good (or, at least,
> unobjectionable) measurement is to isolate the object being measured
> from the influence of the measurement tool. The usual pattern we use in
> Python looks like:
>
> ```
> from time import time
>
>
> bench_start = time()
>
> for _ in range(number_of_tests):
> do_test()
>
> bench_end = time()
>
> print('Performance is {} tests per second'.format(
> number_of_tests / (bench_end - bench_start)
> ))
> ```
>
> I think, you got the idea: the measurement consists almost solely of the
> time taken by our subject function `do_test`. As few other code as
> possible influence the result.
>
> Now, let's take a look at your code:
>
> https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
>
> Ideally, the `while` loop should include only `cache.put(last_key,
> some_precomputed_value)`. But instead it also includes:
>
> - a series of the `time()` calls, which could be mostly excluded from
> the measured time, if the measurement done right; each call is probably
> addresses the HPET device, or network time, or both,
>
> - some floating-point calculations, including `round()`, which is hardly
> necessary,
>
> - formatting and output of the intermediate result.
>
> I suppose the measurement influence can be quite significant here, but
> it is at least more or less constant for each test.
>
> But if we look at the other benchmarks:
>
> https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
> [Node.js]
> https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80 [PHP]
> https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce
> [Java]
>
> The extra code that influence the measurement is not equivalent across
> all platforms. For example, PHP's `time()` is most probably lighter than
> Python `time()`, since it do not give out milliseconds and may address
> RTC, not HPET. So the platform-to-platform comparison in your benchmark
> does not look completely fair to me.
>
> The second remark concerns not the measurement procedure, but the object
> being measured.
>
> The only client operation being used is OP_CACHE_PUT with a payload of a
> primitive type. (BTW the type is `Long` in case of the Python client;
> what about the other clients? Is it `Int`?) I afraid that such an
> object, even being properly isolated from the measurement tool, would
> show mostly the throughput of the underlying platform's sockets
> implementation, not the performance of the client's code. To show the
> potential of the thin client itself, more varied and fancy tasks needed,
> i. e. serialization/deserialization of the Complex objects.
>
> But it depends on the goal of the benchmarking. If showing off the raw
> platform agility was intended, than this objection is removed.
>
> Dmitry
>
> On 10/9/18 10:50 PM, Stepan Pilshchikov wrote:
> > Hi, all
> >
> > Tried to compare new thin client performance and made similar benchmarks
> for
> > each one
> > And result not so good for python
> >
> > Ticket with results and bench code:
> > https://issues.apache.org/jira/browse/IGNITE-9824
> >
> > Py code src:
> > https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
> >
> > Dmitry, please review results and bench code, maybe
[jira] [Created] (IGNITE-9833) Update Master Trends metrics: add total run time (duration), number of runs
Nikolai Kulagin created IGNITE-9833: --- Summary: Update Master Trends metrics: add total run time (duration), number of runs Key: IGNITE-9833 URL: https://issues.apache.org/jira/browse/IGNITE-9833 Project: Ignite Issue Type: Sub-task Reporter: Nikolai Kulagin Assignee: Nikolai Kulagin Update [Master Treands|https://mtcga.gridgain.com/comparison.html] metrics on TC Bot: add total run time (duration) and number of runs -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Python thin client
Hi, Stepan!
I looked at the benchmark code and the overall methodics, discussed it
with fellow programmers, and came up with basically two remarks.
First of all, I think, the key for the good (or, at least,
unobjectionable) measurement is to isolate the object being measured
from the influence of the measurement tool. The usual pattern we use in
Python looks like:
```
from time import time
bench_start = time()
for _ in range(number_of_tests):
do_test()
bench_end = time()
print('Performance is {} tests per second'.format(
number_of_tests / (bench_end - bench_start)
))
```
I think, you got the idea: the measurement consists almost solely of the
time taken by our subject function `do_test`. As few other code as
possible influence the result.
Now, let's take a look at your code:
https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
Ideally, the `while` loop should include only `cache.put(last_key,
some_precomputed_value)`. But instead it also includes:
- a series of the `time()` calls, which could be mostly excluded from
the measured time, if the measurement done right; each call is probably
addresses the HPET device, or network time, or both,
- some floating-point calculations, including `round()`, which is hardly
necessary,
- formatting and output of the intermediate result.
I suppose the measurement influence can be quite significant here, but
it is at least more or less constant for each test.
But if we look at the other benchmarks:
https://gist.github.com/pilshchikov/8a4bdb03a8304136c22c9bf7217ee447
[Node.js]
https://gist.github.com/pilshchikov/b4351d78ad59e9cd923689c2e387bc80 [PHP]
https://gist.github.com/pilshchikov/08096c78b425e00166a2ffa2aa5f49ce [Java]
The extra code that influence the measurement is not equivalent across
all platforms. For example, PHP's `time()` is most probably lighter than
Python `time()`, since it do not give out milliseconds and may address
RTC, not HPET. So the platform-to-platform comparison in your benchmark
does not look completely fair to me.
The second remark concerns not the measurement procedure, but the object
being measured.
The only client operation being used is OP_CACHE_PUT with a payload of a
primitive type. (BTW the type is `Long` in case of the Python client;
what about the other clients? Is it `Int`?) I afraid that such an
object, even being properly isolated from the measurement tool, would
show mostly the throughput of the underlying platform's sockets
implementation, not the performance of the client's code. To show the
potential of the thin client itself, more varied and fancy tasks needed,
i. e. serialization/deserialization of the Complex objects.
But it depends on the goal of the benchmarking. If showing off the raw
platform agility was intended, than this objection is removed.
Dmitry
On 10/9/18 10:50 PM, Stepan Pilshchikov wrote:
Hi, all
Tried to compare new thin client performance and made similar benchmarks for
each one
And result not so good for python
Ticket with results and bench code:
https://issues.apache.org/jira/browse/IGNITE-9824
Py code src:
https://gist.github.com/pilshchikov/8aff4e30d83f8bac20c5a4a9c3917abb
Dmitry, please review results and bench code, maybe somthing wrong or it's
expected numbers?
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
