Hi, Igniters!
I had a discussion about the scope of work of IEP-17 with Denis and Pavel.
To estimate the time I took 2 weeks for R during which I would do the task:
https://issues.apache.org/jira/browse/IGNITE-8361
Then I will inform the community about the planned work time.
On Tue, May 8,
GitHub user alexpaschenko opened a pull request:
https://github.com/apache/ignite/pull/4009
IGNITE-8384
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-8384
Alternatively you can review and apply
Github user glukos closed the pull request at:
https://github.com/apache/ignite/pull/4001
---
Aleksey Plekhanov created IGNITE-8517:
-
Summary: Implement
CacheGroupMetricsMXBean.getTotalAllocatedPages() calculation for
PageMemoryNoStore
Key: IGNITE-8517
URL:
I do not suggest to restrict removal using JIRA rights, it is not
reasonable.
I ask contributors to avoid such practice. In a number of cases it doesn't
make any sense and confuses community members.
ср, 16 мая 2018 г. в 15:58, Vladimir Ozerov :
> People make mistakes.
Nikolay Izhikov created IGNITE-8516:
---
Summary: Not null constraint doesn't checked
Key: IGNITE-8516
URL: https://issues.apache.org/jira/browse/IGNITE-8516
Project: Ignite
Issue Type: Bug
Github user andrewmed closed the pull request at:
https://github.com/apache/ignite/pull/4006
---
Aleksey Plekhanov created IGNITE-8515:
-
Summary: Value of CacheGroupMetricsMXBean.getTotalAllocatedPages()
is always 0
Key: IGNITE-8515
URL: https://issues.apache.org/jira/browse/IGNITE-8515
Sergey Kozlov created IGNITE-8514:
-
Summary: Missed descriptions for a few package
Key: IGNITE-8514
URL: https://issues.apache.org/jira/browse/IGNITE-8514
Project: Ignite
Issue Type: Bug
Hi, I filed the ticket https://issues.apache.org/jira/browse/IGNITE-8512
I'll do this when I have enough time if it won't be done earlier.
On Mon, May 14, 2018 at 8:46 PM, Dmitry Pavlov wrote:
> Hi Vyacheslav,
>
> plugin was published in AI wiki, feel free to create
People make mistakes. Sometimes I can edit comment. Sometimes I can delete
it if I understand it makes no sense. If I do this then I think that
comment adds no value. If you restrict removal, then users would use
"Edit" and print something like "comment was removed". Same thing.
Again - what is
Hi Vladimir,
I receive a number of such emails, then contributor deletes data. This is
valueable information about ticket history.
I'm not sure what are we trying to solve using this, as you said, perfectly
normal operation - deleting comments. Could you provide cases?
Sincerely,
Dmitriy Pavlov
Vyacheslav Daradur created IGNITE-8512:
--
Summary: Abbr-plugin: Add check of method arguments code style
Key: IGNITE-8512
URL: https://issues.apache.org/jira/browse/IGNITE-8512
Project: Ignite
GitHub user andrewmed opened a pull request:
https://github.com/apache/ignite/pull/4006
IGNITE-5883 Only for testing. Add random dir to debug flacky tests in TC
Do NOT merge
Only for tests
You can merge this pull request into a Git repository by running:
$ git pull
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/3958
---
One more thing, If we implement this component and will aggregate
information about all files, we can
create failure handler which provided detail information about node
persistence structure. It will be helpful for debugging node crash.
On Wed, May 16, 2018 at 12:46 PM, Dmitry Pavlov
Agree, comments deletion is perfectly normal operation.
What are we trying to solve?
On Wed, May 16, 2018 at 3:12 PM, Vyacheslav Daradur
wrote:
> +1 to Andrey's point.
>
> Do we really have any problems with comment's deletion?
>
> I think: if a contributor will make a
+1 to Andrey's point.
Do we really have any problems with comment's deletion?
I think: if a contributor will make a decision to remove a comment and
will not be able to do this he just will edit the comment with the
message *deleted*.
On Wed, May 16, 2018 at 2:46 PM, Andrey Kuznetsov
Aleksey Zinoviev created IGNITE-8511:
Summary: [ML] Add support for Multi-Class Logistic Regression
Key: IGNITE-8511
URL: https://issues.apache.org/jira/browse/IGNITE-8511
Project: Ignite
Folks,
Let me disagree with you.
As you've mentioned, there is a history of changes for an issue, so nothing
can be lost. Comment deletions can be useful to maintain clear path of
issue evolution. For me, it's ok to delete misleading comments, but this
should be done with care, of course.
GitHub user vveider opened a pull request:
https://github.com/apache/ignite/pull/4005
IGNITE-8510 RPM package 2.4.0 is incorrectly upgraded by 2.5.0
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite
Not applicable for NodeJS client as there are no threads in NodeJS (only
processes) [1]
Just in case - of course, it's possible to run multiple
queries/operations concurrently from one thread/process.
Eg. see Promise.all in CachePutGetExample.js and AuthTlsExample.js
examples [2]
Is Java
Maxim Muzafarov created IGNITE-8509:
---
Summary: A lot of "Execution timeout" result for Cache 6 suite
Key: IGNITE-8509
URL: https://issues.apache.org/jira/browse/IGNITE-8509
Project: Ignite
Alexey Goncharuk created IGNITE-8508:
Summary: Zookeeper discovery SPI may notify custom message ACK
with out-of-order topology version
Key: IGNITE-8508
URL: https://issues.apache.org/jira/browse/IGNITE-8508
Fixed for .NET.
What about NodeJS? Alexey?
Best Regards,
Igor
On Wed, May 16, 2018 at 12:48 PM, Pavel Tupitsyn
wrote:
> Ignite.NET client is thread-safe as stated in XMLDoc [1]
>
> [1]
> https://github.com/apache/ignite/blob/master/modules/
>
+1 Dmitriy,
I do not see any reason for deletion comments.
Maybe only edit operation must be allowed.
On Wed, May 16, 2018 at 12:32 PM, Igor Sapego wrote:
> I totally agree. There is no sense in most cases in deletion
> of commentaries.
>
> There is even less sense, when
Andrey Gura expressed in words what I also thought.
I agree if we extract common code to some kind of file utils.
In the same time creating common file operation framework is not possible
because of different nature of WAL, Page Store and other components using
files.
ср, 16 мая 2018 г. в
Hi Igor,
Nice one!
On 16 May 2018 at 11:26, Igor Sapego wrote:
> Pavel,
>
> This is about concurrent usage of the same connection (client)
> by several threads.
>
> By the ways guys, I wanted to ask you, if your clients support this
> feature, as I was not sure. I mean,
I totally agree. There is no sense in most cases in deletion
of commentaries.
There is even less sense, when you can look into ticket
history and see all the removed comments anyway.
Best Regards,
Igor
On Wed, May 16, 2018 at 12:27 PM, Dmitry Pavlov
wrote:
> Hi
Hi Igniters,
What do you think about deletion of comment in JIRA tickets? I constantly
see that participants add comments, and then delete them.
IMO , we have partially lost the history of problem research, and we can
lose interesting ideas about the problem causes; or already tested
hypotheses.
Dmitriy,
I will add technical details to the ticket, however, looks like there is
still no consensus on how this change should be presented to a user. It
would be ok if we changed this behavior in Ignite 3.0, but for one of the
next point releases we have to agree how this should be
Hello!
* The message that you provided most likely means there's a prolonged
deadlock or some other severe problem that made your cluster inoperational.
* You are using putAll which is known to cause deadlocks if used in
parallel and maps in question are not sorted.
* Is the map that you're
Dmitriy,
I guess, you can find some reasons in this discussion :)
Best Regards,
Igor
On Wed, May 16, 2018 at 11:18 AM, Dmitriy Govorukhin <
dmitriy.govoruk...@gmail.com> wrote:
> Folks,
>
> Why do you interpret the question as a necessity for action?
> In my first message, "Are there any
Vladimir Ozerov created IGNITE-8507:
---
Summary: SQL: Print a warning if SQL index inline size is not
sufficient
Key: IGNITE-8507
URL: https://issues.apache.org/jira/browse/IGNITE-8507
Project:
Andrey,
My point is, it will be very cool if there is some component who will know
about persistence folder and files,
and we can move all generic code, for work with files, to this component.
On Wed, May 16, 2018 at 12:59 AM, Pavel Kovalenko
wrote:
> Andrey,
>
> I think
Pavel,
This is about concurrent usage of the same connection (client)
by several threads.
By the ways guys, I wanted to ask you, if your clients support this
feature, as I was not sure. I mean, protocol seems to be designed
to support such use-case, but I was not sure about clients.
Best
Folks,
Why do you interpret the question as a necessity for action?
In my first message, "Are there any reasons why ignite does not support
yaml or json format for configuration? or some other popular format?"
On Wed, May 16, 2018 at 10:35 AM, Dmitriy Setrakyan
wrote:
>
GitHub user voipp reopened a pull request:
https://github.com/apache/ignite/pull/3991
IGNITE-8161 Suspend-resume TX test is flaky on TC (~5% fail rate)
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/voipp/ignite IGNITE-8161
Github user voipp closed the pull request at:
https://github.com/apache/ignite/pull/3991
---
Github user gromtech closed the pull request at:
https://github.com/apache/ignite/pull/3661
---
I generally agree with Andrey Gura. I do not think that the effort required
to implement another format for configuration justifies the means. Let's
stick to the Spring configuration.
D.
On Wed, May 16, 2018 at 10:10 AM, Pavel Tupitsyn
wrote:
> Andrey G, +1
>
>
> Andrey
Vasiliy Sisko created IGNITE-8506:
-
Summary: Visor CMD: Show consistent ID in node tables.
Key: IGNITE-8506
URL: https://issues.apache.org/jira/browse/IGNITE-8506
Project: Ignite
Issue Type:
Andrey G, +1
Andrey K,
> json-schema
It's a draft. XML schema is a mature standard.
> eye fatigue
Here is Ignite.NET config:
Equivalent JSON excerpt: "cacheConfiguration": { "cacheMode":
"Replicated", "name": "myCache" }
Enough said I guess :)
On Wed, May 16, 2018 at 12:48 AM, Andrey
43 matches
Mail list logo