[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1150:
------------------------------------------
In a discussion with Andy Miller, he recommended we use the same values that we previously used for PermSize/MaxPermSize.
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1150:
-------------------------------------
Fix Version/s: 2.0.6.Final
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Fix For: 2.0.6.Final, 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1278) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1278:
----------------------------------------
Summary: Capability resolution complaints on admin-only slave HCs not connected to the master
Key: WFCORE-1278
URL: https://issues.jboss.org/browse/WFCORE-1278
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.0.5.Final
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.0.Alpha1
If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
{code}
bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
{code}
The boot is fine:
{code}
[Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
{code}
However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
{code}
[domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
{code}
The HC's log:
{code}
[Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
[Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
[Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
{code}
The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1260?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1260:
------------------------------------------
The CapabilityRegistry.resolveCapabilities already has logic for ignoring unresolved capabilities like this, via its "hostXmlOnly" param. So the solution to this is to ensure that this param has the correct value in these situations where the HC is admin only with no available domain model.
> Capability resolution complaints on admin-only slave HCs not connected to the master
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1260
> URL: https://issues.jboss.org/browse/WFCORE-1260
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
> Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
> {code}
> bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
> {code}
> The boot is fine:
> {code}
> [Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
> {code}
> However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
> {code}
> [domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> The HC's log:
> {code}
> [Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> {code}
> The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
> But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
> This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1260) Capability resolution complaints on admin-only slave HCs not connected to the master
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1260?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1260:
-------------------------------------
Fix Version/s: 3.0.0.Alpha1
> Capability resolution complaints on admin-only slave HCs not connected to the master
> ------------------------------------------------------------------------------------
>
> Key: WFCORE-1260
> URL: https://issues.jboss.org/browse/WFCORE-1260
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.5.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> If you start a slave HC in admin-only with no master to connect to, boot is fine but then any modifications made to the config result in capability resolution ERROR messages in the host-controller.log
> Starting a slave HC in admin-only with no master to connect to is meant to work, allowing you to use CLI to manipulate the slave's host config:
> {code}
> bin/domain.sh --host-config=host-slave.xml --admin-only -Djboss.domain.master.address=127.0.0.1
> {code}
> The boot is fine:
> {code}
> [Host Controller] 11:06:10,639 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.0.0.Final-SNAPSHOT (WildFly Core 2.0.5.Final) (Host Controller) started in 1152ms - Started 41 of 42 services (12 services are lazy, passive or on-demand)
> {code}
> However, subsequent changes made via management tools (e.g. CLI) succeed but result in ERROR logging by the HC:
> {code}
> [domain@127.0.0.1:9999 /] /host=localhost/system-property=foo:add(value=bar)
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> {code}
> The HC's log:
> {code}
> [Host Controller] 11:07:37,744 ERROR [org.jboss.as.controller] (management-handler-thread - 4) WFLYCTL0369: Required capabilities are not available:
> [Host Controller] org.wildfly.domain.server-group.other-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> [Host Controller] org.wildfly.domain.server-group.main-server-group in context 'server-config'; There are no known registration points which can provide this capability.
> {code}
> The boot works without logging because of the enhancement Stuart added such that capability reference failures won't fail an admin-only boot, thus letting the user use admin-only to fix the config. But then with subsequent changes, the user gets ERRORs notifying them of the unfixed references.
> But in this case, the references will never be available, so long as there is no connection to a master to provide the domain-wide config.
> This is a general case that needs to be accounted for in the capability resolution logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1277) Embed-server from CLI launch shows twice prompt string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1277?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1277:
------------------------------------------
Yesterday using non-embedded CLI I noticed something similar after using CLI to shut down the server:
{code}
[standalone@localhost:9990 /] shutdown
[disconnected /] [disconnected /]
{code}
> Embed-server from CLI launch shows twice prompt string
> ------------------------------------------------------
>
> Key: WFCORE-1277
> URL: https://issues.jboss.org/browse/WFCORE-1277
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.5.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
> Priority: Minor
>
> {noformat}
> When I launch an embed-server from CLI, it displays twice [standalone@embedded /] [standalone@embedded /] for the first time.
> [wangc@dhcp-128-40 wildfly-10.0.0.Final-SNAPSHOT]$ sh bin/jboss-cli.sh
> You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
> [disconnected /] embed-server
> [standalone@embedded /] [standalone@embedded /] ls
> core-service launch-type=EMBEDDED product-version=undefined
> deployment management-major-version=4 profile-name=undefined
> deployment-overlay management-micro-version=0 release-codename=Kenny
> extension management-minor-version=0 release-version=2.0.5.Final
> interface name=dhcp-128-40 running-mode=ADMIN_ONLY
> path namespaces=[] schema-locations=[]
> socket-binding-group organization=undefined server-state=running
> subsystem process-type=Server suspend-state=RUNNING
> system-property product-name=undefined uuid=8c4ede2f-8e14-48bf-9eaf-73947e23edcf
> [standalone@embedded /] quit
> {noformat}
> This does not happen in 2.0.4.Final.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Alessandro Lazarotti <alazarot(a)redhat.com> changed the Status of [bug 1293965|https://bugzilla.redhat.com/show_bug.cgi?id=1293965] from MODIFIED to ON_QA
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-5484 at 1/7/16 2:48 PM:
------------------------------------------------------------
This issue seems to be due to a conflict between Undertow's CachedAuthenticatedSessionMechanism and SingleSignOnMechanism. If the CachedAuthenticatedSessionMechanism detects an AuthenticatedSession in the HttpSession, the SingleSignOnMechanism never has the chance to register a security notification listener, thus the SSO is not invalidated on logout, not until the AuthenticatedSession is first removed from the session in a previous request. Reassigning this to [~swd847] as this is an issue with Undertow security, not with clustering SSO management.
was (Author: pferraro):
This issue seems to be due to a conflict between Undertow's CachedAuthenticatedSessionMechanism and SingleSignOnMechanism. If the CachedAuthenticatedSessionMechanism detects an AuthenticatedSession in the HttpSession, the SingleSignOnMechanism never has the chance to register a security notification listener, thus the SSO is not invalidated on logout. Reassigning this to [~swd847] as this is clearly an issue with Undertow security, not with clustering SSO management.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5484:
------------------------------------
This issue seems to be due to a conflict between Undertow's CachedAuthenticatedSessionMechanism and SingleSignOnMechanism. If the CachedAuthenticatedSessionMechanism detects an AuthenticatedSession in the HttpSession, the SingleSignOnMechanism never has the chance to register a security notification listener, thus the SSO is not invalidated on logout. Reassigning this to [~swd847] as this is clearly an issue with Undertow security, not with clustering SSO management.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-5484:
-------------------------------
Component/s: (was: Clustering)
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
> Attachments: reproducer-jbeap-1282.zip
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months