[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse edited comment on WFLY-7987 at 1/28/17 2:23 PM:
-----------------------------------------------------------------
The messages shown mention service dependencies and not capabiltiies so I would assume these resources are not making use of them.
was (Author: dlofthouse):
The messages shows mention service dependencies and not capabiltiies so I would assume these resources are not making use of them.
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Guillermo González de Agüero (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Guillermo González de Agüero commented on WFLY-7987:
----------------------------------------------------
[~dlofthouse] Keep in mind that the filter and Servlet Container cases were just examples. The same happens when removing the default mdb pool from the EJB subsystem: it works at runtime, but complains after the reload.
I deduce from the format of the boot errors that they are already registered as capabilities.
It is expected by design that a capability can't be remove while there are still any services requiring it? Or is it up to the operation implementor?
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7987:
----------------------------------------
Just moved this to specifically be about Undertow.
The application server now has support for something called capabilities and requirements which means that in situations like this broken dependencies can be detected whilst we validate the model before actually operating on the services.
The scenarios described here should be double checked to see if we have appropriate capability dependencies defined.
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-7987:
--------------------------------------
Assignee: Stuart Douglas (was: Jason Greene)
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Stuart Douglas
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7987?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7987:
-----------------------------------
Component/s: Web (Undertow)
> Remove operations should warn the user if the resource has any dependents
> -------------------------------------------------------------------------
>
> Key: WFLY-7987
> URL: https://issues.jboss.org/browse/WFLY-7987
> Project: WildFly
> Issue Type: Task
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Jason Greene
>
> Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
> Take a look at this example:
> {code:shell}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> [standalone@localhost:9990 /] :reload()
> {
> "outcome" => "success",
> "result" => undefined
> }
> [standalone@localhost:9990 /] /core-service=management:read-boot-errors()
> {
> "outcome" => "success",
> "result" => [{
> "failed-operation" => {
> "operation" => "add",
> "address" => [
> ("subsystem" => "undertow"),
> ("server" => "default-server"),
> ("host" => "default-host"),
> ("filter-ref" => "test")
> ]
> },
> "failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
> "services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
> }]
> }
> {code}
> A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
> The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
> My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7987) Remove operations should warn the user if the resource has any dependents
by Guillermo González de Agüero (JIRA)
Guillermo González de Agüero created WFLY-7987:
--------------------------------------------------
Summary: Remove operations should warn the user if the resource has any dependents
Key: WFLY-7987
URL: https://issues.jboss.org/browse/WFLY-7987
Project: WildFly
Issue Type: Task
Affects Versions: 10.1.0.Final
Reporter: Guillermo González de Agüero
Assignee: Jason Greene
Services may have dependents that can't work if they are not present. Removal operations should prevent, or least warn the user then he is about to remove a service that may have side effects.
Take a look at this example:
{code:shell}
[standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:add(header-name=X-test, header-value=test)
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=default-host/filter-ref=test:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/configuration=filter/response-header=test:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
[standalone@localhost:9990 /] :reload()
{
"outcome" => "success",
"result" => undefined
}
[standalone@localhost:9990 /] /core-service=management:read-boot-errors()
{
"outcome" => "success",
"result" => [{
"failed-operation" => {
"operation" => "add",
"address" => [
("subsystem" => "undertow"),
("server" => "default-server"),
("host" => "default-host"),
("filter-ref" => "test")
]
},
"failure-description" => "{\"WFLYCTL0412: Required services that are not installed:\" => [\"jboss.undertow.filter.test\"],\"WFLYCTL0180: Services with missing/unavailable dependencies\" => [\"jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]\"]}",
"services-missing-dependencies" => ["jboss.undertow.server.default-server.default-host.filter-ref.test is missing [jboss.undertow.filter.test]"]
}]
}
{code}
A new Undertow filter is created and assigned to a host. The filter is then removed, but the host still needs it.
The problem is only seen after a server reload. The same thing happens when you remove, i.e. the default Servlet Container or the Bean pool of the EJB subsystem.
My proposal is to at least add a response head to the remove operations listing affected (dependent) services. This would complement the new WildFly 11 capability registry.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (JGRP-2154) FRAG3: create full message up front
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2154?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2154:
--------------------------------
We actually *won't* save 50% of the allocated memory: memory for received messages is allocated by the transport and in FRAG2, messages are stored directly in a list, their buffers are not copied!
The difference is that FRAG3 discards incoming messages as soon as it copied their buffers into the full message's buffer, whereas FRAG2 keeps the fragment messages until all fragments have been received, and only then creates the final message and discards the fragment messages.
> FRAG3: create full message up front
> -----------------------------------
>
> Key: JGRP-2154
> URL: https://issues.jboss.org/browse/JGRP-2154
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> In FRAG2, a full message to be passed up the stack is created when all fragments have been received. Say we send a 30K message and frag_size is 8000 bytes. On the sender side, FRAG2 will create the following fragments: {{1:8000 2:8000 3:8000 4:6000}}.
> When fragment 1 is received, it is added to a fragment list. When all 4 fragments have been received, a full message of 30K is created and the 4 fragments' buffers are copied into the full message's buffer.
> FRAG2's memory allocation is therefore:
> * T1: 8000 // fragment 1 has been received
> * T2: 16000 // fragment 2 has been received
> * T3: 24000 // fragment 3 has been received
> * T4: 30000 // fragment 4 has been received
> * T4: 30000 + 30000 // full message is created and all 4 fragments are still in the list
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
> In FRAG3, the full message of 30K is created on reception of the first fragment. Fragments are not stored in a fragment list, but directly copied into the full message as soon as they have been received. Each fragment carries its offset and length, and the size of the full message, so the full message can be created on reception of the first fragment.
> The advantage is that the fragment list does not need to be maintained and fragments can be discarded as soon as they've been copied into the full message.
> Also, instead of allocating 60K of memory, only 30K are allocated.
> The disadvantage is that the full message is created up front, and remains in memory until the last segment has been received and the message has been delivered to the application.
> FRAG3's memory allocation looks as follows:
> * T1: 30000 // the full message is created on reception of fragment 1, frag is copied into the full message
> * T2: 30000 // fragment 2 has been received, copied into the full message and discarded
> * T3: 30000 // fragment 3 has been received, copied into the full message and discarded
> * T4: 30000 // fragment 4 has been received, copied into the full message and discarded
> * T4: 30000 // full message is being delivered up the stack, and fragments have been removed
> * T5: 0 // full message has been delivered and can be garbage collected
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2238) Drop the inflowed security domains attribute from access=identity
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-2238:
----------------------------------------
Summary: Drop the inflowed security domains attribute from access=identity
Key: WFCORE-2238
URL: https://issues.jboss.org/browse/WFCORE-2238
Project: WildFly Core
Issue Type: Task
Components: Domain Management, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 3.0.0.Alpha23
We may restore it later so don't remove the code that uses it but remove it from the management model.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months