Igniters,
Do we really need the confirmation flag on the public API? I absolutely
agree on the CLI and MXBean, but what is the reason for the flag in the
API? It will be specified at the compile time anyway and does not prevent
any user error.
>From the implementation point of view I see no contra
Folks,
I have merged IGNITE-12650 (mark MVCC as experimental) to master and
ignite-2.8. What's left? Should we remove deprecation from the old metrics
and start the vote?
пн, 17 февр. 2020 г. в 14:18, Vladimir Steshin :
> > The only reason is the same implementation IgniteMXBean#active(boolean)
> > and Ignite#active(boolean). Looks like we have to choose whether to allow
> > user erase data unexpectedly or to change behavior of the API call.
>
Vladimir, those two
I do not think the change size can even be an argument for not doing a
proper improvement. We need to agree whether IgniteMxBean#active(boolean)
and Ignite#active(boolean) behaving differently is ok from the user side.
Prasad,
Since optimistic transactions do not acquire key locks until prepare phase,
it is possible that the key value is concurrently changed before the
prepare commences. Optimistic exceptions is thrown exactly in this case and
suggest a user that they should retry the transaction.
Consider the
Prasad,
> Can you please answer following questions?
> 1) The significance of the nodeOrder w.r.t Grid and cache?
>
Node order is a unique integer assigned to a node when the node joins grid.
The node order is included into GridCacheVersion to disambiguate versions
generated on different nodes th
>> >> > > >
> > > >> >> > > > I think we must accept only blocker issues to the release
> > branch.
> > > >> >> > > >
> > > >> >> > > > My previous experience tells me that even a small c
Prasad,
The current version in the entry is checked agains the version which was
read from the very same entry, so with absence of concurrent updates the
version will be the same.
>From your description, I think there might be a concurrent read for the key
that you clear which loads the value on
Nikolay, Alexey,
First, the idea of the slim binary release and docker image was discussed
openly on the dev-list [1]. Second, nobody talks about removing these
modules from the product. The idea was to create an additional distribution
which is much lighter than the current full package to reduce
Ivan,
Unless I missed something, we do not even have a scope for 2.8.1. As I
recall, there were some important changes that did not get to 2.8.0. As the
voting is close to finish, I think we can kick off a discussion for 2.8.1?
tical issues to 2.8.1 which are, from my point, have
> to be fixed in 2.8 but still not due to lack of contributions. Since
> the scope for 2.8.1 is not fixed and not discussed yet the goal for
> such tasks is 2.9.
>
>
> On Mon, 2 Mar 2020 at 19:20, Alexey Goncharuk
> wrote:
&
Igniters,
I have recently discovered [1] that Ignite can arrive in a state when an
optimistic serializable transaction can never be successfully committed
from a backup node [2].
In short, the root cause of this issue is that there are configurations
that allow a key to be stored on primary and b
t; > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > >
> org.apache.ignite.internal.processors.cache.distribut
Anton,
> >> In short, the root cause of this issue is that there are configurations
> >> that allow a key to be stored on primary and backup nodes with different
> >> versions.
> Faced with the same problem during ReadRepair development.
>
> >> I suggest to force reads from a primary
> >> node in
>
>
> Alex, thanks for monitoring various discussion threads and sharing these
> problems with the rest of the dev community.
>
> >> As a short-term solution for [2] I suggest to force reads from a primary
> > node inside optimistic serializable transactions.
>
>
> Totally agree on this. Anyway, co
Folks,
I've walked through all the commits to master since 2.8 branch was cut and
filtered some tickets that in my opinion are worth including to 2.8.1
release below (note that they are ready end the effort of including them to
the release should be low as long as there are no implicit dependencie
Igniters, Ivan, Nikolay,
I am strongly against adding confirmation flags to any kind of APIs,
whether we change the deactivation behavior or not (even though I agree
that it makes sense to fix the deactivation to not clean up the in-memory
data). The confirmation should only present in the user-fa
>
> Hello, Alexey.
>
> I just repeat our agreement to be on the same page
>
> > The confirmation should only present in the user-facing interfaces.
>
> 1. We should add —force flag to the command.sh deactivation command.
> 2. We should throw the exception if cluster has in-memory caches and
> —forc
Maxim,
Thanks for raising this PR. I will do a review during next week.
--AG
Mikhail,
I think you've answered your first question in your second question. The
CQ handler on client nodes does not make sense because there is no data on
client nodes that can be notified of, therefore there is no reason to fail
the CQ as it does not affect the execution in any way.
As for the
gt;>>>> Sergey Kosarev.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> вс, 5 апр. 2020 г. в 01:22, Saikat Maitra <
> > >>>> saikat.mai...@gmail.com>:
> > >>>>>>
evious tickets for 2.8.1 to avoid
> conflicts.
>
> > 17 апр. 2020 г., в 18:01, Alexey Goncharuk
> написал(а):
> >
> > Nikolay,
> >
> > If I merge a ticket that is already targeted for 2.8.1 to master, do you
> > prefer this ticket to be cherry-picket
ssues.apache.org/jira/browse/IGNITE-11073
>
> On Mon, 20 Apr 2020 at 11:54, Alex Plehanov
> wrote:
> >
> > Maxim, I've reviewed your PR and it looks good to me. Good job!
> >
> > пт, 10 апр. 2020 г. в 19:43, Alexey Goncharuk <
> alexey.goncha...@gmail.co
re added.
> >
> >
> > [1] https://github.com/apache/ignite/pull/7607
> > [2] https://issues.apache.org/jira/browse/IGNITE-11073
> >
> > On Tue, 21 Apr 2020 at 09:53, Alexey Goncharuk
> > wrote:
> > >
> > > Maxim,
> > &
Maxim,
I am super excited that we start discussing Ignite 3.0, but I think that
leaving only half a year for all the 3.0 changes is overly optimistic.
Moving to a major release allows us to significantly change APIs and
default behavior, storage formats, etc. Honestly, I think just discussions
wil
Pavel, Anton,
How do you see the whole key rotation procedure will work? Clearly, during
the re-encryption there will exist pages encrypted with both new and old
keys at the same time. Will a node continue to re-encrypt the data after it
restarts? If a node goes down during the re-encryption, but
Sergey,
How exactly do you want to change the StopNodeFH? The current behavior does
not terminate the JVM and its exit code is totally out of our control; one
of the use-cases we had in mind for this failure handler is that a user may
have other processes running in the same JVM, so we do not want
> > How exactly do you want to change the StopNodeFH?
> I want to stop JVM with KILL_EXIT_CODE and add an option (constructor
> argument of JVM option) for disabling JVM termination.
>
When the flag is enabled, the behavior is identical to StopNodeOrHaltFH
with tryStop=false. In other words,
StopNo
Alexey,
Hello,
>
> I've benchmarked 1-operation approach vs 2-operations approach and
> published benchmark results on IEP page [1]. It looks like performance
> almost the same, so the single-operation approach should be implemented.
>
Do I understand correctly that you suggest to remote
the OP_SE
scenarios
> affecting cluster availability and consistency. That ticket reminds me of
> those notorious issues that would fire once a week or month under specific
> configuration settings. So, I would not touch the code that fixes the issue
> unless @Alexey Goncharuk or @Sergey Chuguno
Nikita, Igniters,
I left a few comments on the tool itself in the PR.
However, I would like to reiterate and discuss why a user would prefer to
use the profiling tool over tracing? Profiling tool only captures very
high-level details of the operations (a single cache operation, for
example), and
Definitely a +1 from me for moving the CLI tooling to a separate module.
As for the autocompletion - can you elaborate how it works? Will it require
to run an additional tool when a user hits TAB? Or will it generate an
autocompletion file during the build? Will we require an install step for
Igni
Hello Maxim, folks,
ср, 6 мая 2020 г. в 21:01, Maxim Muzafarov :
> We won't do performance analysis on the production environment. Each
> time we need performance analysis it will be done on a test
> environment with verbose logging enabled. Thus I suggest moving these
> changes to a separate `pr
Stan,
Currently we never build indexes one-by-one - we always use a cache data
row visitor which either updates all indexes (see IndexRebuildFullClosure)
or updates a set of all indexes that need to catch up (see
IndexRebuildPartialClosure). GIven that, I do not see any need for
per-index rebuild
Igniters,
I would like to run the idea of deprecating and probably ignoring the NONE
rebalance mode by the community. It's in the removal list for Ignite 3.0
[1], but it looks like it still confuses and creates issues for users [2].
What about deprecating it in one of the next releases and even i
> >
> >
> https://stackoverflow.com/questions/62902640/apache-ignite-cacherebalancemode-is-not-respected-by-nodes
> > >
> > > On Mon, Jul 20, 2020 at 8:26 PM Alexey Goncharuk
> > >
> > > wrote:
> > >
> > >> Igniters,
> >
nd serve client requests. Entries for not
> owning anymore partitions expire according to configuration.
>
> Actually, I have an idea. My guess is that "rebalancing" is a smarter
> and better approach than waiting for expiration. Am I right?
>
> 2020-07-21 15:31 GMT+03:00, Alex
Hello Nikolay,
> > 10. Question - CRC is read in two places encryptionFileIO and
> filePageStore - what should we do with this?
>
> filePageStore checks CRC of the encrypted page. This required to confirm
> the page not corrupted on the disk.
> encryptionFileIO checks CRC of the decrypted page(CR
Konstantin, thank you, I will take a look.
пт, 31 июл. 2020 г. в 19:04, Konstantin Sirotkin :
> Hello!
>
> Done, I divided the PR into five smaller ones 8090-8093,8095.
> Can someone please check the changes now?
>
> Thanks.
>
> ---
> Kind Regards,
> Konstantin Sirotkin
>
> On 28 Jul 2020, at 22:
Kirill,
Thank you for driving this discussion and implementation.
A few points from my side:
* Agree that it will be best to keep the strategy interface private because
it will be very dependent on the persistent storage implementation. We
would need to expose page IDs and types to public API, wh
Zhenya,
Stacktraces are considered to be able to expose sensitive information about
code, see [1]. So as previously, I agree with Pavel that we should have an
option to disable this behavior.
[1]
https://wiki.sei.cmu.edu/confluence/display/java/ERR01-J.+Do+not+allow+exceptions+to+expose+sensitive
Hello folks,
I agree with Val: IgniteFuture was created long before we could use the
Java futures and is being kept for compatibility reasons. While keeping API
consistent between thin/thick clients is a good reason, I think moving to
Java futures benefits more to the project and end-users.
Agree
>
> Alexey.
>
> This option should be on the server side, so server administrator can
> disable stack trace for all clients.
> Correct?
>
Yes, correct.
пт, 28 авг. 2020 г. в 11:16, Alex Plehanov :
> Guys,
>
> We have benchmarked 2.9 without IGNITE-13060 and IGNITE-12568 (reverted it
> locally) and got the same performance as on 2.8.1
>
> IGNITE-13060 (Tracing) - some code was added to hot paths, to trace these
> hot paths, it's clear why we have
to verify the fix versions.
--AG
[1]
https://github.com/apache/ignite/commit/3e492bd23851856bbd0385c6a419892d0bba2a34
пн, 31 авг. 2020 г. в 12:42, Alexey Goncharuk :
> пт, 28 авг. 2020 г. в 11:16, Alex Plehanov :
>
>> Guys,
>>
>> We have benchmarked 2.9 without IGNIT
do with IGNITE-12568 (MessageFactory refactoring)?
>
> пн, 31 авг. 2020 г. в 13:25, Alexey Goncharuk >:
>
>> Alexey,
>>
>> While investigating, I found that IGNITE-12568 has an incorrect fix
>> version and is actually present in ignite-2.8.1 branch [1], so it
Ivan,
Thank you for reminding me about the dynamic schema. I've updated the IEP
draft with more details on the approach, hopefully now it's more clear. I
think we will be able to take the best from both fixed-schema and
schemaless approaches.
вт, 1 сент. 2020 г. в 14:31, Ivan Pavlukhin :
> Hi Va
Ivan,
Thank you, I got your concern now. As it is mostly regarding the
terminology, I am absolutely fine with changing the name to whatever fits
the approach best. Dynamic or evolving schema sounds great. I will make
corresponding changes to the IEP once we settle on the name.
пн, 7 сент. 2020 г.
nt returns fields in wrong
> > order since the 2 row when fields_count>10"
> > >
> > > [1] https://issues.apache.org/jira/browse/IGNITE-12809
> > > [2]
> >
> https://github.com/apache/ignite/commit/38025ee4167f05eaa2d6a2c5c2ab70c83a462cfc
> > >
&
docs by following the instruction. Unfortunately, I won't be
>> able to spend any time on this project any longer. You can send your pull
>> requests and questions about the documentation to Denis Magda.
>>
>> -Artem
>>
>> [1] : https://cwiki.apache.org
Hi folks,
Despite the autocompletion support only for bash, I see the following
benefits from this change:
* It may unify all the CLI tooliing in Ignite, providing a better user
experience
* The library has an ability to generate man pages, which may be nice
* I see there is an open issue for a
the next
> releases?
> >>> > Andrey, can you take a look at my change? I think it is fairly
> >>> straightforward and does not change the semantics, just skips the
> factory
> >>> closures for certain messages.
> >>>
> >>> IMHO 2.
out, VCS root: "GitBox [asf/ignite]" {instance id=300, parent
>> > internal id=74, parent id=GitBoxAsfIgnite, description: "
>> > https://gitbox.apache.org/repos/asf/ignite.git#refs/heads/master"}
>> >
>> > Is there some problem with this TC tas
Denis,
I've tried to quickly add licenses to the files, but there are simply too
many different file types in the change. I reverted the original commit and
the dependent one about the continuous query guarantees (which, btw, was
merged without ticket name and with a merge commit).
Please make su
README.md files for the ignite-extensions
> > >>>> modules
> > >>>>> as required.
> > >>>>> 4. Update the docs for ignite-extensions modules in ignite-website.
> > >>>>> 5. Release each module separately and share updates.
> > >>&g
Makes sense,
I added a tag copy to match the released module name.
вт, 13 окт. 2020 г. в 10:08, Petr Ivanov :
> Keep it as a reference to what?
> That tag will be confusing both users and developers because:
> — there is no release of any extension with version 1.0, only 1.0.0
> — ignite-sprin
Nikolay, Saikat, Igniters,
I started migrating the OSGi modules to the ignite-extensions repository
and I've got some questions regarding the ignite-extensions project:
- We agreed that ignite extensions have their own release cycle, so why
do we reference a -snapshot version of Ignite in t
Nikolay,
> > I thought the extensions should be tested against the latest released
> Ignite version
>
> It seems, we should try to keep extension Ignite version agnostic.
> If it impossible, then yes, we should use latest Ignite version.
>
I doubt it's possible at least for OSGi: the published art
Hello Nikolay,
Thanks for the suggestion, it definitely may be a good feature, however, I
do not see any significant value that it currently adds to the already
existing WAL Iterator. I think the following issues should be addressed,
otherwise, no regular user will be able to use the CDC reliably:
Hello Yakov,
Glad to see you back!
Hi!
> I am back!
>
> Here are several ideas on top of my mind for Ignite 3.0
> 1. Client nodes should take the config from servers. Basically it should be
> enough to provide some cluster identifier or any known IP address to start
> a client.
>
This totally mak
Hello Ivan,
Thanks for the feedback, see my comments inline:
чт, 22 окт. 2020 г. в 17:59, Ivan Daschinsky :
> Hi!
> Alexey, your proposal looks great. Can I ask you some questions?
> 1. Is nodes, that take part of metastorage replication group (raft
> candidates and leader) are expected to also
Igniters,
Since Ignite 2.9 has been released, I think we can now release the
extension modules related to streaming.
I noticed that unlike spring autoconfigure, the streamer extensions
dependencies do not have provided scope, so I created a ticket to fix that
[1]. Anything else we should fix befo
Hello folks,
I think we should start both 2.9.1 and 2.10. In practice, maintenance
release contains only critical and usability bugfixes (for example, I would
include this ticket [1] to include in 2.9.1 as it prevents users from using
tracing) and is released much faster than a minor release.
[1]
Igniters,
I wanted to pitch a rather radical idea regarding the Ignite 3.0
development which has occurred to me some time ago.
We already have several IEPs targeted to Ignite 3.0 which imply major
changes to the codebase (the change in replication protocol and thus
transactions, change in binary
APIs
> and internal structure is overwhelming
> >
> > Maybe we should relax a bit requirements for Ignite3?
> > Maybe we should move step by step and make Ignite3 with new
> configuration than Ignite4 with new transactions, etc?
> >
> >> 2 нояб. 2020 г., в 13:1
ookeeper support, etc.
> > We have bugs and issues that can be fixed in 2.x without breaking
> backward
> > compatibility.
> > We have many users who are happy with the 2.x with all it’s issues.
> >
> > > 2 нояб. 2020 г., в 14:09, Anton Vinogradov написал(а):
> > >
> >
; lifecycle,
> >> component wiring mechanics, general methods to approach core components
> >> such as exchange/communication
> >> to avoid code mess like we have in ExchangeFuture with all these custom
> >> callbacks for each component, interfaces like
&
Folks,
I want to bump up this discussion and slightly change the format suggested
by Nikita. I dot think it is correct to gather any information related to
the user environment. However, can we collect just the fact of some of the
Ignite APIs/subsystems being used with no user information whatsoev
PM Alexey Zinoviev <
> zaleslaw@gmail.com>
> > > > wrote:
> > > >
> > > >> Let's discuss the possible planning dates for feature freeze for
> 2.10,
> > > for
> > > >> example? Do you have any plans or ideas?
> > >
:28 AM Denis Magda wrote:
> >
> >> Alex,
> >>
> >> Should we create a dedicated ticket for the documentation changes or
> can we
> >> reuse IGNITE-13634? As a bare minimum, we need to update maven
> artifacts'
> >> names and versions:
o make extensions as independent as possible.
> >
> > Doubt if we can do it for each module.
> > We have, ignite-hibernate_4.2, ignite-hibernate_5.1 modules that
> attached to specific hibernate version by their name.
> >
> >
> >> 11 нояб. 2020 г., в 11:19, Ale
t; > > >> wrote:
> > > > >>>
> > > > >>> Makes sense to me.
> > > > >>>
> > > > >>> вт, 10 нояб. 2020 г. в 18:47, Sergey Chugunov <
> > > > sergey.chugu...@gmail.com>:
> &
Good,
I think we have an intermediate agreement on the scope and significance of
the changes we want to make. I suggest creating separate discussion streams
and calls for each of the suggested topics so that:
- It is clear for the community what is the motivation of the stream
(this include
I support having a single vote for all the extensions. Mikhail, do you mind
releasing the rest of the modules together with spring-boot? If you do, I
can take care of them but looks like this will be a separate vote, though.
чт, 19 нояб. 2020 г. в 10:55, Petr Ivanov :
> No 11 separate votes, but
Following up the Ignite 3.0 scope/development approach threads, this is a
separate thread to discuss technical aspects of the IEP.
Let's reiterate one more time on the questions raised by Ivan and also see
if there are any other thoughts on the IEP:
- *Whether to deploy metastorage on a separa
г. в 13:47, Ivan Daschinsky :
> >
> >>
> >>
> >> -- Forwarded message -
> >> От: Ivan Daschinsky
> >> Date: чт, 19 нояб. 2020 г. в 13:02
> >> Subject: Re: IEP-61 Technical discussion
> >> To: Alexey Goncharuk
&
Igniters,
I think we a bit overdue for releasing already migrated extension modules
which were removed in Ignite 2.9. As Saikat mentioned, I suggest releasing
the following modules:
ignite-flink-ext
ignite-flume-ext
ignite-pub-sub-ext
ignite-zeromq-ext
ignite-twitter-ext
ignite-rocketmq-ext
ignite
cd (see raft/node.go) contains some heartbeats mechanism etc.
> > I agree with you, this seems not to be a huge deal to port.
> >
> > чт, 19 нояб. 2020 г. в 16:13, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> >> Ivan,
> >>
>
Dear Ignite Community,
I have uploaded a release candidate of the following extension modules:
ignite-camel-ext
ignite-flink-ext
ignite-flume-ext
ignite-jms11-ext
ignite-kafka-ext
ignite-mqtt-ext
ignite-pub-sub-ext
ignite-rocketmq-ext
ignite-storm-ext
ignite-twitter-ext
ignite-zeromq-ext
The foll
as a more recent version
> then
> > > the
> > > > > > > > key-value
> > > > > > > > > > pair
> > > > > > > > > > > > > > should
gt; end of story.
>
> On Tue, Nov 24, 2020 at 6:25 PM Alexey Goncharuk <
> alexey.goncha...@gmail.com>
> wrote:
>
> > Folks, I think this is a reasonable request. I thought about this when I
> > was drafting the IEP, but hesitated to add these types right away.
> &g
cture
пн, 23 нояб. 2020 г. в 13:28, Alexey Goncharuk :
> Thanks, Ivan,
>
> Another protocol for group membership worth checking out is RAPID [1] (a
> recent one). Not sure though if there are any available implementations for
> it already.
>
> [1] https://www.usenix.org/sys
Folks, let's have the call on Friday, Nov 27th at 18:00 MSK? We can use the
following waiting room link:
https://zoom.us/j/99450012496?pwd=RWZmOGhCNWlRK0ZpamdOOTZsYTJ0dz09
Let me know if this time works for everybody.
ср, 25 нояб. 2020 г. в 16:42, Alexey Goncharuk :
> Folks,
>
>
in the morning.
>
> ср, 25 нояб. 2020 г. в 20:10, Alexey Goncharuk >:
>
> > Folks, let's have the call on Friday, Nov 27th at 18:00 MSK? We can use
> the
> > following waiting room link:
> > https://zoom.us/j/99450012496?pwd=RWZmOGhCNWlRK0ZpamdOOTZsYTJ0dz0
eniya Romanova :
> Done
>
> чт, 26 нояб. 2020 г. в 13:18, Ivan Daschinsky :
>
> > Alexey, is it possible to manage call at 16:00 MSK?
> >
> > чт, 26 нояб. 2020 г. в 12:30, Alexey Goncharuk <
> alexey.goncha...@gmail.com
> > >:
> >
> > >
The vote is closed now.
Vote result: Vote passed with 5 "+1" votes (3 binding and 2 non-binding
votes), no "0" and no "-1" votes.
+1 Votes:
Denis Magda (binding)
Saikat Maitra (binding)
Andrey Gura (binding)
Kirill Tkalenko
Konstantin Orlov
Vote thread
http://apache-ignite-developers.2346864.n4.
Igniters,
I want to tackle the topic of modules structure in Ignite 3. So far, the
modules in Ignite are mostly defined intuitively which leads to some
complications:
- Ignite public API is separated from the rest of the code only by
package name. This leads to private classes leaking to pu
h this approach or
> some
> > > > issues should be resolved at first.
> > > >
> > > > Any thoughts or objections?
> > > > Are interfaces good enough to be merged within the current ticket?
> > > >
> > > >
> > > > htt
Folks,
I updated the IEP to contain the missing pieces; actually, most of the
questions here were covered by the text. Please let me know if there is
something still missing or unclear.
чт, 31 дек. 2020 г. в 12:48, Alexey Goncharuk :
> Mikhail and Igniters,
>
> Thanks for your comm
Folks,
Did we already check that omitting hearbeat priority does not break
discovery? I am currently working on another issue with discovery and
skipping hearbeat priority would help a lot in my case.
--AG
пт, 11 янв. 2019 г. в 23:21, Yakov Zhdanov :
> > How big the message worker's queue may g
Community.
Best Regards,
Alexey Goncharuk
Hello Pavel, Vladimir,
As far as I know, Semyon Boikov and Sergi Vladykin (CCed) are prototyping
this feature.
Folks, can you comment?
ср, 6 мар. 2019 г. в 10:57, Vladimir Ozerov :
> Hi Pavel,
>
> As far as I know batch tree updates already being developed. Alex, could
> you please elaborate?
Igniters,
I came across the same issue during development and found no sane
workaround for this issue. I believe the solution should be as simple as
possible because we are already adding a warning to let users know that it
is good to specify a consistent ID in production deployments.
As for the
Hello Ilya,
I do not see any issues with the mentioned test. I see the following output
in the logs:
[21:41:44] : [Step 4/5] [2019-03-22 21:41:44,970][INFO ][main][root] >>>
Stopping test:
TcpDiscoveryCoordinatorFailureTest#testCoordinatorFailedNoAddFinishedMessageStartOneNode
in 37768 ms <<<
[21
Maxim,
I left response in the ticket.
пт, 17 мая 2019 г. в 12:04, Maxim Muzafarov :
> Igniters,
>
>
> I've implemented the file transfer machinery between grid nodes over
> Communication SPI covered by JIRA [1] and as the first part of IEP-28
> [3]. Please, consider my PR [2] to be reviewed and
Hello Denis,
As for p.1 - fully agree. For p.2 - I have some ideas to be implemented in
the future in Ignite 3.0, will share some ideas later.
чт, 6 июн. 2019 г. в 13:29, Denis Magda :
> Hey Igniters,
>
> I'd like us to brainstorm how to solve the following usability issue.
>
> A user starts dev
+1 (binding) - checked build from source, persistence example and basic
control.sh commands.
ср, 5 июн. 2019 г. в 17:48, Andrey Gura :
> +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
Denis,
I fully support this idea.
First, looking back, I do not think it was a good design in the first place
to build IGFS on top of Ignite caches. Second, I have never seen a case
where IGFS provided significant performance boost. Usually it's either all
data already fits buffer cache, and IGFS
Igniters,
Even though we are still planning the Ignite 2.8 release, I would like to
kick-off a discussion related to Ignite 3.0, because the efforts for AI 3.0
will be significantly larger than for AI 2.8, better to start early.
As a first step, I would like to discuss the list of things to be re
Nikolay,
Local caches and scalar are already in the list :) Added the outdated
metrics point.
пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov :
> * Scalar.
> * LOCAL caches.
> * Deprecated metrics.
>
> В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> > Igniters,
>
101 - 200 of 1062 matches
Mail list logo
