Alexey Goncharuk created IGNITE-11930:
-
Summary: TcpDiscoverySpi does not close bound server socket if
discovery thread did not start
Key: IGNITE-11930
URL: https://issues.apache.org/jira/browse/IGNITE-11930
Denis,
I must say that aforementioned solutions for a Hadoop ecosystem appear
from time to time in questions on a user mailing list. So, it seems
that there is a practical need for such solutions.
But of course it does not mean that we should continue a support of
IGFS and Hadoop Accelerator. If
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
+1 from me to reduce supported feature list.
Guys, are we talking about Ignite 3.0?
В Пн, 17/06/2019 в 11:57 +0300, Alexey Goncharuk пишет:
> 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 c
Hello guys,
My name is Evgeniy Rudenko and I want to contribute. Want to start from
this issue - https://issues.apache.org/jira/browse/IGNITE-11832.
Need access to Ignite Jira. My username is erudenko.
Thanks in advance.
Best regards,
Evgeniy
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
* Scalar.
* LOCAL caches.
* Deprecated metrics.
В Пн, 17/06/2019 в 15:18 +0300, Alexey Goncharuk пишет:
> 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 l
Alexey, Igor, thank you for your replies.
I've found one more usage at Java side:
It is Amazon AWS S3 Client-side encryption:
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingClientSideEncryption.html
See code at:
https://github.com/apache/ignite/blob/master/modules/aws/src/main/java/org/apac
Ivan Bessonov created IGNITE-11931:
--
Summary: Rewrite @WithSystemProperty handling using JUnit rules.
Key: IGNITE-11931
URL: https://issues.apache.org/jira/browse/IGNITE-11931
Project: Ignite
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,
> >
> > Even though we are
Alexey.
I want to share a thought (just don't drop it out in one moment :) ).
Do we really need "client nodes"?
We have thin client protocol that is a very convenient point to interact with
Ignite.
So, why, we need one more entity and work mode such as "client node"?
From my point of view, cli
Alexey,
* SqlQuery (not SqlFieldsQuery)
* Twitter module
On Mon, Jun 17, 2019 at 3:52 PM Alexey Goncharuk
wrote:
> Nikolay,
>
> Local caches and scalar are already in the list :) Added the outdated
> metrics point.
>
> пн, 17 июн. 2019 г. в 15:32, Nikolay Izhikov :
>
> > * Scalar.
> > * LOCAL c
Hi Denis,
Ignite.NET uses .NET Framework Standard Library for all security and
cryptographic related code. There are no dependencies on external libraries.
Thanks
ср, 12 июн. 2019 г., 21:07 Denis Magda :
> Igniters,
>
> Regardless of the fact that Ignite is an open source software, ASF as an
>
>> * Twitter module
Every extension/adapter/etc module should be checked to be useful.
My wish is to get rid of all lesser-used features, to make AI as small as
possible.
It's time to clean-up legacy :)
BTW, do we really need TCK support?
On Mon, Jun 17, 2019 at 4:05 PM Andrey Mashenkov
wrote:
Nikolay,
I had this thought too, but I am not too eager to implement it yet. The
reason is transaction protocol complexity/performance issues with thin
clients.
A thick client can communicate with each primary node and coordinate
prepare/commit phases. Thin client can only communicate with one no
Thanks, Pavel!
Denis, Pavel, Igniters, please review the following proposal:
- Python, Node JS, ODBC to be declared as OpenSSL usage.
- AWS-S3 client-side encryption to be declared as JCA/JCE usage.
- SSLContextFactory usage to be declared as JCA/JCE usage.
- TDE to be declared as JCA/JCE
Export
Igniters,
One more usage,we need to mention at Export matrix data:
<<<
JCraft, Inc.
title=Provides encryption SSH library
href=http://www.jcraft.com/jsch/
>>>
One more thing I would like to declare as an open question:
3) Is it possible to setup HTTPs connection to Ignite Rest
>1) Declaring older versions of Ignite.
>2) Is it correct to mention that Ignite uses .NET core controlled by .NET
>Foundation? E.g. as follows:
>(controlled by)
>.NET Foundation
>title=Designed to use .NET Framework Cryptography Model
>href=https://dotnetfoundation.org/projects
>Should it go ins
Could we suggest here remove whole modules?
пн, 17 июн. 2019 г. в 16:28, Alexey Goncharuk :
> Nikolay,
>
> I had this thought too, but I am not too eager to implement it yet. The
> reason is transaction protocol complexity/performance issues with thin
> clients.
>
> A thick client can communicate
Hi Nikolay,
I think client nodes removal is not possible in the near future because of
tons of usages everywhere outside Ignite code (in products, guides, books,
training, etc.)
If we have replacement we should encourage users to migrate, but we can't
remove such a core feature.
Alexey, sure we
+1 from me. Hadoop Accelerator seems like an outdated solution,
and I believe IGFS was only added to support Hadoop Accelerator.
Best Regards,
Igor
On Mon, Jun 17, 2019 at 12:00 PM Nikolay Izhikov
wrote:
> +1 from me to reduce supported feature list.
>
> Guys, are we talking about Ignite 3.0?
Dmitriy Pavlov created IGNITE-11932:
---
Summary: Follow ASF crypto process, declare encryption software
usaged
Key: IGNITE-11932
URL: https://issues.apache.org/jira/browse/IGNITE-11932
Project: Ignite
Hi Igniters,
+1 from me provided that we move sources to some supplementary repository.
If someone later would like to maintain/fix this module, he/she should be
able to access sources with current state of the master.
Sincerely,
Dmitriy Pavlov
пн, 17 июн. 2019 г. в 18:25, Igor Sapego :
> +1 fr
Dmitriy,
I think the whole concept of "client" nodes is broken.
And that's why:
Ignite Client node nothing to do with "client" :)
We can deploy cache on it, we can execute compute tasks, services on it.
"client node" is a node with special join process and some rebalance/PME hacks.
And we put ma
Nikolay,
we can (and probably should) discuss stop deploying caches/services to
client nodes.
But I would not name it removal of client nodes at all. Any Apache Ignite
guide I saw is starting from 2 steps: 1) start server node, 2) start client
node.
There are no reasons to write software if user
Alexander, thank you for your reply.
Let's follow the motto: "Show me the code!" Even we don't have any single
line of code here.
I've created
- issue https://issues.apache.org/jira/browse/IGNITE-11932
- a new head with draft content
https://gitbox.apache.org/repos/asf?p=ignite.git;a=shortlog;h=r
>>Should it go instead of Microsoft? Should we mention .NET code in addition
>>to Microsoft?
>Yes, I think we can do this. Ignite targets both of the them. And .NET
Core uses it’s own implementation of standard class library[1]
>Pavel may correct me.
We use crypto APIs from standard class li
I would like to add to the list following:
1. Remove ForceKeyRequests and related code. Since we have Late affinity
assignment and primary node partitions are always up to date we don't need
to request actual data from backups.
2. Remove @CentralizedAffinityFunction and related code. I don't see a
For the C++ I propose to drop support of VS 2010 and move to
at least 2012 (or, better yet 2013).
Also, I'd drop x86 support for everything except for maybe ODBC.
Best Regards,
Igor
On Mon, Jun 17, 2019 at 7:12 PM Pavel Kovalenko wrote:
> I would like to add to the list following:
>
> 1. Remov
Dmitriy.
When we remove all "features" that is uncommon for the term "client node" what
will remain?
Thin client protocol with transactions and P2P feature.
I'm talking about design and naming, not about "documentation and supplementary
materials".
We should have clear and consistent design and
Big changes for .NET:
* Remove legacy Entity Framework integration
* Remove legacy ASP.NET integration
* Move from .NET Framework 4.0 (released in 2010) to .NET Standard 2.0
(modern way to build libraries)
Thanks,
Pavel
On Mon, Jun 17, 2019 at 7:14 PM Igor Sapego wrote:
> For the C++ I propose
Pavel,
we need to follow the process from
https://www.apache.org/dev/crypto.html#classify
Please see similar products in the draft export matrix,
https://github.com/apache/ignite/pull/6616/files#diff-1995c8a78832996cb48db91f7550479cR7
We don't ship JDK, but we designed our product to use a cryp
Hi Igniters,
During preparing of the release I've faced with lack of information related
to required steps. This was one reason of too long release preparation.
This process was automated by several Ignite contributors (thank you, BTW).
Now, these valued automation results are more or less stored
This is Madhusudhan, I am interested to contribute to Apache Ignite.
Can someone please add me as contributor, I would like to assign tasks
which i can work upon. My jira username is *sudhan499*
Also I am interested to start with IGNITE-11677, IGNITE-11547
(related/similar issues). Can someone as
>
> +1 from me to reduce supported feature list.
> Guys, are we talking about Ignite 3.0?
Nikolay, I would discontinue IGFS before 3.0. Let's do this in the next
release? As for other features and integrations, 3.0 should be considered
as a version.
> +1 from me provided that we move sources to
Remove "force server mode" for client nodes (already was discussed on dev
list earlier [1]).
[1] :
http://apache-ignite-developers.2346864.n4.nabble.com/Deprecate-force-server-mode-for-clients-td33614.html
пн, 17 июн. 2019 г. в 19:22, Pavel Tupitsyn :
> Big changes for .NET:
> * Remove legacy En
36 matches
Mail list logo
