That's a good question. I'm fully for committing docs' changes straight to
the "ignite-2.9" branch without introducing superfluous branches such as
"ignite-2.9-docs".
Igniters, any notable reason why we can't commit changes to a branch of a
finished release? This "frozen" state sounds artificial,
Hi Kseniya,
Thank you for sharing the videos details, much appreciate it.
Regards,
Saikat
On Fri, 30 Oct 2020 at 12:13 PM, Kseniya Romanova
wrote:
> Hi, igniters!
> Below you can find videos of Ignite talks at the passed Virtual In-memory
> Computing Summit:
>
>1. Apache Ignite Training
Denis,
Thanks for the answer. Makes sense.
We already have 2.9.0 tag pointing to the release commit. Is it safe
changing docs right from ignite-2.9 branch? Why should we keep it
frozen?
On Fri, 30 Oct 2020 at 23:02, Denis Magda wrote:
>
> Maxim,
>
> The approach you're suggesting (to keep the
Maxim,
The approach you're suggesting (to keep the docs in a separate repo) was
among the two possible options we were reviewing while deciding where to
keep the docs. Eventually, we selected the current solution by storing the
docs together with the source code in a single repo.
As a technical
Denis, Alex
It's a bit confusing for me of having the main dedicated branches for
documentation (ignite-2.9-docs, ignite-2.9.1-docs etc.) instead of
keeping docs in the release branch. The drawback of freezing all the
documentation in the release branch is not good for our users also.
We already
Hello,
It can be compiled if you don't need JavaDoc and scala modules (visor
console, ignite-spark integration):
mvn clean install -Pall-java,licenses,-scala,-scala-2.10,-spark-2.4
-DskipTests -Dmaven.javadoc.skip=true
пт, 30 окт. 2020 г. в 18:49, Ilya Kasnacheev :
> Hello!
>
> I don't think
Igniters,
I've created "ignite-2.9-docs" branch and cherry-picked documentation
related commits from master.
If you changing documentation in master branch and this fix should affect
Ignite 2.9, please cherry-pick this commit to "ignite-2.9-docs" branch too.
чт, 15 окт. 2020 г. в 01:58, Denis
Hi, igniters!
Below you can find videos of Ignite talks at the passed Virtual In-memory
Computing Summit:
1. Apache Ignite Training Part 1—Setting Up Apache Ignite Management and
Monitoring Solution with GridGain Control Centerr—by Denis Magda
https://www.youtube.com/watch?v=6R6y7RLT2YA
Hello!
I don't think so. Why? You can use a binary package.
Regards,
--
Ilya Kasnacheev
пт, 30 окт. 2020 г. в 16:59, shm :
> Hi
> Does Apache Ignite version 2.8.1 supported compilation on JAVA 11 installed
> machine ?
>
>
> Shiva
>
>
>
> --
> Sent from:
Hi Sergi,
we are planning to on-board Ignite persistence store and since we are having
huge volume of data we need to have page compression. After checking few
links I would like to confirm that does any critical issue still pending or
do we need to wait for specific version to release? It would
Hi
Does Apache Ignite version 2.8.1 supported compilation on JAVA 11 installed
machine ?
Shiva
--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
I suggests to mark these tests with @Ignore and file tickets to fix them.
пт, 30 окт. 2020 г. в 16:26, Ivan Daschinsky :
> Hi
>
> WalCompactionAfterRestartTest -- yes we need it. This test failed because
> of race (test shold be rewritten a little bit)
>
> пт, 30 окт. 2020 г. в 16:15, Max
Hi
WalCompactionAfterRestartTest -- yes we need it. This test failed because
of race (test shold be rewritten a little bit)
пт, 30 окт. 2020 г. в 16:15, Max Timonin :
> Hi!
>
> Yes, you're correct. I've developed the check and started to clean tests
> (move them to suites, mark some tests with
Hi!
Yes, you're correct. I've developed the check and started to clean tests
(move them to suites, mark some tests with Ignore, etc.). I finish work on
the core module. I hope it was the biggest one, and others are less. If so,
I think I will finish the work on other modules in 1 or 2 weeks, as I
Folks,
What's the current state of this thread?
AFAIU, we found unused and wrongly located tests and developed some
checker, could we split this to some PRs?
Let's merge tests usage fix and location fixes first, this will provide us
an ability to automate check using Travis.
On Tue, Oct 20, 2020
> When TLS 1.3 is introduced, whole sun.security.ssl.SSLSocketImpl was
> rewritten.
Correct, I meant rewritten TLSv1.3, the good news that 1.2- also were fixed.
so,
-- brand new TLS with any linger
-- plain old TLS with linger>0
On Fri, Oct 30, 2020 at 3:10 PM Ivan Daschinsky wrote:
> Ilya,
Ilya, Anton.
It means that not if TLS 1.3 is worked ok and with TLS < 1.2 is not ok.
When TLS 1.3 is introduced, whole sun.security.ssl.SSLSocketImpl was
rewritten.
There is not any code anymore that could cause a deadlock.
Therefore, in JDK, that supports TLS 1.3, this option is unnecessary,
Vladimir Steshin created IGNITE-13646:
-
Summary: Discovery ducktape test might have setting for socket
linger.
Key: IGNITE-13646
URL: https://issues.apache.org/jira/browse/IGNITE-13646
Project:
Vladimir Steshin created IGNITE-13645:
-
Summary: Discovery ducktape test should detect failed nodes by
asking the cluster.
Key: IGNITE-13645
URL: https://issues.apache.org/jira/browse/IGNITE-13645
Ilya
> I think we should still keep setting linger if SSL is enabled
Modern (updated) JVMs do not require this.
AFAIK, Problem caused this workaround already fixed everywhere, including
JDK 8.
> If SSL only works with TLSv1.3 and no linger
SSL works if
-- TLSv1.3 with any linger
-- TLSv1.2- with
Hello!
I think we should still keep setting linger if SSL is enabled, and not
expect user to enable it (or face consequences).
If SSL only works with TLSv1.3 and no linger, we should make TLSv1.3 a
default. If JVM does not support it, user will have to reconfigure
explicitly.
Regards,
--
Ilya
Hi!
Vova, I agree with you, this default behaviour is quite confusing. Even if
we want to workaround bug for old jdk's and SSL,
it's strange idea to affect all other users by default. I think that we
should add section in documentation how to workaround this issue,
and disable socket linger on
*
Hi, Igniters.
We’ve found that enabled by default socket linger causes unexpected
delay in detection of node failure.
Moreover, long closing of socket works as Thread.sleep() within
algorithms of failure detection and connection recovery in TCP
discovery. These time gaps lead to hardly
Hello!
I guess that you have EVT_NODE_METRICS_UPDATED event enabled on client
nodes (but maybe not on server nodes)
It will indeed produce a lot of garbage so I recommend disabling the
recording of this event by calling
ignite.events().disableLocal(EVT_NODE_METRICS_UPDATED);
+ dev@
Why do we
Nikolay, thank you!
Ilya Kazakov
пт, 30 окт. 2020 г. в 13:58, Nikolay Izhikov :
> Hello, Ilya.
>
> This task already solved:
>
> 1. We have system view
> https://apacheignite.readme.io/docs/continuous_queries
> 2. We have ability to output any view via
>
> `./control.sh
Alexey,
Thanks for details!
Common replication infra suggestion looks great!
Agree with your points regarding per-page replication, but still have a
feeling that this protocol can be made compact enough, e.g. by sending only
deltas. As far as entry processors we can decide on what to send - if
26 matches
Mail list logo
