[jira] [Created] (IGNITE-1618) [Test failed] TransactionHeuristicException: Failed to locally write to cache

[Andrey Gura (JIRA)]

Andrey Gura created IGNITE-1618:
---

 Summary: [Test failed] TransactionHeuristicException: Failed to 
locally write to cache
 Key: IGNITE-1618
 URL: https://issues.apache.org/jira/browse/IGNITE-1618
 Project: Ignite
  Issue Type: Bug
Affects Versions: ignite-1.4
Reporter: Andrey Gura


The following test fail:

  * {{GridCacheDeploymentOffHeapSelfTest.testDeployment}}
  * {{GridCacheDeploymentOffHeapSelfTest.testDeployment6}}
  * {{GridCacheDeploymentOffHeapSelfTest.testDeployment7}}

The stack trace:

{noformat}
org.apache.ignite.IgniteException: class 
org.apache.ignite.transactions.TransactionHeuristicException: Failed to locally 
write to cache (all transaction entries will be invalidated, however there was 
a window when entries for this transaction were visible to others): 
GridDhtTxLocal [nearNodeId=203fa7b5-ee81-4cf2-8671-d61284b4d002, 
nearFutId=c5e88ca3051-87e59273-3dfd-4d87-a40c-dfe902c4bbc9, 
nearMiniId=d5e88ca3051-87e59273-3dfd-4d87-a40c-dfe902c4bbc9, 
nearFinFutId=46e88ca3051-87e59273-3dfd-4d87-a40c-dfe902c4bbc9, 
nearFinMiniId=b6e88ca3051-87e59273-3dfd-4d87-a40c-dfe902c4bbc9, 
nearXidVer=GridCacheVersion [topVer=55541037, nodeOrderDrId=2, 
globalTime=1444061036097, order=1444061035918], super=GridDhtTxLocalAdapter 
[dhtThreadId=33042, needsCompletedVers=true, nearOnOriginatingNode=true, 
nearNodes=[], dhtNodes=[100ca1fe-f561-4ddd-b6d9-88d7cf12e001], 
explicitLock=false, super=IgniteTxLocalAdapter [txMap={IgniteTxKey 
[key=KeyCacheObjectImpl [val=13, hasValBytes=true], cacheId=1]=IgniteTxEntry 
[key=KeyCacheObjectImpl [val=13, hasValBytes=true], cacheId=1, 
txKey=IgniteTxKey [key=KeyCacheObjectImpl [val=13, hasValBytes=true], 
cacheId=1], val=[op=CREATE, val=UserCacheObjectImpl 
[val=org.apache.ignite.tests.p2p.CacheDeploymentTestValue@6c8704b3, 
hasValBytes=true]], prevVal=[op=NOOP, val=null], entryProcessorsCol=null, 
entryProcessorCalcVal=null, ttl=-1, conflictExpireTime=-1, conflictVer=null, 
explicitVer=null, dhtVer=null, filters=[], filtersPassed=false, 
filtersSet=false, entry=GridDhtCacheEntry [rdrs=[], 
locPart=GridDhtLocalPartition [id=546, mapPubSize=1, 
rmvQueue=GridCircularBuffer [sizeMask=127, idxGen=0], state=OWNING, 
reservations=0, empty=false, createTime=10/05/2015 16:03:56, mapPubSize=1], 
super=GridDistributedCacheEntry [super=GridCacheMapEntry 
[key=KeyCacheObjectImpl [val=13, hasValBytes=true], val=null, 
startVer=1444061035921, ver=GridCacheVersion [topVer=55541037, nodeOrderDrId=2, 
globalTime=1444061036098, order=1444061035921], hash=462848615, 
extras=GridCacheMvccEntryExtras [mvcc=GridCacheMvcc 
[locs=[GridCacheMvccCandidate [nodeId=203fa7b5-ee81-4cf2-8671-d61284b4d002, 
ver=GridCacheVersion [topVer=55541037, nodeOrderDrId=2, 
globalTime=1444061036098, order=1444061035920], timeout=0, ts=1444061036094, 
threadId=33042, id=2544576, topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=0], reentry=null, otherNodeId=203fa7b5-ee81-4cf2-8671-d61284b4d002, 
otherVer=GridCacheVersion [topVer=55541037, nodeOrderDrId=2, 
globalTime=1444061036097, order=1444061035918], mappedDhtNodes=null, 
mappedNearNodes=null, ownerVer=null, key=KeyCacheObjectImpl [val=13, 
hasValBytes=true], 
masks=local=1|owner=1|ready=1|reentry=0|used=0|tx=1|single_implicit=1|dht_local=1|near_local=0|removed=0,
 prevVer=null, nextVer=null]], rmts=null]], flags=0]]], prepared=true, 
locked=false, nodeId=null, locMapped=false, expiryPlc=null, 
transferExpiryPlc=false, flags=0, xidVer=null]}, completedBase=null, 
sndTransformedVals=false, super=IgniteTxAdapter [xidVer=GridCacheVersion 
[topVer=55541037, nodeOrderDrId=2, globalTime=1444061036098, 
order=1444061035920], writeVer=GridCacheVersion [topVer=55541037, 
nodeOrderDrId=2, globalTime=1444061036098, order=1444061035922], implicit=true, 
implicitSingle=true, loc=true, threadId=33042, startTime=1444061036094, 
nodeId=203fa7b5-ee81-4cf2-8671-d61284b4d002, startVer=GridCacheVersion 
[topVer=55541037, nodeOrderDrId=2, globalTime=1444061036098, 
order=1444061035920], endVer=null, isolation=READ_COMMITTED, 
concurrency=OPTIMISTIC, timeout=0, sysInvalidate=false, sys=false, plc=2, 
commitVer=null, finalizing=USER_FINISH, preparing=false, invalidParts={}, 
state=COMMITTING, timedOut=false, topVer=AffinityTopologyVersion [topVer=2, 
minorTopVer=0], duration=10ms, onePhaseCommit=true], size=1]]]
at 
org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:881)
at 
org.apache.ignite.internal.IgniteComputeImpl.execute(IgniteComputeImpl.java:174)
at 
org.apache.ignite.internal.processors.cache.GridCacheDeploymentSelfTest.testDeployment6(GridCacheDeploymentSelfTest.java:344)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

Re: 'How to Contribute' wiki page updated.

[Dmitriy Setrakyan]

Thanks, Anton!

I think the whole process looks too big right now. Perhaps we can make the
following changes:

   - Remove "Development Process" section (not sure if it applies to us).
   - Remove "Git Workflow" section as it is described already in "Workflow"
   section.
   - Remove "Git Branches" section
   - "Release Process" section should be a numbered list describing steps
   (including QA branch) necessary to create a release.
   - For the ticket branch section, I don't think it is clear how to submit
   a branch for review or how to apply changes on master. Would be nice if you
   could clarify.
   - I would add Continuous Integration section with URL to TeamCity. It
   should also state that merges to master should only happen after the whole
   TC suite passes.

Raul, it would be nice if you could also take a look and provide comments.

Thanks,
D.

On Mon, Oct 5, 2015 at 7:36 AM, Anton Vinogradov  wrote:

> Igniters,
>
> https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute page
> updated.
>
> Changes:
> 1) Jira process and Git process becomes part of How to Contribute
> .
> 2) Added 'Ticket Branch' case (only for committers).
> 3) Fixed minor issues.
>
> It will be nice if someone check correctness.
>

[GitHub] ignite pull request: [Ignite-429] Implement IgniteStormStreamer to...

[chandresh-pancholi]

GitHub user chandresh-pancholi opened a pull request:

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

[Ignite-429] Implement IgniteStormStreamer to stream data from Apache Storm

I have made some refactor changes suggested by Gian/Anton.



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

$ git pull https://github.com/chandresh-pancholi/ignite master

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

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


commit 8420e109c4d07bbf438f17dc79268c39b47e76b2
Author: chandresh pancholi 
Date:   2015-09-15T12:50:30Z

ignite-429 feature fix

commit a5adeb4c7badd52dd7724fa5a9a9ba7924e934ed
Author: chandresh pancholi 
Date:   2015-09-16T13:19:37Z

Ignite code refactor and modification

commit c6335046a07d9859a46d078e6cd8d7d2a7011df2
Author: chandresh pancholi 
Date:   2015-09-21T11:59:24Z

Code refactor

commit 4596bedfbfc756d3974b4d2270401515fa618bb5
Author: chandresh pancholi 
Date:   2015-09-28T09:12:13Z

Work completed

commit 538986b186b3d89797a34fe35c8120fecaf9
Author: chandresh pancholi 
Date:   2015-09-29T11:37:17Z

Apache ignite-storm integration

commit 3f40de788e5a050bbefb69ac2517a625e72b5299
Author: chandresh pancholi 
Date:   2015-09-29T11:37:50Z

exclusion of zookeeper

commit aa59cdade93d41d877b1966c4851aa827981b73c
Author: chandresh pancholi 
Date:   2015-10-03T12:13:18Z

Implemented Refactor suggestion given by Anton in Ignite0429

commit 2e103b915ba88b38604030092f55ed1f04b14cfe
Author: chandresh pancholi 
Date:   2015-10-05T07:43:02Z

Code refactor in storm module suggested by Gian/Anton




---
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-1615) .Net: Perform AtomicLong.get() without JNI if possible.

[Vladimir Ozerov (JIRA)]

Vladimir Ozerov created IGNITE-1615:
---

 Summary: .Net: Perform AtomicLong.get() without JNI if possible.
 Key: IGNITE-1615
 URL: https://issues.apache.org/jira/browse/IGNITE-1615
 Project: Ignite
  Issue Type: Task
  Components: interop
Affects Versions: ignite-1.4
Reporter: Vladimir Ozerov
 Fix For: ignite-1.5


Variables with atomic/interlocked semantics are frequently used in mostly-read 
scenarios. E.g. in spin-loops, non-blocking alogrithms, as regular volatiles, 
etc..

With current implementation we perform JNI call on every read which is too 
expensive, especially with poor Java performance when performing (native -> 
JVM) transition.

We can optimize it with the following non-blocking algorithm:
1) Add atomic "stamp" field.
2) Add atomic "cached" field.
3) On any update:
- Do the update;
- Atomically increment the stamp;
4) On any read:
- Read stamp (oldStamp);
- Read cached value;
- Read stamp again (newStamp);
- if (oldStamp == newStamp == cache.stamp()), return cached value.
- Otherwise perform real read through JNI and update cached value with a pair 
of (readValue + oldStamp);



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

Cluster group affinity

[Andrey Kornev]

Hello,

I have a user-defined cluster group and I'd like to be able to consistently 
pick the same node in the group for a given key. Essentially, what I want is a 
cluster group affinity that is not associated with any cache. How can I do it?

Thanks
Andrey
  

[GitHub] ignite pull request: IGNITE-1610: Implemented portable reader and ...

[isapego]

Github user isapego closed the pull request at:

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


---
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: Fwd: Coding Guidelines: zookeeper IP finder and mqtt streamer

[Branko Čibej]

On 29.09.2015 00:41, Konstantin Boudnik wrote:
> Hmm...
>
> Negligence, n. : the trait of neglecting responsibilities and lacking concern
> syn : omission, oversight

"Negligence" usually means continued and repeated (non-)action. In that
respect it's an extremely negative label to use; you're effectively
accusing someone of being an incompetent lazy b**rd.

The "synonyms" are not synonymous because both "omission" and
"oversight" imply a on-time event.


-- Brane


> Doesn't sound catastrophic in my vocabulary, really. Does this
>> case of negligence and needs to be addressed accordingly.
> translate to "should face a firing squad without a trial of his peers"?
> Have I anywhere pointed a finger at you or anyone else? Or attacked someone? 
> Why are you all upset and defensive about it?
>
> Cos
>
> On September 28, 2015 7:39:51 AM PDT, Raul Kripalani  wrote:
>> Cos, your language seems too harsh for the situation.
>>
>> No one here is committing negligence. The explanation is simple: people
>> aren't perfect.
>>
>> Now, let's take a step back and see the big picture. Around 95% of the
>> commits in this project are by GridGain personnel (check git shortlog
>> -s
>> -n) who have spent months/years working on this codebase during their
>> daily
>> job. Their eyes are accustomed to this code style and naturally they'll
>> spot oddities in a twitch. It's obvious.
>>
>> For newer people, we don't even have checkstyle nor decent facilities
>> for
>> newer people to spot formatting issues quickly. Because, surprise! The
>> issues that Yakov spotted are simply of formatting. The code is
>> functional
>> and much better tested than other streamers and IP Finders. Other
>> streamers
>> have 1 test, this streamer has 9 unit tests! Look at the code.
>> Furthermore,
>> Yakov seems to have made a mistake reading the Git commit history.
>> There
>> were never WIP commits on master.
>>
>> So may I ask you to stop using catastrophic vocabulary. The situation
>> is
>> not catastrophic, it's simply improvable.
>>
>> Now, as an ASF member, I ask you to recognise that unaffiliated
>> volunteers
>> like me bring diversity to the project that's otherwise dominated by a
>> company. You should appreciate that – more so given that you're a
>> former
>> mentor. I do this for the fun, and attacks like yours take the fun out
>> of
>> it. Have a look again at this project's team composition and, for those
>> people not affiliated to GridGain, try to find when their last commit
>> was... Then you'll see what I mean.
>>
>> P.S.: I did not merge the ZK IP Finder myself and I'm assuming that
>> Valentin will want to comment.
>>
>> Regards,
>>
>> *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
>>
>> On Mon, Sep 28, 2015 at 1:53 PM, Konstantin Boudnik 
>> wrote:
>>
>>> Are these official guidelines that are worked-out and communicated by
>>> community? Basically, were they made clear when the project went on
>> the CTR
>>> model? I presume it is/was looking at the wikipage. Hence
>> non-sticking
>>> to them is a case of negligence and needs to be addressed
>> accordingly.
>>> I would also want to highlight the other side of such negligence: by
>>> dumping
>>> semi-baked code to the master one creates a burden for the rest of
>> the
>>> community as the code degrades in quality, potentially breaks tests,
>> style
>>> checks, etc. And someone else needs to deal with it to unblock her's
>> future
>>> progress. And that's brings forward another point that Brane and I
>> were
>>> making on a few occasions: in the CTR communities you need to invite
>> in
>>> people
>>> with great deal of attention to how they work with others. Are they
>>> respecting
>>> others' time and effort? Are they good citizens of the community? And
>> on,
>>> and
>>> on.
>>>
>>> Another purely technically matter: master isn't a trash can. Master
>> should
>>> be
>>> close to releasable at any given point of time. WIP stuff doesn't
>> belong to
>>> master, that's what the dev and integration branches are for.
>>>
>>> Cos
>>>
>>> On Mon, Sep 28, 2015 at 03:31PM, Yakov Zhdanov wrote:
 Guys,

 I have just reviewed the code and have some comments. 1-2 are very
>>> serious
 from my point of view.

 1. Code is in master. Did anyone checked tests on TC? Moreover, are
>> there
 suites for those tests?
 2. It seems that work on streamer has been done directly in master.
>> I see
 WIP commits, but I think I should not. As agreed finished work
>> should be
 committed as a single set of changes.
 3. I see unused variable
 - org.apache.ignite.stream.mqtt.MqttStreamer#cachedLogPrefix
 4. Unused import - import com.google.common.base.Joiner;
 5. Code and javadocs lines exceed 120 chars restriction.
 6.