Re: Cluster group affinity

[Andrey Gura]

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 future.

2) the consequences of returning null from
> AffinityFunctionContext.previousAssignment and
> AffinityFunctionContext.discoveryEvent methods (because I can't provide any
> meaningful implementation for them) are not clear.
>

Both methods declared as @Nullable, so affinity function developer should
correctly handle this cases. In Ignite only FairAffinityFunction uses these
methods. FairAffinityFunction tries to obtain left node Id from event of
EventType.EVT_NODE_LEFT or EventType.EVT_NODE_FAILED type. It needs to
exclude this node assignment from previous assignments. So if your cluster
group lost node you can return EVT_NODE_LEFT discovery event with Id of
lost node from discoveryEvent method and assignments for previous cluster
group state from previousAssignment method.

RendezvousAffinityFunction uses only currentTopologySnapshot() and
backups() methods of AffinityFunctionContext interface.


On Tue, Oct 6, 2015 at 5:07 PM, Andrey Kornev 
wrote:

> 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 methods (because I can't provide any
> meaningful implementation for them) are not clear.
>
> Please advise.
>
> Thanks
> Andrey
>
> > Date: Tue, 6 Oct 2015 16:43:10 +0300
> > Subject: Re: Cluster group affinity
> > From: ag...@gridgain.com
> > To: dev@ignite.apache.org
> >
> > 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 functions for you case just passing properly formed
> > AffinityFunctionContext to assignPartitions method.
> >
> > On Tue, Oct 6, 2015 at 4:25 PM, Andrey Kornev 
> > wrote:
> >
> > > 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:25 -0700
> > > > Subject: Re: Cluster group affinity
> > > > To: dev@ignite.apache.org
> > > >
> > > > On Mon, Oct 5, 2015 at 2:28 AM, Andrey Kornev <
> andrewkor...@hotmail.com>
> > > > wrote:
> > > >
> > > > > Hello,
> > > > >
> > > > > I have a user-defined cluster group and I'd like to be able to
> > > > > consistently pick the same node in the group for a given key.
> > > Essentially,
> > > > > what I want is a cluster group affinity that is not associated
> with any
> > > > > cache. How can I do it?
> > > > >
> > > >
> > > > Andrey, perhaps you could just take our affinity function and use it
> > > > directly, no?
> > > >
> > > >
> > > > >
> > > > > Thanks
> > > > > Andrey
> > > > >
> > >
> > >
> >
> >
> >
> > --
> > Andrey Gura
> > GridGain Systems, Inc.
> > www.gridgain.com
>
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

Re: Cluster group affinity

[Dmitriy Setrakyan]

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.
>
> 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)?
>

Affinity is usually associated with data. In your case you have no data,
but you still need keys to be always mapped to the same node.  How about
creating an empty cache and using standard cache API for determining the
affinity for a key?


> Regards
> Andrey
>
> > Date: Tue, 6 Oct 2015 18:12:48 +0300
> > Subject: Re: Cluster group affinity
> > From: ag...@gridgain.com
> > To: dev@ignite.apache.org
> >
> > 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 future.
> >
> > 2) the consequences of returning null from
> > > AffinityFunctionContext.previousAssignment and
> > > AffinityFunctionContext.discoveryEvent methods (because I can't
> provide any
> > > meaningful implementation for them) are not clear.
> > >
> >
> > Both methods declared as @Nullable, so affinity function developer should
> > correctly handle this cases. In Ignite only FairAffinityFunction uses
> these
> > methods. FairAffinityFunction tries to obtain left node Id from event of
> > EventType.EVT_NODE_LEFT or EventType.EVT_NODE_FAILED type. It needs to
> > exclude this node assignment from previous assignments. So if your
> cluster
> > group lost node you can return EVT_NODE_LEFT discovery event with Id of
> > lost node from discoveryEvent method and assignments for previous cluster
> > group state from previousAssignment method.
> >
> > RendezvousAffinityFunction uses only currentTopologySnapshot() and
> > backups() methods of AffinityFunctionContext interface.
> >
> >
> > On Tue, Oct 6, 2015 at 5:07 PM, Andrey Kornev 
> > wrote:
> >
> > > 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 methods (because I can't
> provide any
> > > meaningful implementation for them) are not clear.
> > >
> > > Please advise.
> > >
> > > Thanks
> > > Andrey
> > >
> > > > Date: Tue, 6 Oct 2015 16:43:10 +0300
> > > > Subject: Re: Cluster group affinity
> > > > From: ag...@gridgain.com
> > > > To: dev@ignite.apache.org
> > > >
> > > > 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 functions for you case just passing properly formed
> > > > AffinityFunctionContext to assignPartitions method.
> > > >
> > > > On Tue, Oct 6, 2015 at 4:25 PM, Andrey Kornev <
> andrewkor...@hotmail.com>
> > > > wrote:
> > > >
> > > > > 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:25 -0700
> > > > > > Subject: Re: Cluster group affinity
> > > > > > To: dev@ignite.apache.org
> > > > > >
> > > > > > On Mon, Oct 5, 2015 at 2:28 AM, Andrey Kornev <
> > > andrewkor...@hotmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > I have a user-defined cluster group and I'd like to be able to
> > > > > > > consistently pick the same node in the group for a given key.
> > > > > Essentially,
> > > > > > > what I want is a cluster group affinity that is not associated
> > > with any
> > > > > > > cache. How can I do it?
> > > > > > >
> > > > > >
> > > > > > Andrey, perhaps you could just take our affinity function and
> use it
> > > > > > directly, no?
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > > Andrey
> > > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Andrey Gura
> > > > GridGain Systems, Inc.
> > 

Re: Why portable marshaller handle Date and Timestamp in the same way?

[Denis Magda]

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 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 this? Transparent conversion from Timestamp
to Date is invalid use case because it leads to data loss. Looks like we
can separate these types from each other and remove this strange
configuration parameter.

Thoughts?

Vladimir.

Re: Why portable marshaller handle Date and Timestamp in the same way?

[Pavel Tupitsyn]

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
interoperability.

Thanks,

On Tue, Oct 6, 2015 at 10:29 AM, Denis Magda  wrote:

> 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 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 this? Transparent conversion from Timestamp
>> to Date is invalid use case because it leads to data loss. Looks like we
>> can separate these types from each other and remove this strange
>> configuration parameter.
>>
>> Thoughts?
>>
>> Vladimir.
>>
>>
>


-- 
-- 
Pavel Tupitsyn
GridGain Systems, Inc.
www.gridgain.com

Re: Why portable marshaller handle Date and Timestamp in the same way?

[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 timestamp" is defined on class level. It means we
> cannot handle a class which have both Date and Timestamp fields.
>
> Looks like a bug and/or invalid design for me.
>

Agree, current design is not ideal. Vladimir, do you have other suggestions?


>
> On Tue, Oct 6, 2015 at 12:21 PM, Dmitriy Setrakyan 
> wrote:
>
> > 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
> > > DateTime as Timestamp will preserve precision, but may hurt
> > > interoperability.
> > >
> >
> > Thanks Pavel. This is exactly the reason why Date vs Timestamp selection
> it
> > is implemented right now via a configuration flag.
> >
> >
> > >
> > > Thanks,
> > >
> > > On Tue, Oct 6, 2015 at 10:29 AM, Denis Magda 
> > wrote:
> > >
> > > > 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 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 this? Transparent conversion from
> > > Timestamp
> > > >> to Date is invalid use case because it leads to data loss. Looks
> like
> > we
> > > >> can separate these types from each other and remove this strange
> > > >> configuration parameter.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >> Vladimir.
> > > >>
> > > >>
> > > >
> > >
> > >
> > > --
> > > --
> > > Pavel Tupitsyn
> > > GridGain Systems, Inc.
> > > www.gridgain.com
> > >
> >
>

Re: Cluster group affinity

[Andrey Kornev]

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 Affinity instance 
corresponding to the group? Cheers!
_
From: Andrey Gura 
Sent: Tuesday, October 6, 2015 9:31 PM
Subject: Re: Cluster group affinity
To:  


   >   
 > 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 ClusterGroup does not make sense in   
 API because for each cache topology snapshot always consist of cache   
 affinity nodes. However, I don't see any fundamentally problems in using   
 affinity fucntion for some collection of nodes. But you should make sure   
 that your code is aware of changes in this collection.   

 On Tue, Oct 6, 2015 at 6:46 PM, 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.   
 >   
 > 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)?   
 >   
 > Regards   
 > Andrey   
 >   
 > > Date: Tue, 6 Oct 2015 18:12:48 +0300   
 > > Subject: Re: Cluster group affinity   
 > > From: ag...@gridgain.com   
 > > To: dev@ignite.apache.org   
 > >   
 > > 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 future.   
 > >   
 > > 2) the consequences of returning null from   
 > > > AffinityFunctionContext.previousAssignment and   
 > > > AffinityFunctionContext.discoveryEvent methods (because I can't   
 > provide any   
 > > > meaningful implementation for them) are not clear.   
 > > >   
 > >   
 > > Both methods declared as @Nullable, so affinity function developer should  
 > >  
 > > correctly handle this cases. In Ignite only FairAffinityFunction uses   
 > these   
 > > methods. FairAffinityFunction tries to obtain left node Id from event of   
 > > EventType.EVT_NODE_LEFT or EventType.EVT_NODE_FAILED type. It needs to   
 > > exclude this node assignment from previous assignments. So if your   
 > cluster   
 > > group lost node you can return EVT_NODE_LEFT discovery event with Id of   
 > > lost node from discoveryEvent method and assignments for previous cluster  
 > >  
 > > group state from previousAssignment method.   
 > >   
 > > RendezvousAffinityFunction uses only currentTopologySnapshot() and   
 > > backups() methods of AffinityFunctionContext interface.   
 > >   
 > >   
 > > On Tue, Oct 6, 2015 at 5:07 PM, Andrey Kornev    
 > > wrote:   
 > >   
 > > > 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 methods (because I can't   
 > provide any   
 > > > meaningful implementation for them) are not clear.   
 > > >   
 > > > Please advise.   
 > > >   
 > > > Thanks   
 > > > Andrey   
 > > >   
 > > > > Date: Tue, 6 Oct 2015 16:43:10 +0300   
 > > > > Subject: Re: Cluster group affinity   
 > > > > From: ag...@gridgain.com   
 > > > > To: dev@ignite.apache.org   
 > > > >   
 > > > > 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 functions for you case just passing properly formed   
 > > > > AffinityFunctionContext to assignPartitions method.   
 > > > >   
 > > > > On Tue, Oct 6, 2015 at 4:25 PM, Andrey Kornev <   
 > 

Re: Why portable marshaller handle Date and Timestamp in the same way?

[Vladimir Ozerov]

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 Date to .Net DateTime is alomst
certainly a bad thing because we loos too much data. But interoping between
Timestamp and DateTime is more or less sensible, we loose only 0.1-s of
microseconds.

I would suggest the following solution:
1) Fully decouple Date and Timestamp in Java. These are completely
different types from Java perspective, H2 perspective (see GridH2Date,
GridH2Timestamp), any data database perspective, etc..
2) Map .Net DateTime to Java Timestamp with warning about possible
precision loss.

Vladimir.

On Tue, Oct 6, 2015 at 1:08 PM, Yakov Zhdanov  wrote:

> 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 timestamp" is defined on class level. It means we
> > > cannot handle a class which have both Date and Timestamp fields.
> > >
> > > Looks like a bug and/or invalid design for me.
> > >
> >
> > Agree, current design is not ideal. Vladimir, do you have other
> > suggestions?
>
>
> how about writing at max precision possible (+ proper type ID) and
> interpreting binary data on read depending on (a) portable reader method
> call or (b) on actual field type.
>
> --Yakov
>

Re: 'How to Contribute' wiki page updated.

[Anton Vinogradov]

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's not a part of Ignite release process.
Another steps Prepare->Vote->Release are declared at Apache site and they
are the same for all projects.

   - I would add Continuous Integration section with URL to TeamCity. It
>should also state that merges to master should only happen after the
> whole
>TC suite passes.

Each case at workflow ends with phrase similar to:
"Run TC tests.Once tests are passed, the pull request can be reviewed and
merged by a committer."
Is it enough?

On Tue, Oct 6, 2015 at 8:10 AM, Dmitriy Setrakyan 
wrote:

> Thanks, Anton!
>
> I think the whole process looks too big right now. Perhaps we can make the
> following changes:
>
>- Remove "Development Process" section (not sure if it applies to us).
>- Remove "Git Workflow" section as it is described already in "Workflow"
>section.
>- Remove "Git Branches" section
>- "Release Process" section should be a numbered list describing steps
>(including QA branch) necessary to create a release.
>- For the ticket branch section, I don't think it is clear how to submit
>a branch for review or how to apply changes on master. Would be nice if
> you
>could clarify.
>- I would add Continuous Integration section with URL to TeamCity. It
>should also state that merges to master should only happen after the
> whole
>TC suite passes.
>
> Raul, it would be nice if you could also take a look and provide comments.
>
> Thanks,
> D.
>
> On Mon, Oct 5, 2015 at 7:36 AM, Anton Vinogradov  wrote:
>
> > Igniters,
> >
> > https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute
> page
> > updated.
> >
> > Changes:
> > 1) Jira process and Git process becomes part of How to Contribute
> > .
> > 2) Added 'Ticket Branch' case (only for committers).
> > 3) Fixed minor issues.
> >
> > It will be nice if someone check correctness.
> >
>

Re: Cluster group affinity

[Andrey Gura]

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 functions for you case just passing properly formed
AffinityFunctionContext to assignPartitions method.

On Tue, Oct 6, 2015 at 4:25 PM, Andrey Kornev 
wrote:

> 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:25 -0700
> > Subject: Re: Cluster group affinity
> > To: dev@ignite.apache.org
> >
> > On Mon, Oct 5, 2015 at 2:28 AM, Andrey Kornev 
> > wrote:
> >
> > > Hello,
> > >
> > > I have a user-defined cluster group and I'd like to be able to
> > > consistently pick the same node in the group for a given key.
> Essentially,
> > > what I want is a cluster group affinity that is not associated with any
> > > cache. How can I do it?
> > >
> >
> > Andrey, perhaps you could just take our affinity function and use it
> > directly, no?
> >
> >
> > >
> > > Thanks
> > > Andrey
> > >
>
>



-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

Re: Why portable marshaller handle Date and Timestamp in the same way?

[Branko Čibej]

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
> DateTime  .Net: 10^-7
>
> What we see here, is that mapping Java Date to .Net DateTime is alomst
> certainly a bad thing because we loos too much data. But interoping between
> Timestamp and DateTime is more or less sensible, we loose only 0.1-s of
> microseconds.
>
> I would suggest the following solution:
> 1) Fully decouple Date and Timestamp in Java. These are completely
> different types from Java perspective, H2 perspective (see GridH2Date,
> GridH2Timestamp), any data database perspective, etc..
> 2) Map .Net DateTime to Java Timestamp with warning about possible
> precision loss.

>From the peanut gallery ... it seems like a really bad idea to design a
marshalling format based on what some language standard library happens
to provide. IMO, the way to do this is to define your own max precision
timestamp type, marshal it at full precision, and provide conversions to
standard types. That way your users can choose to use your type which
provides full precision on all platforms, or decide to use the standard
types with the potential loss of precision that entails; but it becomes
*their* decision, not a limitation set by the library.

-- Brane


> On Tue, Oct 6, 2015 at 1:08 PM, Yakov Zhdanov  wrote:
>
>> 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 timestamp" is defined on class level. It means we
 cannot handle a class which have both Date and Timestamp fields.

 Looks like a bug and/or invalid design for me.

>>> Agree, current design is not ideal. Vladimir, do you have other
>>> suggestions?
>>
>> how about writing at max precision possible (+ proper type ID) and
>> interpreting binary data on read depending on (a) portable reader method
>> call or (b) on actual field type.
>>
>> --Yakov
>>

[GitHub] ignite pull request: IGNITE-1619 Platform .Net: Generic type is lo...

[ptupitsyn]

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/ptupitsyn/ignite ignite-1619

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

https://github.com/apache/ignite/pull/136.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 #136


commit 1164ff10694ce4690f57190708d6bc4a6efaf9b5
Author: ptupitsyn 
Date:   2015-10-06T10:04:49Z

wip

commit c4fc5a9def2c46454a774a6527066d4742c9
Author: ptupitsyn 
Date:   2015-10-06T10:13:33Z

test added

commit 73700655a6d6f20dbe5ecd92a90fc5734a5ba5e4
Author: ptupitsyn 
Date:   2015-10-06T10:14:55Z

test wip

commit 2a70a47dc103e87bacd1792434aaabb408362dcd
Author: ptupitsyn 
Date:   2015-10-06T10:25:01Z

wip

commit 2f4204b5d57e411517893eb9c43436025eaf5b47
Author: ptupitsyn 
Date:   2015-10-06T10:32:16Z

wip

commit 3c76ef26b4204358d4f709516a94f6e351da3ca5
Author: ptupitsyn 
Date:   2015-10-06T10:49:14Z

wip WriteGenericArray

commit 53c2cb42f95e68e1836757a80725289b8851ac7d
Author: ptupitsyn 
Date:   2015-10-06T12:11:29Z

wip

commit 01e110f59fe2884cddb725b8c5947458b06cb840
Author: ptupitsyn 
Date:   2015-10-06T12:16:34Z

ReadWriteTypedArray done

commit d0aef6919f170af5e26a13a9240033a48871d631
Author: ptupitsyn 
Date:   2015-10-06T12:24:59Z

wip

commit cdf3397736bcf97eb64ee3ebfb4c1c9a54b7f27a
Author: ptupitsyn 
Date:   2015-10-06T12:32:51Z

wip

commit c7829e068bc05bf34d7609c0b9ee3c0631947225
Author: ptupitsyn 
Date:   2015-10-06T13:00:31Z

wip

commit f3204af7d5374f0daec2727c14607674dc9a9dd4
Author: ptupitsyn 
Date:   2015-10-06T13:01:23Z

wip

commit f495585f717c0f7eb338ae6020d9c079e0afb439
Author: ptupitsyn 
Date:   2015-10-06T13:06:36Z

wip cleanup

commit 15324f7f86a5d56b3377a01784d38dec4140b415
Author: ptupitsyn 
Date:   2015-10-06T13:59:22Z

ReadTypedCollection wip

commit f6486af2411528bf23dc92f39179d963d4c464c4
Author: ptupitsyn 
Date:   2015-10-06T14:23:10Z

Collections done without delegate caching

commit 24868ebde65eae94d42ba4271c745f86f6e70002
Author: ptupitsyn 
Date:   2015-10-06T14:49:44Z

ReplaceTypes

commit 24d62dac1d4b8675861d03abd6be9c8c01dc7f63
Author: ptupitsyn 
Date:   2015-10-06T14:55:45Z

wip

commit 6d9e324218e07188ee7e04bd073629e4e6c65867
Author: ptupitsyn 
Date:   2015-10-06T16:00:37Z

Fix interop collection reads

commit 1a7b68213801dfda2700720f320208c19bfcffc5
Author: ptupitsyn 
Date:   2015-10-06T16:05:51Z

fixing tests

commit d7c7c6d8ddd1c24ff2874a16c4b91c011f9a5f9b
Author: ptupitsyn 
Date:   2015-10-06T16:42:33Z

wip

commit 6d36c1facfd8cea3aa94f117da50380e92626ae8
Author: ptupitsyn 
Date:   2015-10-06T16:44:10Z

wip

commit 1e292481158408d5c512ebb804c087f645755b31
Author: ptupitsyn 
Date:   2015-10-06T16:58:37Z

wip

commit f54256ebc2f4bcb8c9de1775dcd8d623fcb3c1b0
Author: ptupitsyn 
Date:   2015-10-06T17:08:31Z

comment out "trying to be nice" code




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: IGNITE-638: Implements cache distributed sema...

[vladisav]

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.concurrent.Semaphore.

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

$ git pull https://github.com/vladisav/ignite ignite-638

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

https://github.com/apache/ignite/pull/120.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 #120


commit e9567adec4057b0a0528735d4934440f4cd9fee3
Author: vladisav 
Date:   2015-09-25T09:14:18Z

Implements distributed semaphore ignite-638

This interface provides a rich API for working with distributed semaphore.
Distributed semaphore provides functionality similar to 
java.util.concurrent.Semaphore.

commit be332a82711ddd7e9088e00d7f26edd7de407a11
Author: Vladisav Jelisavcic 
Date:   2015-10-01T18:19:32Z

Fixes formatting issues;

commit 77f9deb7f79acb04b73994e83efd4539646073e6
Author: Vladisav Jelisavcic 
Date:   2015-10-03T10:44:02Z

Fixes formatting issues;




---
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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: IGNITE-638: Implements cache distributed sema...

[vladisav]

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 enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---