Re: Default hash code generation strategy for new binary objects

I've posted proposed example of hash code resolver interface and XML configuration for classless key on issue page https://issues.apache.org/jira/browse/IGNITE-2294. 2016-09-29 20:16 GMT+03:00 Dmitriy Setrakyan : > On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda

Please unsubcribe me

unsubscribe

Re: Default hash code generation strategy for new binary objects

On Thu, Sep 29, 2016 at 9:57 AM, Denis Magda wrote: > Alex, > > A minor note regarding this > > > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > > A set of fields participating in hashCode and equals is impossible to > > change

[GitHub] ignite pull request #1134: IGNITE-4007 Fixed Query metrics min time

GitHub user akuznetsov-gridgain opened a pull request: https://github.com/apache/ignite/pull/1134 IGNITE-4007 Fixed Query metrics min time You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4007

Re: Default hash code generation strategy for new binary objects

Alex, A minor note regarding this > On Sep 29, 2016, at 8:39 AM, Alexey Goncharuk > wrote: > > A set of fields participating in hashCode and equals is impossible to > change without cluster restart. It’s unlikely that someone will change a key or at least it

Re: Default hash code generation strategy for new binary objects

On Thu, Sep 29, 2016 at 9:19 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > I want to step back a little bit. Why do we need to choose fields for > hashCode at all? If all fields participate in equals, all of them should > participate in hashCode as well. We already serialize a user

Re: Default hash code generation strategy for new binary objects

Dmitry, Just list them in XML config, in the section about indexed types. Will do proposal for that on issue page later today. Regarding validation of the field list - currently there's no (and hardly can be) protection against miscalculation of hash codes passed to the BinaryObjectBuilder. It's

Re: Default hash code generation strategy for new binary objects

I want to step back a little bit. Why do we need to choose fields for hashCode at all? If all fields participate in equals, all of them should participate in hashCode as well. We already serialize a user key in order to get a value from cache, so we can use a hashCode based on binary object

Re: Default hash code generation strategy for new binary objects

In the assumption that we do not have 'non-equals' fields, binary array comparison generally should be faster, because even if we did a field-by-field comparison, we would read the same amount of data anyway, but also would need to do some byte jiggling for type conversion. 2016-09-29 19:07

Re: Default hash code generation strategy for new binary objects

Alexander, How do you plan to annotate fields that participate in the hashcode calculation? Can you add all the changes you plan to make to the configuration in the ticket and post the link here? Also, we must make sure that hashcode fields do not change. I believe you should have validation in

[jira] [Created] (IGNITE-4007) SQL: QueryMetrics.minimumTime() is always zero.

Alexey Kuznetsov created IGNITE-4007: Summary: SQL: QueryMetrics.minimumTime() is always zero. Key: IGNITE-4007 URL: https://issues.apache.org/jira/browse/IGNITE-4007 Project: Ignite

Re: Default hash code generation strategy for new binary objects

Thanks everyone! Denis, yes, that's what I meant, now we're on the same page :) However, I'm worried about the same things Alexey is, that is, I'm not sure how we can handle presence of key fields that don't participate in 'equals' evaluation. Hence I'm all up for keeping mechanism of comparison

Re: Default hash code generation strategy for new binary objects

Alexey, in your opinion, what will be faster, the binary array comparison or field-by-field comparison? On Thu, Sep 29, 2016 at 8:39 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > Folks, let me point out a few obvious (or not) things > > A set of fields participating in hashCode and

Re: Default hash code generation strategy for new binary objects

Folks, let me point out a few obvious (or not) things A set of fields participating in hashCode and equals is impossible to change without cluster restart. Imagine a new client adding a field F to key structure (A, B) so that new key is (A, B, F). In this case key (1, 2, 0) will be treated as a

[jira] [Created] (IGNITE-4006) Hadoop: integrate with ResourceManager.

Vladimir Ozerov created IGNITE-4006: --- Summary: Hadoop: integrate with ResourceManager. Key: IGNITE-4006 URL: https://issues.apache.org/jira/browse/IGNITE-4006 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-4005) Hadoop: introduce default job counters.

Vladimir Ozerov created IGNITE-4005: --- Summary: Hadoop: introduce default job counters. Key: IGNITE-4005 URL: https://issues.apache.org/jira/browse/IGNITE-4005 Project: Ignite Issue Type:

[jira] [Created] (IGNITE-4004) .NET: Non-ASCII characters in code

Pavel Tupitsyn created IGNITE-4004: -- Summary: .NET: Non-ASCII characters in code Key: IGNITE-4004 URL: https://issues.apache.org/jira/browse/IGNITE-4004 Project: Ignite Issue Type: Bug

[GitHub] ignite pull request #1133: IGNITE-3972: Continuous query events could be los...

GitHub user AMashenkov opened a pull request: https://github.com/apache/ignite/pull/1133 IGNITE-3972: Continuous query events could be lost on backup node when primary leaves. Reproduced. Fix provided prevents CQ events from being lost, but single duplicate event can occur if

[GitHub] ignite pull request #1132: IGNITE-3163 IGFS: Add working directory notion.

GitHub user tledkov-gridgain opened a pull request: https://github.com/apache/ignite/pull/1132 IGNITE-3163 IGFS: Add working directory notion. You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-3163

[GitHub] ignite pull request #1131: Ignite 1.5.32

GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/1131 Ignite 1.5.32 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-1.5.32 Alternatively you can review and apply

[jira] [Created] (IGNITE-4003) Slow or faulty client can stall the whole cluster.

Vladimir Ozerov created IGNITE-4003: --- Summary: Slow or faulty client can stall the whole cluster. Key: IGNITE-4003 URL: https://issues.apache.org/jira/browse/IGNITE-4003 Project: Ignite

[GitHub] ignite pull request #1130: Ignite 4001

GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/1130 Ignite 4001 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-4001 Alternatively you can review and apply these

Re: Start threads in our pools on demand?

Ignite node thread dump after applying quick and dirty solution - just added *ThreadPoolExecutor.allowCoreThreadTimeOut(true)* to base thread pool: "srvc-deploy-#20%null%" "exchange-worker-#19%null%" "ttl-cleanup-worker-#18%null%" "grid-time-coordinator-#17%null%"

[jira] [Created] (IGNITE-4002) Incorrect errors/warnings while odbc driver installation

Ksenia Rybakova created IGNITE-4002: --- Summary: Incorrect errors/warnings while odbc driver installation Key: IGNITE-4002 URL: https://issues.apache.org/jira/browse/IGNITE-4002 Project: Ignite

Re: Start threads in our pools on demand?

Created ticket: https://issues.apache.org/jira/browse/IGNITE-4001 On Thu, Sep 29, 2016 at 12:25 PM, Alexey Kuznetsov wrote: > Just as idea - > > if we implement stop thread after some idle time, may be it make sense to > add a line to log about this? > > -- > Alexey

[GitHub] ignite pull request #1058: IGNITE-3163 IGFS: Add working directory notion.

Github user tledkov-gridgain closed the pull request at: https://github.com/apache/ignite/pull/1058 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the

[jira] [Created] (IGNITE-4001) Ignite thread pools must have timeouts for idle threads.

Vladimir Ozerov created IGNITE-4001: --- Summary: Ignite thread pools must have timeouts for idle threads. Key: IGNITE-4001 URL: https://issues.apache.org/jira/browse/IGNITE-4001 Project: Ignite

Re: Start threads in our pools on demand?

Just as idea - if we implement stop thread after some idle time, may be it make sense to add a line to log about this? -- Alexey Kuznetsov

Re: Start threads in our pools on demand?

+100500 We need to stop threads after some idle time. Sergi 2016-09-29 11:26 GMT+03:00 Vladimir Ozerov : > Igniters, > > If you look at a thread dump of an idle Ignite instance, you will find > billions threads there. System pool, public pool, management pool, IGFS >

Start threads in our pools on demand?

Igniters, If you look at a thread dump of an idle Ignite instance, you will find billions threads there. System pool, public pool, management pool, IGFS pool, data streamer pool, etc.. I think we can easily do the following with no risk to performance: 1) Set core size to zero to all thread

[jira] [Created] (IGNITE-4000) Web Console: Improve build speed for frontend

Maxim Afanasiev created IGNITE-4000: --- Summary: Web Console: Improve build speed for frontend Key: IGNITE-4000 URL: https://issues.apache.org/jira/browse/IGNITE-4000 Project: Ignite Issue