Pavel Konstantinov created IGNITE-1505:
--
Summary: Error on stopping cache in visorcmd
Key: IGNITE-1505
URL: https://issues.apache.org/jira/browse/IGNITE-1505
Project: Ignite
Issue Type:
Pavel Konstantinov created IGNITE-1504:
--
Summary: Add cache name to the warning
Key: IGNITE-1504
URL: https://issues.apache.org/jira/browse/IGNITE-1504
Project: Ignite
Issue Type: Task
Pavel Konstantinov created IGNITE-1503:
--
Summary: Do not ask user to provide node ID8 for cache details
Key: IGNITE-1503
URL: https://issues.apache.org/jira/browse/IGNITE-1503
Project: Ignite
Yakov,
The approach with collecting discovery data on NodeAddFinished message does
not work because this messages get relayed to clients before the message
passes the whole ring. If we make it to pass the ring and relay it to
clients on the second round, we get the same race as I was fixing.
I th
On Thu, Sep 17, 2015 at 7:06 PM, Sergi Vladykin
wrote:
> Looks a bit strange for me if most of development and testing happens on
> Oracle JDK but
> we distribute with OpenJDK. I believe if something works under OpenJDK most
> probably
> it will under Oracle JDK as well, but not the reverse.
>
I
If something like compareAndSetAndThenAgainGet will not pop up on public
Java API, I have no objections :)
Sergi
2015-09-17 21:42 GMT+03:00 Vladimir Ozerov :
> Lets put getAndUpdate() aside for now, because is not what the question
> about. Of course we can add this operation to Java, no problem
Lets put getAndUpdate() aside for now, because is not what the question
about. Of course we can add this operation to Java, no problems. But we are
talking about a single CAS, not spin-loop.
The problem is that for .Net/CPP guy CAS on long is not "bool CAS(old,
new)". For him CAS is "long CAS(old,
2015-09-17 10:55 GMT-07:00 Vladimir Ozerov :
This is not something weird, but rather how things work everywhere except
> of Java. getAndUpdate() is not what we need, because it is a CAS loop, not
> CAS.
>
This is an implementation detail. For a distributed data structure it will
never be a CAS lo
Nikita Ivanov created IGNITE-1502:
-
Summary: Move to HTTPS.
Key: IGNITE-1502
URL: https://issues.apache.org/jira/browse/IGNITE-1502
Project: Ignite
Issue Type: New Feature
Component
This is not something weird, but rather how things work everywhere except
of Java. getAndUpdate() is not what we need, because it is a CAS loop, not
CAS.
Since we are working on integration with other platforms where returning
value on failed CAS is what developer expect from API by default, we nee
GitHub user agura opened a pull request:
https://github.com/apache/ignite/pull/99
ignite-1135 GridPartitionedGetFuture assertion error
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/agura/incubator-ignite ignite-1135
Alternativ
Git hub:https://github.com/chandresh-pancholi/ignite
ERROR][main][root] Test has been timed out and will be interrupted (threads
dump will be taken before interruption) [test=testStormStreamer,
timeout=30]
[17:50:52,004][WARN ][main][StormIgniteStreamerSelfTest] Dumping debug info
for node [id=
Looks a bit strange for me if most of development and testing happens on
Oracle JDK but
we distribute with OpenJDK. I believe if something works under OpenJDK most
probably
it will under Oracle JDK as well, but not the reverse.
Sergi
2015-09-17 17:13 GMT+03:00 Dmitriy Setrakyan :
> On Thu, Sep 1
Instead of inventing something weird looking I'd better take a closer look
at
what happens in Java 8 and 9.
For example in Java 8 there is already a method AtomicLong.getAndUpdate[1]
(paired
with updateAndGet of course) which provides the needed semantics.
We can implement it reusing known current
Alex, I think it makes sense to continue investigating this. We can discuss
whether we include or skip the fix once fix is ready.
As far as other tickets:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%20ignite-1.4%20AND%20status%20!%3D%20closed%20ORDER%
GitHub user iveselovskiy opened a pull request:
https://github.com/apache/ignite/pull/98
Ignite 586
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/iveselovskiy/ignite ignite-586
Alternatively you can review and apply these chan
On Thu, Sep 17, 2015 at 4:19 PM, Pavel Tupitsyn
wrote:
> Hi,
>
> Looking at other methods in IgniteAtomicLong, it would be
> compareAndSetAndGet. Ugly, but consistent.
>
Agree.
>
> On Thu, Sep 17, 2015 at 3:36 PM, Vladimir Ozerov
> wrote:
>
> > Igniters,
> >
> > As we know Java implementation
In this case, should we just simply update the documentation to reflect the
reality?
On Thu, Sep 17, 2015 at 3:30 PM, Andrey Gura wrote:
> There is the same comment for the following interfaces:
>
> - IgniteAtomicReference
> - IgniteAtomicSequence
> - IgniteAtomicStamped
>
> On Thu, Sep 17, 2015
On Thu, Sep 17, 2015 at 1:39 PM, Sergi Vladykin
wrote:
> Probably it means that we should use openjdk by default for development and
> testing as well?
>
We can, but I am not sure why we have to. Can you explain?
>
> Sergi
>
> 2015-09-17 7:39 GMT+03:00 Dmitriy Setrakyan :
>
> > Ignters,
> >
>
Vladimir Ozerov created IGNITE-1501:
---
Summary: Add compare-and-set operation which returns currnet value
in case of failure.
Key: IGNITE-1501
URL: https://issues.apache.org/jira/browse/IGNITE-1501
P
Vladimir Ozerov created IGNITE-1500:
---
Summary: Invalid docs in distributed data structures classes.
Key: IGNITE-1500
URL: https://issues.apache.org/jira/browse/IGNITE-1500
Project: Ignite
I
Github user ptupitsyn closed the pull request at:
https://github.com/apache/ignite/pull/97
---
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 ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/97
IGNITE-1499 Platform .Net: fix naming and use properties where appropriate
in the API
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsy
Hi,
Looking at other methods in IgniteAtomicLong, it would be
compareAndSetAndGet. Ugly, but consistent.
On Thu, Sep 17, 2015 at 3:36 PM, Vladimir Ozerov
wrote:
> Igniters,
>
> As we know Java implementation of atomics are rather limited because it
> cannot return current value in case of faile
Pavel Tupitsyn created IGNITE-1499:
---
Summary: Platform .Net: fix naming and use properties where
appropriate in the API
Key: IGNITE-1499
URL: https://issues.apache.org/jira/browse/IGNITE-1499
Proje
Igniters,
As we know Java implementation of atomics are rather limited because it
cannot return current value in case of failed CAS. Other modern platforms
like .Net, WinAPI and GCC have this feature.
We can easily implement this method because we have old value in hands
during distributed CAS. B
There is the same comment for the following interfaces:
- IgniteAtomicReference
- IgniteAtomicSequence
- IgniteAtomicStamped
On Thu, Sep 17, 2015 at 3:00 PM, Vladimir Ozerov
wrote:
> Igniters,
>
> In *IgniteAtomicLong* I see the following statement: "All previously
> described methods have asyn
Igniters,
In *IgniteAtomicLong* I see the following statement: "All previously
described methods have asynchronous analogs." But there are no async
operations in it's implemenation.
Is this a bug in documentation of we forgot to implement them?
Vladimir.
Probably it means that we should use openjdk by default for development and
testing as well?
Sergi
2015-09-17 7:39 GMT+03:00 Dmitriy Setrakyan :
> Ignters,
>
> Can we change our docker image to download the OpenJDK? We should not
> automatically download Oracle JDK in the docker image - it is ag
GitHub user ptupitsyn opened a pull request:
https://github.com/apache/ignite/pull/96
IGNITE-1496 Platform .Net: Add .Net examples
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ptupitsyn/ignite ignite-1496
Alternatively you ca
30 matches
Mail list logo
