date:20170307

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

2017-03-07 Thread Kozlov Maxim

Andrey, in GridTimeSyncProcessorSelfTest class methods: testTimeSync() and 
testTimeSyncChangeCoordinator() also removed?


> 6 марта 2017 г., в 18:42, Andrey Gura  написал(а):
> 
> Maxim,
> 
> About SER_VER_COMPARATOR. You can use code branch that executes when
> times are equal:
> 
> int nodeOrder1 = ver1.nodeOrder();
> int nodeOrder2 = ver2.nodeOrder();
> 
> if (nodeOrder1 == nodeOrder2) {
>long order1 = ver1.order();
>long order2 = ver2.order();
> 
>assert order1 != order2;
> 
>return order1 > order2 ? 1 : -1;
> }
> else
>return nodeOrder1 > nodeOrder2 ? 1 : -1;
> 
> On Mon, Mar 6, 2017 at 6:32 PM, Alexey Goncharuk
>  wrote:
>> Maxim,
>> 
>> Global time comparison is only needed for CLOCK mode, so you should modify
>> the code as if ignoreTime is always true.
>> 
>> 2017-03-06 18:13 GMT+03:00 Kozlov Maxim :
>> 
>>> ok,
>>> in GridCacheAtomicVersionComparator class, method
>>> compare(GridCacheVersion one, GridCacheVersion other, boolean ignoreTime)
>>> if (globalTime == otherGlobalTime || ignoreTime) {  // => if (ignoreTime) {
>>> .
>>> }
>>> else
>>>return globalTime > otherGlobalTime ? 1 : -1;   // => return -1;
>>> 
>>> and,
>>> GridCacheMvcc class,
>>> SER_VER_COMPARATOR is comparator by globalTime var. His remove and remove
>>> compareSerializableVersion?
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
 6 марта 2017 г., в 16:51, Andrey Gura  написал(а):
 
 Maxim,
 
 updateTime() method should be removed.
 
 On Mon, Mar 6, 2017 at 12:12 PM, Kozlov Maxim 
>>> wrote:
> In CacheEntryImplEx class use ver.globalTime() in
> 
> @Override public long updateTime() {
>   return ver.globalTime();
> }
> 
> Than is better to replace this variable?
> 
> 
>> 3 марта 2017 г., в 19:19, Andrey Gura  написал(а):
>> 
>> Maxim,
>> 
>> I think the next implementation will be good enough:
>> 
>> public IgniteUuid asGridUuid() {
>>  return new IgniteUuid(new UUID(nodeOrderDrId, topVer), order);
>> }
>> 
>> 
>> Serialization/deserialization of GridCacheVersion.globalTime field
>> should be removed.
>> 
>> On Fri, Mar 3, 2017 at 5:57 PM, Kozlov Maxim 
>>> wrote:
>>> Alexey,
>>> 
>>> public IgniteUuid asGridUuid() {
>>>  return new IgniteUuid(new UUID(nodeOrderDrId << 32, topVer << 32),
>>> order);
>>> }
>>> 
>>> So you want to change or not?
>>> 
>>> And
>>> - GridCacheVersion.writeTo(ByteBuffer buf, MessageWriter writer)
>>> - GridCacheVersion.readFrom(ByteBuffer buf, MessageReader reader)
>>> 
>>> use globalTime variable, must be removed case 0: (in both methods) or
>>> replace globalTime?
>>> 
>>> 
>>> 
 2 марта 2017 г., в 16:58, Andrey Gura  написал(а):
 
 +1
 
 Removing of asGridUuid() method can lead to much code changes but it
 should be avoided on this step.
 
 On Thu, Mar 2, 2017 at 4:56 PM, Alexey Goncharuk
  wrote:
> Maxim,
> 
> I see several usages of asGridUuid() method, so I would just remove
>>> global
> time and use nodeOrderDrId and topVer as different parts of high
>>> and low
> parts of the embedded UUID.
> 
> --AG
> 
> 2017-03-02 12:39 GMT+03:00 Kozlov Maxim :
> 
>> Andrey,
>> 
>> When removed parameter globalTime, in method:
>> 
>> public IgniteUuid asGridUuid() {
>> return new IgniteUuid(new UUID(((long)topVer << 32) |
>>> nodeOrderDrId,
>> globalTime), order);
>> }
>> 
>> globalTime parameter replaced by something or remove this method?
>> 
>> 
>>> 2 марта 2017 г., в 12:07, Kozlov Maxim 
>> написал(а):
>>> 
>>> Andrey,
>>> 
>>> Please review PR again.
>>> 
 1 марта 2017 г., в 18:47, Andrey Gura 
>>> написал(а):
 
 I think that it is ok.
 
 On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim <
>>> dreamx@gmail.com>
>> wrote:
> Ok. What do you say for the rest?
> 
>> 1 марта 2017 г., в 18:15, Andrey Gura 
>>> написал(а):
>> 
>> Maxim,
>> 
>> I think that during renaming we should not lose "Atomic"
>>> prefix.
>> 
>> 
>> On Wed, Mar 1, 2017 at 5:16 PM, Kozlov Maxim <
>>> dreamx@gmail.com>
>> wrote:
>>> Andrey, ok.
>>> 
>>> Also remove in the modules/platform/dotnet
>> CacheAtomicWriteOrderMode.cs?
>>> 
>>> Rename classes:
>>> 
>>> GridCacheAtomicNearCacheSelfTest.startGrids ->
>> GridCacheAtomicNearCacheSelfTest.startGridsLocal (commit)
>>> IgniteCacheAtomicPrimaryWriteOrderWithStoreInvokeTest ->
>>>

Re: IgniteSemaphore and failoverSafe flag

2017-03-07 Thread Alexey Goncharuk

Guys,

I was looking at this ticket and have a question related to the lock
semantics:

Suppose I have a node which has already acquired the lock, and then all
affinity nodes related to the lock leave topology. In this case, if we
automatically re-created the lock, we would end up having two lock owners
in the grid, which is unacceptable.

I think throwing an exception and forcing a user to re-create the lock by
himself is a correct way to resolve this.

2016-11-02 14:36 GMT+03:00 Andrey Gura :

> Vladisav,
>
> I've ran this test with partitioned cache and 1 backup and with replicated
> cache (4 nodes in topology). Behavior is the same. I think it is bug. But
> the first I wanted make sure that I understand failoverSafe flag correctly.
>
> Thank you for reply. I'll create ticket.
>
> On Tue, Nov 1, 2016 at 8:48 PM, Vladisav Jelisavcic 
> wrote:
>
> > Hi,
> >
> > when failoverSafe == true, semaphore should silently redistribute the
> > permits acquired on the failing node.
> > If failoverSafe is set to false, exception is thrown to every node
> > attempting to acquire.
> >
> > It seems to me that when the first instance left topology,
> > no backups were available (this is similar to:
> > https://issues.apache.org/jira/browse/IGNITE-3386).
> > This should be fixed (semaphore should be recreated when create==true, as
> > suggested by Denis in the ticket).
> >
> > It should be a minor fix, will be ready for 1.8.
> >
> > Best regards,
> > Vladisav
> >
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Nov 1, 2016 at 5:41 PM, Andrey Gura  wrote:
> >
> > > Hi all!
> > >
> > > Guys, could somebody explain semantic of failoverSafe flag in
> > > IgniteSemaphore. From my point of view the test below should work but
> it
> > > fails:
> > >
> > > public void testFailoverReleasePermits() throws Exception {
> > > Ignite ignite = grid(0);
> > >
> > > IgniteSemaphore sem = ignite.semaphore("sem", 1, true, true);
> > >
> > > sem.acquire(1);
> > >
> > > ignite.close();
> > >
> > > U.sleep(5000);
> > >
> > > ignite = grid(1);
> > >
> > > sem = ignite.semaphore("sem", 1, true, true);
> > >
> > > boolean acquire = sem.tryAcquire(1, 5000,
> TimeUnit.MILLISECONDS);
> > >
> > > assertTrue(acquire); // fails here
> > > }
> > >
> > > From my point of view permit should be available after the first ignite
> > > instance left topology.
> > >
> >
>

[GitHub] ignite pull request #1599: ignite-4767

2017-03-07 Thread akuramshingg

GitHub user akuramshingg opened a pull request:

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

ignite-4767

Suppressing or logging rollback exceptions instead of hiding the origin 
exception

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

$ git pull https://github.com/gridgain/apache-ignite ignite-4767-master

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

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


commit d8b89d1b6771035a82eae2c153fd1f7e4b2ee7c6
Author: Alexandr Kuramshin 
Date:   2017-03-07T09:33:33Z

Suppressing or logging rollback exceptions instead of hiding the origin 
exception




---
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: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

2017-03-07 Thread Yakov Zhdanov

>> What’s about compute engine load balancers then? They rely on the
metrics received from remote nodes.

First of all, that was poor design decision - to make different components
dependant, possibly, through user-defined implementation of Discovery Spi.

What you say makes sense to me. Let's remove HB frequency from Discovery
SPI API and adjust it accordingly to
IgniteConfiguraion.getMetricsUpdateFrequency.
You should also consider completely removing heartbeats from failure
detection process - it should rely only on internal ping packets.

--Yakov

Re: assigning IGNITE-933

2017-03-07 Thread Вадим Опольский

Denis,

I'm planning to adjust processing time of incoming and outgoing messages by
JMH benchmarks.

What do you think are the parameters of commodity hardware/? RAM size? CPU
speed ? or others ?

Vadim

2017-03-06 22:36 GMT+03:00 Denis Magda :

> Vadim,
>
> How do you plan to adjust processing time of incoming and outgoing
> messages? In general, I don’t think that you need to move the direction of
> the communication layer.
>
> I’m thinking that you just need to set some reasonable awaiting time so
> that the test passes on a commodity hardware.
>
> —
> Denis
>
> On Mar 6, 2017, at 2:31 AM, Вадим Опольский  wrote:
>
> Hi everyone!
>
> I executed test GridFailFastNodeFailureDetectionSelfTest.testFailFast
> fails periodically with different values of node quantity and awaiting
> time. Test fails if the awaiting time is less than 600 miliseconds.
> I debugged test and understood that messaging took a lot of time in this
> case.
> I want to measure (with GridFailFastNodeFailureDetecti
> onSelfTest.testFailFast) and increase speed of receiving and sending
> message.
>
> Denis, what do you think about it ?
>
> Vadim Opolski
>
>
> 2017-02-24 5:55 GMT+03:00 Denis Magda :
>
>> Hi Vadim,
>>
>> Yes, this issue might be still relevant. I can’t guide you through but,
>> basically, you need to reproduce the issue, spot it in the code and propose
>> a fix.
>>
>> BTW, do you have any experience with Hibernate? If so, I would be amazing
>> if you pick up this ticket reassigning on yourself:
>> https://issues.apache.org/jira/browse/IGNITE-1794 <
>> https://issues.apache.org/jira/browse/IGNITE-1794>
>>
>> —
>> Denis
>>
>> > On Feb 23, 2017, at 2:40 AM, Вадим Опольский 
>> wrote:
>> >
>> > Dear sirs !
>> >
>> > I want to resolve issue IGNITE-933
>> >
>> > https://issues.apache.org/jira/browse/IGNITE-933
>> >
>> > Is it actual ?
>> >
>> > In which class and method you want me to make changes ?
>> >
>> > Vadim Opolski
>>
>>
>
>

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

2017-03-07 Thread Kozlov Maxim

Andrey, or better remove GridTimeSyncProcessorSelfTest class?

> 7 марта 2017 г., в 12:21, Kozlov Maxim  написал(а):
> 
> Andrey, in GridTimeSyncProcessorSelfTest class methods: testTimeSync() and 
> testTimeSyncChangeCoordinator() also removed?
> 
> 
>> 6 марта 2017 г., в 18:42, Andrey Gura  написал(а):
>> 
>> Maxim,
>> 
>> About SER_VER_COMPARATOR. You can use code branch that executes when
>> times are equal:
>> 
>> int nodeOrder1 = ver1.nodeOrder();
>> int nodeOrder2 = ver2.nodeOrder();
>> 
>> if (nodeOrder1 == nodeOrder2) {
>>   long order1 = ver1.order();
>>   long order2 = ver2.order();
>> 
>>   assert order1 != order2;
>> 
>>   return order1 > order2 ? 1 : -1;
>> }
>> else
>>   return nodeOrder1 > nodeOrder2 ? 1 : -1;
>> 
>> On Mon, Mar 6, 2017 at 6:32 PM, Alexey Goncharuk
>>  wrote:
>>> Maxim,
>>> 
>>> Global time comparison is only needed for CLOCK mode, so you should modify
>>> the code as if ignoreTime is always true.
>>> 
>>> 2017-03-06 18:13 GMT+03:00 Kozlov Maxim :
>>> 
 ok,
 in GridCacheAtomicVersionComparator class, method
 compare(GridCacheVersion one, GridCacheVersion other, boolean ignoreTime)
 if (globalTime == otherGlobalTime || ignoreTime) {  // => if (ignoreTime) {
 .
 }
 else
   return globalTime > otherGlobalTime ? 1 : -1;   // => return -1;
 
 and,
 GridCacheMvcc class,
 SER_VER_COMPARATOR is comparator by globalTime var. His remove and remove
 compareSerializableVersion?
 
 
 
 
 
 
 
> 6 марта 2017 г., в 16:51, Andrey Gura  написал(а):
> 
> Maxim,
> 
> updateTime() method should be removed.
> 
> On Mon, Mar 6, 2017 at 12:12 PM, Kozlov Maxim 
 wrote:
>> In CacheEntryImplEx class use ver.globalTime() in
>> 
>> @Override public long updateTime() {
>>  return ver.globalTime();
>> }
>> 
>> Than is better to replace this variable?
>> 
>> 
>>> 3 марта 2017 г., в 19:19, Andrey Gura  написал(а):
>>> 
>>> Maxim,
>>> 
>>> I think the next implementation will be good enough:
>>> 
>>> public IgniteUuid asGridUuid() {
>>> return new IgniteUuid(new UUID(nodeOrderDrId, topVer), order);
>>> }
>>> 
>>> 
>>> Serialization/deserialization of GridCacheVersion.globalTime field
>>> should be removed.
>>> 
>>> On Fri, Mar 3, 2017 at 5:57 PM, Kozlov Maxim 
 wrote:
 Alexey,
 
 public IgniteUuid asGridUuid() {
 return new IgniteUuid(new UUID(nodeOrderDrId << 32, topVer << 32),
 order);
 }
 
 So you want to change or not?
 
 And
 - GridCacheVersion.writeTo(ByteBuffer buf, MessageWriter writer)
 - GridCacheVersion.readFrom(ByteBuffer buf, MessageReader reader)
 
 use globalTime variable, must be removed case 0: (in both methods) or
 replace globalTime?
 
 
 
> 2 марта 2017 г., в 16:58, Andrey Gura  написал(а):
> 
> +1
> 
> Removing of asGridUuid() method can lead to much code changes but it
> should be avoided on this step.
> 
> On Thu, Mar 2, 2017 at 4:56 PM, Alexey Goncharuk
>  wrote:
>> Maxim,
>> 
>> I see several usages of asGridUuid() method, so I would just remove
 global
>> time and use nodeOrderDrId and topVer as different parts of high
 and low
>> parts of the embedded UUID.
>> 
>> --AG
>> 
>> 2017-03-02 12:39 GMT+03:00 Kozlov Maxim :
>> 
>>> Andrey,
>>> 
>>> When removed parameter globalTime, in method:
>>> 
>>> public IgniteUuid asGridUuid() {
>>> return new IgniteUuid(new UUID(((long)topVer << 32) |
 nodeOrderDrId,
>>> globalTime), order);
>>> }
>>> 
>>> globalTime parameter replaced by something or remove this method?
>>> 
>>> 
 2 марта 2017 г., в 12:07, Kozlov Maxim 
>>> написал(а):
 
 Andrey,
 
 Please review PR again.
 
> 1 марта 2017 г., в 18:47, Andrey Gura 
 написал(а):
> 
> I think that it is ok.
> 
> On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim <
 dreamx@gmail.com>
>>> wrote:
>> Ok. What do you say for the rest?
>> 
>>> 1 марта 2017 г., в 18:15, Andrey Gura 
 написал(а):
>>> 
>>> Maxim,
>>> 
>>> I think that during renaming we should not lose "Atomic"
 prefix.
>>> 
>>> 
>>> On Wed, Mar 1, 2017 at 5:16 PM, Kozlov Maxim <
 dreamx@gmail.com>
>>> wrote:
 Andrey, ok.
 
 Also remove in the modules/platform/dotnet
>>> CacheAtomicWriteOrder

Merging all network components to a single one

2017-03-07 Thread Yakov Zhdanov

Guys,

I have an idea of merging all net components to one.

Now we have the following components interacting via network:
1. discovery
2. communication
3. rest
4. odbc
5. ignite-hadoop
6. time processor (being removed together with clock mode)
7. IPC communication endpoint

2-6 use GridNioServer each with different set of selector threads which may
result to exceeding the number of cores. Tcp discovery uses blocking socket
API.

All above mean that we may require many TCP ports opened on nodes. When it
comes to some secured environments with firewalls and gathering special
permissions to open new ports Ignite installation may become painful.

What if we have the only TCP port per node (of course we can still bind all
the components to different ports) and single component that encapsulates
all the network activities and resource management? All components that
need network interaction may register filter chain to the network component
and start getting/sending network messages.

In other words, I suggest to have a single set of nio-selectors and clean
API to install network listeners to satisfy demands of all other
components. E.g. discovery, communication and rest will not open their own
servers but go to the new NetworkProcessor and setup listeners chain on
some ports (possibly on the default one and NetworkProcessor will properly
dispatch incoming connections between the components)

Current implementation has the following drawbacks that will be fixed by
new approach.
1. may require too many ports opened
2. may have selector threads count exceeding number of CPU which may lead
to performance degradation.

Please share your thoughts or ask questions.

--Yakov

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

2017-03-07 Thread ALEKSEY KUZNETSOV

Hi! I have fixed all sources. Plz, review it again

пн, 6 мар. 2017 г. в 15:43, Andrey Gura :

> Aleksey, thanks!
>
> I answered in JIRA ticket.
>
> On Mon, Mar 6, 2017 at 10:56 AM, ALEKSEY KUZNETSOV
>  wrote:
> > I've fixed the comments.
> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
> >
> > пт, 3 мар. 2017 г. в 19:23, Andrey Gura :
> >
> >> Aleksey,
> >>
> >> GitHub isn't official review tool in Apache Ignite community. There
> >> are two ways for code review: upsource and comments in JIRA tickets.
> >> So, I think, we should finish review of this ticket in upsource.
> >>
> >> On Thu, Mar 2, 2017 at 11:30 AM, ALEKSEY KUZNETSOV
> >>  wrote:
> >> > lets review code at github rather than upsource later on. Because, the
> >> > later is too slow and bring no substantial benefits compared github
> >> >
> >> > ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
> >> >
> >> >> Hi, Aleksey!
> >> >>
> >> >> Thank you for contribution!
> >> >>
> >> >> I've reviewed your changes and have some comments (mostly cosmetic).
> >> >> Could you please fix this comment? See review in Upsource for
> details.
> >> >>
> >> >> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
> >> >>  wrote:
> >> >> > Plz, review my PR :
> >> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
> >> >> > or https://github.com/apache/ignite/pull/1545
> >> >> > --
> >> >> >
> >> >> > *Best Regards,*
> >> >> >
> >> >> > *Kuznetsov Aleksey*
> >> >>
> >> > --
> >> >
> >> > *Best Regards,*
> >> >
> >> > *Kuznetsov Aleksey*
> >>
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Merging all network components to a single one

2017-03-07 Thread ALEKSEY KUZNETSOV

What tasks do discovery component responsible for ?

вт, 7 мар. 2017 г. в 13:15, Yakov Zhdanov :

> Guys,
>
> I have an idea of merging all net components to one.
>
> Now we have the following components interacting via network:
> 1. discovery
> 2. communication
> 3. rest
> 4. odbc
> 5. ignite-hadoop
> 6. time processor (being removed together with clock mode)
> 7. IPC communication endpoint
>
> 2-6 use GridNioServer each with different set of selector threads which may
> result to exceeding the number of cores. Tcp discovery uses blocking socket
> API.
>
> All above mean that we may require many TCP ports opened on nodes. When it
> comes to some secured environments with firewalls and gathering special
> permissions to open new ports Ignite installation may become painful.
>
> What if we have the only TCP port per node (of course we can still bind all
> the components to different ports) and single component that encapsulates
> all the network activities and resource management? All components that
> need network interaction may register filter chain to the network component
> and start getting/sending network messages.
>
> In other words, I suggest to have a single set of nio-selectors and clean
> API to install network listeners to satisfy demands of all other
> components. E.g. discovery, communication and rest will not open their own
> servers but go to the new NetworkProcessor and setup listeners chain on
> some ports (possibly on the default one and NetworkProcessor will properly
> dispatch incoming connections between the components)
>
> Current implementation has the following drawbacks that will be fixed by
> new approach.
> 1. may require too many ports opened
> 2. may have selector threads count exceeding number of CPU which may lead
> to performance degradation.
>
> Please share your thoughts or ask questions.
>
> --Yakov
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Ignite 2.0 - Update Spring dependency to latest stable version

2017-03-07 Thread Vyacheslav Daradur

Hello everyone!

There are no changes long ago:
https://issues.apache.org/jira/browse/IGNITE-4211

Is it actual?

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

2017-03-07 Thread Andrey Gura

Maxim,

all GridClockSyncProcessor related code should be remove (objects,
messages, etc)

On Tue, Mar 7, 2017 at 12:23 PM, Kozlov Maxim  wrote:
> Andrey, or better remove GridTimeSyncProcessorSelfTest class?
>
>> 7 марта 2017 г., в 12:21, Kozlov Maxim  написал(а):
>>
>> Andrey, in GridTimeSyncProcessorSelfTest class methods: testTimeSync() and 
>> testTimeSyncChangeCoordinator() also removed?
>>
>>
>>> 6 марта 2017 г., в 18:42, Andrey Gura  написал(а):
>>>
>>> Maxim,
>>>
>>> About SER_VER_COMPARATOR. You can use code branch that executes when
>>> times are equal:
>>>
>>> int nodeOrder1 = ver1.nodeOrder();
>>> int nodeOrder2 = ver2.nodeOrder();
>>>
>>> if (nodeOrder1 == nodeOrder2) {
>>>   long order1 = ver1.order();
>>>   long order2 = ver2.order();
>>>
>>>   assert order1 != order2;
>>>
>>>   return order1 > order2 ? 1 : -1;
>>> }
>>> else
>>>   return nodeOrder1 > nodeOrder2 ? 1 : -1;
>>>
>>> On Mon, Mar 6, 2017 at 6:32 PM, Alexey Goncharuk
>>>  wrote:
 Maxim,

 Global time comparison is only needed for CLOCK mode, so you should modify
 the code as if ignoreTime is always true.

 2017-03-06 18:13 GMT+03:00 Kozlov Maxim :

> ok,
> in GridCacheAtomicVersionComparator class, method
> compare(GridCacheVersion one, GridCacheVersion other, boolean ignoreTime)
> if (globalTime == otherGlobalTime || ignoreTime) {  // => if (ignoreTime) 
> {
> .
> }
> else
>   return globalTime > otherGlobalTime ? 1 : -1;   // => return -1;
>
> and,
> GridCacheMvcc class,
> SER_VER_COMPARATOR is comparator by globalTime var. His remove and remove
> compareSerializableVersion?
>
>
>
>
>
>
>
>> 6 марта 2017 г., в 16:51, Andrey Gura  написал(а):
>>
>> Maxim,
>>
>> updateTime() method should be removed.
>>
>> On Mon, Mar 6, 2017 at 12:12 PM, Kozlov Maxim 
> wrote:
>>> In CacheEntryImplEx class use ver.globalTime() in
>>>
>>> @Override public long updateTime() {
>>>  return ver.globalTime();
>>> }
>>>
>>> Than is better to replace this variable?
>>>
>>>
 3 марта 2017 г., в 19:19, Andrey Gura  написал(а):

 Maxim,

 I think the next implementation will be good enough:

 public IgniteUuid asGridUuid() {
 return new IgniteUuid(new UUID(nodeOrderDrId, topVer), order);
 }


 Serialization/deserialization of GridCacheVersion.globalTime field
 should be removed.

 On Fri, Mar 3, 2017 at 5:57 PM, Kozlov Maxim 
> wrote:
> Alexey,
>
> public IgniteUuid asGridUuid() {
> return new IgniteUuid(new UUID(nodeOrderDrId << 32, topVer << 32),
> order);
> }
>
> So you want to change or not?
>
> And
> - GridCacheVersion.writeTo(ByteBuffer buf, MessageWriter writer)
> - GridCacheVersion.readFrom(ByteBuffer buf, MessageReader reader)
>
> use globalTime variable, must be removed case 0: (in both methods) or
> replace globalTime?
>
>
>
>> 2 марта 2017 г., в 16:58, Andrey Gura  написал(а):
>>
>> +1
>>
>> Removing of asGridUuid() method can lead to much code changes but it
>> should be avoided on this step.
>>
>> On Thu, Mar 2, 2017 at 4:56 PM, Alexey Goncharuk
>>  wrote:
>>> Maxim,
>>>
>>> I see several usages of asGridUuid() method, so I would just remove
> global
>>> time and use nodeOrderDrId and topVer as different parts of high
> and low
>>> parts of the embedded UUID.
>>>
>>> --AG
>>>
>>> 2017-03-02 12:39 GMT+03:00 Kozlov Maxim :
>>>
 Andrey,

 When removed parameter globalTime, in method:

 public IgniteUuid asGridUuid() {
 return new IgniteUuid(new UUID(((long)topVer << 32) |
> nodeOrderDrId,
 globalTime), order);
 }

 globalTime parameter replaced by something or remove this method?


> 2 марта 2017 г., в 12:07, Kozlov Maxim 
 написал(а):
>
> Andrey,
>
> Please review PR again.
>
>> 1 марта 2017 г., в 18:47, Andrey Gura 
> написал(а):
>>
>> I think that it is ok.
>>
>> On Wed, Mar 1, 2017 at 6:34 PM, Kozlov Maxim <
> dreamx@gmail.com>
 wrote:
>>> Ok. What do you say for the rest?
>>>
 1 марта 2017 г., в 18:15, Andrey Gura 
> написал(а):

 Maxim,

 I think that during renaming we should not lose "Atomic"
> prefix.

>>>

distributed transaction of non-single coordinator

2017-03-07 Thread ALEKSEY KUZNETSOV

Hi all! Im designing distributed transaction which can be started at one
node, and continued at other one. Has anybody thoughts on it ?
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: PR IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

2017-03-07 Thread ALEKSEY KUZNETSOV

Regarding your comment in ticket. Do you mean broken factory node ought to
send notifications to cache nodes through sharedCtx.io().send(...) ?

пт, 3 мар. 2017 г. в 11:33, Yakov Zhdanov :

> Alexey, my comments are in the ticket. Please address them.
>
> Thanks!
> --
> Yakov Zhdanov, Director R&D
> *GridGain Systems*
> www.gridgain.com
>
> 2017-03-01 12:15 GMT+03:00 Yakov Zhdanov :
>
> > Alexey, I will take a look at this in couple of days.
> >
> > --Yakov
> >
> > 2017-03-01 11:25 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> >> Plz, review my changes
> >> https://issues.apache.org/jira/browse/IGNITE-1094
> >>
> >> https://github.com/apache/ignite/pull/1581
> >> --
> >>
> >> *Best Regards,*
> >>
> >> *Kuznetsov Aleksey*
> >>
> >
> >
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: general question

2017-03-07 Thread ALEKSEY KUZNETSOV

I've found GridDhtCacheEntry and GridDistributedCacheEntry, so they
must have been of the same logic ?


пт, 3 мар. 2017 г. в 15:03, Alexander Fedotov :

> Yes, DHT stands for distributed hash table.
>
> On Fri, Mar 3, 2017 at 3:01 PM, ALEKSEY KUZNETSOV <
> alkuznetsov...@gmail.com>
> wrote:
>
> > Thank you so much! And the last one. I cannot find definition of DHT.
> Does
> > it stand for distributed ? In contrary to Local
> >
> > пт, 3 мар. 2017 г. в 13:51, Alexander Fedotov <
> > alexander.fedot...@gmail.com
> > >:
> >
> > > Probably, IgniteTxHandler#processDhtTxPrepareRequest is what you are
> > > looking for.
> > > Check the data flow from GridDhtTxPrepareRequest#nearWrites
> > >
> > > On Fri, Mar 3, 2017 at 1:19 PM, ALEKSEY KUZNETSOV <
> > > alkuznetsov...@gmail.com>
> > > wrote:
> > >
> > > > Ah, thanks! Which class is responsible for near cache
> synchronization ?
> > > >
> > > > пт, 3 мар. 2017 г. в 13:15, Alexander Fedotov <
> > > > alexander.fedot...@gmail.com
> > > > >:
> > > >
> > > > > Hi Aleksey,
> > > > >
> > > > > Local cache pertains only to the node where it's created and no
> data
> > is
> > > > > distributed to
> > > > > or synchronized with other nodes, while near cache serves as a
> front
> > > end
> > > > > for a partitioned cache, storing recently requested data which is
> > > > > synchronized when it's changed on
> > > > > other nodes.
> > > > >
> > > > >
> > > > > On Fri, Mar 3, 2017 at 10:39 AM, ALEKSEY KUZNETSOV <
> > > > > alkuznetsov...@gmail.com
> > > > > > wrote:
> > > > >
> > > > > > Hi all ! What is the difference between local and near
> transactions
> > > > > > --
> > > > > >
> > > > > > *Best Regards,*
> > > > > >
> > > > > > *Kuznetsov Aleksey*
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Kind regards,
> > > > > Alexander.
> > > > >
> > > > --
> > > >
> > > > *Best Regards,*
> > > >
> > > > *Kuznetsov Aleksey*
> > > >
> > >
> > >
> > >
> > > --
> > > Kind regards,
> > > Alexander.
> > >
> > --
> >
> > *Best Regards,*
> >
> > *Kuznetsov Aleksey*
> >
>
>
>
> --
> Kind regards,
> Alexander.
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

[jira] [Created] (IGNITE-4797) Need to expose offheap memory allocated size metric for internal data structures

2017-03-07 Thread Andrey Gura (JIRA)

Andrey Gura created IGNITE-4797:
---

 Summary: Need to expose offheap memory allocated size metric for 
internal data structures
 Key: IGNITE-4797
 URL: https://issues.apache.org/jira/browse/IGNITE-4797
 Project: Ignite
  Issue Type: Improvement
Reporter: Andrey Gura
 Fix For: 2.0


Offheap caches expose offheap memory allocated size via 
{{CacheMetricsMXBean.getOffHeapAllocatedSize()}}. But this metric doesn't take 
into account offheap memory that allocated for internal data structures 
(GridUnsafeMap and LRU eviction policy). 

However Ignite collects this metric (see GridUnsafeMemory.systemAllocatedSize() 
method).

Need to expose this metric via {{CacheMetricsMXBean}}.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] ignite pull request #1600: Ignite 3018 fair

2017-03-07 Thread tledkov-gridgain

GitHub user tledkov-gridgain opened a pull request:

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

Ignite 3018 fair



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

$ git pull https://github.com/gridgain/apache-ignite ignite-3018-fair

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

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


commit ed35a9eb6f02771c5996209a1e19a4b0557309b6
Author: tledkov-gridgain 
Date:   2017-02-27T09:49:31Z

IGNITE-3018: RendezvousAffinityFunction performance tuning

commit 3a6d17c2250158b54e3573af23b9b1534c3c8e92
Author: tledkov-gridgain 
Date:   2017-02-27T10:57:36Z

IGNITE-3018: fix review issues

commit db5512b65ce273d955ecd1c2381ade84491895ad
Author: tledkov-gridgain 
Date:   2017-03-02T14:32:04Z

Merge branch 'ignite-2.0' into ignite-3018

commit f969a5b923ec9532464efb657cf3f8aa37232fcc
Author: tledkov-gridgain 
Date:   2017-03-07T12:56:10Z

IGNITE-3018: implement simple partition balance for rendezvouz affinity




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

[jira] [Created] (IGNITE-4798) Cluster does not finish rebalancing after nodes leaving

2017-03-07 Thread Semen Boikov (JIRA)

Semen Boikov created IGNITE-4798:


 Summary: Cluster does not finish rebalancing after nodes leaving
 Key: IGNITE-4798
 URL: https://issues.apache.org/jira/browse/IGNITE-4798
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Kholodov


   
Hi Valentin,

I managed to reproduce the stability issue we've been having in production in a 
relatively sterile environment.
The logs and stack traces are accessible here: 
https://drive.google.com/open?id=0B1YMrCiHZq1PMWJsblBYSXhaX1k

The situation is:
1. Startup a cluster of 223 nodes.
2. Wait for everything to stabilize (took about 2 minutes).
3. Shut down 112 nodes.
4. Wait for everything to stabilize..

Since that point, I can't connect client nodes to the cluster:
2017-02-15 23:13:16.396 WARN  o.a.i.i.p.c.GridCachePartitionExchangeManager 
main ctx: actor: - Failed to wait for 
initial partition map exchange. Possible reasons are:
  ^-- Transactions in deadlock.
  ^-- Long running transactions (ignore if this is the case).
  ^-- Unreleased explicit locks.

Other cache operations are also stuck.

Let me know what other information I can provide.

 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

IGNITE-1393 - ready for review

2017-03-07 Thread Дмитрий Рябов

Hello. Please, review.

https://issues.apache.org/jira/browse/IGNITE-1393 [Test] AssertionError
when stop node executing transaction - GridCacheStopSelfTest

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

2017-03-07 Thread Andrey Gura

Aleksey, thanks a lot!

Answered in JIRA ticket.

On Tue, Mar 7, 2017 at 1:27 PM, ALEKSEY KUZNETSOV
 wrote:
> Hi! I have fixed all sources. Plz, review it again
>
> пн, 6 мар. 2017 г. в 15:43, Andrey Gura :
>
>> Aleksey, thanks!
>>
>> I answered in JIRA ticket.
>>
>> On Mon, Mar 6, 2017 at 10:56 AM, ALEKSEY KUZNETSOV
>>  wrote:
>> > I've fixed the comments.
>> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>> >
>> > пт, 3 мар. 2017 г. в 19:23, Andrey Gura :
>> >
>> >> Aleksey,
>> >>
>> >> GitHub isn't official review tool in Apache Ignite community. There
>> >> are two ways for code review: upsource and comments in JIRA tickets.
>> >> So, I think, we should finish review of this ticket in upsource.
>> >>
>> >> On Thu, Mar 2, 2017 at 11:30 AM, ALEKSEY KUZNETSOV
>> >>  wrote:
>> >> > lets review code at github rather than upsource later on. Because, the
>> >> > later is too slow and bring no substantial benefits compared github
>> >> >
>> >> > ср, 1 мар. 2017 г. в 18:04, Andrey Gura :
>> >> >
>> >> >> Hi, Aleksey!
>> >> >>
>> >> >> Thank you for contribution!
>> >> >>
>> >> >> I've reviewed your changes and have some comments (mostly cosmetic).
>> >> >> Could you please fix this comment? See review in Upsource for
>> details.
>> >> >>
>> >> >> On Tue, Feb 28, 2017 at 2:17 PM, ALEKSEY KUZNETSOV
>> >> >>  wrote:
>> >> >> > Plz, review my PR :
>> >> >> > http://reviews.ignite.apache.org/ignite/review/IGNT-CR-98
>> >> >> > or https://github.com/apache/ignite/pull/1545
>> >> >> > --
>> >> >> >
>> >> >> > *Best Regards,*
>> >> >> >
>> >> >> > *Kuznetsov Aleksey*
>> >> >>
>> >> > --
>> >> >
>> >> > *Best Regards,*
>> >> >
>> >> > *Kuznetsov Aleksey*
>> >>
>> > --
>> >
>> > *Best Regards,*
>> >
>> > *Kuznetsov Aleksey*
>>
> --
>
> *Best Regards,*
>
> *Kuznetsov Aleksey*

Re: Merging all network components to a single one

2017-03-07 Thread Dmitriy Setrakyan

Yakov,

I think you are proposing to have a single NIO (or TCP) SPI and have all
other SPIs and components register with it and receive message callbacks.
Is that right? If yes, then I really like the idea.

D.

On Tue, Mar 7, 2017 at 2:15 AM, Yakov Zhdanov  wrote:

> Guys,
>
> I have an idea of merging all net components to one.
>
> Now we have the following components interacting via network:
> 1. discovery
> 2. communication
> 3. rest
> 4. odbc
> 5. ignite-hadoop
> 6. time processor (being removed together with clock mode)
> 7. IPC communication endpoint
>
> 2-6 use GridNioServer each with different set of selector threads which may
> result to exceeding the number of cores. Tcp discovery uses blocking socket
> API.
>
> All above mean that we may require many TCP ports opened on nodes. When it
> comes to some secured environments with firewalls and gathering special
> permissions to open new ports Ignite installation may become painful.
>
> What if we have the only TCP port per node (of course we can still bind all
> the components to different ports) and single component that encapsulates
> all the network activities and resource management? All components that
> need network interaction may register filter chain to the network component
> and start getting/sending network messages.
>
> In other words, I suggest to have a single set of nio-selectors and clean
> API to install network listeners to satisfy demands of all other
> components. E.g. discovery, communication and rest will not open their own
> servers but go to the new NetworkProcessor and setup listeners chain on
> some ports (possibly on the default one and NetworkProcessor will properly
> dispatch incoming connections between the components)
>
> Current implementation has the following drawbacks that will be fixed by
> new approach.
> 1. may require too many ports opened
> 2. may have selector threads count exceeding number of CPU which may lead
> to performance degradation.
>
> Please share your thoughts or ask questions.
>
> --Yakov
>

Re: IgniteSemaphore and failoverSafe flag

2017-03-07 Thread Dmitriy Setrakyan

On Tue, Mar 7, 2017 at 1:26 AM, Alexey Goncharuk  wrote:

> Guys,
>
> I was looking at this ticket and have a question related to the lock
> semantics:
>
> Suppose I have a node which has already acquired the lock, and then all
> affinity nodes related to the lock leave topology. In this case, if we
> automatically re-created the lock, we would end up having two lock owners
> in the grid, which is unacceptable.
>
> I think throwing an exception and forcing a user to re-create the lock by
> himself is a correct way to resolve this.
>

Which user operation would result in exception? To my knowledge, user may
already be holding the lock and not invoking any Ignite APIs, no?

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

2017-03-07 Thread Denis Magda

Good, the ticket is ready:
https://issues.apache.org/jira/browse/IGNITE-4799 


—
Denis

> On Mar 7, 2017, at 1:47 AM, Yakov Zhdanov  wrote:
> 
>>> What’s about compute engine load balancers then? They rely on the
> metrics received from remote nodes.
> 
> First of all, that was poor design decision - to make different components
> dependant, possibly, through user-defined implementation of Discovery Spi.
> 
> What you say makes sense to me. Let's remove HB frequency from Discovery
> SPI API and adjust it accordingly to
> IgniteConfiguraion.getMetricsUpdateFrequency.
> You should also consider completely removing heartbeats from failure
> detection process - it should rely only on internal ping packets.
> 
> --Yakov

[jira] [Created] (IGNITE-4799) Remove TcpDiscoverySpi.heartbeatsFrequency parameter

2017-03-07 Thread Denis Magda (JIRA)

Denis Magda created IGNITE-4799:
---

 Summary: Remove TcpDiscoverySpi.heartbeatsFrequency parameter
 Key: IGNITE-4799
 URL: https://issues.apache.org/jira/browse/IGNITE-4799
 Project: Ignite
  Issue Type: Bug
Reporter: Denis Magda
 Fix For: 2.0


{{TcpDiscoverySpi.heartbeatsFrequency}} is no longer used to adjust the 
heartbeats frequence. It affects the frequency of metrics messages sent over 
the cluster ring.

The following has to be done as a part of 2.0 release:
* Remove {{TcpDiscoverySpi.heartbeatsFrequency}} parameter.
* Use {{IgniteConfiguraion.getMetricsUpdateFrequency}} to adjust the rate of 
metrics messages.
* Make sure {{IgniteConfiguraion.getMetricsUpdateFrequency}} and metrics 
messages are not participated in the failure detection process. We have to 
clean up legacy code in {{ServerImpl}}.

Refer to this discussion for more details:
http://apache-ignite-developers.2346864.n4.nabble.com/Renaming-TcpDiscoverySpi-heartbeatsFrequency-to-TcpDiscoverySpi-metricsUpdateFrequency-td14941.html
 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: assigning IGNITE-933

2017-03-07 Thread Denis Magda

Vadim,

The timeout should be such that the test completes successfully on single core 
machine as well as on multi-core servers. Setting timeout to 3 - 5 seconds 
should work.

—
Denis

> On Mar 7, 2017, at 1:55 AM, Вадим Опольский  wrote:
> 
> Denis,
> 
> I'm planning to adjust processing time of incoming and outgoing messages by 
> JMH benchmarks.
> 
> What do you think are the parameters of commodity hardware/? RAM size? CPU 
> speed ? or others ?
> 
> Vadim
> 
> 2017-03-06 22:36 GMT+03:00 Denis Magda  >:
> Vadim,
> 
> How do you plan to adjust processing time of incoming and outgoing messages? 
> In general, I don’t think that you need to move the direction of the 
> communication layer.
> 
> I’m thinking that you just need to set some reasonable awaiting time so that 
> the test passes on a commodity hardware.
> 
> —
> Denis
> 
>> On Mar 6, 2017, at 2:31 AM, Вадим Опольский > > wrote:
>> 
>> Hi everyone!
>> 
>> I executed test GridFailFastNodeFailureDetectionSelfTest.testFailFast fails 
>> periodically with different values of node quantity and awaiting time. Test 
>> fails if the awaiting time is less than 600 miliseconds. 
>> I debugged test and understood that messaging took a lot of time in this 
>> case.
>> I want to measure (with 
>> GridFailFastNodeFailureDetectionSelfTest.testFailFast) and increase speed of 
>> receiving and sending message.
>> 
>> Denis, what do you think about it ?
>> 
>> Vadim Opolski
>>  
>> 
>> 2017-02-24 5:55 GMT+03:00 Denis Magda > >:
>> Hi Vadim,
>> 
>> Yes, this issue might be still relevant. I can’t guide you through but, 
>> basically, you need to reproduce the issue, spot it in the code and propose 
>> a fix.
>> 
>> BTW, do you have any experience with Hibernate? If so, I would be amazing if 
>> you pick up this ticket reassigning on yourself:
>> https://issues.apache.org/jira/browse/IGNITE-1794 
>>  
>> > >
>> 
>> —
>> Denis
>> 
>> > On Feb 23, 2017, at 2:40 AM, Вадим Опольский > > > wrote:
>> >
>> > Dear sirs !
>> >
>> > I want to resolve issue IGNITE-933
>> >
>> > https://issues.apache.org/jira/browse/IGNITE-933 
>> > 
>> >
>> > Is it actual ?
>> >
>> > In which class and method you want me to make changes ?
>> >
>> > Vadim Opolski

Re: Ignite 2.0 - Update Spring dependency to latest stable version

2017-03-07 Thread Denis Magda

Yes, it’s planned for 2.0 release. You can assign it on yourself helping out 
the community to release as many improvements in 2.0 as possible.

—
Denis

> On Mar 7, 2017, at 2:59 AM, Vyacheslav Daradur  wrote:
> 
> Hello everyone!
> 
> There are no changes long ago:
> https://issues.apache.org/jira/browse/IGNITE-4211
> 
> Is it actual?

Re: Merging all network components to a single one

2017-03-07 Thread Denis Magda

Personally, I’m fully for this idea.

BTW, there is already a ticket for this task created by Yakov some time ago:
https://issues.apache.org/jira/browse/IGNITE-3480 


—
Denis

> On Mar 7, 2017, at 10:50 AM, Dmitriy Setrakyan  wrote:
> 
> Yakov,
> 
> I think you are proposing to have a single NIO (or TCP) SPI and have all
> other SPIs and components register with it and receive message callbacks.
> Is that right? If yes, then I really like the idea.
> 
> D.
> 
> On Tue, Mar 7, 2017 at 2:15 AM, Yakov Zhdanov  wrote:
> 
>> Guys,
>> 
>> I have an idea of merging all net components to one.
>> 
>> Now we have the following components interacting via network:
>> 1. discovery
>> 2. communication
>> 3. rest
>> 4. odbc
>> 5. ignite-hadoop
>> 6. time processor (being removed together with clock mode)
>> 7. IPC communication endpoint
>> 
>> 2-6 use GridNioServer each with different set of selector threads which may
>> result to exceeding the number of cores. Tcp discovery uses blocking socket
>> API.
>> 
>> All above mean that we may require many TCP ports opened on nodes. When it
>> comes to some secured environments with firewalls and gathering special
>> permissions to open new ports Ignite installation may become painful.
>> 
>> What if we have the only TCP port per node (of course we can still bind all
>> the components to different ports) and single component that encapsulates
>> all the network activities and resource management? All components that
>> need network interaction may register filter chain to the network component
>> and start getting/sending network messages.
>> 
>> In other words, I suggest to have a single set of nio-selectors and clean
>> API to install network listeners to satisfy demands of all other
>> components. E.g. discovery, communication and rest will not open their own
>> servers but go to the new NetworkProcessor and setup listeners chain on
>> some ports (possibly on the default one and NetworkProcessor will properly
>> dispatch incoming connections between the components)
>> 
>> Current implementation has the following drawbacks that will be fixed by
>> new approach.
>> 1. may require too many ports opened
>> 2. may have selector threads count exceeding number of CPU which may lead
>> to performance degradation.
>> 
>> Please share your thoughts or ask questions.
>> 
>> --Yakov
>>

Re: distributed transaction of non-single coordinator

2017-03-07 Thread Denis Magda

Hi Alexey,

Please share the rational behind this and the thoughts, design ideas you have 
in mind.

—
Denis

> On Mar 7, 2017, at 3:19 AM, ALEKSEY KUZNETSOV  
> wrote:
> 
> Hi all! Im designing distributed transaction which can be started at one
> node, and continued at other one. Has anybody thoughts on it ?
> -- 
> 
> *Best Regards,*
> 
> *Kuznetsov Aleksey*

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

2017-03-07 Thread Andrey Gura

JFYI

Also today Vert.x 3.4.0 was released with Apache Ignite 1.9 based
cluster manager for Vert.x in HA/Clustered mode.

On Tue, Mar 7, 2017 at 3:10 AM, Denis Magda  wrote:
> The Apache Ignite Community is pleased to announce the release of Apache 
> Ignite 1.9.0.
>
> Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and 
> distributed in-memory platform for computing and transacting on large-scale 
> data sets in real-time, orders of magnitude faster than possible with 
> traditional disk-based or flash-based technologies.
>
> The Fabric is a collection of independent and well integrated components some 
> of which are the following:
> Data Grid
> SQL Grid
> Compute Grid
> Streaming & CEP
> Service Grid
>
>
> In this release the community provided an integration with Kubernetes cluster 
> manager, improved performance of core and SQL Grid components, expanded Data 
> Modification Language support to the level of .NET and C++ API, integrated 
> with .NET TransactionScope API and more.
>
> Learn more details from our blog post: 
> https://blogs.apache.org/ignite/entry/apache-ignite-1-9-released
>
> The full list of the changes can be found here [2].
>
> Please visit this page if you’re ready to try the release out:
> https://ignite.apache.org/download.cgi
>
> Please let us know [3] if you encounter any problems.
>
> Regards,
>
> The Apache Ignite Community
>
> [1] https://ignite.apache.org
> [2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt
> [3] https://ignite.apache.org/community/resources.html#ask

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

2017-03-07 Thread Denis Magda

Andrey,

Excellent! Thanks for keeping an eye on this. Please let us know what you do 
the same for Zeppelin.

*Raul*, *Roman*, could you update Camel and MyBatis integrations respectively?
https://cwiki.apache.org/confluence/display/IGNITE/External+Integrations 


—
Denis

> On Mar 7, 2017, at 11:47 AM, Andrey Gura  wrote:
> 
> JFYI
> 
> Also today Vert.x 3.4.0 was released with Apache Ignite 1.9 based
> cluster manager for Vert.x in HA/Clustered mode.
> 
> On Tue, Mar 7, 2017 at 3:10 AM, Denis Magda  wrote:
>> The Apache Ignite Community is pleased to announce the release of Apache 
>> Ignite 1.9.0.
>> 
>> Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated 
>> and distributed in-memory platform for computing and transacting on 
>> large-scale data sets in real-time, orders of magnitude faster than possible 
>> with traditional disk-based or flash-based technologies.
>> 
>> The Fabric is a collection of independent and well integrated components 
>> some of which are the following:
>> Data Grid
>> SQL Grid
>> Compute Grid
>> Streaming & CEP
>> Service Grid
>> 
>> 
>> In this release the community provided an integration with Kubernetes 
>> cluster manager, improved performance of core and SQL Grid components, 
>> expanded Data Modification Language support to the level of .NET and C++ 
>> API, integrated with .NET TransactionScope API and more.
>> 
>> Learn more details from our blog post: 
>> https://blogs.apache.org/ignite/entry/apache-ignite-1-9-released
>> 
>> The full list of the changes can be found here [2].
>> 
>> Please visit this page if you’re ready to try the release out:
>> https://ignite.apache.org/download.cgi
>> 
>> Please let us know [3] if you encounter any problems.
>> 
>> Regards,
>> 
>> The Apache Ignite Community
>> 
>> [1] https://ignite.apache.org
>> [2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt
>> [3] https://ignite.apache.org/community/resources.html#ask

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

2017-03-07 Thread Denis Magda

Updated news section on the site and tweeted about the release:
https://twitter.com/ApacheIgnite/status/839208220841275392 


—
Denis

> On Mar 6, 2017, at 4:10 PM, Denis Magda  wrote:
> 
> The Apache Ignite Community is pleased to announce the release of Apache 
> Ignite 1.9.0.
> 
> Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and 
> distributed in-memory platform for computing and transacting on large-scale 
> data sets in real-time, orders of magnitude faster than possible with 
> traditional disk-based or flash-based technologies.
> 
> The Fabric is a collection of independent and well integrated components some 
> of which are the following:  
> Data Grid
> SQL Grid
> Compute Grid
> Streaming & CEP
> Service Grid
> 
> 
> In this release the community provided an integration with Kubernetes cluster 
> manager, improved performance of core and SQL Grid components, expanded Data 
> Modification Language support to the level of .NET and C++ API, integrated 
> with .NET TransactionScope API and more.
> 
> Learn more details from our blog post: 
> https://blogs.apache.org/ignite/entry/apache-ignite-1-9-released
> 
> The full list of the changes can be found here [2].
> 
> Please visit this page if you’re ready to try the release out:
> https://ignite.apache.org/download.cgi
> 
> Please let us know [3] if you encounter any problems.
> 
> Regards,
> 
> The Apache Ignite Community
> 
> [1] https://ignite.apache.org
> [2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt
> [3] https://ignite.apache.org/community/resources.html#ask

[GitHub] ignite pull request #1601: Added CacheNotAvailableTest, seeing CACHE_REBALAN...

2017-03-07 Thread sfirestone

GitHub user sfirestone opened a pull request:

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

Added CacheNotAvailableTest, seeing CACHE_REBALANCE_PART_DATA_LOST evâ¦

â¦ents and multiple backups for partitions

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

$ git pull https://github.com/sfirestone/ignite ignite-1.8

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

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


commit 3ea76bbeda7b8809f6e3e9e6df8328bda5f08140
Author: Spencer Firestone 
Date:   2017-03-07T22:57:50Z

Added CacheNotAvailableTest, seeing CACHE_REBALANCE_PART_DATA_LOST events 
and multiple backups for partitions




---
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 #1601: Added CacheNotAvailableTest, seeing CACHE_REBALAN...

2017-03-07 Thread sfirestone

Github user sfirestone closed the pull request at:

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


---
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: [ANNOUNCE] Apache Ignite 1.9.0 Released

2017-03-07 Thread Roman Shtykh

MyBatis Ignite cache is updated. The new version is 
1.0.4.http://www.mybatis.org/ignite-cache/

Best regards,Roman


On Wednesday, March 8, 2017 4:50 AM, Denis Magda  wrote:
 

 Andrey,
Excellent! Thanks for keeping an eye on this. Please let us know what you do 
the same for Zeppelin.
*Raul*, *Roman*, could you update Camel and MyBatis integrations 
respectively?https://cwiki.apache.org/confluence/display/IGNITE/External+Integrations
—Denis

On Mar 7, 2017, at 11:47 AM, Andrey Gura  wrote:
JFYI

Also today Vert.x 3.4.0 was released with Apache Ignite 1.9 based
cluster manager for Vert.x in HA/Clustered mode.

On Tue, Mar 7, 2017 at 3:10 AM, Denis Magda  wrote:

The Apache Ignite Community is pleased to announce the release of Apache Ignite 
1.9.0.

Apache Ignite In-Memory Data Fabric [1] is a high-performance, integrated and 
distributed in-memory platform for computing and transacting on large-scale 
data sets in real-time, orders of magnitude faster than possible with 
traditional disk-based or flash-based technologies.

The Fabric is a collection of independent and well integrated components some 
of which are the following:
Data Grid
SQL Grid
Compute Grid
Streaming & CEP
Service Grid


In this release the community provided an integration with Kubernetes cluster 
manager, improved performance of core and SQL Grid components, expanded Data 
Modification Language support to the level of .NET and C++ API, integrated with 
.NET TransactionScope API and more.

Learn more details from our blog post: 
https://blogs.apache.org/ignite/entry/apache-ignite-1-9-released

The full list of the changes can be found here [2].

Please visit this page if you’re ready to try the release out:
https://ignite.apache.org/download.cgi

Please let us know [3] if you encounter any problems.

Regards,

The Apache Ignite Community

[1] https://ignite.apache.org
[2] https://github.com/apache/ignite/blob/master/RELEASE_NOTES.txt
[3] https://ignite.apache.org/community/resources.html#ask

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

Re: IgniteSemaphore and failoverSafe flag

[GitHub] ignite pull request #1599: ignite-4767

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

Re: assigning IGNITE-933

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

Merging all network components to a single one

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

Re: Merging all network components to a single one

Ignite 2.0 - Update Spring dependency to latest stable version

Re: Remove CacheAtomicWriteOrderMode.CLOCK mode.

distributed transaction of non-single coordinator

Re: PR IGNITE-1094 Ignite.createCache(CacheConfiguration) hangs if some exception occurs during cache initialization

Re: general question

[jira] [Created] (IGNITE-4797) Need to expose offheap memory allocated size metric for internal data structures

[GitHub] ignite pull request #1600: Ignite 3018 fair

[jira] [Created] (IGNITE-4798) Cluster does not finish rebalancing after nodes leaving

IGNITE-1393 - ready for review

Re: REVIEW IGNITE-2552 EvictionPolicies refactored, logic changed

Re: Merging all network components to a single one

Re: IgniteSemaphore and failoverSafe flag

Re: Renaming TcpDiscoverySpi.heartbeatsFrequency to TcpDiscoverySpi.metricsUpdateFrequency

[jira] [Created] (IGNITE-4799) Remove TcpDiscoverySpi.heartbeatsFrequency parameter

Re: assigning IGNITE-933

Re: Ignite 2.0 - Update Spring dependency to latest stable version

Re: Merging all network components to a single one

Re: distributed transaction of non-single coordinator

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

[GitHub] ignite pull request #1601: Added CacheNotAvailableTest, seeing CACHE_REBALAN...

[GitHub] ignite pull request #1601: Added CacheNotAvailableTest, seeing CACHE_REBALAN...

Re: [ANNOUNCE] Apache Ignite 1.9.0 Released

33 matches

Site Navigation

Mail list logo

Footer information