+1 Ignite.NET
2015-10-07 18:31 GMT+02:00 Konstantin Boudnik :
> Technically, "Apache Ignite" is the project trademark (which could be
> registered, if needed). Hence the longer name is probably more correct.
>
> Cos
>
> On Wed, Oct 07, 2015 at 07:31AM, Dmitriy Setrakyan wrote:
> > +1 for Ignite.N
Cos,
Initially IGFS was designed to support concurrent structural updates. E.g.,
creation of directories /A/C/D and /E/F/G can be performed concurrently.
Now we revealed that it might cause concurrency issues in case of
conflicting updates.
To fix this problem we now perform every update holding
Pavel Konstantinov created IGNITE-1634:
--
Summary: We should generate POJO classes in Client configuration
too
Key: IGNITE-1634
URL: https://issues.apache.org/jira/browse/IGNITE-1634
Project: Igni
GitHub user isapego opened a pull request:
https://github.com/apache/ignite/pull/142
IGNITE-1467: Standalone node application
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/isapego/ignite ignite-1467
Alternatively you can revie
Artem Shutak created IGNITE-1635:
Summary: Cache.invoke() can work wrong in a failover scenario
Key: IGNITE-1635
URL: https://issues.apache.org/jira/browse/IGNITE-1635
Project: Ignite
Issue T
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/143
IGNITE-1627 .Net: Consistent product naming.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-1627
Alternatively you c
Github user ptupitsyn closed the pull request at:
https://github.com/apache/ignite/pull/143
---
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 e
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/144
IGNITE-1627 .Net: Consistent product naming.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-1627
Alternatively you c
GitHub user ashutakGG opened a pull request:
https://github.com/apache/ignite/pull/145
IGNITE-1397 Load/consistency test framework
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ashutakGG/incubator-ignite ignite-1397-yards
Alte
Vladimir Ozerov created IGNITE-1636:
---
Summary: CPP: Add read/write methods with iterators for maps.
Key: IGNITE-1636
URL: https://issues.apache.org/jira/browse/IGNITE-1636
Project: Ignite
I
Vladimir Ozerov created IGNITE-1637:
---
Summary: IGFS: Consistent properties propagation.
Key: IGNITE-1637
URL: https://issues.apache.org/jira/browse/IGNITE-1637
Project: Ignite
Issue Type: T
Vladimir Ozerov created IGNITE-1638:
---
Summary: IGFS: Review IgfsImpl.checkConflictWithPrimary() method.
Key: IGNITE-1638
URL: https://issues.apache.org/jira/browse/IGNITE-1638
Project: Ignite
Vladimir Ozerov created IGNITE-1639:
---
Summary: IGFS: IgfsMetaManager() contains duplicated "delete"
method.
Key: IGNITE-1639
URL: https://issues.apache.org/jira/browse/IGNITE-1639
Project: Ignite
Vladimir Ozerov created IGNITE-1640:
---
Summary: CPP: Consistent product naming.
Key: IGNITE-1640
URL: https://issues.apache.org/jira/browse/IGNITE-1640
Project: Ignite
Issue Type: Task
Pavel Tupitsyn created IGNITE-1641:
---
Summary: .Net: Get rid of ContinuousQueryFilterHolder
Key: IGNITE-1641
URL: https://issues.apache.org/jira/browse/IGNITE-1641
Project: Ignite
Issue Typ
I released "ignite-1.4".
And also removed "1.5". Who created it? Why not rename "ignite-1.5"?
--Yakov
2015-10-07 19:28 GMT+03:00 Konstantin Boudnik :
> Techically it should be the RM. I am looking through the website and wiki
> and
> I can not find the description of the release procedure. Unle
On Thu, Oct 8, 2015 at 7:31 AM, Yakov Zhdanov wrote:
> I released "ignite-1.4".
>
> And also removed "1.5". Who created it? Why not rename "ignite-1.5"?
>
Yakov, there was discussion to remove "ignite" word from all the release
names in Jira and I think you agreed there. I also think it makes se
This is very easy.
--Yakov
2015-10-08 17:35 GMT+03:00 Dmitriy Setrakyan :
> On Thu, Oct 8, 2015 at 7:31 AM, Yakov Zhdanov wrote:
>
> > I released "ignite-1.4".
> >
> > And also removed "1.5". Who created it? Why not rename "ignite-1.5"?
> >
>
> Yakov, there was discussion to remove "ignite" wor
I renamed "ignite-1.5" and "ignite-1.6" to 1.5 and 1.6
--Yakov
2015-10-08 17:38 GMT+03:00 Yakov Zhdanov :
> This is very easy.
>
> --Yakov
>
> 2015-10-08 17:35 GMT+03:00 Dmitriy Setrakyan :
>
>> On Thu, Oct 8, 2015 at 7:31 AM, Yakov Zhdanov
>> wrote:
>>
>> > I released "ignite-1.4".
>> >
>> > A
Pavel Tupitsyn created IGNITE-1642:
---
Summary: .Net: Rename EventType members
Key: IGNITE-1642
URL: https://issues.apache.org/jira/browse/IGNITE-1642
Project: Ignite
Issue Type: Improvement
Thank you very much !
On October 8, 2015 7:45:39 AM PDT, Yakov Zhdanov wrote:
>I renamed "ignite-1.5" and "ignite-1.6" to 1.5 and 1.6
>
>--Yakov
>
>2015-10-08 17:38 GMT+03:00 Yakov Zhdanov :
>
>> This is very easy.
>>
>> --Yakov
>>
>> 2015-10-08 17:35 GMT+03:00 Dmitriy Setrakyan :
>>
>>> On Thu,
Vladimir Ozerov created IGNITE-1643:
---
Summary: Cleanup platform communication protocol.
Key: IGNITE-1643
URL: https://issues.apache.org/jira/browse/IGNITE-1643
Project: Ignite
Issue Type: T
Igniters,
There are cases when Ignite cluster nodes work on different environments
and JDKs (versions and/or vendors). GridDiscoveryManager class contains
check that all nodes in topology ran under JDKs with the same major Java
version and throws exception if check failed. I want to replace this o
On Thu, Oct 8, 2015 at 9:52 AM, Andrey Gura wrote:
> Igniters,
>
> There are cases when Ignite cluster nodes work on different environments
> and JDKs (versions and/or vendors). GridDiscoveryManager class contains
> check that all nodes in topology ran under JDKs with the same major Java
> versio
Why are we sticked to version? If both JVM has the same major version, but
different vendors, it might be even more important concern, than different
major versions of the same vendor.
On Thu, Oct 8, 2015 at 8:48 PM, Dmitriy Setrakyan
wrote:
> On Thu, Oct 8, 2015 at 9:52 AM, Andrey Gura wrote:
On Thu, Oct 8, 2015 at 11:31 AM, Vladimir Ozerov
wrote:
> Why are we sticked to version? If both JVM has the same major version, but
> different vendors, it might be even more important concern, than different
> major versions of the same vendor.
>
I don't think even this should matter. Java has
This conversation reminds me of the situation with Spark and akka that I just
ran into. Or rather with Akka and the way they designed the remote execution.
The situation is actually _completely_ ridiculous. I stood up a small Spark
cluster and then tried to submit a job into it, which had some
Spar
On Thu, Oct 8, 2015 at 12:28 PM, Konstantin Boudnik wrote:
> This conversation reminds me of the situation with Spark and akka that I
> just
> ran into. Or rather with Akka and the way they designed the remote
> execution.
> The situation is actually _completely_ ridiculous. I stood up a small Sp
On Thu, Oct 08, 2015 at 12:46PM, Dmitriy Setrakyan wrote:
> On Thu, Oct 8, 2015 at 12:28 PM, Konstantin Boudnik wrote:
>
> > This conversation reminds me of the situation with Spark and akka that I
> > just
> > ran into. Or rather with Akka and the way they designed the remote
> > execution.
> >
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 implementat
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 implementat
On Thu, Oct 8, 2015 at 1:56 PM, Konstantin Boudnik wrote:
> On Thu, Oct 08, 2015 at 12:46PM, Dmitriy Setrakyan wrote:
> > On Thu, Oct 8, 2015 at 12:28 PM, Konstantin Boudnik
> wrote:
> >
> > > This conversation reminds me of the situation with Spark and akka that
> I
> > > just
> > > ran into. O
Vladimir,
different JDK versions in topology can lead to problems with P2P deploy for
example. Nodes under different vendors' JDK should work correctly in case
of properly defined SUID.
On Thu, Oct 8, 2015 at 9:31 PM, Vladimir Ozerov
wrote:
> Why are we sticked to version? If both JVM has the s
33 matches
Mail list logo
