Bug 1167319 - Better documentation of state-transfer configuration and behaviour
Summary: Better documentation of state-transfer configuration and behaviour
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Documentation
Version: 6.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER8
: 6.4.0
Assignee: Rakesh
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1168043
TreeView+ depends on / blocked
 
Reported: 2014-11-24 13:06 UTC by wfink
Modified: 2015-01-27 23:44 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
: 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
Embargoed:
wfink: needinfo+


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.