Re: Signing off Ignite for export beyond the U.S.
Alex, Igor, thanks for the details. Looks good. *Pavel Tupitsyn, Aleksandr Shapkin,* could you please help with .NET? - Denis On Thu, Jun 13, 2019 at 2:08 AM Igor Sapego wrote: > Denis, > > C++ thin client and ODBC use OpenSSL to establish secure connection with > the cluster and do not contain any crypto algorithms in their own code. > > Best Regards, > Igor > > > On Thu, Jun 13, 2019 at 12:56 AM Alexey Kosenchuk < > alexey.kosenc...@nobitlost.com> wrote: > >> Hi Denis, >> >> Info about Python, PHP, Node.JS thin clients: >> >> The clients itself do not contain any cryptographic code but use the >> features provided by the underlying platforms. >> >> Python client uses Python's SSL lib [1] which is a wrapper over OpenSSL >> [2]. >> Python 2.7 and Python 3.4 require OpenSSL 1.0, Python 3.5 and higher >> require OpenSSL 1.1. >> >> NodeJS client uses NodeJS's tls module [3] which is a wrapper over >> OpenSSL [2]. >> NodeJS 8.x requires OpenSSL 1.0, NodeJS 10.x and higher require OpenSSL >> 1.1. >> >> PHP client uses PHP OpenSSL extension [4]. >> PHP 7.2 and higher require OpenSSL 1.0. >> >> [1] https://docs.python.org/3/library/ssl.html >> [2] https://www.openssl.org/ >> [3] https://nodejs.org/api/tls.html >> [4] https://www.php.net/manual/en/book.openssl.php >> >> Regards, >> -Alexey >> >> > Igniters, >> > >> > Regardless of the fact that Ignite is an open source software, ASF as >> an >> > entity based in the U.S. has to comply with certain exporting >> > regulations [1]. >> > >> > Dmitry Pavlov and I are working on adding Ignite to the table [2] of >> > projects allowed for export and might need the assistance of some of >> you. >> > >> > Here is a list of cryptographic functions used by Ignite (and provided >> > by a 3rd party vendor): >> > >> > 1. JDK SSL/TLS libraries if a user wishes to enable secured >> > connectivity between cluster nodes. Manufacturer - Oracle/OpenJDK >> > (https://apacheignite.readme.io/docs/ssltls) >> > 2. JDK AES/CBC/PKCS5Padding encryption from the Java libraries for >> > transparent data encryption of data on disk >> > (https://apacheignite.readme.io/docs/transparent-data-encryption) >> > 3. Libraries/vendors for .NET nodes security?*Pavel Tupitsyn*, could >> > you check? >> > 4. Libraries/vendors for C++ clients security (SSL, TLS, anything >> > else?). *Igor Sapego*, could you please check? >> > 5. Libraries/vendors for Python, PHP, Node.JS SSL/TLS? *Dear thin >> > client contributors*, please facilitate. >> > 6. Anything else missing from the list? We don't have any custom crypto >> > features, right? >> > >> > All of these usages/integrations have to comply with the following >> > checklist [3] before I, as a PMC Chair, submit a notice to Export >> > Administration Regulations of the U.S.A. >> > >> > [1] http://www.apache.org/licenses/exports/ >> > [2] http://www.apache.org/licenses/exports/#matrix >> > [3] https://www.apache.org/dev/crypto.html#classify >> > >> > >> > - >> > Denis >> >
[jira] [Created] (IGNITE-11927) [IEP-35] Add ability to disable subset of metrics
Nikolay Izhikov created IGNITE-11927: Summary: [IEP-35] Add ability to disable subset of metrics Key: IGNITE-11927 URL: https://issues.apache.org/jira/browse/IGNITE-11927 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Ignite should be able to enable or disable an arbitrary subset of the metrics. User should be able to do it in runtime. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: Batch write to data pages
Pavel, Thank you for your efforts! I'll take a look, shortly. On Fri, 14 Jun 2019 at 15:53, Pavel Pereslegin wrote: > > Hello Igniters! > > I'm working on implementing batch updates in PageMemory [1] to improve > the performance of batch operations. Details can be found in IEP-32 > [2]. > > As the first step, I have prepared PR [3] with the implementation of > batch insertion of several data rows into the free list [4]. > > Performance increased by reducing the workload on the free list - > after acquiring a memory page, we can write several data rows before > putting the page into the free list. This approach is used in data > preloading. Preloader cannot lock multiple cache entries at once due > to possible deadlock with concurrent batch updates, so it pre-creates > batch of data rows in the page memory, and then sequentially > initializes the cache entries one by one. > > Can someone review these changes? > > [1] https://issues.apache.org/jira/browse/IGNITE-7935 > [2] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-32+Batch+updates+in+PageMemory > [3] https://github.com/apache/ignite/pull/6364 > [4] https://issues.apache.org/jira/browse/IGNITE-11584
[jira] [Created] (IGNITE-11926) [IEP-35] Migrage GridJobMetricsProcessor
Nikolay Izhikov created IGNITE-11926: Summary: [IEP-35] Migrage GridJobMetricsProcessor Key: IGNITE-11926 URL: https://issues.apache.org/jira/browse/IGNITE-11926 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov After merging of IGNITE-11848 we should migrate `GridJobMetricsProcessor` to the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11925) [IEP-35] Migrage QueryMetrics
Nikolay Izhikov created IGNITE-11925: Summary: [IEP-35] Migrage QueryMetrics Key: IGNITE-11925 URL: https://issues.apache.org/jira/browse/IGNITE-11925 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov After merging of IGNITE-11848 we should migrate `QueryMetrics` to the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11923) [IEP-35] Migrate IgniteMXBean
Nikolay Izhikov created IGNITE-11923: Summary: [IEP-35] Migrate IgniteMXBean Key: IGNITE-11923 URL: https://issues.apache.org/jira/browse/IGNITE-11923 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov After merging of IGNITE-11848 we should migrate `IgniteMXBean` to the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11924) [IEP-35] Migrate TransactionMetricsMxBean
Nikolay Izhikov created IGNITE-11924: Summary: [IEP-35] Migrate TransactionMetricsMxBean Key: IGNITE-11924 URL: https://issues.apache.org/jira/browse/IGNITE-11924 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov After merging of IGNITE-11848 we should migrate `TransactionMetricsMxBean` to the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11922) [IEP-35] Migrate ClusterMetricsMxBean
Nikolay Izhikov created IGNITE-11922: Summary: [IEP-35] Migrate ClusterMetricsMxBean Key: IGNITE-11922 URL: https://issues.apache.org/jira/browse/IGNITE-11922 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov After merging of IGNITE-11848 we should migrate `ClusterMetricsMxBean` to the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11921) [IEP-35] Migrage CacheGroupMetrics
Nikolay Izhikov created IGNITE-11921: Summary: [IEP-35] Migrage CacheGroupMetrics Key: IGNITE-11921 URL: https://issues.apache.org/jira/browse/IGNITE-11921 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov After merging of IGNITE-11848 we should migrate `CacheGroupMetricsMXBean` to the new metric framework. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Batch write to data pages
Hello Igniters! I'm working on implementing batch updates in PageMemory [1] to improve the performance of batch operations. Details can be found in IEP-32 [2]. As the first step, I have prepared PR [3] with the implementation of batch insertion of several data rows into the free list [4]. Performance increased by reducing the workload on the free list - after acquiring a memory page, we can write several data rows before putting the page into the free list. This approach is used in data preloading. Preloader cannot lock multiple cache entries at once due to possible deadlock with concurrent batch updates, so it pre-creates batch of data rows in the page memory, and then sequentially initializes the cache entries one by one. Can someone review these changes? [1] https://issues.apache.org/jira/browse/IGNITE-7935 [2] https://cwiki.apache.org/confluence/display/IGNITE/IEP-32+Batch+updates+in+PageMemory [3] https://github.com/apache/ignite/pull/6364 [4] https://issues.apache.org/jira/browse/IGNITE-11584
[jira] [Created] (IGNITE-11920) [IEP-35] Improve Metric API
Nikolay Izhikov created IGNITE-11920:
Summary: [IEP-35] Improve Metric API
Key: IGNITE-11920
URL: https://issues.apache.org/jira/browse/IGNITE-11920
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
MetricRegistry may be made safer if we explicitly extract a group of metrics
for some Ignite entity(cache, service, etc.).
Internally, the registry will stay the same.
API proposition is:
{code:java}
MetricRegistry {
MetricSet default();
MetricSet group(String name);
}
MetricSet {
LongCounter counter();
void registrer(Metric m);
//other methods.
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[MTCGA]: new failures in builds [4114651] needs to be handled
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 your contribution. Could you respond to this email and indicate if you wish to continue and fix test failures or step down and some committer may revert you commit. *New Critical Failure in master-nightly PDS (Direct IO) 2 https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsDirectIo2=%3Cdefault%3E=buildTypeStatusDiv No changes in the build - Here's a reminder of what contributors were agreed to do https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute - Should you have any questions please contact dev@ignite.apache.org Best Regards, Apache Ignite TeamCity Bot https://github.com/apache/ignite-teamcity-bot Notification generated at 12:29:26 14-06-2019
