After giving it some thought, I agree with Denis - there is nothing wrong
with exposing the new APIs, we just need to make it clear that we are still
going to change it.
Should we Introduce something like @IgniteExperimental annotation (I
believe it has been discussed a dozen of times on the dev-l
+1 to @IgniteExperimental
On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk <
alexey.goncha...@gmail.com> wrote:
> After giving it some thought, I agree with Denis - there is nothing wrong
> with exposing the new APIs, we just need to make it clear that we are still
> going to change it.
>
> Sho
Maxim,
I took a quick look at IGNITE-12456 and I am not sure it's about data
corruption. In the attached logs blocked system threads are reported,
however, there is no enough information to investigate the issue (the full
thread dump was not attached). I asked the ticket creator to attach missing
Hello,
I totally agree. It would be nice to have a marker that can be used to
indicate that the feature may be changed in future releases and should be
used to your own risk.
Thanks,
S.
пн, 20 янв. 2020 г. в 12:16, Anton Vinogradov :
> +1 to @IgniteExperimental
>
> On Mon, Jan 20, 2020 at 12:0
>> Also I agree with Alexey about introducing public IgniteMonitoring facade
> This is not an issue with the API.
> Just the new feature that doesn’t affects API.
I disagree. It's part of API and it affects user experience.
> Moreover, I create a ticket to fix it, already.
Creating an issue does
> However, we should do this only when the new APIs are
production-ready.
Denis, the problem is in understanding what does it mean "production
ready". Obviously we have different understanding of this term.
> What if release the improvements labeling as EA instead of
hiding them completely?
It's
It solves problem.
On Mon, Jan 20, 2020 at 12:09 PM Alexey Goncharuk
wrote:
>
> After giving it some thought, I agree with Denis - there is nothing wrong
> with exposing the new APIs, we just need to make it clear that we are still
> going to change it.
>
> Should we Introduce something like @Ign
Maxim,
>From the first glance it seems that "javadoc" profile was really
missed. Are there any other problems except springdata22? If no then
we can add the profile. Also it is interesting how it influence on
execution time?
пн, 13 янв. 2020 г. в 16:53, Maxim Muzafarov :
>
> Igniters,
>
>
> I've
Andrey.
Let’s move from the long letters to the code.
If you want to change API - please, propose this changes.
I think everybody wins if we make our API better.
Please, describe proposed changes.
It would be great if you have some examples or PR for it.
As for this release, I have plans to cont
Hello. Igniters.
Master build fails:
https://ci.ignite.apache.org/viewLog.html?buildId=4944107&buildTypeId=IgniteTests24Java8_BuildApacheIgnite&tab=buildLog&branch_IgniteTests24Java8=pull%2F7269%2Fhead
[13:37:02][Step 3/4] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-p
It seems, this because of IGNITE-12227 fix [1].
Main question is "how this may happen in case fix got the Visa [2] ?".
[1]
https://ci.ignite.apache.org/viewModification.html?modId=895719&personal=false&buildTypeId=IgniteTests24Java8_BuildApacheIgnite&tab=vcsModificationFiles
[2]
https://issues.apa
> Main question is "how this may happen in case fix got the Visa [2] ?".
This can happen because of other changes in master.
"Visa" truly works only when master is in the same state during the merge
as it was during TC run.
On Mon, Jan 20, 2020 at 1:50 PM Anton Vinogradov wrote:
> It seems, this
Pavel Tupitsyn created IGNITE-12555:
---
Summary: .NET: Thin Client: deserializing DateTime fields causes
BinaryTypeGet request for every value
Key: IGNITE-12555
URL: https://issues.apache.org/jira/browse/IGNITE-12
Should we perform an additional compilation attempt on pull/xxx/merge at
each visa request?
On Mon, Jan 20, 2020 at 1:56 PM Pavel Tupitsyn wrote:
> > Main question is "how this may happen in case fix got the Visa [2] ?".
> This can happen because of other changes in master.
> "Visa" truly works
Also, is it possible to perform the same check on the merge attempt?
Each PR can be merged from GitHub page, can we append check to the "megre
button" flow?
Can we restrict merges bypassing this button?
On Mon, Jan 20, 2020 at 2:17 PM Anton Vinogradov wrote:
> Should we perform an additional co
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
Will fix the compilation shortly, apologies for not checking locally.
An additional compilation attempt is a good idea, but: first, I believe,
there is still an option to merge a PR directly to apache git, second -
when running a check, we need to make sure that master gets fast-forwarded
exactly
Master is fixed.
пн, 20 янв. 2020 г. в 15:08, Alexey Goncharuk :
> Will fix the compilation shortly, apologies for not checking locally.
>
> An additional compilation attempt is a good idea, but: first, I believe,
> there is still an option to merge a PR directly to apache git, second -
> when ru
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
Ok, now I'm confused: what is a kosher command to check the build locally?
пн, 20 янв. 2020 г. в 15:38, Alexey Goncharuk :
> Master is fixed.
>
> пн, 20 янв. 2020 г. в 15:08, Alexey Goncharuk >:
>
>> Will fix the compilation shortly, apologies for not checking locally.
>>
>> An additional compil
Stephen created IGNITE-12556:
Summary: Online Dev Tools
Key: IGNITE-12556
URL: https://issues.apache.org/jira/browse/IGNITE-12556
Project: Ignite
Issue Type: Bug
Environment: https://onl
What is it? Some kind of advertisement? Should we close it?
пн, 20 янв. 2020 г. в 16:45, Stephen (Jira) :
>
> Stephen created IGNITE-12556:
>
>
> Summary: Online Dev Tools
> Key: IGNITE-12556
> URL: https://issues.apac
Nikolay,
Should we wait for both of the tickets given that we agreed that we are
putting an experimental marker on the new APIs? I'm ok to fix only the
first one and add the experimental marker so that we do not delay 2.8
release.
пн, 20 янв. 2020 г. в 13:32, Николай Ижиков :
> Andrey.
>
> Let’s
> Let’s move from the long letters to the code.
Let's thinking before coding. Development is not only coding. Why such
a rush? Measure thrice and cut once.
"Long letters" is way of discussion before writing code. And it's ok.
On Mon, Jan 20, 2020 at 1:32 PM Николай Ижиков wrote:
>
> Andrey.
>
>
Hello!
I do the following:
mvn clean install -DskipTests -Dmaven.javadoc.skip=true
-Dmaven.scaladoc.skip=true -Plgpl
Maybe -Pall-java is needed actually, though, it will not check C++ and .Net
anyway :-/
Regards,
--
Ilya Kasnacheev
пн, 20 янв. 2020 г. в 16:35, Alexey Goncharuk :
> Ok, now I
Guys,
There is an issue [1] caused by page list caching [2], which also affects
2.8 release. IgniteOutOfMemoryException can be thrown in some cases (data
region is small, a checkpoint is triggered by "too many dirty pages" reason
and pages list cache is rather big).
The fix is ready and merged to
Sorry for the late reply.
Approach with taskId will require a lot of changes in protocol and thus
more "heavy" for implementation, but it definitely looks to me less hacky
than reqId-approach. Moreover, as was mentioned, server notifications
mechanism will be required in a future anyway with high
Huge +1 from me for Feature Masks.
I think this should be our top priority for thin client protocol, since it
simplifies change management a lot.
On Mon, Jan 20, 2020 at 8:21 PM Igor Sapego wrote:
> Sorry for the late reply.
>
> Approach with taskId will require a lot of changes in protocol and
Alexey.
PR [1] is waiting for your review.
Please, take a look.
I think we should do the following before 2.8 release
* Introduce new @IgniteExperimental annotation as discussed.
* Mark Monitoring API with it.
* merge «[IEP-35] Expose MetricRegistry to the public API» to 2.8
* merge «[IEP-35] pu
Hello, Saikat.
Thanks, for feedback.
I raised a PR [1] to `ignite-extensions`.
You can find description of the new module below(examples can be found at [2]):
Module provides the ability to integrate `Ignite` into you spring-boot
application with zero(or minimal) configuration.
After you add
Hi Yuriy,
Just would like to realize current state. Are you still working on
Ignite text queries? If not, are you going to continue with it?
пт, 13 дек. 2019 г. в 11:52, Ivan Pavlukhin :
>
> Yuriy,
>
> Sure, I will be glad to help.
>
> > - incorrect nodes/partition selection during querying?
> Ap
31 matches
Mail list logo