[jira] [Created] (IGNITE-1644) .Net: DateTime.Kind is lost during serialization

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1644:
---

 Summary: .Net: DateTime.Kind is lost during serialization
 Key: IGNITE-1644
 URL: https://issues.apache.org/jira/browse/IGNITE-1644
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


For example, we write and then read from the same stream (locally):

{code}
var dt = DateTime.Now;
writer.WriteObject(dt);

var dt2 = reader.ReadObject();
Assert.AreEqual(dt, dt2);  // fail
{code}

This happens because we always write DateTime as UTC and lose DateTime.Kind, so 
on deserialization we do not know whether ToLocal should be called.

Possible solutions:
* write .Net DateTime in a different format, not compatible with Java (breaks 
queries)
* 




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Using IgniteContext in... well, Java context

[Andrey Gura]

Cos,

Ignite provides Java friendly RDD API. See JavaIgniteContext and
JavaIgniteRDD classes.

On Fri, Oct 9, 2015 at 12:26 AM, Konstantin Boudnik  wrote:

> Guys,
>
> I've tried to play a little bit with IgniteContext and the whole IgniteRDD
> stuff from the perspective of not touching Scala ever again. And here's
> what I
> have found: IgniteContext isn't usable from Java (or Groovy for that
> matter).
> And it isn't an attempt to critique Ignite's RDD implementation, because we
> have to follow the design patterns setup by the 3rd party platform, Spark
> in
> this case.
>
> If I want to submit a Java-based job into spark cluster I need to do
> something
> like this:
>
> import org.apache.ignite.spark.*
> import org.apache.spark.SparkConf
> import org.apache.spark.api.java.JavaSparkContext
>
> SparkConf sparkConf = new SparkConf().setAppName('SharedCache')
> sparkConf.setMaster('spark://master.spark.mydomain.com:7077')
> JavaSparkContext jsc = new JavaSparkContext(sparkConf)
>
> so far so good. Now, if I want to use Ignite in it, I should be doing
>
> def ic = new IgniteContext(jsc, "spark-ignite-config.xml")
>
> and that's where I hit the wall, because JavaSparkContext isn't a subtype
> of
> SparkContext in Spark world, and I can not cast one to another.
>
> Well then, perhaps I can use SparkContext and hope for the best? Turns out
> I
> can not, because the use of the SparkContext gets me into the swamp of
> Scala
> type-system, with long-mnemonic names like Function1 and Tuple2 (I reckon
> the
> day will come soon, when they will have Function27 and so on). This leads
> me
> to believe the current implementation of IgniteRDD is only good to be used
> from Scala, unless I am completely wrong and don't know what I am talking
> about. Which might be quite possible, of course.
>
> My question is very simple: is there a way to use IgniteRDD from
> Java-language
> family, e.g. Java and Groovy, or there has to be JavaIgniteRDD
> implementation
> of it much like the state of things is in the Spark itself?
>
> Thanks for any feedback
> --
>   Cos
>
>


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

Re: New cub in the den

[Dmitriy Setrakyan]

Hi Shashank,

Welcome to the Ignite community!

Please properly subscribe to the dev list by sending email to
dev-subscr...@ignite.apache.org and following instructions in the reply.

For resources and information on how to get involved, you can use the
community section of the website:

https://ignite.apache.org/community/resources.html
https://ignite.apache.org/community/contribute.html

You should also get familiar with Ignite development process outlined on
our Wiki:
https://cwiki.apache.org/confluence/display/IGNITE/Development+Process

Also, pick any of the tickets in Ignite Jira and let the community know
that you wish to start working on it. Some of the tickets you can start on
are listed here:

https://ignite.apache.org/community/contribute.html#pick-ticket

If you have any questions, send them here.

D.


On Fri, Oct 9, 2015 at 12:22 PM, Shashank Gupta 
wrote:

> Hello everyone,
>
> I am very keen and looking forward to get involved into development
> process at Apache ignite.
>
> Thanks & Regards,
> Shashank Gupta
> ProstGrad Student (BigData Science)
> Queen Mary University of London
> London.
>
>
> Sent from my iPhone

Re: .Net: separate methods for async operations.

[Pavel Tupitsyn]

Hi Dmitry,

> First of all, from my experience, the async APIs are used a lot less than sync
ones

This may be true, especially if the API is clunky.
But .NET has async/await functionality which makes async code a lot cleaner
and easier.
Good async/await support is very important, because it does not block
current thread, which in turn is important for high load applications.
All modern .NET APIs are async.


> Secondly, the scope of this change would be huge.

I don't think so. There are around 40 methods with async support in current
Ignite.NET.
Adding their async counterparts will take a couple of hours at most.
And it will simplify interop code somewhat because GetFuture goes away.


> And lastly, I am against having .NET APIs different from Java APIs.

Functionally they will be the same. But we should not try to bring Java
semantics to .NET.
Async methods in .NET are "T DoSomething()" + "Task DoSomethingAsync()"
and we should follow this pattern so our API looks familiar to .NET
community.


> // Line #2
> cache.Future().Get();

It is cache.GetFuture(). Pay attention to "X". This is very important:
user has to specify correct return type according to return type of
operation on "Line 1".
Very annoying and error prone. There is even a style-checker warning about
such things.


> 2 lines of code instead of one is not a big deal in my view.

It is 2 times too much, sometimes even more. Imagine a situation where you
need to perform multiple async operations:

cache.Get(1);
var res = await cache.GetFuture().ToTask();

compute.Call(new MyCallable(res))
var res2 = await compute.GetFuture().ToTask()


And with proper async API it can even be a one-liner.
var res2 = await compute.CallAsync(new MyCallable(await cache.GetAsync(1)));


API is the first thing a programmer sees in the new product. Let's do it
right.

Thanks,

On Fri, Oct 9, 2015 at 7:17 PM, Dmitriy Setrakyan 
wrote:

> I don't think I like the proposed change.
>
> First of all, from my experience, the async APIs are used a lot less than
> sync ones, so having 2 lines of code for async calls is not a big deal in
> my view.
>
> Secondly, the scope of this change would be huge. We would have to double
> our Compute, Cache, Services, and many other APIs. Seems to me like a huge
> amount of effort for a very questionable benefit, if any at all. One can
> argue, for example, that so many duplicate sync/async methods on all the
> APIs is more confusing, not less.
>
> And lastly, I am against having .NET APIs different from Java APIs. We
> should have API parity as much as possible between all the platforms, and
> especially the .NET one, where we provide so many features.
>
> On Fri, Oct 9, 2015 at 7:05 AM, Pavel Tupitsyn 
> wrote:
>
> > As a .Net dev, I support this change very much.
> >
> > Current design with 2 method calls is not easy to use, is error prone,
> and
> > is not familiar to .Net crowd:
> >
> > var cache = ignite.GetCache().WithAsync();
> > var value = cache.Get(1);   // Is it sync or async? Can't tell from code.
>
> In async mode this always returns 0.
> >
>
> Yes, you are right. But then again, async documentation clearly says that
> you should get a future to get the actual asynchronous result.
>
> The proper code here is:
> ---
> var cache = ignite.GetCache().WithAsync();
>
> // Line #1
> cache.Get(1);
>
> // Line #2
> cache.Future().Get();
> ---
>
> 2 lines of code instead of one is not a big deal in my view.
>
>
> > var future = cache.GetFuture();   // User has to specify right
> generic
> > argument here. Not convenient, error prone, violates design guidelines
> > var actualValue = await future.ToTask();
> >
> >
> > As opposed to:
> > var value = await cache.GetAsync(1).ToTask();
>
>
>
> >
> > Which is one line, obviously async, with proper generic inference.
> >
> >
> >
> > On Fri, Oct 9, 2015 at 4:47 PM, Vladimir Ozerov 
> > wrote:
> >
> > > Igniters,
> > >
> > > Some time ago we decided to merge sync and async methods. E.g. instead
> of
> > > ...
> > >
> > > interface Cache {
> > > V get(K key);
> > > Future getAsync(K key);
> > > }
> > >
> > > ... we now have:
> > >
> > > interface Cache extends AsyncSupport {
> > > V get(K key);
> > > Cache withAsync();
> > >
> > > Future lastFuture(); // From AsyncSupport, returns future for the
> > last
> > > operation.
> > > }
> > >
> > > This approach is questionable. Less methods is good, and all methods go
> > > through JCache API. But async mode became more complex and less usable.
> > > This is especially obvious in Java 8 with its lambdas and
> > > CompletableFuture.
> > >
> > > In .Net we blindly applied this approach as well. But in this world
> > > AsyncSupport gives even less advantages than in Java:
> > > 1) There is no JCache spec here;
> > > 2) Core .Net API very often use paired sync and async operations in the
> > > same class near each 

Re: .Net: separate methods for async operations.

[Dmitriy Setrakyan]

Pavel, can you explain how .NET async semantics are different from Java?

On Fri, Oct 9, 2015 at 1:46 PM, Pavel Tupitsyn 
wrote:

> Hi Dmitry,
>
> > First of all, from my experience, the async APIs are used a lot less
> than sync
> ones
>
> This may be true, especially if the API is clunky.
> But .NET has async/await functionality which makes async code a lot cleaner
> and easier.
> Good async/await support is very important, because it does not block
> current thread, which in turn is important for high load applications.
> All modern .NET APIs are async.
>
>
> > Secondly, the scope of this change would be huge.
>
> I don't think so. There are around 40 methods with async support in current
> Ignite.NET.
> Adding their async counterparts will take a couple of hours at most.
> And it will simplify interop code somewhat because GetFuture goes away.
>
>
> > And lastly, I am against having .NET APIs different from Java APIs.
>
> Functionally they will be the same. But we should not try to bring Java
> semantics to .NET.
> Async methods in .NET are "T DoSomething()" + "Task DoSomethingAsync()"
> and we should follow this pattern so our API looks familiar to .NET
> community.
>
>
> > // Line #2
> > cache.Future().Get();
>
> It is cache.GetFuture(). Pay attention to "X". This is very important:
> user has to specify correct return type according to return type of
> operation on "Line 1".
> Very annoying and error prone. There is even a style-checker warning about
> such things.
>
>
> > 2 lines of code instead of one is not a big deal in my view.
>
> It is 2 times too much, sometimes even more. Imagine a situation where you
> need to perform multiple async operations:
>
> cache.Get(1);
> var res = await cache.GetFuture().ToTask();
>
> compute.Call(new MyCallable(res))
> var res2 = await compute.GetFuture().ToTask()
>
>
> And with proper async API it can even be a one-liner.
> var res2 = await compute.CallAsync(new MyCallable(await
> cache.GetAsync(1)));
>
>
> API is the first thing a programmer sees in the new product. Let's do it
> right.
>
> Thanks,
>
> On Fri, Oct 9, 2015 at 7:17 PM, Dmitriy Setrakyan 
> wrote:
>
> > I don't think I like the proposed change.
> >
> > First of all, from my experience, the async APIs are used a lot less than
> > sync ones, so having 2 lines of code for async calls is not a big deal in
> > my view.
> >
> > Secondly, the scope of this change would be huge. We would have to double
> > our Compute, Cache, Services, and many other APIs. Seems to me like a
> huge
> > amount of effort for a very questionable benefit, if any at all. One can
> > argue, for example, that so many duplicate sync/async methods on all the
> > APIs is more confusing, not less.
> >
> > And lastly, I am against having .NET APIs different from Java APIs. We
> > should have API parity as much as possible between all the platforms, and
> > especially the .NET one, where we provide so many features.
> >
> > On Fri, Oct 9, 2015 at 7:05 AM, Pavel Tupitsyn 
> > wrote:
> >
> > > As a .Net dev, I support this change very much.
> > >
> > > Current design with 2 method calls is not easy to use, is error prone,
> > and
> > > is not familiar to .Net crowd:
> > >
> > > var cache = ignite.GetCache().WithAsync();
> > > var value = cache.Get(1);   // Is it sync or async? Can't tell from
> code.
> >
> > In async mode this always returns 0.
> > >
> >
> > Yes, you are right. But then again, async documentation clearly says that
> > you should get a future to get the actual asynchronous result.
> >
> > The proper code here is:
> > ---
> > var cache = ignite.GetCache().WithAsync();
> >
> > // Line #1
> > cache.Get(1);
> >
> > // Line #2
> > cache.Future().Get();
> > ---
> >
> > 2 lines of code instead of one is not a big deal in my view.
> >
> >
> > > var future = cache.GetFuture();   // User has to specify right
> > generic
> > > argument here. Not convenient, error prone, violates design guidelines
> > > var actualValue = await future.ToTask();
> > >
> > >
> > > As opposed to:
> > > var value = await cache.GetAsync(1).ToTask();
> >
> >
> >
> > >
> > > Which is one line, obviously async, with proper generic inference.
> > >
> > >
> > >
> > > On Fri, Oct 9, 2015 at 4:47 PM, Vladimir Ozerov 
> > > wrote:
> > >
> > > > Igniters,
> > > >
> > > > Some time ago we decided to merge sync and async methods. E.g.
> instead
> > of
> > > > ...
> > > >
> > > > interface Cache {
> > > > V get(K key);
> > > > Future getAsync(K key);
> > > > }
> > > >
> > > > ... we now have:
> > > >
> > > > interface Cache extends AsyncSupport {
> > > > V get(K key);
> > > > Cache withAsync();
> > > >
> > > > Future lastFuture(); // From AsyncSupport, returns future for the
> > > last
> > > > operation.
> > > > }
> > > >
> > > > This approach is questionable. Less methods is good, and all methods
> go
> > 

Getting rid of md5 and sha1

[Konstantin Boudnik]

Guys,

We had to get rid of md5 sum long time ago, but it seems that sha1 is hitting
the wall as well. Here's the good description of the problem:
https://sites.google.com/site/itstheshappening/

I'd suggest to scrape both of them in the next release. Any objections?

Cos

Re: Which thread is used to run IgniteFuture continuations?

[Dmitriy Setrakyan]

I will add +1 on this, which together with Andrey's +10, brings the total
to +11 :)

D.

On Fri, Oct 9, 2015 at 7:48 AM, Andrey Kornev 
wrote:

> Excellent idea! +10
> PS. Got burnt by this a few times already
> _
> From: Vladimir Ozerov 
> Sent: Friday, October 9, 2015 4:22 PM
> Subject: Which thread is used to run IgniteFuture continuations?
> To:  
>
>
>Igniters,
>
>  We are missing an ability to specify which thread should run continuation
>  routine when future is completed.
>
>  Currently we either run routine in the callee thread or in completion
>  thread (usually system pool thread). It means user cannot have any
> blocking
>  or cache operations inside the continuation. The code below could surprise
>  user with either a deadlock or system pool starvation:
>
>  final CountDownLatch latch = new CountDownLatch();
>
>  Cache cache = ignite.cache().withAsync();
>  cache.invoke(...);
>
>  cache.future().listen(() => {
>  latch.await();
>  /** Do something useful. */
>  });
>
>  /** Do something else. */
>  latch.countDown();
>
>  Java 8 and Hazelcast already support custom thread pools for
> continuations.
>  E.g.:
>  Hazelcast.CompletableFutureTask.andThen(ExecutionCallback callback,
>  Executor executor);
>
>  Looks like we should allow users to specify optional thread pool in
> futures
>  likewise.
>
>  Thoughts?
>
>  Vladimir.
>

Re: .Net: separate methods for async operations.

[Dmitriy Setrakyan]

I don't think I like the proposed change.

First of all, from my experience, the async APIs are used a lot less than
sync ones, so having 2 lines of code for async calls is not a big deal in
my view.

Secondly, the scope of this change would be huge. We would have to double
our Compute, Cache, Services, and many other APIs. Seems to me like a huge
amount of effort for a very questionable benefit, if any at all. One can
argue, for example, that so many duplicate sync/async methods on all the
APIs is more confusing, not less.

And lastly, I am against having .NET APIs different from Java APIs. We
should have API parity as much as possible between all the platforms, and
especially the .NET one, where we provide so many features.

On Fri, Oct 9, 2015 at 7:05 AM, Pavel Tupitsyn 
wrote:

> As a .Net dev, I support this change very much.
>
> Current design with 2 method calls is not easy to use, is error prone, and
> is not familiar to .Net crowd:
>
> var cache = ignite.GetCache().WithAsync();
> var value = cache.Get(1);   // Is it sync or async? Can't tell from code.

In async mode this always returns 0.
>

Yes, you are right. But then again, async documentation clearly says that
you should get a future to get the actual asynchronous result.

The proper code here is:
---
var cache = ignite.GetCache().WithAsync();

// Line #1
cache.Get(1);

// Line #2
cache.Future().Get();
---

2 lines of code instead of one is not a big deal in my view.


> var future = cache.GetFuture();   // User has to specify right generic
> argument here. Not convenient, error prone, violates design guidelines
> var actualValue = await future.ToTask();
>
>
> As opposed to:
> var value = await cache.GetAsync(1).ToTask();



>
> Which is one line, obviously async, with proper generic inference.
>
>
>
> On Fri, Oct 9, 2015 at 4:47 PM, Vladimir Ozerov 
> wrote:
>
> > Igniters,
> >
> > Some time ago we decided to merge sync and async methods. E.g. instead of
> > ...
> >
> > interface Cache {
> > V get(K key);
> > Future getAsync(K key);
> > }
> >
> > ... we now have:
> >
> > interface Cache extends AsyncSupport {
> > V get(K key);
> > Cache withAsync();
> >
> > Future lastFuture(); // From AsyncSupport, returns future for the
> last
> > operation.
> > }
> >
> > This approach is questionable. Less methods is good, and all methods go
> > through JCache API. But async mode became more complex and less usable.
> > This is especially obvious in Java 8 with its lambdas and
> > CompletableFuture.
> >
> > In .Net we blindly applied this approach as well. But in this world
> > AsyncSupport gives even less advantages than in Java:
> > 1) There is no JCache spec here;
> > 2) Core .Net API very often use paired sync and async operations in the
> > same class near each other - DoMethod(), DoMethodAsync() - and this is
> what
> > users normally expect from async-enabled classes.
> > 3) [AsyncSupported] attribute is not highlighted in Visual Studio. The
> only
> > way to understand that method supports async mode is to install ReSharper
> > or to look into source code.
> > 4) .Net has native continuations support with async/await keywords. Our
> API
> > doesn't support it well.
> >
> > Having said that I want to return paired "async" operations to .Net API:
> > interface ICache {
> > V Get(K key);
> > IFuture GetAsync(K key);
> > }
> >
> > It will add 25 new methods to ICache interface and remove 2. But API will
> > become much more friendly and natural for .Net users.
> >
> > Any thoughts/objections?
> >
> > Vladimir.
> >
>
>
>
> --
> --
> Pavel Tupitsyn
> GridGain Systems, Inc.
> www.gridgain.com
>

[jira] [Created] (IGNITE-1645) .Net: Throw exception on null flag in PortableReader when reading non-nullable value types

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1645:
---

 Summary: .Net: Throw exception on null flag in PortableReader when 
reading non-nullable value types
 Key: IGNITE-1645
 URL: https://issues.apache.org/jira/browse/IGNITE-1645
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: 1.5
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.5


Currently we always return default(T) when deserializing null value. So for 
value types there is no way  for the user to discern a missing cache key from a 
cache key with default value.

* throw exceptions when there is Null in stream and we are trying to read a 
value type
* update Cache API with Try* methods



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1646) .Net: IgniteGuid must be serializable and portable.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1646:
---

 Summary: .Net: IgniteGuid must be serializable and portable.
 Key: IGNITE-1646
 URL: https://issues.apache.org/jira/browse/IGNITE-1646
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
Priority: Blocker
 Fix For: 1.5


1) User must be able to pass IgniteGuid over a wire using serializable 
semantics when serialized manually by user.
2) On the other hand, it must be portable for correct passing between Java and 
.Net.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (IGNITE-1648) ignitevisorcmd: key "-t" for command "log" works incorrect

[Vasilisa Sidorova (JIRA)]

Vasilisa  Sidorova created IGNITE-1648:
--

 Summary: ignitevisorcmd: key "-t" for command "log" works incorrect
 Key: IGNITE-1648
 URL: https://issues.apache.org/jira/browse/IGNITE-1648
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 1.5
 Environment: Ubuntu 14.04, Apache-Ignite-1.5.0 build #29
Reporter: Vasilisa  Sidorova
Priority: Minor
 Fix For: 1.5


-
DESCRIPTION
-
The key '-t' works incorrect when it's time to print querying events into log - 
it's print topology snapshot as many times as events are in query. Log became 
difficult to read  
-
STEPS FOR REPRODUCE
-
# Run two nodes in the grid
# Run  ignitevisorcmd.sh
# Connect visor to the grid (open)
# Run logging by command, for example:
{noformat}
log -l -p=30 -t=120 -f=../work/visor/test_log
{noformat}
# Generate several grid-wide events by, for example, start-stop one more node
-
ACTUAL RESULT
-
There is events query in the log every 30 seconds and topology snapshot  every 
2 minutes and every 30 seconds before events query logging -  as many times as 
events are in query. Look at the part of log:
{noformat}
10/09/15, 16:08:27 | Log started.
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:57 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:37 |  => NODE_JOINED: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:38 |  => NODE_LEFT: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:42 |  => NODE_JOINED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:44 |  => NODE_FAILED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:46 |  => NODE_JOINED: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:50 |  => NODE_LEFT: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:54 |  => NODE_JOINED: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:09:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:08:59 |  => NODE_LEFT: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:05 |  => NODE_JOINED: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:09 |  => NODE_LEFT: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_JOINED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_FAILED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:17 |  => NODE_JOINED: id8=e15a193f, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:10:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:12:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:14:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:15:27 | Log stopped.
{noformat}
-
EXPECTED RESULT
-
There is events query in the log every 30 seconds and topology snapshot  every 
2 minutes. Something like this:
{noformat}
10/09/15, 16:08:27 | Log started.
10/09/15, 16:08:37 |  => NODE_JOINED: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:38 |  => NODE_LEFT: id8=85d6f860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:42 |  => NODE_JOINED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:44 |  => NODE_FAILED: id8=b732d4c2, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:46 |  => NODE_JOINED: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:50 |  => NODE_LEFT: id8=52265274, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:54 |  => NODE_JOINED: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:08:59 |  => NODE_LEFT: id8=12b6eaf9, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:05 |  => NODE_JOINED: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:09 |  => NODE_LEFT: id8=1666d860, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_JOINED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:13 |  => NODE_FAILED: id8=ef2c76f7, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:09:17 |  => NODE_JOINED: id8=e15a193f, ip=0:0:0:0:0:0:0:1%1
10/09/15, 16:10:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:12:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:14:27 | H/N/C|1   |2   |8   |^...|
10/09/15, 16:15:27 

.Net: separate methods for async operations.

[Vladimir Ozerov]

Igniters,

Some time ago we decided to merge sync and async methods. E.g. instead of
...

interface Cache {
V get(K key);
Future getAsync(K key);
}

... we now have:

interface Cache extends AsyncSupport {
V get(K key);
Cache withAsync();

Future lastFuture(); // From AsyncSupport, returns future for the last
operation.
}

This approach is questionable. Less methods is good, and all methods go
through JCache API. But async mode became more complex and less usable.
This is especially obvious in Java 8 with its lambdas and CompletableFuture.

In .Net we blindly applied this approach as well. But in this world
AsyncSupport gives even less advantages than in Java:
1) There is no JCache spec here;
2) Core .Net API very often use paired sync and async operations in the
same class near each other - DoMethod(), DoMethodAsync() - and this is what
users normally expect from async-enabled classes.
3) [AsyncSupported] attribute is not highlighted in Visual Studio. The only
way to understand that method supports async mode is to install ReSharper
or to look into source code.
4) .Net has native continuations support with async/await keywords. Our API
doesn't support it well.

Having said that I want to return paired "async" operations to .Net API:
interface ICache {
V Get(K key);
IFuture GetAsync(K key);
}

It will add 25 new methods to ICache interface and remove 2. But API will
become much more friendly and natural for .Net users.

Any thoughts/objections?

Vladimir.

New cub in the den

[Shashank Gupta]

Hello everyone,

I am very keen and looking forward to get involved into development process at 
Apache ignite.

Thanks & Regards,
Shashank Gupta
ProstGrad Student (BigData Science)
Queen Mary University of London 
London.


Sent from my iPhone

[GitHub] ignite pull request: IGNITE-1645 .Net: Throw exception on null fla...

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1645 .Net: Throw exception on null flag in PortableReader when 
reading non-nullable value types



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

$ git pull https://github.com/ptupitsyn/ignite ignite-1645

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

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


commit 60d70e4207733dba5c89f619d5b0f6408c1752ce
Author: ptupitsyn 
Date:   2015-10-09T11:46:10Z

Throw in reader

commit 00a16a2c34958cb38ea39d20e1a2f586e723ac06
Author: ptupitsyn 
Date:   2015-10-09T11:47:18Z

wip

commit 293ec0820c97c4cc176fc214938e8f2dec99d80c
Author: ptupitsyn 
Date:   2015-10-09T11:48:50Z

Merge remote-tracking branch 'remotes/upstream/ignite-1282' into ignite-1645

commit 79228771e5823daa81706c5bbf4351ae5ff3
Author: ptupitsyn 
Date:   2015-10-09T12:35:09Z

wip

commit ac9060827eb0774d7c0370554a578d98f5fb6c78
Author: ptupitsyn 
Date:   2015-10-09T12:35:33Z

wip

commit 06c6e5ca0f2de80e03d093165a9ea3eb2b1b0a06
Author: ptupitsyn 
Date:   2015-10-09T12:57:27Z

wip

commit aa6e43a7617956c5a81eeb3afd414ca3448e1b56
Author: ptupitsyn 
Date:   2015-10-09T14:13:53Z

wip

commit 3edb9b9f7d06182feebbb22079f2eea2ed0675fa
Author: ptupitsyn 
Date:   2015-10-09T14:32:32Z

iface done

commit 0ceea4f53a5f4fc31e201c011e52cec8e22339d8
Author: ptupitsyn 
Date:   2015-10-09T14:57:49Z

wip

commit 20c7b66538bd81852a26018cabb7188f806e2ec4
Author: ptupitsyn 
Date:   2015-10-09T14:57:54Z

wip

commit 6167bec2a1a60f65731d07fe2f17fcf06272b25c
Author: ptupitsyn 
Date:   2015-10-09T14:59:42Z

wip

commit 8ae9b9701e308afc4ccb09839c691b2e305bc5e4
Author: ptupitsyn 
Date:   2015-10-09T14:59:47Z

wip

commit 777456ede1a9031dc9feb6a524bf6b3e1431d739
Author: ptupitsyn 
Date:   2015-10-09T15:01:33Z

fixing tetst

commit 4b830771e8683469a342dbc232fd941020c0c660
Author: ptupitsyn 
Date:   2015-10-09T15:12:55Z

wip




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

Re: Which thread is used to run IgniteFuture continuations?

[Andrey Kornev]

Excellent idea! +10
PS. Got burnt by this a few times already
_
From: Vladimir Ozerov 
Sent: Friday, October 9, 2015 4:22 PM
Subject: Which thread is used to run IgniteFuture continuations?
To:  


   Igniters,   

 We are missing an ability to specify which thread should run continuation   
 routine when future is completed.   

 Currently we either run routine in the callee thread or in completion   
 thread (usually system pool thread). It means user cannot have any blocking   
 or cache operations inside the continuation. The code below could surprise   
 user with either a deadlock or system pool starvation:   

 final CountDownLatch latch = new CountDownLatch();   

 Cache cache = ignite.cache().withAsync();   
 cache.invoke(...);   

 cache.future().listen(() => {   
     latch.await();   
     /** Do something useful. */   
 });   

 /** Do something else. */   
 latch.countDown();   

 Java 8 and Hazelcast already support custom thread pools for continuations.   
 E.g.:   
 Hazelcast.CompletableFutureTask.andThen(ExecutionCallback callback,   
 Executor executor);   

 Looks like we should allow users to specify optional thread pool in futures   
 likewise.   

 Thoughts?   

 Vladimir.