[GitHub] ignite pull request: ignite-1923 testResponseMessageOnRequestUnmar...

[agura]

Github user agura closed the pull request at:

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


---
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-1933) .Net: GetOrCreateCache overloads with CacheConfiguration

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1933:
---

 Summary: .Net: GetOrCreateCache overloads with CacheConfiguration
 Key: IGNITE-1933
 URL: https://issues.apache.org/jira/browse/IGNITE-1933
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
 Fix For: 1.6


Add GetOrCreateCache overloads that accept CacheConfiguration, similar to 
Ignite in Java.



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

[GitHub] ignite pull request: ignite-1681 Dogpile effect tests for CacheSto...

[agura]

Github user agura closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] ignite pull request: IGNITE-1932 Fixed wrong value of BusyTimePerc...

[akuznetsov-gridgain]

GitHub user akuznetsov-gridgain opened a pull request:

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

IGNITE-1932 Fixed wrong value of BusyTimePercentage metric after 
ignite.cluster().resetMetrics()



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

$ git pull https://github.com/akuznetsov-gridgain/ignite ignite-1932

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

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


commit 5a116cb264a8834840fde8e5e8a60d06023d6b1a
Author: ashutak 
Date:   2015-11-13T13:23:56Z

Improve IgnitePutGetTxBenchmark

commit 80147128a3b07f927dec65f0a6934f6782efab5c
Author: sboikov 
Date:   2015-11-17T06:48:58Z

ignite-1758 Discovery fixes

commit d54fcbedf9fdc110de8e73387a6796852b0ff42c
Author: Denis Magda 
Date:   2015-11-17T08:56:01Z

Added advanced tests for GridCacheLoadOnlyStoreAdapterSelfTest

commit 23807374f3c43b31d474728fdcd1830308521a6c
Author: AKuznetsov 
Date:   2015-11-17T10:32:53Z

IGNITE-1932 Fixed busy time calculations after 
ignite.cluster().resetMetrics().




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

Contribution merged: IGNITE-1900 Ignite JMX problem with Spring Boot

[Denis Magda]

wmz7year,

(BTW, what is your real name? :) )

Thanks a lot for your first contribution! It will be a part of the next 
release.


Look forward to receiving new contributions from you in the nearest time,
Denis

Re: Review the new Camel Streamer (IGNITE-1790)

[Raul Kripalani]

On Mon, Nov 16, 2015 at 12:32 PM, Denis Magda  wrote:

> Is there any chance we make this contribution available as a part of the
> upcoming release?
>

Yes, it'll be. Will get around to reviewing it by tomorrow.

*Raúl Kripalani*
PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
Messaging Engineer
http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
http://blog.raulkr.net | twitter: @raulvk

Re: Ignite-1.5 Release

[Yakov Zhdanov]

Vladislav,

I started to review the latest changes and have couple of questions:

1. latest changes are here - https://github.com/apache/ignite/pull/120? Is
that correct?
2. 
org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.Sync#nodeMap
is accessed in both sync and unsync context. Are you sure this is fine.
3. As far as failing test - can you please isolate it into separate junit
or point out existing one?

--Yakov

2015-11-11 12:33 GMT+03:00 Vladisav Jelisavcic :

> Yakov,
>
> sorry  for running a bit late.
>
> > Vladislav, do you have any updates for
> > https://issues.apache.org/jira/browse/IGNITE-638? Or any questions?
> >
> > --Yakov
>
> I have problems with some fail-over scenarios;
> It seems that if the two nodes are in the middle of acquiring or releasing
> the semaphore,
> and one of them fails, all nodes get:
>
> [09:36:38,509][ERROR][ignite-#13%pub-null%][GridCacheSemaphoreImpl]
>  Failed to compare and set:
> o.a.i.i.processors.datastructures.GridCacheSemaphoreImpl$Sync$1@5528b728
> class org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> Failed to acquire lock for keys (primary node left grid, retry transaction
> if possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl
> [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
> node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
> ...
> Caused by: class
> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException: Failed
> to acquire lock for keys (primary node left grid, retry transaction if
> possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl
> [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
> node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
> at
>
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.newTopologyException(GridDhtColocatedLockFuture.java:1199)
> ... 10 more
>
>
> I'm still trying to find out how to exactly reproduce this behavior,
> I'll send you more details once I try few more things.
>
> I am still using partitioned cache, does it make sense to use replicated
> cache instead?
>
>
> Other than that, I'm done with everything else.
>
> Thanks,
> Vladisav
>
>

[jira] [Created] (IGNITE-1936) implement spa abilities to web-console

[Dmitriyff (JIRA)]

Dmitriyff created IGNITE-1936:
-

 Summary: implement spa abilities to web-console
 Key: IGNITE-1936
 URL: https://issues.apache.org/jira/browse/IGNITE-1936
 Project: Ignite
  Issue Type: Sub-task
Affects Versions: 1.6
Reporter: Dmitriyff
Assignee: Dmitriyff
 Fix For: 1.6






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

Re: about apache ignite's document localization(Simplified Chinese)

[李玉珏]

Hi：

I had hoped that I would finish the translation work, because the 
workload is not particularly great.


The reason to put the code on git.oschina.net, in addition to some of my 
personal information (such as blogs) are placed on the oschina.net, the 
main reason is that I want to put the final HTML on there, configuration 
management functions are secondary. In fact, from the function of the 
code host, git.oschina.net is not as good as github.


I do not exclude everyone's cooperation, nor selfish, mainly in the 
private communication with Mr. Jiang, there are differences in working 
methods.I do this is part time, so I hope to avoid too much extra workload.


Since there are a lot of people in the community are interested in this, 
I intend to let go of the project fork permissions, in addition to those 
who want to participate in this project to join the developer list.


在 15/11/17 06:18, Dmitriy Setrakyan 写道:

I just got confirmation from oschina (it just took a while). My username is
“diset”, can you please add me to the project?

D.

On Mon, Nov 16, 2015 at 1:38 PM, Dmitriy Setrakyan 
wrote:


In general, it would be great if anyone in the community would be able to
contribute. Looks like oschina.net is a copy of GitHub. I tried to create
a user there, but could not (I am not getting a verification email). Any
ideas?

I think the best way to share this process would be to add users to the
GIT project on oschina (just like we do with readme.io).

D.


On Sun, Nov 15, 2015 at 4:37 AM, 姜 为  wrote:


Hi:

 I do not agree with Yujue Li,his approach is very selfish.
 At first I wanted to help him complete the Chinese translation of
the open-source project,
 but he can not be on the oschina fork, which means that if he
appeared wrong semantic translation,
 others can not make changes to the correction!

 I hope he can follow the spirit of open source, but not for
themselves to achieve certain purposes do such a thing!


在 2015年11月15日，上午10:19，李玉珏@163 <18624049...@163.com> 写道：

Hi:

On the Ignite Development Manual of the simplified chinese

localization, I have the first part of the 'basic concepts' translation is
completed, the second part of the 'cluster' has been translated, the
content is being carried out.

Some people suggest that I translate directly on the readme.io,

because I'm here to visit the readme.io speed is slower, and the other
readme uses a hybrid online editing mode, for the consideration of the
translation speed, I use pure markdown to write. In view of the effect of
readme.io is better, but I have limited time, if there is a volunteer in
the community will be willing to convert pure markdown to readme, and help
me do the translation of the audit, will be a very good thing.

If no one is willing to do this more tedious work, I plan to convert

pure markdown to html, like mail attachments, and then the official put a
link to my page is OK.

在 15/11/9 15:29, Dmitriy Setrakyan 写道:

On Sun, Nov 8, 2015 at 10:36 PM, 姜 为  wrote:


Hi Dmitriy:

 I create https://apacheignitecn.readme.io/docs <
https://apacheignitecn.readme.io/docs> for translate Chinese.


Thanks, I will add the link to Ignite website, once we have something

to

publish.



 And http://apacheignite.readme.io/ <

http://apacheignite.readme.io/>

have plans to do international translate?


I don’t think readme.io supports this feature.





在 2015年11月8日，下午5:38，Dmitriy Setrakyan  写道：

On Sat, Nov 7, 2015 at 6:30 PM, 李玉珏@163 <18624049...@163.com> wrote:


Hi：

I have registered the readme.io account, and I know how to use it

in

general.
I asked, the Suggest Edits will be effective or need a review

process

after the submission?


The committers will review the edits.



In addition, I now know about Ignite is not deep enough, I'm afraid

I

can

only modify some obvious mistakes.


This is OK, any improvement to the documentation helps.



在 15/11/7 17:04, Dmitriy Setrakyan 写道:

Hi,

I agree that documentation may be inconsistent in some places. Can

you

use

the “Suggest Edits” feature of readme.io to provide the fixes to
documentation?

D.

On Fri, Nov 6, 2015 at 4:06 AM, 李玉珏@163 <18624049...@163.com>

wrote:

Hi:

The speed of the problem may be related to the network situation

between

China and the United States, I am here very fast.
I am not very busy recently, so the speed of the translation of

these

days
is very fast, and it is expected that the next week will be

related to

the
cluster will be translated, and then into the translation of data

grid.

In addition,In the translation process, I found that some parts

of the

document is clearly wrong, mainly in the description of some
configuration
parameters, and the code does not match, for example, in the end

of

the

chapter of the cluster configuration, the parameters of the
TcpDiscoverySpi, some obvious 

Request access

[Corey Pentasuglia]

Good morning,


I would like to request access to Jira and also be added to the dev mail list.


Thanks!


Corey Pentasuglia
Software Engineer &
Graduate Student
Blog: rdquest.com
rdqu...@outlook.com

[jira] [Created] (IGNITE-1934) .Net: Store tests broken after keepPortableInStore renaming

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1934:
---

 Summary: .Net: Store tests broken after keepPortableInStore 
renaming
 Key: IGNITE-1934
 URL: https://issues.apache.org/jira/browse/IGNITE-1934
 Project: Ignite
  Issue Type: Bug
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
Assignee: Pavel  Tupitsyn
Priority: Blocker
 Fix For: 1.5


Need to fix .net test configs



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

Contribution merged: IGNITE-1865 Need to add tests on SpringResource annotation

[Denis Magda]

Roman,

Thanks a lot for the contribution! Your changes merged to the release 
branch and will be a part of the upcoming release.


Regards,
Denis

Re: Ignite-1.5 Release

[Vladimir Ozerov]

Folks,

I continue working on IGNITE-1917 - marshalling microoptimizations. I did a
bunch of things today which increased performance a bit, so that
unmarshalling with PortableMarshaller is now a bit faster than
OptimizedMarshaller when object has several fields, but still slower when
there are lots of small fields.

I'm going to apply the last easy optimization in the nearest time and then
will focus on merging all pending tickets to master. Once all important
things are merged, I'm going to spend some more efforts on performance
again.

On Tue, Nov 17, 2015 at 8:30 PM, Vladisav Jelisavcic 
wrote:

> Hi Yakov,
> 1. Yes
>
> 2. if you mean that nodeMap is accessed in onNodeRemoved(UUID nodeID)
> method of the GridCacheSemaphoreImpl class,
> it shouldn't be a problem, but it can be changed easily not to do so;
>
> 3.
>
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantTopologyChangeFailoverSafe()
>
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantMultipleTopologyChangeFailoverSafe()
>
> I think the problem is with the atomicity of the simulated grid failure;
> once stopGrid() is called for a node, other threads on this same node start
> throwing interrupted exceptions,
> which are in turn not handled properly in the
> GridCacheAbstractDataStructuresFailoverSelfTest;
> Those exceptions shouldn't be dealt with inside the GridCacheSemaphoreImpl
> itself.
> In a realworld node failure scenario, all those threads would fail at the
> same time
> (none of them would influence the rest of the grid anymore);
>
> I think fixing the issue Denis is working on can fix this (IGNITE-801 and
> IGNITE-803)
> Am i right? Does it makes sense?
>
>
> Best regards,
> Vladisav
>
>
>
>
> On Tue, Nov 17, 2015 at 5:40 PM, Yakov Zhdanov 
> wrote:
>
> > Vladislav,
> >
> > I started to review the latest changes and have couple of questions:
> >
> > 1. latest changes are here - https://github.com/apache/ignite/pull/120?
> Is
> > that correct?
> > 2.
> >
> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.Sync#nodeMap
> > is accessed in both sync and unsync context. Are you sure this is fine.
> > 3. As far as failing test - can you please isolate it into separate junit
> > or point out existing one?
> >
> > --Yakov
> >
> > 2015-11-11 12:33 GMT+03:00 Vladisav Jelisavcic :
> >
> > > Yakov,
> > >
> > > sorry  for running a bit late.
> > >
> > > > Vladislav, do you have any updates for
> > > > https://issues.apache.org/jira/browse/IGNITE-638? Or any questions?
> > > >
> > > > --Yakov
> > >
> > > I have problems with some fail-over scenarios;
> > > It seems that if the two nodes are in the middle of acquiring or
> > releasing
> > > the semaphore,
> > > and one of them fails, all nodes get:
> > >
> > > [09:36:38,509][ERROR][ignite-#13%pub-null%][GridCacheSemaphoreImpl]
> > >  Failed to compare and set:
> > >
> o.a.i.i.processors.datastructures.GridCacheSemaphoreImpl$Sync$1@5528b728
> > > class
> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> > > Failed to acquire lock for keys (primary node left grid, retry
> > transaction
> > > if possible) [keys=[UserKeyCacheObjectImpl
> [val=GridCacheInternalKeyImpl
> > > [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
> > > node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
> > > ...
> > > Caused by: class
> > > org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
> > Failed
> > > to acquire lock for keys (primary node left grid, retry transaction if
> > > possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl
> > > [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
> > > node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
> > > at
> > >
> > >
> >
> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.newTopologyException(GridDhtColocatedLockFuture.java:1199)
> > > ... 10 more
> > >
> > >
> > > I'm still trying to find out how to exactly reproduce this behavior,
> > > I'll send you more details once I try few more things.
> > >
> > > I am still using partitioned cache, does it make sense to use
> replicated
> > > cache instead?
> > >
> > >
> > > Other than that, I'm done with everything else.
> > >
> > > Thanks,
> > > Vladisav
> > >
> > >
> >
>

Re: Ignite-1.5 Release

[Vladimir Ozerov]

I meant "release branch", not "master".

On Tue, Nov 17, 2015 at 9:25 PM, Vladimir Ozerov 
wrote:

> Folks,
>
> I continue working on IGNITE-1917 - marshalling microoptimizations. I did
> a bunch of things today which increased performance a bit, so that
> unmarshalling with PortableMarshaller is now a bit faster than
> OptimizedMarshaller when object has several fields, but still slower when
> there are lots of small fields.
>
> I'm going to apply the last easy optimization in the nearest time and then
> will focus on merging all pending tickets to master. Once all important
> things are merged, I'm going to spend some more efforts on performance
> again.
>
> On Tue, Nov 17, 2015 at 8:30 PM, Vladisav Jelisavcic 
> wrote:
>
>> Hi Yakov,
>> 1. Yes
>>
>> 2. if you mean that nodeMap is accessed in onNodeRemoved(UUID nodeID)
>> method of the GridCacheSemaphoreImpl class,
>> it shouldn't be a problem, but it can be changed easily not to do so;
>>
>> 3.
>>
>> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantTopologyChangeFailoverSafe()
>>
>> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantMultipleTopologyChangeFailoverSafe()
>>
>> I think the problem is with the atomicity of the simulated grid failure;
>> once stopGrid() is called for a node, other threads on this same node
>> start
>> throwing interrupted exceptions,
>> which are in turn not handled properly in the
>> GridCacheAbstractDataStructuresFailoverSelfTest;
>> Those exceptions shouldn't be dealt with inside the GridCacheSemaphoreImpl
>> itself.
>> In a realworld node failure scenario, all those threads would fail at the
>> same time
>> (none of them would influence the rest of the grid anymore);
>>
>> I think fixing the issue Denis is working on can fix this (IGNITE-801 and
>> IGNITE-803)
>> Am i right? Does it makes sense?
>>
>>
>> Best regards,
>> Vladisav
>>
>>
>>
>>
>> On Tue, Nov 17, 2015 at 5:40 PM, Yakov Zhdanov 
>> wrote:
>>
>> > Vladislav,
>> >
>> > I started to review the latest changes and have couple of questions:
>> >
>> > 1. latest changes are here - https://github.com/apache/ignite/pull/120?
>> Is
>> > that correct?
>> > 2.
>> >
>> org.apache.ignite.internal.processors.datastructures.GridCacheSemaphoreImpl.Sync#nodeMap
>> > is accessed in both sync and unsync context. Are you sure this is fine.
>> > 3. As far as failing test - can you please isolate it into separate
>> junit
>> > or point out existing one?
>> >
>> > --Yakov
>> >
>> > 2015-11-11 12:33 GMT+03:00 Vladisav Jelisavcic :
>> >
>> > > Yakov,
>> > >
>> > > sorry  for running a bit late.
>> > >
>> > > > Vladislav, do you have any updates for
>> > > > https://issues.apache.org/jira/browse/IGNITE-638? Or any questions?
>> > > >
>> > > > --Yakov
>> > >
>> > > I have problems with some fail-over scenarios;
>> > > It seems that if the two nodes are in the middle of acquiring or
>> > releasing
>> > > the semaphore,
>> > > and one of them fails, all nodes get:
>> > >
>> > > [09:36:38,509][ERROR][ignite-#13%pub-null%][GridCacheSemaphoreImpl]
>> > >  Failed to compare and set:
>> > >
>> o.a.i.i.processors.datastructures.GridCacheSemaphoreImpl$Sync$1@5528b728
>> > > class
>> org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
>> > > Failed to acquire lock for keys (primary node left grid, retry
>> > transaction
>> > > if possible) [keys=[UserKeyCacheObjectImpl
>> [val=GridCacheInternalKeyImpl
>> > > [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
>> > > node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
>> > > ...
>> > > Caused by: class
>> > > org.apache.ignite.internal.cluster.ClusterTopologyCheckedException:
>> > Failed
>> > > to acquire lock for keys (primary node left grid, retry transaction if
>> > > possible) [keys=[UserKeyCacheObjectImpl [val=GridCacheInternalKeyImpl
>> > > [name=ac83b8cb-3052-49a6-9301-81b20b0ecf3a], hasValBytes=true]],
>> > > node=c321fcc4-5db5-4b03-9811-6a5587f2c253]
>> > > at
>> > >
>> > >
>> >
>> org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedLockFuture.newTopologyException(GridDhtColocatedLockFuture.java:1199)
>> > > ... 10 more
>> > >
>> > >
>> > > I'm still trying to find out how to exactly reproduce this behavior,
>> > > I'll send you more details once I try few more things.
>> > >
>> > > I am still using partitioned cache, does it make sense to use
>> replicated
>> > > cache instead?
>> > >
>> > >
>> > > Other than that, I'm done with everything else.
>> > >
>> > > Thanks,
>> > > Vladisav
>> > >
>> > >
>> >
>>
>
>

[jira] [Created] (IGNITE-1937) ignite-flume module

[Sergey Kozlov (JIRA)]

Sergey Kozlov created IGNITE-1937:
-

 Summary: ignite-flume module
 Key: IGNITE-1937
 URL: https://issues.apache.org/jira/browse/IGNITE-1937
 Project: Ignite
  Issue Type: Bug
Affects Versions: 1.5
Reporter: Sergey Kozlov
Assignee: Yakov Zhdanov
 Fix For: 1.5


Ignite flume should have following:
 - added as an optional module for binary fabric package
 - uploaded on maven repository
 - README.TXT 



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

Re: Ignite-1.5 Release

[Yakov Zhdanov]

1. Understood
2. Well, I understand that object gets deserialized on get from cache and
this most probably should not cause any issue. However, code does not look
healthy and someone may think that there is an issue - field is not
volatile, initialized in constructor, has sync setter, but is accessed
several times in code outside of sync. Can you please refactor this?
3. Yes, Denis is looking into this. And I think your issue will be fixed in
the scope of Denis one.

Vlad, can you please refactor [2] and I will pick it up and merge tomorrow.

Thank you for your interest and contribution!

--Yakov

2015-11-17 21:30 GMT+04:00 Vladisav Jelisavcic :

> Hi Yakov,
> 1. Yes
>
> 2. if you mean that nodeMap is accessed in onNodeRemoved(UUID nodeID)
> method of the GridCacheSemaphoreImpl class,
> it shouldn't be a problem, but it can be changed easily not to do so;
>
> 3.
>
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantTopologyChangeFailoverSafe()
>
> org.apache.ignite.internal.processors.cache.datastructures.GridCacheAbstractDataStructuresFailoverSelfTest#testSemaphoreConstantMultipleTopologyChangeFailoverSafe()
>
> I think the problem is with the atomicity of the simulated grid failure;
> once stopGrid() is called for a node, other threads on this same node start
> throwing interrupted exceptions,
> which are in turn not handled properly in the
> GridCacheAbstractDataStructuresFailoverSelfTest;
> Those exceptions shouldn't be dealt with inside the GridCacheSemaphoreImpl
> itself.
> In a realworld node failure scenario, all those threads would fail at the
> same time
> (none of them would influence the rest of the grid anymore);
>
> I think fixing the issue Denis is working on can fix this (IGNITE-801 and
> IGNITE-803)
> Am i right? Does it makes sense?
>
>
> Best regards,
> Vladisav
>
>

Re: Ignite-1.5 Release

[Roman Shtykh]

11. Flume intergration
https://issues.apache.org/jira/browse/IGNITE-529


is done too. Thanks Anton for reviews!

Roman




On Monday, November 2, 2015 10:35 PM, Yakov Zhdanov  wrote:



Guys,

I think we can start preparation to Ignite-1.5 release which will include
many interesting features:

1. Portable object API
https://issues.apache.org/jira/browse/IGNITE-1486

2. Ignite.NET and Ignite C++
https://issues.apache.org/jira/browse/IGNITE-1282

3. Optimistic serializable transactions
https://issues.apache.org/jira/browse/IGNITE-1607

4. Distributed SQL joins - we will be able to query non-collocated data as
well
https://issues.apache.org/jira/browse/IGNITE-1232

5. Enhanced Oracle and IBM JDK interoperability
https://issues.apache.org/jira/browse/IGNITE-1526

6. MQTT streamer
https://issues.apache.org/jira/browse/IGNITE-535

7. Continuous query failover
https://issues.apache.org/jira/browse/IGNITE-426

8. Significant transactional cache performance optimizations - I will merge
these changes from 'ignite-1.4-slow-server-debug' today or tomorrow.

9. Many stability and fault-tolerance fixes.

10. I would also like to include distributed Semaphore. Vladislav, any
chance you can finish with it this week?
https://issues.apache.org/jira/browse/IGNITE-
638

Thanks to everyone involved! Guys, esp. assignees of mentioned issues,
please respond to this email and let us know when can we expect your
changes being merged to master and release branch?

Can someone create ignite-1.5 release branch?

--Yakov

Re: about apache ignite's document localization(Simplified Chinese)

[Dmitriy Setrakyan]

Thanks Yujue Li! We really appreciate the work you are doing.

As far as permissions go, is it possible to add users to the project, much
in the same way as in GitHub? Another way to suggest documentation fixes
could be to file issues in the oschina git (looks like it supports issues
in the same way as GitHub).

D.

On Tue, Nov 17, 2015 at 4:47 AM, 李玉珏@163 <18624049...@163.com> wrote:

> Hi：
>
> I had hoped that I would finish the translation work, because the workload
> is not particularly great.
>
> The reason to put the code on git.oschina.net, in addition to some of my
> personal information (such as blogs) are placed on the oschina.net, the
> main reason is that I want to put the final HTML on there, configuration
> management functions are secondary. In fact, from the function of the code
> host, git.oschina.net is not as good as github.
>
> I do not exclude everyone's cooperation, nor selfish, mainly in the
> private communication with Mr. Jiang, there are differences in working
> methods.I do this is part time, so I hope to avoid too much extra workload.
>
> Since there are a lot of people in the community are interested in this, I
> intend to let go of the project fork permissions, in addition to those who
> want to participate in this project to join the developer list.
>
> 在 15/11/17 06:18, Dmitriy Setrakyan 写道:
>
> I just got confirmation from oschina (it just took a while). My username is
>> “diset”, can you please add me to the project?
>>
>> D.
>>
>> On Mon, Nov 16, 2015 at 1:38 PM, Dmitriy Setrakyan > >
>> wrote:
>>
>> In general, it would be great if anyone in the community would be able to
>>> contribute. Looks like oschina.net is a copy of GitHub. I tried to
>>> create
>>> a user there, but could not (I am not getting a verification email). Any
>>> ideas?
>>>
>>> I think the best way to share this process would be to add users to the
>>> GIT project on oschina (just like we do with readme.io).
>>>
>>> D.
>>>
>>>
>>> On Sun, Nov 15, 2015 at 4:37 AM, 姜 为  wrote:
>>>
>>> Hi:

  I do not agree with Yujue Li,his approach is very selfish.
  At first I wanted to help him complete the Chinese translation
 of
 the open-source project,
  but he can not be on the oschina fork, which means that if he
 appeared wrong semantic translation,
  others can not make changes to the correction!

  I hope he can follow the spirit of open source, but not for
 themselves to achieve certain purposes do such a thing!

 在 2015年11月15日，上午10:19，李玉珏@163 <18624049...@163.com> 写道：
>
> Hi:
>
> On the Ignite Development Manual of the simplified chinese
>
 localization, I have the first part of the 'basic concepts' translation
 is
 completed, the second part of the 'cluster' has been translated, the
 content is being carried out.

> Some people suggest that I translate directly on the readme.io,
>
 because I'm here to visit the readme.io speed is slower, and the other
 readme uses a hybrid online editing mode, for the consideration of the
 translation speed, I use pure markdown to write. In view of the effect
 of
 readme.io is better, but I have limited time, if there is a volunteer
 in
 the community will be willing to convert pure markdown to readme, and
 help
 me do the translation of the audit, will be a very good thing.

> If no one is willing to do this more tedious work, I plan to convert
>
 pure markdown to html, like mail attachments, and then the official put
 a
 link to my page is OK.

> 在 15/11/9 15:29, Dmitriy Setrakyan 写道:
>
>> On Sun, Nov 8, 2015 at 10:36 PM, 姜 为  wrote:
>>
>> Hi Dmitriy:
>>>
>>>  I create https://apacheignitecn.readme.io/docs <
>>> https://apacheignitecn.readme.io/docs> for translate Chinese.
>>>
>>> Thanks, I will add the link to Ignite website, once we have something
>>
> to

> publish.
>>
>>
>>  And http://apacheignite.readme.io/ <
>>>
>> http://apacheignite.readme.io/>

> have plans to do international translate?
>>>
>>> I don’t think readme.io supports this feature.
>>
>>
>>
>>> 在 2015年11月8日，下午5:38，Dmitriy Setrakyan  写道：

 On Sat, Nov 7, 2015 at 6:30 PM, 李玉珏@163 <18624049...@163.com>
 wrote:

 Hi：
>
> I have registered the readme.io account, and I know how to use it
>
 in

> general.
> I asked, the Suggest Edits will be effective or need a review
>
 process

> after the submission?
>
> The committers will review the edits.


 In addition, I now know about Ignite is not deep enough, I'm afraid
>
 I

> 

[jira] [Created] (IGNITE-1938) NullPointerException/IllegalMonitorStateException under IBM SDK 8

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-1938:
---

 Summary: NullPointerException/IllegalMonitorStateException under 
IBM SDK 8
 Key: IGNITE-1938
 URL: https://issues.apache.org/jira/browse/IGNITE-1938
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Gura
Assignee: Andrey Gura


{noformat}
[22:16:11,241][ERROR][main][GridDhtAtomicCache]  Unexpected 
exception during cache update
java.lang.NullPointerException
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.lockEntries(GridDhtAtomicCache.java:2161)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1100)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1060)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapSingle(GridNearAtomicUpdateFuture.java:462)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.access$1200(GridNearAtomicUpdateFuture.java:73)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.map(GridNearAtomicUpdateFuture.java:891)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:422)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:291)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$14.apply(GridDhtAtomicCache.java:841)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$14.apply(GridDhtAtomicCache.java:839)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:645)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsync0(GridDhtAtomicCache.java:839)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAsync0(GridDhtAtomicCache.java:378)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.putAsync(GridCacheAdapter.java:2218)
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put(GridDhtAtomicCache.java:354)
at 
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:1924)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1017)
at 
org.apache.ignite.examples.datagrid.CachePutGetExample.putGet(CachePutGetExample.java:72)
at 
org.apache.ignite.examples.datagrid.CachePutGetExample.main(CachePutGetExample.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
{noformat}

{noformat}
Exception in thread "main" org.apache.ignite.cache.CachePartialUpdateException: 
Failed to update keys (retry update if possible).: [5372]
at 
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1615)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.cacheException(IgniteCacheProxy.java:1750)
at 
org.apache.ignite.internal.processors.cache.IgniteCacheProxy.put(IgniteCacheProxy.java:1024)
at 
org.apache.ignite.examples.datagrid.CachePutGetExample.putGet(CachePutGetExample.java:72)
at 
org.apache.ignite.examples.datagrid.CachePutGetExample.main(CachePutGetExample.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:507)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
Caused by: class 
org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException: 
Failed to update keys (retry update if possible).: [5372]
at 
org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture$UpdateState.addFailedKeys(GridNearAtomicUpdateFuture.java:1186)
at 

[jira] [Created] (IGNITE-1931) .Net: Store configuration

[Pavel Tupitsyn (JIRA)]

Pavel  Tupitsyn created IGNITE-1931:
---

 Summary: .Net: Store configuration
 Key: IGNITE-1931
 URL: https://issues.apache.org/jira/browse/IGNITE-1931
 Project: Ignite
  Issue Type: Sub-task
  Components: interop
Affects Versions: 1.1.4
Reporter: Pavel  Tupitsyn
 Fix For: 1.5


Configure store in .NET code



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

[GitHub] ignite pull request: IGNITE-1907 .Net: Cache configuration

[ptupitsyn]

GitHub user ptupitsyn opened a pull request:

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

IGNITE-1907 .Net: Cache configuration



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

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

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

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


commit 39a8bc65a3d8f20145153c614ca4e9746ce331d6
Author: Pavel Tupitsyn 
Date:   2015-11-16T13:40:03Z

IGNITE-1907 .Net: Cache configuration

commit c73d82dfe0e47d16fbfbb0a270d822bd9c8246db
Author: Pavel Tupitsyn 
Date:   2015-11-16T13:47:22Z

IGNITE-1907 .Net: Cache configuration

commit 5e94417d8946d1b92541e83869f14cb8fdc38da9
Author: Pavel Tupitsyn 
Date:   2015-11-16T13:54:51Z

wip

commit 5fce7a1247c4bc34789b8733b921ecfcb4cbdf64
Author: Pavel Tupitsyn 
Date:   2015-11-16T14:17:43Z

wip

commit a4e9c1da1c50dc1081dc97b3aa8eafdecf52fec2
Author: Pavel Tupitsyn 
Date:   2015-11-16T15:23:00Z

wip

commit ad0ff6eb90246c71bd7e7687f3855820e2a9621d
Author: Pavel Tupitsyn 
Date:   2015-11-16T15:29:28Z

wip

commit 1ceca1200fbb98b96c10c173c24d30d80712b94b
Author: Pavel Tupitsyn 
Date:   2015-11-16T15:35:59Z

unit test skeleton

commit 11ed6a55c9d6f1d6a6a77b9f9ecbece135402796
Author: Pavel Tupitsyn 
Date:   2015-11-16T15:41:51Z

wip GetConfiguration

commit 033c5e35d2304976cddd428ccf92e76e2eb039c1
Author: Pavel Tupitsyn 
Date:   2015-11-16T15:50:34Z

wip

commit 45938e6ff0cf0a51726bf82886f53d3f20bc8a9b
Author: Pavel Tupitsyn 
Date:   2015-11-16T15:52:02Z

wip test

commit 8bbb57919397f36697ea6d885418d0de92c02b02
Author: Pavel Tupitsyn 
Date:   2015-11-16T16:36:10Z

wip

commit 3fc284307f15e63c8d12e6a1a13c61f2a3b01ebc
Author: Pavel Tupitsyn 
Date:   2015-11-16T16:49:02Z

wip CacheConfiguration

commit 8a702577910b6d263c99b39c0bccbdd34a09aaf1
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:08:52Z

wip

commit 3bde86ddc3f81b767c8718673b6f8e0c7a89ddcb
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:12:38Z

wip

commit 3960e0aee4c36b6f47181bf79fbd7eb962ae7344
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:16:50Z

wip enums

commit c80dfc80379c3c2640ec2dcf36494112d4bdcd94
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:20:08Z

wip enums

commit 17fb91293a5569f4d0bc924008f7fabbfff2eb73
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:28:34Z

wip enums

commit b74e4c705843d3e9822fcbf2415ae0666b9a8ec5
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:32:58Z

enums done

commit 58f0611a519fd2c82d0af8329145089726deea51
Author: Pavel Tupitsyn 
Date:   2015-11-17T07:59:41Z

wip default values

commit 6d4c3deb39d18ad5a01a74da37acc464fb2889fc
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:09:56Z

Default values done

commit c23078a52683d998e2f5265fa511600418de8dfa
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:13:37Z

cleanup wip

commit 27f12b17c6e00eb1125b1b7ce0fb2025e096b337
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:22:29Z

wip docs

commit 88f52a6ff309f03934bdb4f5da558d9eb8155965
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:32:20Z

Docs done

commit e8ad49508b93ce50dde1f4bfcfe1c19890588c82
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:38:22Z

Timespans instead of milliseconds

commit b2a2382c2fed12ca0ee3e456d4b8f46a4766963c
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:45:19Z

Read from stream

commit 6fbe92cf73a13b856d89dce44bd5bbb5d7283f67
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:51:46Z

write to stream

commit 929477791e9acac41e3ac3d040d082ea8c1f88a9
Author: Pavel Tupitsyn 
Date:   2015-11-17T08:55:32Z

wip

commit e8fbf65080d06726681e753a1b7a446dcd861295
Author: Pavel Tupitsyn 
Date:   2015-11-17T09:02:39Z

wip

commit c89d43c0cd9e50f22ad69f4eb17c9e069f39bb92
Author: Pavel Tupitsyn 
Date:   2015-11-17T09:14:35Z

wip tests

commit 2a597c69eb3e444bf7b105fa2fc2d360e35e27f1
Author: Pavel Tupitsyn 
Date:   2015-11-17T09:18:45Z

Fix tests




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

[jira] [Created] (IGNITE-1932) Wrong value of BusyTimePercentage metric after ignite.cluster().resetMetrics()

[Alexey Kuznetsov (JIRA)]

Alexey Kuznetsov created IGNITE-1932:


 Summary: Wrong value of BusyTimePercentage metric after 
ignite.cluster().resetMetrics()
 Key: IGNITE-1932
 URL: https://issues.apache.org/jira/browse/IGNITE-1932
 Project: Ignite
  Issue Type: Bug
  Components: compute
Affects Versions: ignite-1.4
Reporter: Alexey Kuznetsov
Assignee: Alexey Kuznetsov
 Fix For: 1.5


I found that after call of
  ignite.cluster().resetMetrics()

BusyTimePercentage became 100% 

After some debug I found that BusyTimePercentage - calculated as:
1 - IdleTimePercentage 

and IdleTimePercentage  calculated as  IdleTime / UpTime

and on reset we set IdleTime to 0.

So the possible fix is to preserve IdleTime on reset.



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

Fwd: IGFS backed by persistence on physical filesystem

[Valentin Kulichenko]

Moving this discussion to the dev list.

As far as I know, IGFS stores data in blocks, so one file can be
distributed across nodes. So I don't see how each node can persist locally.
In my understanding it should be designated shared directory where all
files are persisted. This is actually analogous to how our persistence
store works for regular cache data.

Ivan, correct me if I'm wrong.

-Val

-- Forwarded message --
From: Ivan Veselovsky 
Date: Tue, Nov 17, 2015 at 11:48 AM
Subject: Re: IGFS backed by persistence on physical filesystem
To: u...@ignite.apache.org


Paolo Di Tommaso wrote
> What if you have multiple nodes in a cluster using
> org.apache.hadoop.fs.LocalFileSystem as a secondary file system? Each node
> saves the IGFS content locally?

In my understanding yes, each node that was requested to do the file
operation will store the file locally.


Paolo Di Tommaso wrote
> Could it be used to save the data over a NFS mount ?

LocalFileSystem runs over OS file system with "/" being the roott of the
file system, so if an NFS path is mounted , say, in /mnt/nfs/, the files
written under there will be shared. We may think about some kind of "chroot"
there to isolate the Ignite file system from other things.



--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/IGFS-backed-by-persistence-on-physical-filesystem-tp1882p1991.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.

Re: Request access

[Dmitriy Setrakyan]

Hi Corey,

Welcome to the Ignite community!

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

As far as adding you to Jira, you will need to create an account in Apache
Jira [1]. When you do, send your user name here and we will add you.

[1] https://issues.apache.org/jira

Thanks,
D.

On Tue, Nov 17, 2015 at 7:16 AM, Corey Pentasuglia 
wrote:

>
> Good morning,
>
>
> I would like to request access to Jira and also be added to the dev mail
> list.
>
>
> Thanks!
>
>
> Corey Pentasuglia
> Software Engineer &
> Graduate Student
> Blog: rdquest.com
> rdqu...@outlook.com
>