Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1167319

Summary:	Better documentation of state-transfer configuration and behaviour
Product:	[JBoss] JBoss Data Grid 6	Reporter:	wfink
Component:	Documentation	Assignee:	Rakesh <rghatvis>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.4.0	CC:	dberinde, jdg-bugs, mhusnain, rghatvis, tsykora, wfink
Target Milestone:	ER8	Flags:	wfink: needinfo+
Target Release:	6.4.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1168043 (view as bug list)		Environment:	Build Name: 12532, Administration and Configuration Guide-6.4 Beta Build Date: 18-11-2014 21:29:46 Topic IDs: 5792-710800 [Latest]
Last Closed:	2015-01-27 23:44:06 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:
Embargoed:
Bug Depends On:
Bug Blocks:	1168043

Description wfink 2014-11-24 13:06:44 UTC

Title: State Transfer

Describe the issue:
The documentation should describe that the "non-blocking state transfer" does not effect requests (null values) because as long as the ST is running the write works 'normal' but a read will do a remote read to retrive the value.

Also the chunk-size should be described whether can be >0 <=MAX_INT where MAX-INT means "transfer in once"
The chunk size depends on many parameters and it need to be measured what the best setting is.

Suggestions for improvement:
Add more information about behaviour and describe the different settings
- chunk-size
- fetch-in-memory
- fetch-persistent

Comment 3 wfink 2014-11-24 14:00:36 UTC

Description of the element in XSD seems wrong.
The chunk-size is always in number of entities and not byte's!

The default will be changed from 10,000 to 512 which seems better

a rule of thumb is 
- larger entities ==> smaller chunk
- smaller entitues ==> larger chunk

Comment 4 Misha H. Ali 2014-11-25 22:42:18 UTC

Thanks, wfink. Tristan or someone in his team will have to fix the xsd part so I'll log a bug copying your comment over in the other component. For this bug, we will work on the issues reported in comment #0.

Comment 5 Dan Berindei 2014-12-08 14:49:04 UTC

Perhaps it would be best not to mention Integer.MAX_VALUE at all, since it can cause OutOfMemoryErrors in the entry iterator:

https://issues.jboss.org/browse/ISPN-5027

Comment 6 Rakesh 2014-12-08 19:17:12 UTC

(In reply to Dan Berindei from comment #5)
> Perhaps it would be best not to mention Integer.MAX_VALUE at all, since it
> can cause OutOfMemoryErrors in the entry iterator:
> 
> https://issues.jboss.org/browse/ISPN-5027

Thanks Dan, duly noted.

Comment 8 Dan Berindei 2014-12-11 15:38:11 UTC

Wolf, "non-blocking state transfer" actually refers to state transfer blocking write operations on nodes that are already running, not to getCache() being blocking or not.

Comment 10 Dan Berindei 2014-12-15 09:03:33 UTC

Wolf, I'm not sure it's worth discussing which node's settings are actually used in the documentation.
I would expect both nodes to have the same state transfer/cache store configuration, especially since it's not possible to change the configuration without restarting the cache.

Comment 11 wfink 2014-12-23 17:38:46 UTC

For a

Comment 12 Misha H. Ali 2014-12-23 23:15:52 UTC

Moving release note text and flag to build bug here since we usually document the dev bug in release notes:

https://bugzilla.redhat.com/show_bug.cgi?id=1168043

Comment 15 wfink 2015-01-15 10:22:37 UTC

Rakesh,
so far so good. But for 7.6 and 8.4 we should add :

iv. 
The timeout parameter specifies the maximum time (in milliseconds) the cache waits for responses from neighboring caches with the requested states. If no response is received within the timeout period, the start up process aborts and an exception is thrown.

++
As a result of the failed ST the cache is not available on this instance!

Comment 17 wfink 2015-01-15 15:15:41 UTC

Looks good to me now!
Great thanks Rakesh

Comment 20 Tomas Sykora 2015-01-15 15:49:01 UTC

I am verifying that requested changes are in place.