Folks,
I made SpiUriDeploy job successful by enforcing jdk 8 and not passing
any extra jvm arguments for an extra compile step (Step 4: Pre-compile
external data). Everything is running fine so far [1].
[1]
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_SpiUriDeploy&ta
Seems to be an interference of two commits related to continuous
queries [1, 2]. In one a test was added and the test was broken by
another commit.
Ivan, Denis, could please take a look?
[1]
https://github.com/apache/ignite/commit/db74e92dcd56bc5a45ed9d3a382be8bcfa2a76dc
[2]
https://github.com/
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 contribution to this project, but things change and you
may no longer be able to finalize
Looping in Ignite dev community,
Nikolay, in my understanding the new metrics & tracing framework will be
flexible enough so that we can add required metrics for data structures
like queues. Is this counted in our design?
-
Denis
On Mon, Jul 1, 2019 at 8:42 AM Ilya Kasnacheev
wrote:
> Hello!
Hey Anton, Amir,
Looks like we've abandoned the multimap support somewhere close to the
finish line. What's left open? Should we find another contributor who can
finish the feature?
-
Denis
On Wed, Sep 5, 2018 at 2:33 AM Anton Vinogradov wrote:
> Denis,
> Discussion relocated to the issue.
>
I removed command line arguments enabling java.transaction and
java.corba module from TC configuration. All activity in a ticket [1].
[1] https://issues.apache.org/jira/browse/IGNITE-11946
вс, 30 июн. 2019 г. в 07:31, Павлухин Иван :
>
> I made 2 experiments:
> 1. Removed --add-modules=java.trans
Amelchev Nikita created IGNITE-11961:
Summary: Provide JMX metrics for PME timings
Key: IGNITE-11961
URL: https://issues.apache.org/jira/browse/IGNITE-11961
Project: Ignite
Issue Type: Im
Nikolay Izhikov created IGNITE-11960:
Summary: Throw on attemp to create existing metric
Key: IGNITE-11960
URL: https://issues.apache.org/jira/browse/IGNITE-11960
Project: Ignite
Issue Ty
Nikolai,
Metric is disabled if it doesn't allocate any memory and doesn't
update any variable because doesn't have any value. Ideally disabling
metrics for some cache should be equal to cache stopping.
On Fri, Jun 28, 2019 at 1:02 PM Nikolay Izhikov wrote:
>
> Hello, Alexey.
>
> Thanks for the f
Ivan,
Some notes about your comments:
> 1. Specifying subset of metrics which are exported to an external system.
I believe there are no any subset if metrics except of metrics related
with one particular source. Also I think that there is no need to
filter out metrics set on export stage. If so
Kirill Tkalenko created IGNITE-11959:
Summary: NullPointerException If transaction failed and failure
handler doesn't configured explicitly
Key: IGNITE-11959
URL: https://issues.apache.org/jira/browse/IGNITE-1
Denis Chudov created IGNITE-11958:
-
Summary: JDBC connection validation should use it's own task
instead of cache validation task
Key: IGNITE-11958
URL: https://issues.apache.org/jira/browse/IGNITE-11958
Ilya, Dmitriy,
Are we going to drop only compilation on Java 9 and 10 but continue
running tests on all versions (8-11)? The idea sounds ok to me. But to
be honest I must say that currently we compile Ignite only using Java
8.
Also it does not help me to fix SpiUriDeploy job. It has an extra
comp
It was by mistake. Let's drop 9 && 10 compilation.
ср, 3 июл. 2019 г. в 12:54, Ilya Kasnacheev :
> Hello!
>
> Dmitry, why did you switch maven.compiler.target to 11 when using Java 9+
> in maven.compiler.target? Indeed it breaks compilation on Java 9-10. This
> is in IGNITE-11189
>
> BTW they are
Hello!
Dmitry, why did you switch maven.compiler.target to 11 when using Java 9+
in maven.compiler.target? Indeed it breaks compilation on Java 9-10. This
is in IGNITE-11189
BTW they are unsupported now, maybe we just drop them for good? Ivan what
do you think?
Regards,
--
Ilya Kasnacheev
ср,
Hi Nikolay,
Thank you for clarifications.
> What is "disabled" sensor? Why do we need it? (as long as sensort is just a
> AtomicLong)
I meant a possibility of disabling a particular metric value
calculation (skipping AtomicLong.incrementAndGet call). My current
understanding that we do NOT need
Hi Ilya,
Yep there is no problem with Java 12 and 11 as well because a
following option is specified in parent pom:
11
The only easy way I found is to use
9 (for java-9+
profile). Another option could be supplying maven with
-Dmaven.compiler.target argument calculated for a used jdk version.
Wha
17 matches
Mail list logo
