Mikhail,
So, I suppose there should be ordering guarantees that listener is
registered before first validation failure can occur. Hope
GridComponent#onKernalStart is the right place. Is it enough to pass
only problematic node id (or ClusterNode) with an event? Actually such
event seems to fit natu
I think we also should provide the reason why join failed.
> 3 дек. 2019 г., в 12:22, Ivan Pavlukhin написал(а):
>
> Mikhail,
>
> So, I suppose there should be ordering guarantees that listener is
> registered before first validation failure can occur. Hope
> GridComponent#onKernalStart is the
Ivan,
for me GG docs have more clear information on the subject.
As soon as community will improve docs quality link could be changed back
to Apache.
сб, 30 нояб. 2019 г. в 17:22, Ivan Pavlukhin :
> Alexei,
>
> > Ivan, the link is intentional.
>
> Could you please elaborate why is it fine to hav
How that reason will look like? Actually, I mostly thinking about
general API here. What I would like to avoid is exposing something not
general but needed only for a particular extension (plugin).
вт, 3 дек. 2019 г. в 12:31, Николай Ижиков :
>
> I think we also should provide the reason why join
Exception(s) from component(s) that don’t want node joined.
> 3 дек. 2019 г., в 12:39, Ivan Pavlukhin написал(а):
>
> How that reason will look like? Actually, I mostly thinking about
> general API here. What I would like to avoid is exposing something not
> general but needed only for a particu
Maxim,
I'm not sure this is purely a "tombstone" problem, could be a tree
concurrency issue.
Looks like the investigation is required.
For example, tombstone logic can be reverted but test logic is kept.
It seems Ivan Rakov already suggested to revert a commit from master branch
in another thread
Nikolay, Ivan,
I understood the possible problem. It seems that it can be solved using
EventStorageSpi which starts before DiscoveryManager.
As for me, ClusterNode is enough. It contains all info about joining
node including its attributes.
Discovery events such as (join/left/failed) are co
Alexey,
Yet another issue [1] with corrupted B+Tree exception on the master branch.
My suggestion is to revert the IGNITE-11704 [3] issue from the master
branch and rework the patch.
Any objections?
Configuration:
[1] persistence = false
[2] persistence = true
class
org.apache.ignite.internal
Mikhail,
Yep, I see IgniteNodeValidationResult in new event in PR [1].
> Discovery events such as (join/left/failed) are connected with a
> topology version change. In my case that not happens and may be
> misleading. That's why the new event type was chosen.
I did not mean that one of those eve
No objections.
вт, 3 дек. 2019 г. в 15:02, Maxim Muzafarov :
> Alexey,
>
>
> Yet another issue [1] with corrupted B+Tree exception on the master branch.
> My suggestion is to revert the IGNITE-11704 [3] issue from the master
> branch and rework the patch.
>
> Any objections?
>
> Configuration:
>
Pavel Tupitsyn created IGNITE-12414:
---
Summary: .NET: Performance: review
CopyOnWriteConcurrentDictionary.GetOrAdd usage and locking
Key: IGNITE-12414
URL: https://issues.apache.org/jira/browse/IGNITE-12414
Ilya, Yuriy,
It seems that text queries can return incorrect results on tologies
with MOVING partitions. I left a comment in JIRA [1].
[1] https://issues.apache.org/jira/browse/IGNITE-12401
пн, 2 дек. 2019 г. в 15:00, Ivan Pavlukhin :
>
> Ilya,
>
> I checked your test on a revision before "limit
*on topologies
вт, 3 дек. 2019 г. в 17:15, Ivan Pavlukhin :
>
> Ilya, Yuriy,
>
> It seems that text queries can return incorrect results on tologies
> with MOVING partitions. I left a comment in JIRA [1].
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12401
>
> пн, 2 дек. 2019 г. в 15:00, Iv
Folks,
In a thread about a document describing data consistency [1] in Ignite
it was identified that there is a link to GridGain documentation.
I do not have strong arguments against having such links in community
wiki. But it interesting to me to discuss the subject with community.
Might be ther
Igniters,
I'd like to discuss adding full-text queries (TextQuery, our Lucene-based
engine) to the Thin Client protocol.
In my opinion, this is a good addition, and rather easy to implement.
However, I vaguely remember in-person discussions with some community
members along the lines of
"Ignite f
Oh wow, the next thread actually discusses this very issue about
discontinuation:
http://apache-ignite-developers.2346864.n4.nabble.com/Text-queries-indexes-GridLuceneIndex-QueryTextFiled-td43335.html
But the question stands - add to Thin Clients or not?
On Tue, Dec 3, 2019 at 5:43 PM Pavel Tupit
Pavel,
I'm against adding this feature, as there were talks recently, that we
should stop supporting TextQuery altogether. No sense in adding
something, that we will need to depreciate and remove soon.
Best Regards,
Igor
On Tue, Dec 3, 2019 at 5:46 PM Pavel Tupitsyn wrote:
> Oh wow, the next
Hi Ivan,
If an author of an article believes that there is a 3rd party resource that
is handy and helpful for his/her work then there is nothing wrong to refer
to it. Based on Alexey's response in another thread, that GridGain page
brings more clarity to the topic, thus, don't see any issue with t
Hi Igniters,
It is not good if we'll made a tradition of linking to company websites
from the community website / wiki / lists. But if it makes sense to mention
something useful for users, why not.
And in this particular case it may be ok, if it is relevant. Just remember,
community resources are
Hello, Igniters.
Looks like we have an issues with the TC agents disc space [1]
Can someone take a look?
[1]
https://ci.ignite.apache.org/viewLog.html?buildId=4809938&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_PlatformCPPLinuxClang
20 matches
Mail list logo
