Alexey Kuznetsov created IGNITE-10668:
-
Summary: Web Console: Prepare sample NGINX config with SSL and
ciphers support
Key: IGNITE-10668
URL: https://issues.apache.org/jira/browse/IGNITE-10668
In terms of providing consistency of services' API, where the
interface `Service` extend `Serializable` end-user should make his
implementation to be serializable properly.
>From this point of view, `JdkMarshaller` can be used as the common
marshaller for service's instance, this allows reduce
> On 11 Dec 2018, at 10:10, Nikolay Izhikov wrote:
>
> Hello, Ivan.
>
> Personally, I keep my PR's clear.
> So, I don't have dozens of opened PR.
>
> But, I don't support Dmitriy proposal for several reasons:
>
> 1. We introduce some new, not required, level of bureaucracy.
> From my
ARomantsov created IGNITE-10669:
---
Summary: NPE in freelist.PagesList.findTailIndex
Key: IGNITE-10669
URL: https://issues.apache.org/jira/browse/IGNITE-10669
Project: Ignite
Issue Type: Bug
There is an error in Build project [1] section.
How can it be fixed? Ticket to IGNITE Jira?
[1]
https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#building-project
> On 12 Dec 2018, at 20:21, Dmitriy Pavlov wrote:
>
> Hi Igniters,
>
> Just to inform, the very first version of the
Oleg Ignatenko created IGNITE-10670:
---
Summary: investigate why Cassandra modules don't have testsuite(s)
Key: IGNITE-10670
URL: https://issues.apache.org/jira/browse/IGNITE-10670
Project: Ignite
Hi, as suggested by Ilya here:
http://apache-ignite-users.70518.x6.nabble.com/Continuous-queries-and-duplicates-td25314.html
I'm resending it to the developers list.
>From that thread we know that there might be duplicates between initial
query results and listener entries received as part of
Fixed memory issues with increasing heap size and forcing G1GC.
Do we need all these plugins loaded for inspections?
I've found a 'disable plugin' option in TC Inspections build configuration,
but it is unclear how to disable plugin correctly.
Can someone take over this?
> 46 plugins initialized
Hi All, the Bot detected some stable failure in the past because failure
history in the latest Bot release is longer, so this is not a recent
failure.
But anyway both tests need to be fixed as they are flaky.
вт, 11 дек. 2018 г. в 23:34, :
> Hi Igniters,
>
> I've detected some new issue on
Mentioned failure is not recent, but occurred in the past. Hopefully, new
services implementation will fix the test.
чт, 13 дек. 2018 г. в 04:11, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to
I'll fix. There is an ignored files list.
чт, 13 дек. 2018 г. в 12:02, Petr Ivanov :
> There is an error in Build project [1] section.
> How can it be fixed? Ticket to IGNITE Jira?
>
>
> [1]
> https://github.com/apache/ignite/blob/master/CONTRIBUTING.md#building-project
>
> > On 12 Dec 2018, at
Igniters, Alexey
I want to discuss the ticket 10371 [1], currently, we calculate 4 numbers
(true positive, true negative, false positive, false negative) for each
"point metric" like accuracy, recall, f-score and precision for each label.
So for the full score we need calculates those 4 numbers
Pavel Voronkin created IGNITE-10671:
---
Summary: Double initialization of segmentAware and FileArchiver
lead to race breaking file compression.
Key: IGNITE-10671
URL:
Flaky timeout. Probably already fixed
пн, 10 дек. 2018 г. в 04:47, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make the
TC Bot detected some stable failure in the past. The mentioned build is
outside of TC storage now. Failure history in the latest Bot release is
longer, so this is not a recent failure. But anyway, the test needs to be
fixed as it is flaky.
ср, 12 дек. 2018 г. в 00:11, :
> Hi Igniters,
>
>
The failure occurred a long time ago, it is outside of TC history now. The
test is still flaky.
чт, 13 дек. 2018 г. в 07:56, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're
Guys,
I've just creates a copy of Inspections TC build task with GC logs turned
on to check if there is any issues
and found Inspections task spent too much time in STW due to long Full GC
pauses.
I've tried to increase Xmx up to 4Gb and use G1GC got 2+ times better
execution time down to ~15
Sure, let's apply. I hope all TC agents may handle 4G heap.
чт, 13 дек. 2018 г. в 12:54, Andrey Mashenkov :
> Guys,
>
> I've just creates a copy of Inspections TC build task with GC logs turned
> on to check if there is any issues
> and found Inspections task spent too much time in STW due to
It is really recently broken test:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7945125576049372508=%3Cdefault%3E=testDetails
Now it fails stable.
Igor S, Vladimir O. please chime in.
вт, 11 дек. 2018 г. в 09:17, :
> Hi Igniters,
>
> I've detected some new issue on
This failure bot complains was occurred in November. It is not a recent
failure. But the test is still flaky.
ср, 12 дек. 2018 г. в 03:26, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this
Maxim M, do you know if we can disable inspections by wildcard? E.g.
Android* ?
чт, 13 дек. 2018 г. в 14:59, Andrey Mashenkov :
> Fixed memory issues with increasing heap size and forcing G1GC.
>
> Do we need all these plugins loaded for inspections?
> I've found a 'disable plugin' option in TC
https://issues.apache.org/jira/browse/IGNITE-10245
ср, 12 дек. 2018 г. в 17:11, :
> Hi Igniters,
>
> I've detected some new issue on TeamCity to be handled. You are more than
> welcomed to help.
>
> If your changes can lead to this failure(s): We're grateful that you were
> a volunteer to make
Dmitry Sherstobitov created IGNITE-10672:
Summary: Changing walSegments property leads to fallen node
Key: IGNITE-10672
URL: https://issues.apache.org/jira/browse/IGNITE-10672
Project: Ignite
Roman,
We have a ticket to improve repeatable_read mode [1] via caching entries
locally.
This should make mvcc transaction repeatable_read semantic similar to
non-mvcc Txs
and allow us to implement eviction in correct way.
Another way is to introduce mvcc shared (read) entry locks and evict only
ASC / SHA512 verification:
1. Download signing key: wget -c https://www.apache.org/dist/ignite/KEYS
2. Import key: gpg --import KEYS
3. Download release with signature and sha512 hash sum: wget -c
http://apache.org/dist/ignite/2.7.0/apache-ignite-2.7.0-src.zip
Ilya Kasnacheev created IGNITE-10674:
Summary: Remove MARSH_CLASS_NAME=BinaryMarshaller from tests
Key: IGNITE-10674
URL: https://issues.apache.org/jira/browse/IGNITE-10674
Project: Ignite
Andrey,
We will not be able to cache the whole data set locally, as it potentially
lead to OOME. We will have this only as an option and only for non-SQL
updates. Thus, similar semantics is not possible.
On Thu, Dec 13, 2018 at 4:56 PM Andrey Mashenkov
wrote:
> Roman,
>
> We have a ticket to
Maxim,
It looks like we can't make logs more verbose due to possible bug, I've
create a ticket in Jetbrains Jira [1].
We can just publish idea logs in artefacts as suggested in this manual [2].
For now, Inspections logs looks like this one [3].
Also, would you please to take a look at inspection
Hi igniters,
I need your advice with the following issue. When in-memory cache
reaches it's memory limit, some data may be purged to avoid OOM error.
This process is described in [1]. For MVCC caches this eviction may
break repeatable read semantics. For example, if transaction reads key
Hello!
Is it possible to 'touch' entries read by MVCC transactions to ensure that
they are considered recent and therefore are almost never targeted by
eviction?
This is 1) with benefits.
Regards,
--
Ilya Kasnacheev
чт, 13 дек. 2018 г. в 16:22, Roman Kondakov :
> Hi igniters,
>
> I need
Peter Ivanov created IGNITE-10673:
-
Summary: Prepare instructions for ASC and SHA512 verification
Key: IGNITE-10673
URL: https://issues.apache.org/jira/browse/IGNITE-10673
Project: Ignite
So, I agree that we should avoid ineffective metrics calculations.
I think that in 2.8 release we should have
1. BinaryClassificationMetric with all metrics from Wikipedia
2. Metric interface with 1 or two implementations in example folder or
in metric package like roc auc and accuracy
Vladimir,
Agree,
I've just forget about queries :)
On Thu, Dec 13, 2018 at 5:28 PM Vladimir Ozerov
wrote:
> Andrey,
>
> We will not be able to cache the whole data set locally, as it potentially
> lead to OOME. We will have this only as an option and only for non-SQL
> updates. Thus, similar
Roman,
I would start with the fact that eviction can never be consistent unless it
utilizes atomic broadcast protocol, which is not the case for Ignite. In
Ignite entries on node are evicted independently.
So you may easily get into situation like this:
1) Start a cache with 1 backup and
Andrey,
Thank you for solving this issue with GC pauses! I've checked the
given report. The inspections configuration is correct, but it seems
to me that we have enabled by default rules of included plugins (for
instance, KotlinInternalInJava in the report is enabled).
Can you share more details
Dmitriy,
Sure, all changes in ML module will be described on readme.io site with
next release (2.8).
Best regards,
Yuriy Babak
чт, 13 дек. 2018 г. в 17:21, Dmitriy Pavlov :
> Folks, I sometimes hear complains related to metrics and its clearness for
> end-users.
>
> Would you add a couple of
Maxim,
Idea has a file in config directory ./config/disabled_plugins.txt , you can
easily find it at you local machine.
Teamcity Inspections runner has an option "Disabled plugins" where
disabled_plugins.txt file content can be set.
So, looks like we can disable useless plugins.
But I'm not
Yes, it is expected this test become not flaky once Service Grid phase
1 have been merged:
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5756858704963167219=%3Cdefault%3E=testDetails_IgniteTests24Java8=pull%2F4434%2Fhead
On Thu, Dec 13, 2018 at 3:22 PM Dmitriy Pavlov
You can compute just TP (true-positive), FP, TN and FN counters and use
them to evaluate Recall, Precision, Accuracy, ect. If you want to specify
class for Pr evaluation, then you can compute Pr for first label as
TP/(TP+FP) and for second label as TN/(TN+FN) for example. After it we can
unite all
Folks, I sometimes hear complains related to metrics and its clearness for
end-users.
Would you add a couple of words related to each value to wiki/readme.io?
чт, 13 дек. 2018 г. в 17:13, Alexey Zinoviev :
> So, I agree that we should avoid ineffective metrics calculations.
> I think that in
Peter Ivanov created IGNITE-10675:
-
Summary: Refactor Release Candidate check build
Key: IGNITE-10675
URL: https://issues.apache.org/jira/browse/IGNITE-10675
Project: Ignite
Issue Type:
Please, have a look at new version in my PR where I've implemented the
approach that was listed above
https://github.com/apache/ignite/pull/5612
чт, 13 дек. 2018 г. в 17:21, Dmitriy Pavlov :
> Folks, I sometimes hear complains related to metrics and its clearness for
> end-users.
>
> Would you
Vladimir Ozerov created IGNITE-10676:
Summary: Binary: optionally do not check types in metadata
Key: IGNITE-10676
URL: https://issues.apache.org/jira/browse/IGNITE-10676
Project: Ignite
Hi Ilya!
Touching entries seem to me not a possible solution here. During what
the period entry should be considered as recent? I think until all
transactions which have touched the given entry are terminated. If all
transactions which have read the particular entry are terminated - it
can
Vladimir,
correct me please if i misunderstood your thought. So, if eviction is
not about a consistency at all, we may evict keys in any way because
broken repeatable read semantics is not the biggest problem here. But we
should add some notes about it to user documentation. Right?
--
Kind
No, I mean that we should think about what kind of guarantees it possible.
My proposal was to prevent evictions of locked entries. This way we can say
users: "if you want true REPEATABLE_READ when evictions are enabled, then
make sure to lock entries on every access". This effectively means that
Hello Piotr,
That's a known problem and I thought a JIRA ticket already exists. However,
failed to locate it. The ticket for the improvement should be created as a
result of this conversation.
Speaking of an initial query type, I would differentiate from ScanQueries
and SqlQueries. For the
Vladimir,
we do not lock entries on backups when MVCC is enabled and therefore we
don't avoid entry eviction from backup by locking. So, your first
scenario with primary stop is still relevant.
--
Kind Regards
Roman Kondakov
On 13.12.2018 22:14, Vladimir Ozerov wrote:
No, I mean that we
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/Continuous-queries-and-MVCC-td33972.html
On Thu, Dec 13, 2018 at 11:38 PM Vladimir Ozerov
wrote:
> Denis,
>
> Not really. They are used to ensure that ordering of notifications is
> consistent with ordering of updates, so that when a key
Partition counter is internal implemenattion detail, which has no sensible
meaning to end users. It should not be exposed through public API.
On Thu, Dec 13, 2018 at 10:14 PM Denis Magda wrote:
> Hello Piotr,
>
> That's a known problem and I thought a JIRA ticket already exists. However,
>
Vladimir,
The partition counter is supposed to be used internally to solve the
duplication issue. Does it sound like a right approach then?
What would be an approach for SQL queries? Not sure the partition counter
is applicable.
--
Denis
On Thu, Dec 13, 2018 at 11:16 AM Vladimir Ozerov
wrote:
It's hard to believe that entries are not locked on backups, because we
wrtite data right away. Even if it so, it should be very easy to fix - just
do not evict and entry if it was created or deleted by currently active
transaction.
On Thu, Dec 13, 2018 at 10:28 PM Roman Kondakov
wrote:
>
Sergey Kozlov created IGNITE-10678:
--
Summary: Shell script unification
Key: IGNITE-10678
URL: https://issues.apache.org/jira/browse/IGNITE-10678
Project: Ignite
Issue Type: Improvement
For point 3, I cannot find where dist.apache.org is used...Can you please
point me to the right place?
On Thu, Dec 13, 2018 at 6:07 AM Peter Ivanov wrote:
> ASC / SHA512 verification:
>
> 1. Download signing key: wget -c https://www.apache.org/dist/ignite/KEYS
> 2. Import key: gpg --import
Pavel Voronkin created IGNITE-10681:
---
Summary: PME benchmarks become unstable at high number of
partitions per cache.
Key: IGNITE-10681
URL: https://issues.apache.org/jira/browse/IGNITE-10681
Hi,
I am working on building Apache Ignite v2.7.0 on s390x architecture. The build
was successful, however facing some test failures.
One of the failures is:
[ERROR]
testAllocationRateMultiThreaded(org.apache.ignite.internal.processors.database.DataRegionMetricsSelfTest)
Time elapsed: 17.204
Hello, Denis.
Great news.
> *1. Testing of the cache-based implementation of the service grid.*
> I think, we should make a test suite, that will test the old implementation>
> until we> remove it from the project.
Aggree. Let's do it.
> *2. DynamicServiceChangeRequest.*
> I think, this class
Maxim Muzafarov created IGNITE-10682:
Summary: Disable unnecessary loaded plugins for the Inspection
test suite
Key: IGNITE-10682
URL: https://issues.apache.org/jira/browse/IGNITE-10682
Project:
Denis,
Not really. They are used to ensure that ordering of notifications is
consistent with ordering of updates, so that when a key K is updated to V1,
then V2, then V3, you never observe V1 -> V3 -> V2. It also solves
duplicate notification problem in case of node failures, when the same
update
Guys,
I've been looking through the PR by Vyacheslav for past few weeks.
Slava, great job! You've done an impressive amount of work.
I posted my comments to the PR and had a few calls with Slava.
I am close to finishing my review.
There are some points, that I'd like to settle in this discussion
Dmitriy Pavlov created IGNITE-10677:
---
Summary: [TC Bot] Include build failure on metric & exit code into
critical failures
Key: IGNITE-10677
URL: https://issues.apache.org/jira/browse/IGNITE-10677
Hi,
>From my experience it is better when all needed stuff available on GitHub.
It is very comfortable when thinks like, "read me", "change log", "how to
build", "how to contribute" and so on available on GitHub.
No need to open some external links.
--
Alexey Kuznetsov
Pavel Voronkin created IGNITE-10679:
---
Summary: Add more debug info for 'Affinity changes' PME stage.
Key: IGNITE-10679
URL: https://issues.apache.org/jira/browse/IGNITE-10679
Project: Ignite
Aleksey Plekhanov created IGNITE-10680:
--
Summary: Add the ability to use started kernel context in
standalone WAL iterator
Key: IGNITE-10680
URL: https://issues.apache.org/jira/browse/IGNITE-10680
There will be no problem with TC, as we use GitHub as main VCS root, using ASF
only for release (which I will reconfigure during release builds refactoring
and optimisations for AI 2.8).
> On 11 Dec 2018, at 19:25, Alexey Goncharuk wrote:
>
> Given that there is no option to stay on the old
The Github page looks like a shorter version of the main wiki page:
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
Not sure we want to maintain both. If the wiki source is sluggish and
overloaded then I would rework it instead moving secondary stuff to
sub-pages. Think that
66 matches
Mail list logo
