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 wrote:
>
>> Alex,
>>
>> A minor note
unsubscribe
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 without cluster restart.
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
Altern
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 should be a rare or
accidental
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 k
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
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
represe
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 GMT+0
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 t
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
Issu
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 f
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
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 di
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: Ta
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: Ta
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 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 n
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
A
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 th
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
Iss
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
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%"
"grid-time-server-reader-#16%null
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
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 Kuznetsov
>
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 feat
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
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
+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
> pool, data streamer pool, e
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 pools
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 Ty
31 matches
Mail list logo
