Bug 1044957

Summary: QA Review: Admin Guide: Appendix B (References)
Product: [JBoss] JBoss Data Grid 6 Reporter: Tomas Sykora <tsykora>
Component: DocumentationAssignee: Rakesh <rghatvis>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.2.0CC: gsheldon, jdg-bugs, mhusnain
Target Milestone: GA   
Target Release: 6.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-01-16 00:02:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Tomas Sykora 2013-12-19 10:06:53 UTC
Hello, I went through it and would like to suggest some minor cosmetic changes, if possible.

B.2.
1. -- this is a strange sentence
"1. If Key K is hashed to nodes {A,B} and transaction TX1 acquires a lock for K on, for example, node A." --- then? what? I think I miss something here, maybe not.

Or 1. should be predecessor for point 2.? 
What is a source of these information about consistency guarantee? Any web page, ISPN internal DOC? Thank you!


B.4. About JSON -- not mentioned ever before in the documentation -- remove B.4 completely 


B.5. About RELAY2

This sentence -- The RELAY protocol bridges two remote clusters -- needs some introduction: "there is/exists also REALY protocol... which..." because this looks like a mistake. The first sentence is talking about RELAY2 and immediately after it is something about RELAY. Reader may be confused.


B.10.2. 

"The following is an example of the incorrect method to deal with this"

For me: "to deal with this" -- looks like a proposed solution, but it's not, this is the incorrect example. It may be little bit confusing.
Can it be introduced like: "This it the example of incorrect usage...." or smth like that? :) 

------

+ do we know the source of these information? I'm curious about source of consistency and c. guarantee and externalizers samples. (Need to look at it thoroughly and understand it a little bit better)

Thank you!

Comment 2 gsheldon 2013-12-19 23:17:22 UTC
(In reply to Tomas Sykora from comment #0)

> ------
> 
> + do we know the source of these information? I'm curious about source of
> consistency and c. guarantee and externalizers samples. (Need to look at it
> thoroughly and understand it a little bit better)

Hi Tomas,

This chapter is something I'm sure we've had since the beginning may have originally just been a Reference chapter of sorts.

Any changes you suggest we would be happy to accommodate.

I am assigning this bug to Bobb.

Comment 3 Tomas Sykora 2013-12-20 12:43:03 UTC
Suggesting some changes for B.2.:

Despite the locking of a single owner instead of all owners, Red Hat JBoss Data Grid's consistency guarantee remains intact. Let's (TODO: let's needs proper DOC wording) consider the following situation:

1) If Key K is hashed to nodes {A,B} and transaction TX1 acquires a lock for K on, for example, node A 
and
2) If another cache access occurs on node B, or any other node, and TX2 attempts to lock K

as a result, this access attempt fails with a timeout because the transaction TX1 already holds a lock on K. 

This lock acquisition attempt always fails because the lock for key K is always deterministically acquired on the same node of the cluster, irrespective of the transaction's origin.

Comment 7 Tomas Sykora 2014-01-08 10:16:34 UTC
Cool! Thanks for changes.

Absolutely last think I noticed:

B.2. About Consistency Guarantee, point 2:

 If another cache access occurs on node B, or any other node, and TX2 attempts to lock K, this access attempt fails with a timeout because the transaction TX2 already holds a lock on K. 

The second TX2 has to be TX1.

The completely correct point 2:

If another cache access occurs on node B, or any other node, and TX2 attempts to lock K, this access attempt fails with a timeout because the transaction TX1 already holds a lock on K. 

I will verify it once it is fixed.

(Short question here -- do we (QE) have write/modification access to docs? For case of small correction, so we don't need to bother you? Thanks!)

Comment 9 Misha H. Ali 2014-01-16 00:02:36 UTC
The fix for this bug is now generally released and available here:

https://access.redhat.com/site/documentation/en-US/Red_Hat_JBoss_Data_Grid/6.2/index.html