Bug 1032797 - Adding state-transfer To Infinispan Cache Via CLI Not Intuitive
Adding state-transfer To Infinispan Cache Via CLI Not Intuitive
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: CLI (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Joe Wertz
Petr Kremensky
Russell Dickenson
Depends On:
  Show dependency treegraph
Reported: 2013-11-20 16:05 EST by Jonathan Mason
Modified: 2016-01-04 00:08 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-07-29 08:03:04 EDT
Type: Enhancement
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jonathan Mason 2013-11-20 16:05:59 EST
Description of problem:

Adding state-transfer to Infinispan configuration via CLI is not very intuitive.

Version-Release number of selected component (if applicable): EAP 6

How reproducible:

Steps to Reproduce:
1. Start EAP 6 instance.

2. Access the CLI.

3. Attempt to add state-transfer within one of the Infinispan caches:  /subsystem=infinispan/cache-container=ejb/replicated-cache=repl/state-transfer=

Actual results:

Nothing happens. Usually tab completion gives some kind of indicatation as to what can/should be specified, but nothing occurs after "/../state-transfer=". One has to explicitly type the following: 


Expected results:

Tab completion would provide some kind of indication as to what can/should be specified when adding state-transfer.

Additional info:
Comment 1 Brian Stansberry 2013-11-21 16:21:29 EST
I was wrong reassigning this to Clustering. It's an enhancement request for the CLI tab completion function. The /subsystem=infinispan/cache-container=*/replicated-cache=* supports children of type "state-transfer" but children of that type do not allow any arbitrary child name. Rather, the valid names are declared in the /subsystem=infinispan/cache-container=ejb/replicated-cache=repl:read-resource-description(recursive=true) output.

    "outcome" => "success",
    "result" => {
        "children" => {
            "state-transfer" => {
                "description" => "The state transfer configuration for distribution and replicated caches.",
                "model-description" => {
                   "STATE_TRANSFER" => {

If arbitrary child names were supported, the "model-description" node would have a child named "*".

To satisfy this enhancement request, tab completion would have to recognize that "*" was not present and that specific child names are present, and then use those specific child names for tab completion.
Comment 3 Joe Wertz 2014-07-25 02:02:40 EDT
The problem here is caused by one of the steps along the address path not existing yet. Either the 'ejb' cache-container or the 'repl' replicated-cache is going to be created by this command, but is currently a non-existent entity.

The CLI uses ':read-child-names' to find possible values after an '=' in the address path, but that command fails because it requires all the nodes in the address to already exist.

If they do exist already, having been added by a previous command, the tab-complete works and fills in 'STATE-TRANSFER' successfully.

I'm not sure if that's a bug in the CLI tab-complete or in the ':read-child-names' operation. The ':read-child-types' operation can return successfully even with non-existent values in the address nodes, but I'm not sure if ':read-child-names' can, or should, be refactored to allow for that ability.
Comment 4 Brian Stansberry 2014-07-25 09:45:44 EDT
I don't think I want to change the behavior of :read-children-names. That can break people who assume the old behavior; i.e. that any value returned indicates an actual resource at that address.

The :read-resource-description output for the parent resource provides the needed data. I can see though why the tab completion isn't using that data, as it's quite a bit more verbose.

If we pursued this enhancement, the CLI might also need to change its behavior once the tab completion is done. That is, it should no longer provide further tab completion based on the existing assumption that the resource exists, since it does not. For example, if tab is hit after this:


the choice set should only include "add" and "read-resource-description" and perhaps some others. But "read-resource", "read-attribute", "write-attribute" etc would not be valid.

It's a can of worms and I'm not sure it's a good idea.
Comment 6 Petr Kremensky 2014-07-29 08:03:04 EDT
Closing this as per Brian's last comment.

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