t; Exporters expose metrics if they are disabled.
>
> We don’t have an ability to disable metrics.
> And that done, intentionally.
> You are working on this issue, aren’t you?
> I can fix this issue, by myself.
>
> > Metrics of type lists are not metric at all.
>
> The
ly, it’s a responsibility of the exporter to decide.
> JMX exporter can exports ObjectMetric while OpenCensus exporter can’t.
>
> [1]
> https://github.com/apache/ignite/pull/7269/files#diff-0ae5657231fc4c1f650493b02190b81bR25
>
> > 17 янв. 2020 г., в 16:57, Andrey Gura на
l haunt us till next major release. I'll create tickets.
On Fri, Jan 17, 2020 at 7:03 PM Andrey Gura wrote:
>
> >> Because it is brand new API and it requires rewrite client code.
> > We doesn’t break backward compatibility.
> > The message is - this interface wo
osal for the API change and discuss them.
>
> > Because IGNITE-11927 doesn't solve all problems
>
> What is *ALL* problems?
> Seems, we never be able to solve *ALL* problems.
> But, we should move the product forward.
>
> As for your steps [1-6].
> I’m always followin
It would be grate.
Only one comment: we can't cancel service or service's method
execution because service grid API doesn't imply any requirement to
service implementation. So if user do something like infinite cycle or
blocking but non-interruptible operation it's impossible to interrupt
it. Also
cs.
> 2. This is not public API issue.
>
>
> > Ignoring of statisticsEnabled flag.
>
> I don’t ignore this flag.
> It just doesn’t exists in new framework(because of scope).
> I don’t think it’s an issue.
>
> > JmxExporterSpi creates beans that doesn't satisfy
ance problem).
> >
> > 1. We(You and I) did this choice together to simplify creation of the new
> > metrics.
> > 2. This is not public API issue.
> >
> >
> > > Ignoring of statisticsEnabled flag.
> >
> > I don’t ignore this flag.
> > It
gt; > > > Why this is issue?
> > > >
> > > > > Inconsistent MetricRegistry API.
> > > >
> > > > It’s consistent.
> > > >
> > > > > Metrics lookups from map instead of using direct reference
> > > >
//issues.apache.org/jira/browse/IGNITE-12553
>
>
> > 20 янв. 2020 г., в 13:08, Andrey Gura написал(а):
> >
> > It solves problem.
> >
> > On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
> > wrote:
> >>
> >> After giving it some thought, I
to fix only the
> >>>>> first one and add the experimental marker so that we do not delay 2.8
> >>>>> release.
> >>>>>
> >>>>> пн, 20 янв. 2020 г. в 13:32, Николай Ижиков :
> >>>>>
> >>>>>>
desired usages.
>
> This will help to the community and me personally better understand your idea
> and share feedback.
>
> Thanks.
>
> > 23 янв. 2020 г., в 17:15, Andrey Gura написал(а):
> >
> > Nikolay,
> >
> > as I wrote early in this thread API si
; argument to postpone creation of the API in the current release.
>
>
> > 23 янв. 2020 г., в 18:11, Andrey Gura написал(а):
> >
> >> We don’t discuss your changes and your proposals for the Metric API.
> >
> > You want say didn't discuss? Actually we di
Igniters,
I want to add one more issue to the Apache Ignite 2.8 release scope [1].
The problem is impossibility of using communication metrics gathered
for nodes in the cluster because node ID will changed in case of
restart. Obvious solution is using consistent ID instead of node ID.
PR is alre
there is no performance drop.
> Note, that these metrics updated on each communication message.
>
> > 27 янв. 2020 г., в 18:19, Andrey Gura написал(а):
> >
> > Igniters,
> >
> > I want to add one more issue to the Apache Ignite 2.8 release scope [1].
> >
&
n
> current master so we should change this code carefully
>
> https://github.com/apache/ignite/blob/ignite-2.7.6/modules/core/src/main/java/org/apache/ignite/spi/communication/tcp/TcpCommunicationSpi.java#L1178
>
> > 27 янв. 2020 г., в 20:40, Andrey Gura написал(а):
> >
&g
come back to the discussion of the changes itself?
> >>> I think API changes should be discussed in the other thread.
> >>>
> >>>> Why do you think this is a wrong usage pattern? From the top of my
> >> head, here is a few cases of direct met
ave free servers to do
> it.
>
>
> > 27 янв. 2020 г., в 21:47, Andrey Gura написал(а):
> >
> >>> "If it doesn’t work, it doesn’t matter how fast it doesn’t work." (c)
> >> Please, clarify, what do you mean by «doesn’t work»?
> >> Are there
ults
> > >
> > > I perform benchmarking for initial refactoring of
> > TcpCommunicationMetricsListener.
> > > Initial refactoring of TcpCommunicationMetricsListener doesn’t bring any
> > performance drop according to the results of the tests I performed.
>
for Slack )
On Wed, Jan 29, 2020 at 8:17 PM Andrey Gura wrote:
>
> +1
>
>
> On Wed, Jan 29, 2020 at 7:59 PM Denis Magda wrote:
> >
> > Folks, why don't you name the channel "ignite-spring-framework_russian" in
> > Slack ;)
> >
> > -
&
+1
On Wed, Jan 29, 2020 at 7:59 PM Denis Magda wrote:
>
> Folks, why don't you name the channel "ignite-spring-framework_russian" in
> Slack ;)
>
> -
> Denis
>
>
> On Wed, Jan 29, 2020 at 12:50 AM Maksim Stepachev <
> maksim.stepac...@gmail.com> wrote:
>
> > Yes, I do.
> >
> > ср, 29 янв. 2020 г
>From my point of view we still don't have consensus.
I think we should do at least the following:
1. Remove @Deprecated from old API (because it strange to have one
deprecated API and second experimental API)
2. Add @IgniteExperimetnal to new API (because... see item. 1)
3. Do not merge IGNITE-1
.dataregion.pageCount»
>
> Andrey.
>
> We doesn’t come to an agreement that API should be changed.
> We should discuss the design of the Metric API and your proposals for it in
> another thread.
>
> Please, avoid arguments like «this API will be 100% changed» in this
>
I'll just repeat one thought with some changes.
There are at least two groups of people in this discussion. One group
sure that new API is complete and production ready while other group
disagree with it. Obviously we can't reach consensus about it right
now. But we can do it in the future.
At pre
e deprecation for now and unblock the release.
>
> On Thu, Jan 30, 2020 at 10:23 PM Andrey Gura wrote:
>
> > I'll just repeat one thought with some changes.
> >
> > There are at least two groups of people in this discussion. One group
> > sure that new API is c
Hi, Lev!
I think you understand task correctly.
A couple of comments:
- Existing annotations and related functionality must not be deleted
because it is part of public API and we committed to have stable API
between major releases.
- I would suggest introduce @MXBeanParameter annotation instead
ionality.
> So, I can't change implementation of *getDescription / getParameterName
> (MBeanOperationInfo op, MBeanParameterInfo param, int seq)* methods from*
> IgniteStandardMXBean* class,
> and replace current annotations with new one.
>
> вт, 4 февр. 2020 г. в 14:28, Andrey Gura :
MXBeanParametersNames and MXBeanParametersDescriptions could be marked
as deprecated if MXBeanParameter will be added.
On Tue, Feb 4, 2020 at 5:12 PM Ivan Pavlukhin wrote:
>
> Should we mark old annotations deprecated?
>
> вт, 4 февр. 2020 г. в 16:57, Andrey Gura :
> >
>
d should I also replace usage of old annotations or leave it as it is?
>
> вт, 4 февр. 2020 г. в 16:57, Andrey Gura :
>
> > Lev,
> >
> > > I'm confused about your first comment. Does it mean, that the only thing
> > I
> > can do is to create new annotation?
&g
rs. So, my question was the order of searching
> annotations (first - old, after - new).
>
> вт, 4 февр. 2020 г. в 21:10, Andrey Gura :
>
> > > Andrey, then I suggest firstly check if old annotations are present, and
> > if
> > > not - are there any new annotat
Anton, Mikhail,
I stumbled upon impossibility to configure plugin with out adding
appropriate class names to org.apache.ignite.plugin.PluginProvider
file and found change where this possibility was added [1].
Thanks a lot for this change. I noticed also that
IgniteConfiguration.setPluginProviders
One comment about first choice.
The formulation has one issue from my point of view: Never deprecate
the old APIs unless the new APIs are stable *and released* without
@IgniteExperimental.
Actually we can introduce new stable API and deprecate old API at the
same time without releasing of new API
re there any reasons to continue support
> of the ServiceLoader approach, given the fact that configurations needed
> for a plugin, in this case, are also specified via IgniteConfiguration?
> Moreover, why someone should mix those approaches?
>
> On 05.02.2020 17:35, Andrey Gura wrote:
> &g
+1
By the way, is there any reason to have this code in the master
branch? It seems feature is in unsupportable state and just wastes TC
time and our effort to support MVCC related tests.
On Thu, Feb 6, 2020 at 2:44 PM Alexey Goncharuk
wrote:
>
> Agree, let's mark MVCC experimental.
>
> Stephen,
> > > > If it does too much strain on the TC, let's discuss that, but I don't
> > > > remember problems with TC load lately, so maybe this is a moot point.
> > > >
> > > > Regards,
> > > > --
> > > > Ilya Kasnacheev
> > > >
> > >
don't
> > remember problems with TC load lately, so maybe this is a moot point.
> >
> > Regards,
> > --
> > Ilya Kasnacheev
> >
> >
> > чт, 6 февр. 2020 г. в 15:27, Nikolay Izhikov :
> >
> > > > By the way, is there any reason
-1 Prohibit
On Mon, Feb 10, 2020 at 11:02 AM Alexey Goncharuk wrote:
>
> Dear Apache Ignite community,
>
> We would like to conduct a formal vote on the subject of whether to allow
> or prohibit a joint existence of @deprecated annotation for an old API
> and @IgniteExperimental [1] for a new (re
Lev,
it's enough to comment corresponding JIRA ticket. It already contains
all needed info (links to PR, TC bot, etc) and also all changes to the
ticket will be sent to the dev list.
On Fri, Feb 14, 2020 at 1:31 PM Лев Киселев wrote:
>
> Hello everyone,
> I've fixed codestyle issues in my branch
I couldn't find any usages too.
But value if this property is serialized in some places and we can't
remove this due to a backward compatibility.
I think we can safely remove it on 3.0. But for now it is better to
mark it as deprecated.
On Thu, Feb 13, 2020 at 5:42 PM Alexey Goncharuk
wrote:
>
No )
The reasons is serialization of this field. We can mark it as
deprecated and remove in 3.0.
On Thu, Feb 13, 2020 at 6:08 PM Alexei Scherbakov
wrote:
>
> I think yes.
>
> чт, 13 февр. 2020 г. в 16:52, Ivan Pavlukhin :
>
> > Hi,
> >
> > It seems I found some more unused configuration properti
Agree with Andrey and Slava.
Your change could lead to exception in case when current thread does
not own read lock.
> Checking for a writе lock holding through method isHeldByCurrentThread is not
> atomic, so there is no certainty that this thread still owns a write lock.
What do you mean when
Hi there,
what if we will generate proxy that collects service's metrics only if
service will implement some special interface? In such case:
- we won't affect existing services at all.
- we can impose additional requirement for services that want use
metrics out of box (i.e. service that impleme
Ivan,
targeting to specific version means that this change should be
included in release with target fix version. No more, no less.
On Wed, Mar 11, 2020 at 2:42 AM Ivan Pavlukhin wrote:
>
> Igniters,
>
> Initially I wanted to delay the discussion about everything related to
> 2.8.1 until all 2.8
r some bug with metrics aggregation during
discovery metrics message round trip.
On Wed, Mar 11, 2020 at 12:05 AM Denis Magda wrote:
>
> @Nikolay Izhikov , @Andrey Gura ,
> could you folks check out this thread?
>
> I have a feeling that what Dominik is describing was talked out
nvalid for me. And I expect problems from such issues in the future.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12756
> >
> > Best regards,
> > Ivan Pavlukhin
> >
> > ср, 11 мар. 2020 г. в 03:23, Andrey Gura :
> > >
> > > Ivan,
&
Aleksey,
> My propose:
> ~ June 01 - 2.8.1
> ~ September 01 - 2.8.2
> ~ November 01 - 2.9.0
What is your motivation for such release schedule? I believe release
should be features/fixes driven not by time/deadline driven.
We can release 2.8.x versions every week yet (as maintenance
releases). Bu
never used it :)
>>
>> Also it would be great to know what version of Apache Ignite used in
>> described case. I remember some bug with metrics aggregation during
>> discovery metrics message round trip.
>>
>> On Wed, Mar 11, 2020 at 12:05 AM Denis Magda wrote:
Denis,
I agree with you.
Also I think that we should move to process which will require
documentation updates during work on issue/feature and will part of
code review process. Such approach has some useful benefits:
- Documentation readiness at the same time when fix/implementation is
ready (re
ce#service()
>
>
> - Make service metrics enabled by default for all services.
>
>
> - Bring system param which disables metrics by default for all services.
>
>
> - Bring parameter/method in MetricsMxBean which allows disabling/enabling
> metrics for all servic
not break backward compatibility and will always return proxy.
>
> Why not using IgniteServices.serviceProxy() for that? Since it requires an
> interface, It could return proxy for local service too and
> keep backward compatibility at the same time.
>
> 16.03.2020 20:21, Andrey Gura пишет:
> &g
Igniters,
please, notice that right commit message format the following:
IGNITE- my message
There is no colon (:) after . There is no hyphen (-) between
and message. There is only one space.
How to contribute doc [1] doesn't state this as requirement and just
contains some examples
/kafka/commits/trunk
> [2] https://github.com/apache/hive/commits/trunk
> [3] https://github.com/openjdk/jdk/commits/master
>
> Best regards,
> Ivan Pavlukhin
>
> чт, 19 мар. 2020 г. в 23:15, Alexey Zinoviev :
> >
> > Ok, lets keep in mind and remind du
all.
> >
> > And please answer the question from my previous message:
> > > Is there any any harm from a "colon" in a commit message?
> >
> > In my opinion current state with commit messages prefixes is totally
> > fine and there is no need to change any
TcpCommunication SPI metrics
> >> improvement" - it depends
> >> on https://issues.apache.org/jira/browse/IGNITE-12735 and
> >> https://issues.apache.org/jira/browse/IGNITE-12568,
> >> both were targeted to 2.9, but this has to be changed probably.
>
Definitely agree with Alexey Goncharuk. Mentioned FH implementations
don't terminate JVM.
I think returning KILL_EXIT_CODE is bad idea because actually process
wasn't terminated using SIGINT. So it contradicts to motivation
described in proposal.
Also how could it help to administrators. For exam
Sergey, Anton, Kirill,
I think we have to do not change anything in FH. At least without
enough motivation.
Now I see only assumption that it "could be helpful for administration
purposes". It isn't enough, I believe.
On Tue, Jun 2, 2020 at 4:59 PM ткаленко кирилл wrote:
>
> Hello, Alexey!
>
>
t implementation StopNodeOrHaltFH uses Runtime#halt(). This method
> doesn't cause shutdown hooks. Why we don't try to stop the node by
> System#exit() before Runtime#halt()?
>
>
> вт, 2 июн. 2020 г. в 17:18, Andrey Gura :
>
> > Sergey, Anton, Kirill,
> >
nvocation before Runtime#halt().
>
> вт, 2 июн. 2020 г. в 17:51, Andrey Gura :
>
> > > Current implementation StopNodeOrHaltFH uses Runtime#halt(). This method
> > > doesn't cause shutdown hooks. Why we don't try to stop the node by
> > > System#exit()
I've prepared PR [1]
I already tried to discuss commit message format [2] but stumbled upon
some criticism. I still believe that we have to follow only one
standard. It is unrelated with any annoying. It is just normal
practice which also allows avoid of precedents with references to any
concessio
t ok to continue like this, or do you think we should remove ":" here
> as well?
>
> On Wed, Jun 3, 2020 at 4:38 PM Andrey Gura wrote:
>
> > I've prepared PR [1]
> >
> > I already tried to discuss commit message format [2] but stumbled upon
> > some cr
; >
> > Can you merge it?
> >
> > Thanks,
> > --
> > Ilya Kasnacheev
> >
> >
> > ср, 3 июн. 2020 г. в 16:38, Andrey Gura :
> >
> > > I've prepared PR [1]
> > >
> > > I already tried to discuss commit message for
+1
I don't see any badges.
On Wed, Jun 10, 2020 at 10:27 PM Ilya Kasnacheev
wrote:
>
> Hello!
>
> I don't see such a badge. Instead I see "Watch" "Star" "Fork".
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> ср, 10 июн. 2020 г. в 20:58, Ivan Pavlukhin :
>
> > Hi Igniters,
> >
> > I noticed that we ha
display/IGNITE/How+to+Document
>>>
>>> On Thu, Sep 10, 2020 at 2:45 PM Alexey Goncharuk
>>> wrote:
>>>>
>>>> Alexey,
>>>>
>>>> I've tried to play with message factories locally, but unfortunately, I
>>>> cann
Alex,
It seems that the described problem is not a problem at all. The
mentioned reason (is
not obvious what is a cache name and what is next hierarchical
element) will exist forever. If we will replace dots by underscores
(or escaped dots, or something else) still will exist the possibility
of na
Hi,
I definitely agree with Pavel and Evgenii ideas and comments.
>From my point of view the proposal is not about Apache Ignite
features. Described functionality could be implemented outside of the
Apache Ignite project. Perhaps, Debezium connector or WAL-G module are
the best candidates for the
+1 (binding)
On Thu, Oct 15, 2020 at 9:55 PM Denis Magda wrote:
>
> +1 (binding)
>
> -
> Denis
>
>
> On Thu, Oct 15, 2020 at 5:04 AM Alex Plehanov
> wrote:
>
> > Dear Community,
> >
> >
> > I have uploaded a release candidate to:
> > https://dist.apache.org/repos/dist/dev/ignite/2.9.0-rc4/
> > h
Follow up
Igniters,
is there any comment to this IEP?
JFYI, IEP is renamed and placed here [1]
[1]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-58%3A+Statistics+for+SQL+query+optimization
On Thu, Sep 24, 2020 at 2:30 PM Sasha Belyak wrote:
>
> Igniters,
> I'e prepared an IEP [1], p
Saikat,
thanks a lot! *applause*
On Fri, Oct 16, 2020 at 12:11 AM Saikat Maitra wrote:
>
> Hi,
>
> My talk about Data Streaming using Apache Flink and Apache Ignite in
> ApacheCon is available now
>
> https://www.youtube.com/watch?v=n74HMmTz5i0
>
> Regards,
> Saikat
Hi there,
I accidentally stumbled upon a potential performance problem in this commit.
CacheGroupMetricImpls.getPagesLeftForReencryption method contains at
least two problems:
- Relatively major: In order to calculate a value for one metric the
method has O(N) complexity (N is number of partiti
continue of previous mail...
The same method rethrows an exception which will lead to failure of an
metrics exporter. The method should return some numeric value which
indicates the failure.
On Wed, Oct 28, 2020 at 3:09 PM Andrey Gura wrote:
>
> Hi there,
>
> I accidentally stu
Hi,
I agree with Alexey. We should release 2.9.1 and start preparing for
the 2.10 release.
2.x releases usually take a lot of time. So we can release 2.9.1, and
even 2.9.2 before 2.10.
On Thu, Oct 29, 2020 at 12:02 PM Alexey Goncharuk
wrote:
>
> Hello folks,
>
> I think we should start both 2.9
Hi, Ilya.
I've left a comment to the JIRA issue. Please, look at it.
On Tue, Oct 20, 2020 at 8:39 AM Ilya Kazakov wrote:
>
> Hello, the community!
>
> Sometimes one needs to understand how long ago did the last checkpoint
> start or end, how long was it, etc. There is lastCheckpointDuration alre
+1
On Tue, Nov 24, 2020 at 3:24 AM Saikat Maitra wrote:
>
> +1
>
> Denis, Alex
>
> I have raised PR for the docs for Maven artifactIds and versions on the
> documentation pages of the integrations.
>
> PR : https://github.com/apache/ignite/pull/8488
>
> Jira : https://issues.apache.org/jira/brow
Igniters,
We already had some discussion about using modern Java versions for
Ignite 3.0 development [1] but we still don't have consensus.
As I see from this discussion the strongest argument for Java 11 is
the fact that Java 11 is the latest LTS release which will have
premier support until Sept
Definitely agree with Alexey. Separating API declaration from
implementation could really improve system design and avoid coupling.
About extending @IgniteExperimental annotation. It doesn't look good
to me. We should consider any API either experimental or stable. Third
option is deprecated API.
+1
On Tue, Dec 8, 2020 at 10:02 PM Nikolay Izhikov wrote:
>
> +1
>
> > 8 дек. 2020 г., в 21:54, Valentin Kulichenko
> > написал(а):
> >
> > +1
> >
> > On Tue, Dec 8, 2020 at 8:31 AM Вячеслав Коптилин
> > wrote:
> >
> >> Hello Igniters,
> >>
> >> I want to start voting on removing the public AP
Kiriill,
Issue description contains the following:
> At the moment, WAL archive is cleared at the end of the checkpoint, which
> does not seem correct and needs to be moved
Could you please explain why existing behavior is not correct. It
seems that it is not enough motivation for change.
On W
Igniters, JFYI
According to discussion [1] there are no any objections to usage of
Java 11 for Ignite 3 development as target Java language and platform
version. So pom.xml for Ignite 3 is already updated.
1.
http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Java-11-for-Ignite-3-0
Kirill,
thanks for adding motivation to the issue description.
On Wed, Dec 9, 2020 at 5:24 PM Andrey Gura wrote:
>
> Kiriill,
>
> Issue description contains the following:
>
> > At the moment, WAL archive is cleared at the end of the checkpoint, which
> > does not s
+1 (binding)
On Thu, Jan 7, 2021 at 10:42 PM Vladimir Pligin wrote:
>
> +1 (non-binding)
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
Being a committer enables easier contribution to the project since there is
no need to go via the patch submission process. This should enable better
productivity.
Please join me in welcoming Ivan, and congratulating him on the new role in
the Apache Ignite Community.
Best Regards,
Andrey Gura
t; > >
> > > Thanks,
> > > S.
> > >
> > > вт, 12 янв. 2021 г. в 14:27, Ivan Pavlukhin :
> > >
> > >> Ivan, congratulations!
> > >>
> > >> 2021-01-12 13:36 GMT+03:00, Kseniya Romanova <
> > romanova.ks...
Guys,
there is no problem in blocking thread monitroing. Please, look at the
error message: "failureCtx=FailureContext
[type=SYSTEM_WORKER_TERMINATION, err=class
o.a.i.IgniteCheckedException: Node is stopping: grid-2]]". Some
critical worker was terminated unexpectedly. So the problem isn't
relate
HI, Maksim
Welcome to the Apache Ignite contributors! I've assign contributor
role to you. Fell free to assign tickets.
On Wed, Jan 23, 2019 at 4:16 PM Максим Степачёв
wrote:
>
> Hello Ignite Community!
>
> My name is Maksim. I want to contribute to Apache Ignite and want to start
> with this is
Failure handlers were introduced in order to avoid cluster hanging and
they kill nodes instead.
If critical worker was terminated by GridDhtInvalidPartitionException
then your node is unable to work anymore.
Unexpected cluster shutdown with reasons in logs that failure handlers
provide is better
> > > > > could
> > > > > > > be ignored for a while when rebalancing <- I might be wrong
> > here).
> > > > > > >
> > > > > > > -- Roman
> > > > > > >
> > > > > > >
> &
> > > >
> > > > > > >
> > > > > > >On Tuesday, March 26, 2019, 2:52:14 p.m. GMT+9, Denis Magda <
> > > > > > > dma...@apache.org> wrote:
> > > > > > >
> &
651.html
>
>
> -
> Denis
>
>
> On Tue, Mar 26, 2019 at 9:04 AM Andrey Gura wrote:
>
> > CleanupWorker termination can lead to the following effects:
> >
> > - Queries can retrieve data that have to expired so application will
> > behave incorr
It seems that SharedSecrets is moved to jdk.internal.access package.
See PR for OpenJ9 [1].
I believe we should just add export of jdk.internal.access package to
our scripts and TC configurations.
[1] https://github.com/eclipse/openj9/pull/3824
On Wed, Mar 27, 2019 at 8:33 PM Dmitriy Pavlov wro
>> Just a thought regarding a particular error, we can borrow some ideas
from netty.
We are going in the similar way:
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/GridUnsafe.java#L1467
On Wed, Mar 27, 2019 at 9:38 PM Павлухин Иван wrote:
>>> I believe we should just add export of jdk.internal.access package to
our scripts and TC configurations.
Unfortunately it isn't enough! We have to modify
GridUnsafe#javaNioAccessObject method.
On Wed, Mar 27, 2019 at 10:08 PM Andrey Gura wrote:
>
> It seems that Share
e similar way:
>
> Our way is similar, but it does not work in java 12.
>
> I think it is for separate thread. Let's stop live coding =)
>
> ср, 27 мар. 2019 г. в 22:15, Andrey Gura :
> >
> > >>> I believe we should just add export of jdk.internal.access p
Hi,
I don't see any mentions of OOM. Provided log message reports blocking
of db-checkpoint-thread. I think worker tries to acquire checkpoint
read lock.
Stack trace corresponds to the thread that detected blocking. Failure
handler prints out threads dump to the log. This thread dump can help
in p
Anton,
what does expression "withConsistency" mean? From user's standpoint it
means that all operations performed without this proxy are not
consistent. It means also that at least method name is bad.
Are there any guarantees that withConsistency proxy will not contain
bugs that will lead to inco
ount of "inconsistency caused
> war/strikes/devastation" situations, which is important for financial
> systems.
>
> On Mon, Apr 15, 2019 at 3:58 PM Andrey Gura wrote:
>
> > Anton,
> >
> > what does expression "withConsistency" mean? From user
ess implementation
> Not sure it's possible. Once you have software it contains bugs.
> This proxy will tell you whether these bugs lead to inconsistency.
>
> On Mon, Apr 15, 2019 at 5:19 PM Andrey Gura wrote:
>
> > Method name is minor problem. I still believe that there
Ilya, do you have any estimation for fix Java 12 with SSL issue?
On Tue, May 21, 2019 at 10:26 PM Denis Magda wrote:
>
> Ignite PMC and committers, please cast your vote. It's time to roll the
> release out.
>
> --
> Denis Magda
>
>
> -- Forwarded message -
> From: Denis A. Magda
gt;
> Do you agree?
>
> Denis
>
> On Tuesday, May 21, 2019, Andrey Gura wrote:
>
> > Ilya, do you have any estimation for fix Java 12 with SSL issue?
> >
> > On Tue, May 21, 2019 at 10:26 PM Denis Magda wrote:
> > >
> > > Ignite PMC and committers
+1 (binding)
On Wed, Jun 5, 2019 at 4:39 PM Ilya Kasnacheev
wrote:
>
> +1
>
> Built C++ and .Net successfully, started .Net <-> Java <-> C++ SSL Cluster
> on Java 11 and Java 8 without tuning any flags.
> --
> Ilya Kasnacheev
>
>
> ср, 5 июн. 2019 г. в 09:44, Nikolay Izhikov :
>
> > +1 (binding)
Big +1 from me.
Make code base clean and clear.
On Fri, Jun 7, 2019 at 3:26 PM Nikolay Izhikov wrote:
>
> Hello, Igniters.
>
> Please, pay attention to commits quality.
>
> 1. Please, writer Javadocs.
> 2. Please, make the new lines according to code style.
>
> Issues like [1] has to be fixed *BE
+1
On Thu, Jun 20, 2019 at 12:58 AM Denis Magda wrote:
>
> Igniters,
>
> Based on our earlier discussion [1], let's formalize our decision and vote
> for the following:
>
>- IGFS and In-Memory Hadoop Accelerator components are to be
>discontinued and no longer supported by the community
>
101 - 200 of 563 matches
Mail list logo
