Re: Documentation for Binary Client Protocol

[Pavel Tupitsyn]

Hi everyone,

Just a reminder that initial spec is on wiki:
https://cwiki.apache.org/confluence/display/IGNITE/IEP-9+Thin+Client+Protocol

It is quite terse and may be harder to understand.
Prachi tried to document all of this in a more user-friendly manner with
examples and so on.

On Fri, Jan 19, 2018 at 6:30 AM, Denis Magda  wrote:

> Lucas, thanks for chiming in,
>
> The protocol itself consists of all these magic constants (type and
> operations codes). See type codes table from this section:
> https://apacheignite.readme.io/docs/binary-client-
> protocol#section-data-objects  io/docs/binary-client-protocol>
>
> Hope that my explanation given to Alexey makes sense to both of you.
>
> Initially, we didn’t plan to have the code snippets at all and wanted to
> document the protocol in a way similar to Mongo’s protocol:
> https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/ <
> https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/>
>
> But after several iterations we agreed to simplify a life of those who
> will be developing thin clients on top of the protocol and filled out the
> doc with as many code snippets as possible. Again, the snippets are not a
> complete application and this is why we ignored some of the best practices
> used by Java developers.
>
> —
> Denis
>
> > On Jan 18, 2018, at 7:11 PM, Lucas Beeler 
> wrote:
> >
> > Hi Igniters,
> >
> > I’m with Alexey here: hard-coded “magic” literals make code hard to read
> and neither communicate coding professionalism nor comport with published
> Sun/Oracle style guides. So I suggest that:
> > For already defined symbolic constants, let’s use them instead of
> literal values
> > If there are literal values for which symbolic constants haven’t yet
> been defined, let’s define symbolic constants for them, commit this change
> to master, and start using the newly defined symbolic constants
> > Anyhoo, that’s just my two cents.
> >
> > As always, it’s a pleasure to be a part of Ignite development...
> >
> > Cheers guys & gals,
> > Lucas
> >
> > --
> > Lucas BEELER
> > Technical Consultant, Professional Services
> > GridGain Systems
> > www.gridgain.com 
> >
> >> On Jan 18, 2018, at 6:47 PM, Alexey Kuznetsov  > wrote:
> >>
> >> Prachi, Denis,
> >>
> >>
> >> It is OK that we are using numbers in code samples instead of named
> >> constants?
> >>
> >> For example:
> >>   writeByteLittleEndian(3, out);  // Integer type code
> >>
> >> It could be smth. like this:
> >>   writeByteLittleEndian(TYPE_INT, out);  // Integer type code
> >>
> >> Where TYPE_INT is declared at some place:
> >> 
> >> public static final int TYPE_INT = 3;
> >> 
> >>
> >> Make sense?
> >>
> >>
> >> On Fri, Jan 19, 2018 at 4:47 AM, Prachi Garg  > wrote:
> >>
> >>> Igniters,
> >>>
> >>> The document for Binary Client Protocol (awaiting 2.4 release) is
> ready on
> >>> Apache Ignite readme.io . This document explains:
> >>>
> >>>   - How to connect to Ignite cluster
> >>>   - Common message format (Request/Response header)
> >>>   - Supported Data types and their format
> >>>   - Request/Response format for each message type
> >>>
> >>> Here are the links -
> >>>
> >>> https://apacheignite.readme.io/docs/binary-client-protocol <
> https://apacheignite.readme.io/docs/binary-client-protocol>
> >>>
> >>> https://apacheignite.readme.io/docs/binary-client-protocol-
> >>> key-value-operations
> >>>
> >>> https://apacheignite.readme.io/docs/binary-client-
> protocol-sql-operations
> >>>
> >>> https://apacheignite.readme.io/docs/binary-client-protocol-
> >>> binary-type-operations
> >>>
> >>> https://apacheignite.readme.io/docs/binary-client-protocol-
> >>> cache-configuration-operations
> >>>
> >>>
> >>> Currently these pages are hidden and are accessible only with the link.
> >>> They will be active after the release.
> >>>
> >>> -Prachi
> >>>
> >>
> >>
> >>
> >> --
> >> Alexey Kuznetsov
> >
>
>

Re: Documentation for Binary Client Protocol

[Denis Magda]

Lucas, thanks for chiming in,

The protocol itself consists of all these magic constants (type and operations 
codes). See type codes table from this section:
https://apacheignite.readme.io/docs/binary-client-protocol#section-data-objects 


Hope that my explanation given to Alexey makes sense to both of you.

Initially, we didn’t plan to have the code snippets at all and wanted to 
document the protocol in a way similar to Mongo’s protocol:
https://docs.mongodb.com/manual/reference/mongodb-wire-protocol/ 


But after several iterations we agreed to simplify a life of those who will be 
developing thin clients on top of the protocol and filled out the doc with as 
many code snippets as possible. Again, the snippets are not a complete 
application and this is why we ignored some of the best practices used by Java 
developers.

—
Denis

> On Jan 18, 2018, at 7:11 PM, Lucas Beeler  wrote:
> 
> Hi Igniters,
> 
> I’m with Alexey here: hard-coded “magic” literals make code hard to read and 
> neither communicate coding professionalism nor comport with published 
> Sun/Oracle style guides. So I suggest that:
> For already defined symbolic constants, let’s use them instead of literal 
> values
> If there are literal values for which symbolic constants haven’t yet been 
> defined, let’s define symbolic constants for them, commit this change to 
> master, and start using the newly defined symbolic constants
> Anyhoo, that’s just my two cents.
> 
> As always, it’s a pleasure to be a part of Ignite development...
> 
> Cheers guys & gals,
> Lucas
> 
> --
> Lucas BEELER
> Technical Consultant, Professional Services
> GridGain Systems
> www.gridgain.com 
> 
>> On Jan 18, 2018, at 6:47 PM, Alexey Kuznetsov > > wrote:
>> 
>> Prachi, Denis,
>> 
>> 
>> It is OK that we are using numbers in code samples instead of named
>> constants?
>> 
>> For example:
>>   writeByteLittleEndian(3, out);  // Integer type code
>> 
>> It could be smth. like this:
>>   writeByteLittleEndian(TYPE_INT, out);  // Integer type code
>> 
>> Where TYPE_INT is declared at some place:
>> 
>> public static final int TYPE_INT = 3;
>> 
>> 
>> Make sense?
>> 
>> 
>> On Fri, Jan 19, 2018 at 4:47 AM, Prachi Garg > > wrote:
>> 
>>> Igniters,
>>> 
>>> The document for Binary Client Protocol (awaiting 2.4 release) is ready on
>>> Apache Ignite readme.io . This document explains:
>>> 
>>>   - How to connect to Ignite cluster
>>>   - Common message format (Request/Response header)
>>>   - Supported Data types and their format
>>>   - Request/Response format for each message type
>>> 
>>> Here are the links -
>>> 
>>> https://apacheignite.readme.io/docs/binary-client-protocol 
>>> 
>>> 
>>> https://apacheignite.readme.io/docs/binary-client-protocol-
>>> key-value-operations
>>> 
>>> https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations
>>> 
>>> https://apacheignite.readme.io/docs/binary-client-protocol-
>>> binary-type-operations
>>> 
>>> https://apacheignite.readme.io/docs/binary-client-protocol-
>>> cache-configuration-operations
>>> 
>>> 
>>> Currently these pages are hidden and are accessible only with the link.
>>> They will be active after the release.
>>> 
>>> -Prachi
>>> 
>> 
>> 
>> 
>> -- 
>> Alexey Kuznetsov
> 

Re: Documentation for Binary Client Protocol

[Denis Magda]

Documentation consists of a set of unrelated code snippets for various 
operations. Do not treat it as a complete application or sample (the protocol 
is huge). This is why it’s totally fine to use numerical constants in the doc 
and leave it as as responsibility of a developer to define and use customs 
constants such as TYPE_INT.

—
Denis
 

> On Jan 18, 2018, at 6:47 PM, Alexey Kuznetsov  wrote:
> 
> Prachi, Denis,
> 
> 
> It is OK that we are using numbers in code samples instead of named constants?
> 
> For example:
>writeByteLittleEndian(3, out);  // Integer type code
> 
> It could be smth. like this:
>writeByteLittleEndian(TYPE_INT, out);  // Integer type code
> 
> Where TYPE_INT is declared at some place:
> 
> public static final int TYPE_INT = 3;
> 
> 
> Make sense?
> 
> 
> On Fri, Jan 19, 2018 at 4:47 AM, Prachi Garg  > wrote:
> Igniters,
> 
> The document for Binary Client Protocol (awaiting 2.4 release) is ready on
> Apache Ignite readme.io . This document explains:
> 
>- How to connect to Ignite cluster
>- Common message format (Request/Response header)
>- Supported Data types and their format
>- Request/Response format for each message type
> 
> Here are the links -
> 
> https://apacheignite.readme.io/docs/binary-client-protocol 
> 
> 
> https://apacheignite.readme.io/docs/binary-client-protocol-key-value-operations
>  
> 
> 
> https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations 
> 
> 
> https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations
>  
> 
> 
> https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations
>  
> 
> 
> 
> Currently these pages are hidden and are accessible only with the link.
> They will be active after the release.
> 
> -Prachi
> 
> 
> 
> -- 
> Alexey Kuznetsov

Re: Documentation for Binary Client Protocol

[Lucas Beeler]

Hi Igniters,

I’m with Alexey here: hard-coded “magic” literals make code hard to read and 
neither communicate coding professionalism nor comport with published 
Sun/Oracle style guides. So I suggest that:
For already defined symbolic constants, let’s use them instead of literal values
If there are literal values for which symbolic constants haven’t yet been 
defined, let’s define symbolic constants for them, commit this change to 
master, and start using the newly defined symbolic constants
Anyhoo, that’s just my two cents.

As always, it’s a pleasure to be a part of Ignite development...

Cheers guys & gals,
Lucas

--
Lucas BEELER
Technical Consultant, Professional Services
GridGain Systems
www.gridgain.com

> On Jan 18, 2018, at 6:47 PM, Alexey Kuznetsov  wrote:
> 
> Prachi, Denis,
> 
> 
> It is OK that we are using numbers in code samples instead of named
> constants?
> 
> For example:
>   writeByteLittleEndian(3, out);  // Integer type code
> 
> It could be smth. like this:
>   writeByteLittleEndian(TYPE_INT, out);  // Integer type code
> 
> Where TYPE_INT is declared at some place:
> 
> public static final int TYPE_INT = 3;
> 
> 
> Make sense?
> 
> 
> On Fri, Jan 19, 2018 at 4:47 AM, Prachi Garg  wrote:
> 
>> Igniters,
>> 
>> The document for Binary Client Protocol (awaiting 2.4 release) is ready on
>> Apache Ignite readme.io. This document explains:
>> 
>>   - How to connect to Ignite cluster
>>   - Common message format (Request/Response header)
>>   - Supported Data types and their format
>>   - Request/Response format for each message type
>> 
>> Here are the links -
>> 
>> https://apacheignite.readme.io/docs/binary-client-protocol
>> 
>> https://apacheignite.readme.io/docs/binary-client-protocol-
>> key-value-operations
>> 
>> https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations
>> 
>> https://apacheignite.readme.io/docs/binary-client-protocol-
>> binary-type-operations
>> 
>> https://apacheignite.readme.io/docs/binary-client-protocol-
>> cache-configuration-operations
>> 
>> 
>> Currently these pages are hidden and are accessible only with the link.
>> They will be active after the release.
>> 
>> -Prachi
>> 
> 
> 
> 
> -- 
> Alexey Kuznetsov

Re: Documentation for Binary Client Protocol

[Alexey Kuznetsov]

Prachi, Denis,


It is OK that we are using numbers in code samples instead of named
constants?

For example:
   writeByteLittleEndian(3, out);  // Integer type code

It could be smth. like this:
   writeByteLittleEndian(TYPE_INT, out);  // Integer type code

Where TYPE_INT is declared at some place:

public static final int TYPE_INT = 3;


Make sense?


On Fri, Jan 19, 2018 at 4:47 AM, Prachi Garg  wrote:

> Igniters,
>
> The document for Binary Client Protocol (awaiting 2.4 release) is ready on
> Apache Ignite readme.io. This document explains:
>
>- How to connect to Ignite cluster
>- Common message format (Request/Response header)
>- Supported Data types and their format
>- Request/Response format for each message type
>
> Here are the links -
>
> https://apacheignite.readme.io/docs/binary-client-protocol
>
> https://apacheignite.readme.io/docs/binary-client-protocol-
> key-value-operations
>
> https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations
>
> https://apacheignite.readme.io/docs/binary-client-protocol-
> binary-type-operations
>
> https://apacheignite.readme.io/docs/binary-client-protocol-
> cache-configuration-operations
>
>
> Currently these pages are hidden and are accessible only with the link.
> They will be active after the release.
>
> -Prachi
>



-- 
Alexey Kuznetsov

[GitHub] ignite pull request #3346: IGNITE-7284: Introduce DEV_ONLY marker to IgniteL...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3346


---

Documentation for Binary Client Protocol

[Prachi Garg]

Igniters,

The document for Binary Client Protocol (awaiting 2.4 release) is ready on
Apache Ignite readme.io. This document explains:

   - How to connect to Ignite cluster
   - Common message format (Request/Response header)
   - Supported Data types and their format
   - Request/Response format for each message type

Here are the links -

https://apacheignite.readme.io/docs/binary-client-protocol

https://apacheignite.readme.io/docs/binary-client-protocol-key-value-operations

https://apacheignite.readme.io/docs/binary-client-protocol-sql-operations

https://apacheignite.readme.io/docs/binary-client-protocol-binary-type-operations

https://apacheignite.readme.io/docs/binary-client-protocol-cache-configuration-operations


Currently these pages are hidden and are accessible only with the link.
They will be active after the release.

-Prachi

Re: IGNITE-7107 Apache Ignite RPM packages

[Denis Magda]

Just as a follow up for the community.

We had a private conversation with Peter and decided that RPMs will be 
initially hosted in Ignite root. Going forward (Ignite 2.5) we might to store 
RPMs and DEBs on JFrog Bintray [1] (this is what Cassandra does for its DEB 
packages [2]).

So, Peter please keep us posted on immediate results and your investigation 
results on how to proceed with RPMs and DEBs after we release 2.4.

[1] https://bintray.com/ 
[2] http://apache.org/dist/cassandra/debian/ 


—
Denis

> On Jan 17, 2018, at 10:58 PM, Petr Ivanov  wrote:
> 
> Hi, Denis.
> 
> 
> Proposed layout will require changes to release procedure.
> Also, I’d like to add to this layout symlink to latest repository, which we 
> will update every release.
> 
> But my concern will be — are we allowed to add and store about half a 
> gigabyte of artifacts every 3 months?
> 
> 
> 
>> On 18 Jan 2018, at 04:16, Denis Magda  wrote:
>> 
>> Hi Petr,
>> 
>> I would go for the approach implemented for Cassandra. Specifically:
>> 
>> Cassandra root repository includes all the most recent versions and packages 
>> for RPM and DEB:
>> http://www.apache.org/dist/cassandra/
>> 
>> This is a subdirectory for RPMs there:
>> http://www.apache.org/dist/cassandra/redhat/ 
>> 
>> 
>> So, technically it’s possible to have more than one version in the root and 
>> not worrying about that something is moved to the archives. It suggests to 
>> me that we have only one directory with the latest version in Ignite root 
>> because we took this path.
>> 
>> I propose to lay out Ignite root this way:
>> 
>> - latest Ignite version directory
>> - rpm
>> — 2.4
>>  — ignite-2.1..rpm
>>  — etc
>> — 2.5
>> ---
>> - deb
>>   — 2.5
>>  — ignite-2.1..deb
>>  — etc
>> — 2.6
>> ---
>> 
>> Ignite latest version directory is changed over the time while “rpm” and 
>> “deb” are never go to archive. We might archive specific RPM/DEB versions 
>> over the time, but presently it’s not an issue.
>> 
>> —
>> Denis
>> 
>>> On Jan 17, 2018, at 4:18 AM, Petr Ivanov  wrote:
>>> 
>>> Hi, Igniters!
>>> 
>>> 
>>> As part of "Apache Ignite in Packages" initiative, I’ve introduced update 
>>> to Release procedure, which consists of:
>>> - RPM-build instruction [1].
>>> - new "vote_3_step_1[rpm]create_rpm_repository.sh” script which does 
>>> everything else to prepare RPM-repository layout along with source and 
>>> binary archives.
>>> So 2.4 will be uploaded with RPM-repository structure and will be eligible 
>>> for use as standard third-party repository.
>>> 
>>> Yet, I have concerns regarding this method of packages hosting.
>>> Current package-placing architecture assumes, that repository will be 
>>> available as something like this [2]. But after next major release (2.5 for 
>>> example) that URL will become unavailable due to archive procedure — users 
>>> will have to update repository URL for continuous access to that version.
>>> If we are to place repository layout to the root [3], then after next major 
>>> release (2.5 for example) package of 2.4 version will silently become 
>>> unavailable for installing. However if we manage somehow to have single 
>>> repository layout with multiple packages versions in Apache Archive, users 
>>> with plugged in main and archive repositories will get access to all new 
>>> and archive version of Apache Ignite transparently. Unfortunately — I do 
>>> not know how this can be achieved.
>>> 
>>> There is also one last approach for package (and artifacts in common) 
>>> keeping — we can have some kind of third-party mirror, where will be able 
>>> to host all artifacts, binaries, packages, repositories and other Apache 
>>> Ignite related stuff with full control and access according to current 
>>> developer role (reducing impact on Apache’s storages and uploading there 
>>> only sources).
>>> 
>>> 
>>> Please, share your thoughts on subject. 
>>> 
>>> 
>>> [1] https://cwiki.apache.org/confluence/display/IGNITE/RPM-packages
>>> [2] http://apache.org/dist/ignite/2.4.0/rpm
>>> [3] http://apache.org/dist/ignite
>>> 
>>> 
 On 29 Dec 2017, at 07:54, Petr Ivanov  wrote:
 
 Hi, Denis.
 
 
 I was glad to contribute.
 
 Concerning DEB package — for 2.4 release I’m planning to introduce 
 instructions and spec files for conversion RPM package to DEB, 
 substantially reducing efforts for now because of file structure and 
 install scripts inheritance.
 Later, of course, I’m going to prepare fully synchronised source-based 
 package creation process, packages from which are meant for inclusion into 
 official repositories.
 
 
 
> On 28 Dec 2017, at 22:53, Denis Magda  wrote:
> 
> Peter, thanks for this Christmas/New Year gift for the community! :)

[jira] [Created] (IGNITE-7470) Eviction policy for SQL on-heap row cache

[Denis Magda (JIRA)]

Denis Magda created IGNITE-7470:
---

 Summary: Eviction policy for SQL on-heap row cache
 Key: IGNITE-7470
 URL: https://issues.apache.org/jira/browse/IGNITE-7470
 Project: Ignite
  Issue Type: New Feature
  Components: sql
Affects Versions: 2.4
Reporter: Denis Magda


SQL on-heap row cache was introduced in Ignite 2.4:

[https://apacheignite-sql.readme.io/v2.3/docs/performance-and-debugging_24_hidden#sql-on-heap-row-cache]

The cache can occupy as much RAM as allocated and used for off-heap data 
regions. If a user stores dozens or hundreds of gigabytes in the data regions 
the on-heap row cache will become enormous and the cluster will suffer from 
atrocious GC pauses.

Let's come up with an eviction policy for this cache. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Binary protocol documentation

[Pavel Tupitsyn]

Hi Prachi,

1. Fixed in code, wiki doc updated
2. Actually the response contains first page of results, same as SQL and
FIELDS queries. Wiki page fixed.

Please update readme io pages accordingly.

Thanks,
Pavel

On Thu, Jan 18, 2018 at 9:55 AM, Prachi Garg  wrote:

> Hi Pavel,
>
> I have a few more questions regarding the binary protocol.
>
> 1. OP_GET_BINARY_TYPE
>
>
>- Response returns array (not mentioned in the wiki doc), but
>OP_PUT_BINARY_TYPE does not require to pass an array. Wiki doc need to be
>fixed.
>- Response returns Schema Id as well (not mentioned in the left column
>of the spec for OP_GET_BINARY_TYPE; needs to be fixed in the wiki doc).
>
>
> 2. OP_QUERY_SCAN
>
>
>- Response returns only Cursor Id ( as mentioned in the wiki doc).
>However, OP_QUERY_SCAN_CURSOR_GET_PAGE returns complete query data. Why
>doesn't OP_QUERY_SCAN return query data? Why is the user supposed to call
>OP_QUERY_SCAN_CURSOR_GET_PAGE to get the data?
>
> If you update the wiki doc, please update the document as well. The
> document links are mentioned in this ticket - https://issues.apache.org/ji
> ra/browse/IGNITE-6607
>
> Thanks,
> -Prachi
>

Re: Internal problems requiring graceful node shutdown, reboot, etc.

[Jokser]

Igniters,

I have implemented handling critical persistence I/O errors with temporary
callback which stops the node. After  PR
   merge the callback should be
replaced with the generic solution proposed by Anton.
Also I have added tests checking that node recovers successfully after Cache
initialization, Checkpoint writing and WAL writing critical failures.



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[GitHub] ignite pull request #3400: Ignite 6946 1

[slukyano]

GitHub user slukyano opened a pull request:

https://github.com/apache/ignite/pull/3400

Ignite 6946 1



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-6946-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3400.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3400


commit 6e94275db145e3fd2141f7af96af0ec6f1c5bdef
Author: Stanislav Lukyanov 
Date:   2018-01-18T13:42:19Z

IGNITE-6946: Adjust log4j and log4j2 to allow updating configuration files 
on the fly

commit 2868566f976beb5915b11024a7e7ca61a0704ddf
Author: Stanislav Lukyanov 
Date:   2018-01-18T14:00:27Z

Merge remote-tracking branch 'apache/master' into ignite-6946-1

# Conflicts:
#   modules/core/src/main/java/org/apache/ignite/IgniteSystemProperties.java




---

[GitHub] ignite pull request #3226: IGNITE-6341: Direct IO implemented for file page ...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3226


---

Re: Username/password authentication for thin clients

[Taras Ledkov]

Password hashing algorithms of the popular vendors:

mysql: SHA-265, old-native-hash
postgres: MD5, DES, Extended DES, Blowfish-based
oracle: SHA-1

Some about "comparison" SHA-2 vs bcrypt [1]:

> SHA-512 is a cryptographic hash while bcrypt is a password hash or 
PBKDF (password based key derivation function).


> SHA-512 has been designed to be fast. You don't want any delays when 
validating a signature, for instance.

> There is no reason for generic cryptographic hashes to be slow.

> bcrypt on the other hand is a password hash that performs key 
strengthening on the input.
> Basically it does this by slowing down the calculation so that 
attackers will have to spend

> more resources to find the input by brute forcing or dictionary attacks.
> The idea is that although the legit users - you in this case - will 
also be slowed down,
> they are only slowed down once per password. However the attackers 
are slowed down for each try.
> The legit user is of course much more likely to input the right 
password first.


> Furthermore bcrypt also contains a salt as input, which can be used 
to avert rainbow table attacks.


Conclusion: bcrypt can provide more security but the popular vendors use 
SHA and even MD5 by default.


[1]. 
https://crypto.stackexchange.com/questions/46550/benchmark-differences-between-sha-512-and-bcrypt


On 18.01.2018 9:29, Vladimir Ozerov wrote:

Taras,

I think we need a comparison of available options and (possibly) analysis
what other vendors use.

On Tue, Jan 16, 2018 at 3:56 PM, Taras Ledkov  wrote:


What do you think about usage bcrypt [1], [2] to store encrypted password?

[1] https://stackoverflow.com/questions/1561174/sha512-vs-blowfi
sh-and-bcrypt
[2] https://en.wikipedia.org/wiki/Bcrypt



On 15.01.2018 11:19, Vladimir Ozerov wrote:


2) Credentials will be stored in a form of [username + hash] [1]


--
Taras Ledkov
Mail-To: tled...@gridgain.com




--
Taras Ledkov
Mail-To: tled...@gridgain.com

[GitHub] ignite pull request #3399: IGNITE-7316: Make Linear SVM for binary classific...

[zaleslaw]

GitHub user zaleslaw opened a pull request:

https://github.com/apache/ignite/pull/3399

IGNITE-7316: Make Linear SVM for binary classification

1. Fixed bugs in LabeledDatasets
2. Added SVM Model
3. Added SVM Trainer based on SDCA algorithm
4. Added tests for distributed and local versions


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/gridgain/apache-ignite ignite-7316

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/ignite/pull/3399.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #3399


commit 7d22bcd33fcea3a7588c46368b5289d5b306db7f
Author: Zinoviev Alexey 
Date:   2017-12-07T11:01:43Z

Merge from master

commit 84cbd8b380772ce773790b18066c86b663b1af27
Author: Zinoviev Alexey 
Date:   2017-12-13T10:36:56Z

Merge branch 'master' of https://github.com/apache/ignite

commit b58db6a44be3c625174c1d89c577240771d1bfb4
Author: Zinoviev Alexey 
Date:   2017-12-26T16:37:24Z

Merged from master

commit c050cf6e9ad052ca2d5d15b035da9536eab5ba80
Author: Zinoviev Alexey 
Date:   2017-12-26T19:06:24Z

IGNITE-7205: Added draft

commit 6506cf1d0e3bdf50125004494d075d81b863a0a2
Author: Zinoviev Alexey 
Date:   2017-12-27T08:06:30Z

IGNITE-7205: Fixed classes

commit 427743e0ad8ab1cbbc2a45d3e2b032a6b66c5632
Author: Zinoviev Alexey 
Date:   2017-12-27T14:19:10Z

IGNITE-7205: Refactored Labeled Dataset

commit 1f4792fe2a4cfddbee5390b4e79d74f1cf74585e
Author: Zinoviev Alexey 
Date:   2017-12-27T14:57:49Z

IGNITE-7205: Fixed serialization issue

commit de3996fabe7d77795517c07d43ec1a631494209a
Author: Zinoviev Alexey 
Date:   2017-12-27T17:20:24Z

IGNITE-7205: Added Labelling Machine for group prediction

commit 7ad09a115105ab31ef7caecf83b6466df9f102bb
Author: Yury Babak 
Date:   2017-12-28T11:49:10Z

IGNITE-7205: Dataset API

codestyle fixes

commit 26f878d13f16e07b8e0b939545e504700e581f6a
Author: zaleslaw 
Date:   2017-12-28T12:24:41Z

IGNITE-7205: Fixed externalization

commit 9e0d060f0a2d4b86c473a6e48817be8693ad0465
Author: zaleslaw 
Date:   2017-12-28T12:50:13Z

IGNITE-7205: Fixed bugs

commit 0acd8f82df090da5c5216bdb400d09fc77b25c79
Author: zaleslaw 
Date:   2017-12-28T16:47:32Z

Initial commit

commit f68785c2296ba414a89e4399c8fbece544cd18e2
Author: Zinoviev Alexey 
Date:   2018-01-10T13:59:30Z

Merge branch 'master' of https://github.com/apache/ignite

commit 612d713283b1e96274b3ec73a71310bb72da9cab
Author: Zinoviev Alexey 
Date:   2018-01-10T14:35:20Z

Merge from master

commit 731dfc5c2c8b0f11fca68088661e62d53ae92ea4
Author: Zinoviev Alexey 
Date:   2018-01-10T20:51:31Z

Added naive implementation

commit ed459bf97d25a9ec4276f4303724f760cf34d67e
Author: zaleslaw 
Date:   2018-01-11T16:09:50Z

Worked version

commit 35e54a086b10cdcb6f1e86fe07dc3b3ae66058e2
Author: Zinoviev Alexey 
Date:   2018-01-12T16:25:44Z

Refactored code

commit a82ab9a2abebe49df3eaba71599bcb769afe3ecd
Author: Zinoviev Alexey 
Date:   2018-01-16T18:39:06Z

Refactored code

commit fa633750e24f76914c0632803facbb16513520de
Author: Zinoviev Alexey 
Date:   2018-01-16T18:53:00Z

Refactored code

commit 84e476ff4fc05347b2b58424218e136eec8190de
Author: Zinoviev Alexey 
Date:   2018-01-16T19:13:45Z

Fixed tests

commit 2618a04d7f95ef4be0b3951f4bc4b242de4d1940
Author: Zinoviev Alexey 
Date:   2018-01-17T12:10:03Z

Fixed style

commit 116b887cb5f8109418b1a22ffda50280654bd02b
Author: Zinoviev Alexey 
Date:   2018-01-18T09:20:57Z

Fixed style

commit 7be3c489c44c2305d96771d5a972f820e56af0e8
Author: Zinoviev Alexey 
Date:   2018-01-18T09:31:20Z

Merge branch 'master' of https://github.com/apache/ignite

commit 3c79b70cbb62df733a8ca1374ebe36fb7c1a175c
Author: Zinoviev Alexey 
Date:   2018-01-18T09:32:20Z

Merge branch 'master' into ignite-7316

commit a2da58b2e7e8089ec36c6fe9f5c607496079f67e
Author: Zinoviev Alexey 
Date:   2018-01-18T10:26:42Z

Fixed bug in parsing from file

commit 072eb41b8e362b3b6c0f9b8de4ead719e02c3d92
Author: Zinoviev Alexey 
Date:   2018-01-18T10:31:47Z

Removed incorrect data




---

review Rework exception handling in suspend()\resume() methods

[ALEKSEY KUZNETSOV]

Hello, Igntrs!

Could you plz review the ticket [1],
upsource : [2]

[1]: https://issues.apache.org/jira/browse/IGNITE-7409
[2]: https://reviews.ignite.apache.org/ignite/review/IGNT-CR-463


-- 

*Best Regards,*

*Kuznetsov Aleksey*

[GitHub] ignite pull request #3389: IGNITE-7413 Fix SqlDmlExample

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3389


---

[GitHub] ignite pull request #3378: IGNITE-3935: Fix P2P class loading for StreamTran...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/ignite/pull/3378


---