Иван,
The fix is to dispatch those callbacks (future listeners) to a different
thread pool, not sure which one though.
If I would do a .NET-only fix, I would use the default thread pool (non
Ignite-specific), for Java-side there is no such thing as I understand.
Yes, let's have a ticket to track
Ilya, Pavel,
Do we a have a proposal how to fix the root cause of the problem?
Should we a have a ticket for it?
ср, 7 авг. 2019 г. в 17:48, Ilya Kasnacheev :
>
> Hello!
>
> I think we should definitely stop running futures out of striped pool,
> while holding any cache logs (stripe thread counts
Just for the protocol. There was an original dev-list discussion [1].
Added a link to the ticket as well.
[1]
http://apache-ignite-developers.2346864.n4.nabble.com/IGNITE-7285-Add-default-query-timeout-td41828.html
пт, 9 авг. 2019 г. в 01:22, Denis Magda :
>
> Hey Saikat,
>
> Are you still worki
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
Hey Saikat,
Are you still working on this ticket?
https://issues.apache.org/jira/browse/IGNITE-7285
Seems that's the last API that doesn't support timeouts - JDBC and ODBC
drivers already go with it.
If you don't have time to complete the changes then someone else from the
community can take ove
Ok, thank you.
I forgot to mention atomicity. I discourage contributors from so-called
bulk commits when several unrelated changes are merged into one commit. In
case of any issues, it is not possible to find out reasons why it was
changed, it is not possible to easily revert.
чт, 8 авг. 2019 г.
>
> Do you find the presence of GG's tickets in the commit is a reason for
> revert?
No, GG employees just need to follow "commit messages" guidelines removing
GG-specific details from the messages.
-
Denis
On Thu, Aug 8, 2019 at 1:52 PM Dmitriy Pavlov wrote:
> Hi Igniters,
>
> I little bi
Hi Denis, sure, we can include. Just one point, a wider scope can move very
optimistic dates from the first letter little bit forward.
But since Apache communities are about solutions made without time bounds,
it is perfectly ok for me.
чт, 8 авг. 2019 г. в 22:46, Raymond Wilson :
> +1 for IGNIT
Hi Igniters,
I little bit upset because I sometimes find GG tickets mentioned in Ignite
source code as a reason for Ignoring tests, todos, etc.
I am personally grateful to all GG's employes for contributing to Ignite
code base.
I just want to some accuracy for commits provided to Ignite communit
+1 for IGNITE-10451
Thanks,
Raymond.
Sent from my iPhone
> On 9/08/2019, at 5:40 AM, Dmitriy Pavlov wrote:
>
> Hi Ivan, Ilya, Igniters,
>
>
>
> I would like this release would be as minimal as possible.
>
>
>
> According to dates proposed we could freeze scope at 12.08, 4 days is more
> than en
Dmitry,
Please add this BTree corruption fix to the scope:
https://issues.apache.org/jira/browse/IGNITE-11953
Plus, I would upgrade our Spark integration to version 2.4 as long as 2.3
goes with limitations reported by our users:
https://issues.apache.org/jira/browse/IGNITE-12054
Nickolay, could
Denis Magda created IGNITE-12054:
Summary: Upgrade Spark module to 2.4
Key: IGNITE-12054
URL: https://issues.apache.org/jira/browse/IGNITE-12054
Project: Ignite
Issue Type: Task
Com
Hi Ivan, Ilya, Igniters,
I would like this release would be as minimal as possible.
According to dates proposed we could freeze scope at 12.08, 4 days is more
than enough to stand up and say, ‘Hey, I have an urgent fix’. But it is
also ok for me if we decide to have more relaxed dates.
For
I can agree that some part of javadocs we have is useless. It relates to
DTOs, getters/setters without side-effects, short self-descriptive methods.
In an ideal world, proper modularization of architecture, leading to
KISS/SOLID/DRY/etc. principles, writing self-documented code should result
in jav
Hello Igniters,
[A quick introduction: My name is Garrett and I manage documentation at
GridGain. I'm relatively new here — I've been at GridGain for 4 months —
but I've been in Documentation for most of my career.]
I put together some _proposed_ guidelines for Javadocs as a starting point
for us
Maxim Muzafarov created IGNITE-12053:
Summary: Total time threads parked if checkpoint throttling
occurred
Key: IGNITE-12053
URL: https://issues.apache.org/jira/browse/IGNITE-12053
Project: Ignite
Ivan,
It is not a problem to check Javadocs at the moment code syle checking
performed, but do we really need this? And the human-factor you
mentioned above is also related to the `self-descriptive` names. I
assume, that someone now is desiring to use single-letter variables
and single-letter clas
> What's the scope for this release?
Same question.
On the other hand an idea of 2.7.6 release attracts me because having
a practice of doing frequent minor releases can help us to build
reliable and predictable release rails.
чт, 8 авг. 2019 г. в 15:09, Ilya Kasnacheev :
>
> Hello!
>
> What's t
Maxim,
My main concern here is a human factor. Humans are usually not so good
in keeping documentation always in sync with a code. Examples from an
actual PR:
/**
* @param nodeId The remote node id.
* @param channel The channel to notify listeners with.
*/
private void onChannelOpened0(UUID nodeId
Thank you, Maxim.
>>On what we are trying to save by making Javadoc optional?
Space and time.
I doubt that we need a verbal description of what private method make.
Why we need it if we just can read the code?
Bright examples:
/**
* @param helper Helper to attach to kernal context.
*/
private
Igniters,
I'm -1 with making Javadoc optional (except tests).
Here is my patch [1] with PR [2] which fixes all the Javadoc comments
for the IgniteKernal class mentioned above. Please, take a look. The
review is very appreciated.
On what we are trying to save by making Javadoc optional? In my hum
Sergey Antonov created IGNITE-12052:
---
Summary: GridDhtTxPrepareFuture should print transaction in case
of assertion error
Key: IGNITE-12052
URL: https://issues.apache.org/jira/browse/IGNITE-12052
Pr
I agree that attribute-based filtering is enough.
We should get rid of predicates in configuration as much as possible:
they introduce a lot of complexity for other platforms (.NET), among other
things mentioned above.
On Thu, Aug 8, 2019 at 2:04 PM Pavel Kovalenko wrote:
> Ivan,
>
> > And ther
Hello!
What's the scope for this release?
Regards,
--
Ilya Kasnacheev
чт, 8 авг. 2019 г. в 15:07, Dmitriy Pavlov :
> Hi Apache Ignite Developers,
>
>
>
> We seem to be on the same page about 2.8 release, but we’ve started new
> practice - minor releases, the first release was 2.7.5. Unfortuna
Hi Apache Ignite Developers,
We seem to be on the same page about 2.8 release, but we’ve started new
practice - minor releases, the first release was 2.7.5. Unfortunately,
there is a couple of issues still not fixed in that release, so I would
like to propose to prepare one more minor release fo
Hello, Ivan!
>> Could you please provide more details why do we need to run these tests
in forked JVM?
Surefite documentation [1] says:
If forkCount=0, it's impossible to use the system class loader or a plain
old Java classpath; we have to use an isolated class loader.
When using isolated class
Ivan,
> And there is also one idea (I am not fan of it but still). Can we use
> some kind of scripting for nodes filtering? In that case node filter
> is represented by script string, e.g. javascript.
I guess it can lead to the same situation as in Java NodeFilter's. We can't
control what happens
Maxim Muzafarov created IGNITE-12051:
Summary: Update javadoc for the IgniteKernal class
Key: IGNITE-12051
URL: https://issues.apache.org/jira/browse/IGNITE-12051
Project: Ignite
Issue Ty
Ivan Pavlukhin created IGNITE-12050:
---
Summary: MVCC test suites resurrection
Key: IGNITE-12050
URL: https://issues.apache.org/jira/browse/IGNITE-12050
Project: Ignite
Issue Type: Bug
29 matches
Mail list logo
