Pavel,
That would be a tremendous improvement for the recently release best effort
affinity feature. Without this capability, we force application developers
to reopen thin client connections every type a cluster is scaled out. I
believe that once the folks start using the best effort affinity,
o avoid
> performance problems with SQL queries. Problem indexes:
>
> PUBLIC#TEST_TABLE#L_IDX(1,3),PUBLIC#TEST_TABLE#S1_IDX(1,3),PUBLIC#TEST_TABLE#I_IDX(1,3)
>
>
> Utility output, if a difference in inline sizes was found:
>
> Control utility [ver. 2.9.0-SNAPSHOT#20200427-sha1:
Hi Nikolay,
1. Can we update the DEVNOTES.txt to contain build command as below
"mvn clean install" instead of "mvn clean install
-Pall-java,all-scala,licenses -DskipTests"
I have verified that the build passes with tests and also we do not have
tasks such as all-java, all-scala or licenses.
Nikolay, thanks for responding,
Would you prefer adding this item to the roadmap page after finishing the
idea testing? If there are still many unknowns it can make to the roadmap
after you share the results and propose a final solution.
-
Denis
On Mon, Apr 27, 2020 at 2:06 PM Nikolay Izhikov
Hi Petr,
Yes, I have created an issue to update TC configuration once changes are
merged.
https://issues.apache.org/jira/browse/IGNITE-12960
Please let me know if the PR changes looks good.
Regards,
Saikat
On Mon, Apr 27, 2020 at 1:39 AM Petr Ivanov wrote:
> Please, remember to update TC
Saikat Maitra created IGNITE-12960:
--
Summary: Remove twitter module tests from Teamcity Streamers
TestSuite
Key: IGNITE-12960
URL: https://issues.apache.org/jira/browse/IGNITE-12960
Project: Ignite
Hi Nikolay,
Sorry for being picky about the documentation but I would encourage us as
the community to prepare this release artifact before sending a release for
a vote. As you might remember, we agreed to update the release process [1]
to ensure this practice is followed. Just in case that's a
+1
пн, 27 апр. 2020 г. в 23:26, Nikolay Izhikov :
> +1 (binding)
>
> I’ve checked uploaded artifacts with the test application [1]
>
> [1] https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
>
> > 27 апр. 2020 г., в 23:24, Nikolay Izhikov
> написал(а):
> >
> > Dear Community,
>
Hello, Igniters.
Right now I working on POC for some «framework» for integration testing of
Ignite.
Feature I want to see in this framework:
* To manage several Ignite instances inside docker or bare metal
servers.
* To manage Ignite cluster
* Start/stop arbitrary
Yeah, I remember that because I used this approach when I implemented
first experimental version of partition awareness for the C++ thin client.
Only thing we need to add is the "ThinClientPort" node attribute, or
something like that.
Best Regards,
Igor
On Mon, Apr 27, 2020 at 8:41 PM Pavel
+1 (binding)
I’ve checked uploaded artifacts with the test application [1]
[1] https://github.com/nizhikov/ignite-spring-boot-autoconfigure-example
> 27 апр. 2020 г., в 23:24, Nikolay Izhikov написал(а):
>
> Dear Community,
>
> I have uploaded a release candidate of the two extension modules
Dear Community,
I have uploaded a release candidate of the two extension modules
`ignite-spring-boot-autoconfigure` and
`ignite-spring-boot-client-autoconfigure`.
The following staging can be used for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1478/
Tag with
Amelchev Nikita created IGNITE-12959:
Summary: Add support for GenericWhitespace to checkstyle rules
Key: IGNITE-12959
URL: https://issues.apache.org/jira/browse/IGNITE-12959
Project: Ignite
Amelchev Nikita created IGNITE-12958:
Summary: Add licenses check to Travis configuration
Key: IGNITE-12958
URL: https://issues.apache.org/jira/browse/IGNITE-12958
Project: Ignite
Issue
Igor, actually you are right.
We already have org.apache.ignite.ips node attribute, which contains all
the IPs.
No need to add anything else, just filter the value according to
IgniteConfiguration.LocalHost.
I'll update the IEP and POC.
Thanks
On Mon, Apr 27, 2020 at 8:17 PM Pavel Tupitsyn
> There is already a list of addresses of every node kept by every node,
isn't it?
Can you please elaborate, what exactly do you mean here?
Sure, we can get addresses of other nodes from Discovery/Communication SPIs,
but those addresses may be not what we want. Nodes can belong to multiple
Pavel Tupitsyn created IGNITE-12957:
---
Summary: .NET: Docs have unavailable resource logo3.png
Key: IGNITE-12957
URL: https://issues.apache.org/jira/browse/IGNITE-12957
Project: Ignite
Anton Vinogradov created IGNITE-12956:
-
Summary: Fully prepared TX rolled back on recovery if TX
coordinator failed and some primary has only reads
Key: IGNITE-12956
URL:
Maxim,
I saw the list of the tickets you want to work on in the PR, it looks nice.
I was wondering, what part of that list are you planning to implement
before the feature is released to end users? For example, I agree with
Slava that we should implement a command-line utility part for snapshots
Great, this feature is long awaited.
1. I believe so. Since I've proposed Partition Awareness feature I was
thinking
about a way for clients to discover cluster nodes.
2. In my opinion a simple boolean flag is enough for the beginning. In
future
maybe we can add a node filter. This can be useful
Maxim,
> 1. The Apache Ignite may start multiple instances...
Ignite codebase contains something more than Ignite instances code:
control utility, tests. And it does not sound good to me to use some
project-specific naming rule if it is not really critical. I wish
Ignite coding guidelines are as
Sergey Antonov created IGNITE-12955:
---
Summary: Document a new command control.sh --cache
check_index_inline_sizes
Key: IGNITE-12955
URL: https://issues.apache.org/jira/browse/IGNITE-12955
Project:
-SNAPSHOT#20200427-sha1:DEV]
2020 Copyright(C) Apache Software Foundation
User: santonov
Time: 2020-04-27T15:32:25.759
Command [CACHE] started
Arguments: --cache check_index_inline_sizes --yes
Found 4 secondary indexes.
3
Pavel, Ivan,
Let me clarify some details you missed which may lead you to the light side.
1. The Apache Ignite may start multiple instances on the same VM, so
keeping a class field `static` for mutable objects have no sense in
most of the cases. In case of keeping, the immutable structure will
Hi, Maxim
> But what exactly is `constant` means?! I'd suggest applying this rule
> to all class fields with `static final` modifiers without any clauses.
> (check Java Naming convention [2] paragraph 3.3).
I read this convention [1] and found clarifying exclusion (3.3.2):
All static final
Folks,
Are there any cases left which we need to discuss?
Do you have any questions?
I'm ready to provide all the details you need for the review.
Who else what to take a look at my changes [1] [2]?
[1] https://issues.apache.org/jira/browse/IGNITE-11073
[2]
>> +1 to force upper case for `static final` variables.
+1 too
On Mon, Apr 27, 2020 at 12:08 PM Nikolay Izhikov
wrote:
> +1 to force upper case for `static final` variables.
>
> > 25 апр. 2020 г., в 07:39, Ivan Pavlukhin
> написал(а):
> >
> > Maxim,
> >
> > Thank you for efforts in a code
Hello, Konstantin.
> I think we cannot just turn this optimization on
Why is that?
If we turn on `OPTIMIZE_REUSE_RESULT` consequences would be the following:
* concurrent updated of the subquery table will not be used(we have no
guarantee on that, for now)
* performance of the select increase
Igniters,
I've prepared an IEP [1] and a POC [2] for Thin Client Discovery feature.
Let's discuss it here.
In particular, I'd like to address the following points:
1. Value: do you think this would be a good feature to have?
2. Public API changes: is a boolean property enough? Should we have
+1 to force upper case for `static final` variables.
> 25 апр. 2020 г., в 07:39, Ivan Pavlukhin написал(а):
>
> Maxim,
>
> Thank you for efforts in a code quality improvement!
>
> Unfortunately I do not agree with the proposal. Usually I like to
> refer a following guide [1]. While a question
Taras.
Thank you, very much!
You changes merged to 2.8.1 branch.
Igniters,
We have 10 tickets scheduled for 2.8.1 release:
OPEN:
IGNITE-11687Concurrent WAL replay & log may fail with CRC error on read -
Dmitriy Govorukhin
IGNITE-12346.NET: Platform error:System.NullReferenceException
Hi,
Nikolay, i've created PR [1] that contains the SQL-related tickets to
port into 2.8.1:
IGNITE-12790 Introduce distributed SQL configuration and ability to
disable SQL functions.
IGNITE-12887 Fix handle type mismatch exception on compare values while
traversing index tree.
IGNITE-12848
Please, remember to update TC configuration or create issue to do that.
> On 26 Apr 2020, at 20:40, Saikat Maitra wrote:
>
> Hi,
>
> I have raised PRs for migration of twitter module in ignite-extensions
> repository.
>
> Jira
> https://issues.apache.org/jira/browse/IGNITE-12357
>
> PRs
>
33 matches
Mail list logo
