[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-363:
---------------------------------------
Assignee: (was: Brian Stansberry)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5701) Compile error in clustering/common module with older version of jdk 8
by Paul Gier (JIRA)
Paul Gier created WFLY-5701:
-------------------------------
Summary: Compile error in clustering/common module with older version of jdk 8
Key: WFLY-5701
URL: https://issues.jboss.org/browse/WFLY-5701
Project: WildFly
Issue Type: Feature Request
Components: Build System, Clustering
Reporter: Paul Gier
Assignee: Paul Gier
Priority: Minor
When compiling with jdk version "1.8.0_31" I get a compile error in the clustering/common module.
{noformat}
[ERROR] /home/pgier/projects/jboss-eap/clustering/common/src/main/java/org/jboss/as/clustering/controller/ExecutionHandler.java:[54,48] no suitable method found for collect(java.util.stream.Collector<E,capture#1 of ?,java.util.Map<java.lang.String,java.lang.Object>>)
method java.util.stream.Stream.<R>collect(java.util.function.Supplier<R>,java.util.function.BiConsumer<R,? super capture#2 of ? extends E>,java.util.function.BiConsumer<R,R>) is not applicable
(cannot infer type-variable(s) R
(actual and formal argument lists differ in length))
method java.util.stream.Stream.<R,A>collect(java.util.stream.Collector<? super capture#2 of ? extends E,A,R>) is not applicable
(cannot infer type-variable(s) capture#3 of ?,T,K,U,T
(argument mismatch; java.util.function.Function<capture#2 of ? extends E,capture#2 of ? extends E> cannot be converted to java.util.function.Function<? super capture#2 of ? extends E,? extends capture#2 of ? extends E>))
[INFO] 1 error
{noformat}
If I use a newer jdk 8 version such as "1.8.0_65", the issue does not occur.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1106) Better handling of subsequent changes once the server is placed into reload-required
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1106?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1106:
------------------------------------------
WFCORE-1106 and WFCORE-368 are conceptually related in that they both involve dealing with situations where a server is somehow out of sync with the expected configuration.
> Better handling of subsequent changes once the server is placed into reload-required
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1106
> URL: https://issues.jboss.org/browse/WFCORE-1106
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> When the handler for a configuration change operation determines that it cannot effect the change to the current runtime services, it places the process into "reload-required" state. From the moment this occurs until the reload is performed, the configuration model is inconsistent with the runtime services.
> This can lead to problems when, prior to reload, the user makes further configuration changes. Those changes can succeed in Stage.MODEL, since the change is valid given the current state of the configuration model, but then when the handler attempts to update the runtime the changes fail because the runtime services are in a different state. Some common scenarios:
> 1) User removes a resource, triggering reload required. Then they re-add the resource, which fails with a DuplicateServiceException since the service from the original version of the resource hasn't been removed yet.
> 2) User makes some other config change to a resource which can't be effected immediately, so the server is put into reload-required. The user then adds another resource that depends on the services from the first resource, and that add fails because the runtime service from the first resource is not in the expected state.
> A naive fix for this would be once the process goes into reload-required state to stop making any further runtime changes for steps that alter the persistent config. (Runtime changes for ops that don't touch persistent config would be ok, e.g. reload itself, or runtime-only ops like popping a message off a JMS queue.)
> The problem with the naive approach is config changes that could take immediate effect no longer will. This could break existing scripts, or just be annoying in general. For example, a server is in reload-required state but is still running. Then the user wants to add a logger category or change the level of an existing one in order to get some diagnostic info. The logging change would not affect the runtime until the reload is done, forcing a reload to get the diagnostic data.
> Stuart Douglas had an excellent suggestion today of looking into tying this in to capabilities and requirements. So, for example:
> 1) An op targeted at resource foo=bar causes the process to go into reload-required.
> 2) The kernel detects this and finds the registration for the foo=bar resource type, and sees that the resource provides capability org.wildfly.foo.bar.
> 3) The kernel records in the capability registry that org.wildfly.foo.bar is now "reload-required".
> 4) Thereafter, for any op that changes the model and then adds a runtime step, the kernel:
> a) finds the registration for the resource type associated with that op's target address
> b) finds any capabilities provided by the resource type
> c) looks for direct or transitive requirements for those capabilites that are "reload-required"
> d) if found, the runtime step is not executed, and instead the "server-requires-reload" response-header is added.
> The effect here is the granularity of what ops have their runtime changes skipped is reduced to those associated with capabilities that put the server into reload-required. Unrelated ops, e.g. the logging changes mentioned above, are unaffected.
> Some fine points:
> 1) The restart-required and reload-required states need to be tracked separately. The information regarding any restart-required capabilities needs to survive a reload.
> 2) The information that a capability is reload/restart-required needs to survive the removal of the capability. This allows the remove+add scenario to work. The remove op removes the capability, but the fact it is still present in the runtime is tracked, so when the add comes in no runtime changes are made.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-368) Ability for processes to be placed in a state rejecting config changes and requiring a restart
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-368?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-368:
-----------------------------------------
WFCORE-1106 and WFCORE-368 are conceptually related in that they both involve dealing with situations where a server is somehow out of sync with the expected configuration.
> Ability for processes to be placed in a state rejecting config changes and requiring a restart
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-368
> URL: https://issues.jboss.org/browse/WFCORE-368
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> If a condition occurs whereby a managed process is in an unknown and inconsistent state, we need the ability to mark the process as being unsafe to modify in terms of configuration and requiring restart.
> Examples of this kind of situation in a standalone server would include:
> 1) timeouts waiting for MSC stability as envisioned in WFLY-2741.
> 2) failures that occur in operation rollback.
> In these cases, it is no longer practical to determine how internal service state relates to configuration state. Allowing further configuration changes will exacerbate the situation. The process should be restarted in order to restore consistency before allowing further config changes.
> In a domain environment this can also include servers that are inconsistent with respect to the domain model because some update has failed on that server but the rollout plan allowed the update to commit on other servers.
> In this case, the server config is inconsistent with the domain and subsequent changes to the domain will not make it consistent, so they should not be propagated to the server. The server needs to be restarted in order to get a complete configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-170) Create a shared ScheduledExecutorService
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-170?page=com.atlassian.jira.plugin... ]
Brian Stansberry closed WFCORE-170.
-----------------------------------
Fix Version/s: (was: 3.0.0.Alpha1)
Resolution: Won't Do
ServerService (or HostControllerService on an HC) installs a Service<ScheduledExecutorService> but I don't think it' a good idea to treat this as a globally available resource. ScheduledThreadPoolExecutor is a fixed size thread pool, and if there aren't enough threads to process tasks, task execution will be delayed. This makes ScheduledThreadPoolExecutor unsuitable for arbitrary use, since the appropriate pool size is unknowable.
It's fine to consider using ServerService's pool for other uses in the kernel, but only with care about the pool size considerations. And I don't think it should be used outside the kernel. For example there can be multiple instances of DeploymentScannerService, and those execute tasks that may block for considerable periods.
> Create a shared ScheduledExecutorService
> ----------------------------------------
>
> Key: WFCORE-170
> URL: https://issues.jboss.org/browse/WFCORE-170
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> There are number of ScheduledExecutorService instances being created around wf-core. Create a single service and inject it.
> This will reduce resource usage by creating fewer threads, and will reduce the risk of code mistakes around shutting down the various executors,
> I see these used in:
> LdapCacheService
> RemoteDomainConnectionService
> DeploymentMountProvider
> DeploymentScannerService
> plus the operation response attachment stuff I'm doing will need one.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-464) ProcessController's BufferedReader.readLine() usage allows unbounded memory usage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-464?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-464:
---------------------------------------
Assignee: (was: Brian Stansberry)
> ProcessController's BufferedReader.readLine() usage allows unbounded memory usage
> ---------------------------------------------------------------------------------
>
> Key: WFCORE-464
> URL: https://issues.jboss.org/browse/WFCORE-464
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha14
> Reporter: James Livingston
>
> org.jboss.as.process.ManagedProcess$ReadTask.run() uses readLine() to read a line of output from the manage process' standard output/error streams, which cause the whole line to be loaded into memory.
> Badly written applications may dump excessive amounts of data out in a single line, which would cause the process controller to temporarily use a large amount of memory to process it, potentially leading to an OutOfMemoryError. Practically speaking, with the default -Xmx512m it would require around 128 million characters in a single line to trigger, which is obviously very high.
> Were an OOME to occur, it would almost certainly cause the stream to be closed, and "IOException: Broken pipe" exceptions to occur in the child process, which for WildFly would be caught an ignored by JBoss Logging. A hostile managed process exploiting this would be almost impossible.
> A reasonable solution would probably be to limit size of the buffer read, causing it to split lines over a certain size (a few megabytes?). That would not likely cause any practical problems.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-560) Incorrect wildcard handling in OperationContextImpl.getAuthorizationResource(PathAddress address)
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-560?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-560:
---------------------------------------
Assignee: (was: Brian Stansberry)
> Incorrect wildcard handling in OperationContextImpl.getAuthorizationResource(PathAddress address)
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-560
> URL: https://issues.jboss.org/browse/WFCORE-560
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha18
> Reporter: Brian Stansberry
>
> Problem is 2nd and 3rd lines here:
> {code}
> if (element.isWildcard()) {
> model = Resource.Factory.create();
> final Set<Resource.ResourceEntry> children = model.getChildren(element.getKey());
> for (final Resource.ResourceEntry entry : children) {
> model.registerChild(entry.getPathElement(), entry);
> }
> } else {
> {code}
> Problem is "model" will have no children because it was just reassigned to a new Resource. The lines need to be swapped.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-934) IPv6ScopeIdMatchUnitTestCase fails on some machines
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-934?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-934:
-----------------------------------------
Note to self: perhaps the fact that there is a ':' in the scope-id (%net0:2) is relevant.
> IPv6ScopeIdMatchUnitTestCase fails on some machines
> ---------------------------------------------------
>
> Key: WFCORE-934
> URL: https://issues.jboss.org/browse/WFCORE-934
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 2.0.0.Beta4
> Reporter: Marek Kopecký
> Assignee: Brian Stansberry
>
> *Description of problem:*
> org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase#testNonLoopback in WildFly Core TS fails on Solaris11 SPARC.
> *How reproducible:*
> Always with this configuration on Solaris11 SPARC:
> {noformat}
> $ /usr/sbin/ifconfig -a
> lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
> inet 127.0.0.1 netmask ff000000
> net0: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.91.211 netmask fffff800 broadcast 10.16.95.255
> net0:1: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.24 netmask fffff800 broadcast 10.16.183.255
> net0:2: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.25 netmask fffff800 broadcast 10.16.183.255
> net0:3: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.26 netmask fffff800 broadcast 10.16.183.255
> net0:4: flags=100001000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,PHYSRUNNING> mtu 1500 index 2
> inet 10.16.179.27 netmask fffff800 broadcast 10.16.183.255
> lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1
> inet6 ::1/128
> net0: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab1/10
> net0:1: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab2/10
> net0:2: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 fe80::8:20ff:fe6d:eab0/10
> net0:3: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:164/64
> net0:4: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:165/64
> net0:5: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:166/64
> net0:6: flags=120002000841<UP,RUNNING,MULTICAST,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f::ffff:167/64
> net0:7: flags=120002080841<UP,RUNNING,MULTICAST,ADDRCONF,IPv6,PHYSRUNNING> mtu 1500 index 2
> inet6 2620:52:0:105f:8:20ff:fe6d:eab0/64
> $
> {noformat}
> *Steps to Reproduce:*
> # cd controller
> # mvn test -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dtest=IPv6ScopeIdMatchUnitTestCase
> *Actual results:*
> * StackTrace:
> {noformat}
> java.lang.AssertionError: expected:</fe80:0:0:0:8:20ff:fe6d:eab0%net0:2> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.jboss.as.controller.interfaces.IPv6ScopeIdMatchUnitTestCase.testNonLoopback(IPv6ScopeIdMatchUnitTestCase.java:129)
> {noformat}
> * Test output:
> {noformat}
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab2%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab1%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:167%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:166%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:165%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address 2620:52:0:105f:0:0:ffff:164%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%bogus, so cannot match it to any InetAddress
> WARN (main) [org.jboss.as.controller.management-operation] <InetAddressMatchInterfaceCriteria.java:128> WFLYCTL0001: Cannot resolve address fe80:0:0:0:8:20ff:fe6d:eab0%net0:2, so cannot match it to any InetAddress
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-374) Rethink OperationContextImpl.getBasicAuthorizationResponse
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-374?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-374:
---------------------------------------
Assignee: (was: Brian Stansberry)
> Rethink OperationContextImpl.getBasicAuthorizationResponse
> ----------------------------------------------------------
>
> Key: WFCORE-374
> URL: https://issues.jboss.org/browse/WFCORE-374
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management
> Reporter: Brian Stansberry
>
> OperationContextImpl.getBasicAuthorizationResponse is designed around the "pass" case. It tests all action effects but discards data if any fail. This is ok in the normal case where things will pass. But in the read-resource-description and recursive read-resource cases, where things may often fail with the failure being recorded as expected (i.e. non-failure) output, this approach is inefficient, because the caller is forced to re-authorize to get the discarded data.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months