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?
>
>> 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
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
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
> 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?
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
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
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
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
Hello. Igniters.
Master build fails:
https://ci.ignite.apache.org/viewLog.html?buildId=4944107=IgniteTests24Java8_BuildApacheIgnite=buildLog_IgniteTests24Java8=pull%2F7269%2Fhead
[13:37:02][Step 3/4] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:testCompile
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
> 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,
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
Pavel Tupitsyn created IGNITE-12555:
---
Summary: .NET: Thin Client: deserializing DateTime fields causes
BinaryTypeGet request for every value
Key: IGNITE-12555
URL:
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
+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.
>
>
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
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
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=false=IgniteTests24Java8_BuildApacheIgnite=vcsModificationFiles
[2]
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
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:
> 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
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
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]
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
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:
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
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
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
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.
>
>
31 matches
Mail list logo
