6:35 a.m.
Dominik Pospisil created AS7-3692:
-------------------------------------
Summary: Management: jgroups add stack operation does not work
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Paul Ferraro
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1 p.m.
[
https://issues.jboss.org/browse/AS7-3692?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-3692:
------------------------------------------
The workaround here is to batch together the commands used to build the protocol stack:
{noformat}
[standalone@localhost:9999 /] batch
[standalone@localhost:9999 / #] /subsystem=jgroups/stack=fred:add()
#1 /subsystem=jgroups/stack=fred:add()
[standalone@localhost:9999 / #]
/subsystem=jgroups/stack=fred/transport=TRANSPORT:add(type=UDP)
#2 /subsystem=jgroups/stack=fred/transport=TRANSPORT:add(type=UDP)
[standalone@localhost:9999 / #] /subsystem=jgroups/stack=fred:add-protocol(type=MPING)
#3 /subsystem=jgroups/stack=fred:add-protocol(type=MPING)
[standalone@localhost:9999 / #] run-batch
The batch executed successfully.
{noformat}
Unlike a cache container or a cache which can just be add()'ed and has an extensive
system of defaults which make it a useable service straight away, an empty JGroups stack
is not useable and really needs to have a transport and a minimal set of protocols added
before it becomes useable as a group communication protocol. Consequently, although it is
not made explicit, the add command assumes that a useable stack configuration is present
for the command to succeed.
Some discussion needs to happen on whether or not we do provide a full set of defaults for
an empty add operation.
The error message here definitely needs to be improved to reflect the fact that batching
is required, certain protocol layers should be present, etc.
Management: jgroups add stack operation does not work
-----------------------------------------------------
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Richard Achmatowicz
Labels: eap6_prd_req
Fix For: 7.1.1.Final
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:15 p.m.
[
https://issues.jboss.org/browse/AS7-3692?page=com.atlassian.jira.plugin.s...
]
Brian Stansberry commented on AS7-3692:
---------------------------------------
This could be made better, perhaps, but IMHO it's not a critical issue.
Better == optional params to the top-level resource :add operation that provide the info
needed to build the child resources. Reduces things to one op.
In this specific case though that would be fairly useless, since a human would never type
such a command in the interactive CLI -- just too much data is needed.
They would end up using a script.
In which case, why not use the batch commands?
Management: jgroups add stack operation does not work
-----------------------------------------------------
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Richard Achmatowicz
Labels: eap6_prd_req
Fix For: 7.1.1.Final
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:14 a.m.
[
https://issues.jboss.org/browse/AS7-3692?page=com.atlassian.jira.plugin.s...
]
Dominik Pospisil commented on AS7-3692:
---------------------------------------
Thanks Richard, Brian.
Richard, is this documented somewhere? It would be great if it is as I don't think
that users will be able to figure this out easily using trial and error approach.
I am happy with batch commands. The only problem is consistency - seems that each
subsystem picked its own approach to manage complex resources. On the other hand,
customers will have a chance to learn something new all the time :)
Management: jgroups add stack operation does not work
-----------------------------------------------------
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Richard Achmatowicz
Labels: eap6_prd_req
Fix For: 7.1.1.Final
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:49 p.m.
[
https://issues.jboss.org/browse/AS7-3692?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-3692:
------------------------------------------
Dominik
Now that the dust has settled, I plan to update the documents describing the JGroups
management interface and the Infinispan management interface. Should start on that next
week.
Management: jgroups add stack operation does not work
-----------------------------------------------------
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Richard Achmatowicz
Labels: eap6_prd_req
Fix For: 7.1.1.Final
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:08 p.m.
[
https://issues.jboss.org/browse/AS7-3692?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz commented on AS7-3692:
------------------------------------------
I have implemented a first version of this, in which the stack add operation now takes two
optional parameters:
{noformat}
/subsystem=jgroups/stack=myStack:add(transport=<DMR representation of transport>,
protocols=<DMR representation of LIST of protocols>)
{noformat}
So, for example:
{noformat}
/subsystem=jgroups/stack=myStack:add(transport={"type" => "UDP",
"socket-binding" => "some-binding"}, protocols=[{"type"
=> "MPING", "socket-binding" => "some-binding"},
{"type" => "FRAG", "socket-binding" =>
"some-binding"}])
{noformat}
The full resource description is attached, as it is quite large.
This version simply checks for the optional parameters, and as required executes the
existing handlers for adding a transport and adding a protocol.
Management: jgroups add stack operation does not work
-----------------------------------------------------
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Richard Achmatowicz
Labels: eap6_prd_req
Fix For: 7.1.1.Final
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:13 p.m.
[
https://issues.jboss.org/browse/AS7-3692?page=com.atlassian.jira.plugin.s...
]
Richard Achmatowicz edited comment on AS7-3692 at 2/28/12 6:12 PM:
-------------------------------------------------------------------
I have implemented a first version of this, in which the stack add operation now takes two
optional parameters:
{noformat}
/subsystem=jgroups/stack=myStack:add(transport=<DMR representation of transport>,
protocols=<DMR representation of LIST of protocols>)
{noformat}
So, for example:
{noformat}
/subsystem=jgroups/stack=myStack:add(transport={"type" => "UDP",
"socket-binding" => "some-binding"}, protocols=[{"type"
=> "MPING", "socket-binding" => "some-binding"},
{"type" => "FRAG", "socket-binding" =>
"some-binding"}])
{noformat}
The full resource description is here:
{noformat}
[standalone@localhost:9999 /]
/subsystem=jgroups/stack=udp:read-operation-description(name=add)
{
"outcome" => "success",
"result" => {
"operation-name" => "add",
"description" => "Add a protocol stack to the jgroups
subsystem.",
"request-properties" => {
"transport" => {
"type" => OBJECT,
"description" => "The configuration of a transport for a
protocol stack.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"allowed" => [
"type",
"shared",
"socket-binding",
"diagnostics-socket-binding",
"default-executor",
"oob-executor",
"timer-executor",
"thread-factory",
"site",
"rack",
"machine",
"properties"
],
"value-type" => {
"type" => {
"type" => STRING,
"description" => "The implementation class for a
protocol, which determines protocol functionality.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"shared" => {
"type" => BOOLEAN,
"description" => "If true, the underlying
transport is shared by all channels using this stack.",
"expressions-allowed" => false,
"nillable" => true,
"default" => true
},
"socket-binding" => {
"type" => STRING,
"description" => "The socket binding
specification for this protocol layer, used to specify IP interfaces and ports for
communication.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"diagnostics-socket-binding" => {
"type" => STRING,
"description" => "The diagnostics socket binding
specification for this protocol layer, used to specify IP interfaces and ports for
communication.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"default-executor" => {
"type" => STRING,
"description" => "The thread pool executor to
handle incoming messages.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"oob-executor" => {
"type" => STRING,
"description" => "The thread pool executor to
handle incoming out-of-band messages.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"timer-executor" => {
"type" => STRING,
"description" => "The thread pool executor to
handle protocol-related timing tasks.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"thread-factory" => {
"type" => STRING,
"description" => "The thread factory to use for
handling asynchronous transport-specific tasks.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"site" => {
"type" => STRING,
"description" => "The site (i.e. data centre)
identifier for this node. Used by Infinispan topology-aware consistent hash.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"rack" => {
"type" => STRING,
"description" => "The rack (i.e. server rack)
identifier for this node. Used by Infinispan topology-aware consistent hash.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"machine" => {
"type" => STRING,
"description" => "The machine (i.e. host)
identifier for this node. Used by Infinispan topology-aware consistent hash.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"properties" => {
"type" => LIST,
"description" => "A list of properties for a
protocol layer. Used to customize protocol behaviour.",
"expressions-allowed" => false,
"nillable" => true,
"value-type" => {"property" => {
"type" => PROPERTY,
"description" => "A protocol property with
name and value.",
"expressions-allowed" => false,
"nillable" => true
}}
}
}
},
"protocols" => {
"type" => LIST,
"description" => "The list of configured protocols for a
protocol stack.",
"expressions-allowed" => false,
"required" => false,
"nillable" => true,
"value-type" => {"protocol" => {
"type" => OBJECT,
"description" => "The configuration of a protocol
within a protocol stack.",
"expressions-allowed" => false,
"nillable" => true,
"allowed" => [
"type",
"socket-binding",
"properties"
],
"value-type" => {
"type" => {
"type" => STRING,
"description" => "The implementation class
for a protocol, which determines protocol functionality.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"socket-binding" => {
"type" => STRING,
"description" => "The socket binding
specification for this protocol layer, used to specify IP interfaces and ports for
communication.",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L
},
"properties" => {
"type" => LIST,
"description" => "A list of properties for a
protocol layer. Used to customize protocol behaviour.",
"expressions-allowed" => false,
"nillable" => true,
"value-type" => {"property" => {
"type" => PROPERTY,
"description" => "A protocol property
with name and value.",
"expressions-allowed" => false,
"nillable" => true
}}
}
}
}}
}
},
"read-only" => false
}
}
{noformat}
This version simply checks for the optional parameters, and as required executes the
existing handlers for adding a transport and adding a protocol.
was (Author: rachmato):
I have implemented a first version of this, in which the stack add operation now takes
two optional parameters:
{noformat}
/subsystem=jgroups/stack=myStack:add(transport=<DMR representation of transport>,
protocols=<DMR representation of LIST of protocols>)
{noformat}
So, for example:
{noformat}
/subsystem=jgroups/stack=myStack:add(transport={"type" => "UDP",
"socket-binding" => "some-binding"}, protocols=[{"type"
=> "MPING", "socket-binding" => "some-binding"},
{"type" => "FRAG", "socket-binding" =>
"some-binding"}])
{noformat}
The full resource description is attached, as it is quite large.
This version simply checks for the optional parameters, and as required executes the
existing handlers for adding a transport and adding a protocol.
Management: jgroups add stack operation does not work
-----------------------------------------------------
Key: AS7-3692
URL: https://issues.jboss.org/browse/AS7-3692
Project: Application Server 7
Issue Type: Feature Request
Components: Clustering, Domain Management
Affects Versions: 7.1.0.Final
Reporter: Dominik Pospisil
Assignee: Richard Achmatowicz
Labels: eap6_prd_req
Fix For: 7.1.1.Final
Management: jgroups add stack operation does not work. Add stack operation fails with:
JBAS014746: type may not be null
however, add operation does not accept such parameter.
Steps to reproduce:
1) start domain
2) connect CLI
3) [standalone@localhost:9999 /] /subsystem=jgroups/stack=test:add()
{
"outcome" => "failed",
"failure-description" => "JBAS014746: type may not be null",
"rolled-back" => true,
"response-headers" => {"process-state" =>
"reload-required"}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5214
days inactive
5233
days old
6 comments
3 participants
participants (3)
-
Brian Stansberry (JIRA) -
Dominik Pospisil (JIRA)
-
Richard Achmatowicz (JIRA)