Brane,
I agree that ideally no direct mapping should exist between types with
different size or precision. And of course we can introduce a new type
which will have the same characteristics on all platforms.
The downside is that users will have to learn new types and use them
instead of standard o
Cos,
Yes, no long-time locking is expected here.
On Wed, Oct 7, 2015 at 6:57 AM, Konstantin Boudnik wrote:
> IIRC NN should be locking on these ops anyway, shouldn't it? The situation
> is
> no different if multiple clients are doing these operations
> near-simultaneously. Unless I missed someth
IIRC NN should be locking on these ops anyway, shouldn't it? The situation is
no different if multiple clients are doing these operations
near-simultaneously. Unless I missed something here...
On Thu, Sep 24, 2015 at 11:28AM, Sergi Vladykin wrote:
> May be just check that they are not parent-child
Valentin Kulichenko created IGNITE-1622:
---
Summary: clear() method works incorrectly with near caches
Key: IGNITE-1622
URL: https://issues.apache.org/jira/browse/IGNITE-1622
Project: Ignite
Pavel Konstantinov created IGNITE-1621:
--
Summary: 'Clone' button doesn't work properly
Key: IGNITE-1621
URL: https://issues.apache.org/jira/browse/IGNITE-1621
Project: Ignite
Issue Type:
Github user agura closed the pull request at:
https://github.com/apache/ignite/pull/99
---
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 feature is enable
Maybe I don't quite get your point, Andrey, but to me, the cache affinity nodes
could just be equally expressed as a ClusterGroup.forCache(...) cluster group.
Then, why can't Ignite expose just a single method that takes a cluster group
(rather than a cache name) as a parameter and returns an Af
GitHub user agura opened a pull request:
https://github.com/apache/ignite/pull/137
ignite-1526 IBM JDK is not fully supported by the platfrom
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agura/incubator-ignite ignite-1526
Alt
>
> Just curios, how about providing an override for Ignite.affinity() method
> that ClusterGroup? Is there something fundamentally wrong about calculating
> the affinity for an arbitrary collection of nodes (such as a ClusterGroup
> is)?
>
Andrey,
I think Ignite.affinity() method for ClusterGrou
On Tue, Oct 6, 2015 at 8:46 AM, Andrey Kornev
wrote:
> Thanks, Andrey! This definitely helps.
>
> It's just that implementing such a simple feature in the "user space"
> feels awkward and requires intimate knowledge of fairly low-level details
> of how things work in the current version.
>
> Jus
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/136
IGNITE-1619 Platform .Net: Generic type is lost during array/collection
serialization
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupits
Github user vladisav closed the pull request at:
https://github.com/apache/ignite/pull/120
---
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 feature is en
GitHub user vladisav reopened a pull request:
https://github.com/apache/ignite/pull/120
IGNITE-638: Implements cache distributed semaphore
This interface provides a rich API for working with distributed semaphore.
Distributed semaphore provides functionality similar to
java.util
Thanks, Andrey! This definitely helps.
It's just that implementing such a simple feature in the "user space" feels
awkward and requires intimate knowledge of fairly low-level details of how
things work in the current version.
Just curios, how about providing an override for Ignite.affinity()
Andrey,
> 1) I'm expected to return an instance of the internal class
> AffinityTopologyVersion.
If you are talking about AffinityContextFunction.currentTopologyVersion
method then for now this method is nowhere uses. But it make sense to
return non null value in order to avoid problems in the
Andrey, thanks!
But a "properly formed AffinityFunctionContext" is the problem:
1) I'm expected to return an instance of the internal class
AffinityTopologyVersion.
2) the consequences of returning null from
AffinityFunctionContext.previousAssignment and
AffinityFunctionContext.discoveryEvent m
Vladisav,
Please move issue to the Patch Available state and mention pull request
(start a title of the pull request from 'IGNITE-638').
Val,
Do you have opportunity to review pull request?
On Fri, Oct 2, 2015 at 11:47 AM, Dmitriy Setrakyan
wrote:
> Any reason the pull request is not mentioned
Andrey,
See AffinityFunction.assignPartitions method. It returns assignment list as
List> where index of element in returned list corresponds
to partition number. Assignment for each partition represented as list of
nodes where primary node is always the first. So you can use existing
affinity fun
Dmitriy,
The affinity function only maps a key to a partition id and it doesn't seem to
provide a way to map the partition id to a cluster node. So I'm a little bit
confused right now.
Could you please clarify?
Thanks a lot
Andrey
> From: dsetrak...@apache.org
> Date: Mon, 5 Oct 2015 09:53:2
On 06.10.2015 12:26, Vladimir Ozerov wrote:
> Yakov, this could work in .Net where you have real generics. But it will
> not work in Java in general case due to type erasure - you simply cannot
> infer the type.
>
> Let's look closely to this:
> Date Java: 10^-3
> Timestamp Java: 10^-9
> DateT
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/135
---
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 feature is enab
Github user agura closed the pull request at:
https://github.com/apache/ignite/pull/134
---
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 feature is enabl
GitHub user agura opened a pull request:
https://github.com/apache/ignite/pull/135
ignite-1620 Tests muted
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agura/incubator-ignite ignite-1620-tests-muted
Alternatively you can revi
Dmitriy,
I've fixed page according to your request except:
>- "Release Process" section should be a numbered list describing steps
>(including QA branch) necessary to create a release.
As far as I understans there is no QA's at Ignite community. GridGain QAs
can provide some help, but it
Andrey Gura created IGNITE-1620:
---
Summary: [Test failed] IGFS:Directory creation in DUAL mode failed
Key: IGNITE-1620
URL: https://issues.apache.org/jira/browse/IGNITE-1620
Project: Ignite
Issu
Yakov, this could work in .Net where you have real generics. But it will
not work in Java in general case due to type erasure - you simply cannot
infer the type.
Let's look closely to this:
Date Java: 10^-3
Timestamp Java: 10^-9
DateTime .Net: 10^-7
What we see here, is that mapping Java Da
2015-10-06 12:45 GMT+03:00 Dmitriy Setrakyan :
> On Tue, Oct 6, 2015 at 2:42 AM, Vladimir Ozerov
> wrote:
>
> > This doesn't answers the question. First, Java Timestamp has greater
> > precision than .Net DateTime, so silent data loss could happen in this
> case
> > as well. Second, "use timestam
On Tue, Oct 6, 2015 at 2:42 AM, Vladimir Ozerov
wrote:
> This doesn't answers the question. First, Java Timestamp has greater
> precision than .Net DateTime, so silent data loss could happen in this case
> as well. Second, "use timestamp" is defined on class level. It means we
> cannot handle a c
This doesn't answers the question. First, Java Timestamp has greater
precision than .Net DateTime, so silent data loss could happen in this case
as well. Second, "use timestamp" is defined on class level. It means we
cannot handle a class which have both Date and Timestamp fields.
Looks like a bug
On Tue, Oct 6, 2015 at 1:39 AM, Pavel Tupitsyn
wrote:
> Keep in mind that separating them can introduce difficulties for other
> platforms.
> For example, DateTime in .Net has more precision (100ns vs 1ms in Java).
> Serializing this in Java format will lead to data loss. Serializing .Net
> DateT
Pavel Tupitsyn created IGNITE-1619:
---
Summary: Platform .Net: Generic type is lost during
array/collection serialization
Key: IGNITE-1619
URL: https://issues.apache.org/jira/browse/IGNITE-1619
Proje
Keep in mind that separating them can introduce difficulties for other
platforms.
For example, DateTime in .Net has more precision (100ns vs 1ms in Java).
Serializing this in Java format will lead to data loss. Serializing .Net
DateTime as Timestamp will preserve precision, but may hurt
interoperab
I would definitely remove such a mapping if no one explains a reason we
have it.
--
Denis
On 10/6/2015 10:26 AM, Vladimir Ozerov wrote:
Igniters,
For some reason we "merged" Date and Timestamp types in portable
marshaller. They are both written in the same format with the same type ID.
And ho
Igniters,
For some reason we "merged" Date and Timestamp types in portable
marshaller. They are both written in the same format with the same type ID.
And how date is interpreted on read side - as Date or as Timestamp -
depends on configuration flag "use timestamp".
Is there are reason why we do
34 matches
Mail list logo
