[JBoss JIRA] (WFCORE-580) Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-580?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-580:
------------------------------------
Description:
Take the following hierarchy: -
{code}
keystore=xxx
alias=yyy
certificate-chain=default
certificate-chain=x509
{code}
keystore is a regular resource with storage=configuration.
alias is a regular resource with storage=runtime
certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime.
So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain.
The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist.
For the singleton resources however the following method is called: -
{code}
org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String)
{code}
Within this method the following check takes place: -
{code}
if (resource != null && resource.hasChildren(childType)) {
Set<String> childNames = resource.getChildrenNames(childType);
if (element.isWildcard()) {
set.addAll(childNames);
} else if (childNames.contains(element.getValue())) {
set.add(element.getValue());
}
{code}
Up to this point all is fine, the children the resource claims are available are the only ones added.
But further down this happens: -
{code}
if (!element.isWildcard()) {
ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element));
if (childReg != null && childReg.isRuntimeOnly()) {
set.add(element.getValue());
}
}
{code}
So even though the resource was previously checked and missing children excluded they are now added back.
The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation.
>From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this.
was:
Take the following hierarchy: -
keystore=xxx
alias=yyy
certificate-chain=default
certificate-chain=x509
keystore is a regular resource with storage=configuration.
alias is a regular resource with storage=runtime
certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime.
So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain.
The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist.
For the singleton resources however the following method is called: -
{code}
org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String)
{code}
Within this method the following check takes place: -
{code}
if (resource != null && resource.hasChildren(childType)) {
Set<String> childNames = resource.getChildrenNames(childType);
if (element.isWildcard()) {
set.addAll(childNames);
} else if (childNames.contains(element.getValue())) {
set.add(element.getValue());
}
{code}
Up to this point all is fine, the children the resource claims are available are the only ones added.
But further down this happens: -
{code}
if (!element.isWildcard()) {
ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element));
if (childReg != null && childReg.isRuntimeOnly()) {
set.add(element.getValue());
}
}
{code}
So even though the resource was previously checked and missing children excluded they are now added back.
The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation.
>From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this.
> Recursive read-resource with include-runtime=true assumes all runtime singleton resources will be present.
> ----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-580
> URL: https://issues.jboss.org/browse/WFCORE-580
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha19
> Reporter: Darran Lofthouse
> Assignee: Brian Stansberry
> Labels: affects_elytron
> Fix For: 1.0.0.CR1
>
>
> Take the following hierarchy: -
> {code}
> keystore=xxx
> alias=yyy
> certificate-chain=default
> certificate-chain=x509
> {code}
> keystore is a regular resource with storage=configuration.
> alias is a regular resource with storage=runtime
> certificate-chain=default and certificate-chain=x509 are regular resources with storage=runtime.
> So alias represents a single alias from a Java KeyStore, this may or may not have a certificate chain and it may be a default chain or it may be an x509 chain.
> The recursive read-resource is fine with regular resources such as alias as it has to rely on the underlying resource implementation to identify the instances that actually exist.
> For the singleton resources however the following method is called: -
> {code}
> org.jboss.as.controller.operations.global.GlobalOperationHandlers.getChildAddresses(OperationContext, PathAddress, ImmutableManagementResourceRegistration, Resource, String)
> {code}
> Within this method the following check takes place: -
> {code}
> if (resource != null && resource.hasChildren(childType)) {
> Set<String> childNames = resource.getChildrenNames(childType);
> if (element.isWildcard()) {
> set.addAll(childNames);
> } else if (childNames.contains(element.getValue())) {
> set.add(element.getValue());
> }
> {code}
> Up to this point all is fine, the children the resource claims are available are the only ones added.
> But further down this happens: -
> {code}
> if (!element.isWildcard()) {
> ImmutableManagementResourceRegistration childReg = registry.getSubModel(PathAddress.pathAddress(element));
> if (childReg != null && childReg.isRuntimeOnly()) {
> set.add(element.getValue());
> }
> }
> {code}
> So even though the resource was previously checked and missing children excluded they are now added back.
> The end result in this example is that the recursive read resource attempts to read for certificate-chain=default when it should only be reading for certificate-chain=x509 as already reported by the resource implementation.
> From a discussion in HipChat yesterday there was general agreement this behaviour seems to be wrong, however support for Proxied resources may be (incorrectly) dependent on this.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (LOGMGR-120) Thread local log level overriding
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ]
David Lloyd commented on LOGMGR-120:
------------------------------------
The proposed solution as given will not likely be accepted, thus it's not worth further analysis. See my comments above regarding how such a feature must be implemented to have acceptable performance characteristics.
> Thread local log level overriding
> ---------------------------------
>
> Key: LOGMGR-120
> URL: https://issues.jboss.org/browse/LOGMGR-120
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 1.5.2.Final
> Reporter: Matthew Robson
> Assignee: James Perkins
> Attachments: force_logging.patch
>
>
> Having the ability to force logs down to a filter no matter what the log level is set to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2643) Pass the jboss.server.log.dir parameter to the global system properties
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ]
James Perkins resolved WFLY-2643.
---------------------------------
Resolution: Won't Fix
There is a workaround to use the {{-Djboss.server.log.dir}} system property via the command line or via the {{standalone.conf(.bat)}}. I'd rather not make any changes to the scripts if possible as we've had issues with them recently.
> Pass the jboss.server.log.dir parameter to the global system properties
> -----------------------------------------------------------------------
>
> Key: WFLY-2643
> URL: https://issues.jboss.org/browse/WFLY-2643
> Project: WildFly
> Issue Type: Enhancement
> Components: Logging, Server
> Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1
> Environment: All
> Reporter: Stian Lund
> Priority: Optional
> Labels: jbossas, logging, wildfly
>
> In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
> {code}
> # determine the default log dir, if not set
> if [ "x$JBOSS_LOG_DIR" = "x" ]; then
> JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
> fi
> {code}
> However, this is not actually used to set the value of Java property jboss.server.log.dir.
> {code}
> -Djboss.home.dir="$JBOSS_HOME"
> -Djboss.server.base.dir="$JBOSS_BASE_DIR"
> "$SERVER_OPTS"
> {code}
> (It should be set at the same place)
> This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
> This is a problem for those who want to override the location of the server.log files.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4495) Remove Duplicate Versions and Groupids
by Philippe Marschall (JIRA)
Philippe Marschall created WFLY-4495:
----------------------------------------
Summary: Remove Duplicate Versions and Groupids
Key: WFLY-4495
URL: https://issues.jboss.org/browse/WFLY-4495
Project: WildFly
Issue Type: Patch
Components: Build System
Reporter: Philippe Marschall
Assignee: Paul Gier
Maven POMs inherit the version and groupId from the parent, there is no need to repeat them. Some POMs currently repeat them while others don't.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (LOGMGR-120) Thread local log level overriding
by John Mezzetta (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-120?page=com.atlassian.jira.plugin... ]
John Mezzetta commented on LOGMGR-120:
--------------------------------------
Hi,
Thiago is away for 6 weeks and I am currently doing characteristics testing on the proposed solution.
>From a performance perspective, the implementation does not satisfy requirements. Essentially, every time a logger object is accessed (even if forceLogging turns out to be false), 5 instances of the jboss Logger class are instantiated (assuming that the category being logged has a name that is 5 deep - i.e. 1.2.3.4.5). This happens because of this snippet of code in Logger.java:
private boolean forceLogging() {
if (!FORCING_LOG_CHECKER.isForcingLogFeatureEnabled()) {
return false;
}
final CheckForceLogCallback result = loggerNode.getCheckForceLogCallback();
if (result != null) {
return result.isForcingLog();
}
final Logger parent = getParent();
return parent != null && parent.forceLogging();
}
The call to getParent is a problem. It causes the instantiation of a new logger object. And it is recursive to the root, so multiple objects are created per call. In my test app, if traffic is light, the problem is not noticed. but under heavy logger use, it seems that all of these objects cannot be GCed fast enough because they have a finalize method. Regardless, the implementation is far too inefficient. We cannot have so many method invocations and object instantiations per logger call.
Basically, the requirement was to have an extra 2 or 3 high level instructions per logger call to determine if forcelogging is on. And this was on both sides, not just the jboss side. The current implementation is in the 50-100 range on the jboss side alone.
The proposal to fix this would be:
1. create a static method in a class (LogManager.java?) for the "forceLogging() method.
2. when the LogManager initiaizes, it needs to perform an SPI lookup for implementors of the org.jboss.logmanager.CheckForceLogCallback interface. We would provide that implementor (and deal with the obvious classpath issues by modifying the jboss loggin module.xm). If there are no implementors found in the SPI lookup, the forceLogging() method would return false. This would effectively mean the feature is disabled. If an implementation is found, the forceLogging() method is passed though to the implementation.
3. this means that the forceLogging method above would be replaced by a call to the static method in LogManager. And when the feature is disabled, LogManager would return a local Boolean.
While a productified version of this feature would probably be different, this would be the most concise and efficient implementation that would satisfy our requirements.
What do you think?
Regards,
John
> Thread local log level overriding
> ---------------------------------
>
> Key: LOGMGR-120
> URL: https://issues.jboss.org/browse/LOGMGR-120
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 1.5.2.Final
> Reporter: Matthew Robson
> Assignee: James Perkins
> Attachments: force_logging.patch
>
>
> Having the ability to force logs down to a filter no matter what the log level is set to.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-634) Intermittent failures in SSLMasterSlaveOneWayTestCase
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-634:
---------------------------------------
Summary: Intermittent failures in SSLMasterSlaveOneWayTestCase
Key: WFCORE-634
URL: https://issues.jboss.org/browse/WFCORE-634
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
Assignee: Ondrej Kotek
This test is failing intermittently. I'm going to @Ignore it.
See http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WildFlyCore_...
Example failure:
{code}
java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:189)
at java.net.SocketInputStream.read(SocketInputStream.java:121)
at org.apache.http.impl.io.SessionInputBufferImpl.streamRead(SessionInputBufferImpl.java:139)
at org.apache.http.impl.io.SessionInputBufferImpl.fillBuffer(SessionInputBufferImpl.java:155)
at org.apache.http.impl.io.SessionInputBufferImpl.readLine(SessionInputBufferImpl.java:284)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:140)
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
at org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
at org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:107)
at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.executeOverHttp(AbstractSSLMasterSlaveTestCase.java:169)
at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.isHostStateRunning(AbstractSSLMasterSlaveTestCase.java:144)
at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.checkHostStatusOnMaster(AbstractSSLMasterSlaveTestCase.java:112)
at org.jboss.as.test.integration.domain.AbstractSSLMasterSlaveTestCase.setOriginMasterManagementNativeInterfaceAndCheck(AbstractSSLMasterSlaveTestCase.java:96)
at org.jboss.as.test.integration.domain.SSLMasterSlaveOneWayTestCase.setOriginMasterManagementNativeInterface(SSLMasterSlaveOneWayTestCase.java:100)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4494) Delete Unused WebUtil Class
by Philippe Marschall (JIRA)
Philippe Marschall created WFLY-4494:
----------------------------------------
Summary: Delete Unused WebUtil Class
Key: WFLY-4494
URL: https://issues.jboss.org/browse/WFLY-4494
Project: WildFly
Issue Type: Patch
Components: Web (Undertow)
Reporter: Philippe Marschall
Assignee: Stuart Douglas
The WebUtil class in the security package of the undertow subsystem is unused. I found the class because it invokes #toString on an array instead of calling Arrays#toString. If it was still used this would have to be fixed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-2643) Pass the jboss.server.log.dir parameter to the global system properties
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-2643?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-2643:
--------------------------------
Summary: Pass the jboss.server.log.dir parameter to the global system properties (was: JBOSS_LOG_DIR is checked but not used to set jboss.server.log.dir)
> Pass the jboss.server.log.dir parameter to the global system properties
> -----------------------------------------------------------------------
>
> Key: WFLY-2643
> URL: https://issues.jboss.org/browse/WFLY-2643
> Project: WildFly
> Issue Type: Enhancement
> Components: Logging, Server
> Affects Versions: JBoss AS7 7.1.1.Final, 8.0.0.Beta1
> Environment: All
> Reporter: Stian Lund
> Priority: Optional
> Labels: jbossas, logging, wildfly
>
> In standalone/domain start scripts (standalone.sh/bat) the value of environment variable JBOSS_LOG_DIR is checked for:
> {code}
> # determine the default log dir, if not set
> if [ "x$JBOSS_LOG_DIR" = "x" ]; then
> JBOSS_LOG_DIR="$JBOSS_BASE_DIR/log"
> fi
> {code}
> However, this is not actually used to set the value of Java property jboss.server.log.dir.
> {code}
> -Djboss.home.dir="$JBOSS_HOME"
> -Djboss.server.base.dir="$JBOSS_BASE_DIR"
> "$SERVER_OPTS"
> {code}
> (It should be set at the same place)
> This leads Jboss/Wildfly/EAP to assume the default value of $JBOSS_BASE_DIR/log.
> This is a problem for those who want to override the location of the server.log files.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months