[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 David,
Thanks for the quick response. I reread your comments and agree with them 100%. The thing that stands out the most is the fact that you were concerned with "thread local access is very slow compared to our existing volatile int read". This is exactly the type of discussion that we had when assessing the performance characteristics. However, the current proposed implementation isn't even close to this level of performance, as I describe above.
In terms of a final solution, i don't think that the jboss log manager (the system, not the class) should store the thread local boolean to force logging. I am not sure if that is being considered, but in case it is let me explain why it would not be good for us.
Under such a system, the log manager would (typically) provide an accessor and mutator method to manipulate the thread local force logging flag. Although this would be the safest implementation from the jboss perspective (since the performance would be deterministic), i don't think the system would work, at least from the perspective of our requirements.
The reason for this is that when a new context begins use of a thread (i.e. doGet() servlet method is called), the force logging criteria need to be established and an algorithm needs to be executed to determine if the force logging flag is set to true or false. This algorithm is expensive, so it should only be executed once and its result should be cached for the duration of the context thread execution.
To make the API for this system small and clean, we do not expose any methods to explicitly execute the algorithm. We do it automatically when the first log record is output (for the context). That is why we need the jboss log manager to invoke the forceLogging() method that we implement. We rely on the jboss logging manager to trigger the execution of the algorithm (and the subsequent cacheing), as opposed to exposing and API method to explicitly trigger the algorithm and set the thread local flag in the jboss log manager. This makes the system more robust and simpler to use.
Invoking a forceLogging() method is the only real "low level" requirement that we have. The rest are just implementation details and anything that is efficient and cohesive would suffice. The implementation i describe above captures this requirement in the most succinct and efficient way possible.
Actually, to prototype things and assess performance, i would likely not even implement the SPI lookup, but rather put a setter method in the jboss log manager (the class) to register the implementation. This is not really the greatest approach since the registration of the implementor of the forceLogging() method will come much later in the system, but it should be good enough for our specific purposes.
And i don't expect the proposed implementation to be taken as a contribution; it is only meant to communicate our low level technical requirements. The reality is that the production solution needs to interface with the jboss cli in some way so that a regular user can specify things in the usual way. I am not even attempting to describe this solution...
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-637) /subsystem=logging/log-file resource cannot cope with an expression in the path
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-637?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated WFCORE-637:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1203101
> /subsystem=logging/log-file resource cannot cope with an expression in the path
> -------------------------------------------------------------------------------
>
> Key: WFCORE-637
> URL: https://issues.jboss.org/browse/WFCORE-637
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 1.0.0.Beta3
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> In log subsystem, nested expression can be used for path.
> {noformat}
> "path" => {
> "type" => STRING,
> "description" => "The filesystem path.",
> "expressions-allowed" => true,
> "nillable" => false,
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> {noformat}
> so if I use following log configuration :
> {noformat}
> <periodic-rotating-file-handler name="FILE" autoflush="true">
> <formatter>
> <named-formatter name="PATTERN"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="${jboss.server.name}.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> {noformat}
> server log name will be HOST_NAME.log and there is no problems to write.
> However, there is no log-file resource for it. This also leads into an issue that it cannot be displayed in Admin console Log Viewer menu.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-637) /subsystem=logging/log-file resource cannot cope with an expression in the path
by Ivo Studensky (JIRA)
Ivo Studensky created WFCORE-637:
------------------------------------
Summary: /subsystem=logging/log-file resource cannot cope with an expression in the path
Key: WFCORE-637
URL: https://issues.jboss.org/browse/WFCORE-637
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 1.0.0.Beta3
Reporter: Ivo Studensky
Assignee: Ivo Studensky
In log subsystem, nested expression can be used for path.
{noformat}
"path" => {
"type" => STRING,
"description" => "The filesystem path.",
"expressions-allowed" => true,
"nillable" => false,
"min-length" => 1L,
"max-length" => 2147483647L
}
{noformat}
so if I use following log configuration :
{noformat}
<periodic-rotating-file-handler name="FILE" autoflush="true">
<formatter>
<named-formatter name="PATTERN"/>
</formatter>
<file relative-to="jboss.server.log.dir" path="${jboss.server.name}.log"/>
<suffix value=".yyyy-MM-dd"/>
<append value="true"/>
{noformat}
server log name will be HOST_NAME.log and there is no problems to write.
However, there is no log-file resource for it. This also leads into an issue that it cannot be displayed in Admin console Log Viewer menu.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4271) Wildfly BOM wrong dependencies
by Vsevolod Golovanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4271?page=com.atlassian.jira.plugin.... ]
Vsevolod Golovanov updated WFLY-4271:
-------------------------------------
Description:
1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies:
{code}
<version.io.undertow>1.0.1.Final</version.io.undertow>
...
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-servlet</artifactId>
<version>${version.io.undertow}</version>
</dependency>
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-core</artifactId>
<version>${version.io.undertow}</version>
</dependency>
{code}
The version should be 1.1.0.Final. The wrong version ends up being the effective one in dependencyManagement, messes up debugging in Eclipse, and probably compiling in Eclipse.
2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}:
{code}
<version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen>
{code}
, which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}:
{code}
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${version.org.hibernate-jpamodelgen}</version>
</dependency>
{code}
Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied.
3. {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} specifies a managed version 3.0.0 for {{org.glassfish:javax.el}}. The actual version supplied with Wildfly 8.2.0.Final is javax.el-3.0.1-b05. Maybe {{resteasy-jaxrs-all}} shouldn't export this managed version at all?
Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors.
was:
1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies:
{code}
<version.io.undertow>1.0.1.Final</version.io.undertow>
...
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-servlet</artifactId>
<version>${version.io.undertow}</version>
</dependency>
<dependency>
<groupId>io.undertow</groupId>
<artifactId>undertow-core</artifactId>
<version>${version.io.undertow}</version>
</dependency>
{code}
The version should be 1.1.0.Final. The wrong version ends up being the effective one in dependencyManagement, messes up debugging in Eclipse, and probably compiling in Eclipse.
2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}:
{code}
<version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen>
{code}
, which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}:
{code}
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-jpamodelgen</artifactId>
<version>${version.org.hibernate-jpamodelgen}</version>
</dependency>
{code}
Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied.
Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors.
> Wildfly BOM wrong dependencies
> ------------------------------
>
> Key: WFLY-4271
> URL: https://issues.jboss.org/browse/WFLY-4271
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0.Final, BOM org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final
> Reporter: Vsevolod Golovanov
> Assignee: Tomaz Cerar
>
> 1. The BOM {{org.wildfly.bom:jboss-javaee-7.0-with-all:8.2.1.Final}} (indirectly) imports {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} that has the following dependencies:
> {code}
> <version.io.undertow>1.0.1.Final</version.io.undertow>
> ...
> <dependency>
> <groupId>io.undertow</groupId>
> <artifactId>undertow-servlet</artifactId>
> <version>${version.io.undertow}</version>
> </dependency>
> <dependency>
> <groupId>io.undertow</groupId>
> <artifactId>undertow-core</artifactId>
> <version>${version.io.undertow}</version>
> </dependency>
> {code}
> The version should be 1.1.0.Final. The wrong version ends up being the effective one in dependencyManagement, messes up debugging in Eclipse, and probably compiling in Eclipse.
> 2. {{org.wildfly.bom:jboss-bom-parent:8.2.1.Final}}:
> {code}
> <version.org.hibernate-jpamodelgen>4.3.5.Final</version.org.hibernate-jpamodelgen>
> {code}
> , which affects {{org.wildfly.bom:jboss-javaee-7.0-with-hibernate:8.2.1.Final}}:
> {code}
> <dependency>
> <groupId>org.hibernate</groupId>
> <artifactId>hibernate-jpamodelgen</artifactId>
> <version>${version.org.hibernate-jpamodelgen}</version>
> </dependency>
> {code}
> Hibernate 4.3.7.Final from SourceForge has jpamodelgen 4.3.7.Final supplied.
> 3. {{org.jboss.resteasy:resteasy-jaxrs-all:3.0.10.Final}} specifies a managed version 3.0.0 for {{org.glassfish:javax.el}}. The actual version supplied with Wildfly 8.2.0.Final is javax.el-3.0.1-b05. Maybe {{resteasy-jaxrs-all}} shouldn't export this managed version at all?
> Hoping for a BOM 8.2.2.Final release, because our project POMs are complex enough without workarounds for such errors.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4435) Mixed domain tests fail on infinispan/jgroups subsystems
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4435?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned WFLY-4435:
------------------------------------
Assignee: Radoslav Husar (was: Tomaz Cerar)
Thanks! ProfileParsingCompletionHandler sounds like exactly what we needed but currently don't have.
> Mixed domain tests fail on infinispan/jgroups subsystems
> --------------------------------------------------------
>
> Key: WFLY-4435
> URL: https://issues.jboss.org/browse/WFLY-4435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The same problem happens when attempting to use 2_0 version of these subsystems in current configuration.
> {noformat}
> [Host Controller] [0m[0m15:33:41,155 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[0m15:33:41,161 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute default-clustered-sfsb-cache is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[31m15:33:41,174 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([[0m
> [Host Controller] [31m ("profile" => "full-ha"),[0m
> [Host Controller] [31m ("subsystem" => "jgroups"),[0m
> [Host Controller] [31m ("channel" => "server")[0m
> [Host Controller] [31m]) - failure description: "WFLYCTL0175: Resource [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\")[0m
> [Host Controller] [31m] does not exist; a resource at address [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\"),[0m
> [Host Controller] [31m (\"channel\" => \"server\")[0m
> [Host Controller] [31m] cannot be created until all ancestor resources have been added"[0m
> [Host Controller] [31m[0m[31m15:33:41,183 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.[0m
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4435) Mixed domain tests fail on infinispan/jgroups subsystems
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4435?page=com.atlassian.jira.plugin.... ]
Kabir Khan edited comment on WFLY-4435 at 4/10/15 5:37 AM:
-----------------------------------------------------------
I think it could be possible to use a ProfileParsingCompletionHandler to put the operations into the correct location.
Something along the lines of having the parser add the jgroups operations to infinispan's list like it does at the moment, but then register a profile completion handler either for jgroups or infinispan, and move the jgroups operations from infinispan's list to jgroup's list.
was (Author: kabirkhan):
I think it could be possible to use a ProfileParsingCompletionHandler to put the operations into the correct location.
Something along the lines of having the parser add the jgroups operations to infinispan's list like it does at the moment, but then register a profile completion handler either for jgroups or infinispan, and move the operations from infinispan's list to jgroup's list.
> Mixed domain tests fail on infinispan/jgroups subsystems
> --------------------------------------------------------
>
> Key: WFLY-4435
> URL: https://issues.jboss.org/browse/WFLY-4435
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Tomaz Cerar
>
> The same problem happens when attempting to use 2_0 version of these subsystems in current configuration.
> {noformat}
> [Host Controller] [0m[0m15:33:41,155 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute enabled is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[0m15:33:41,161 INFO [org.jboss.as.controller.management-deprecated] (Controller Boot Thread) WFLYCTL0028: Attribute default-clustered-sfsb-cache is deprecated, and it might be removed in future version![0m
> [Host Controller] [0m[31m15:33:41,174 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([[0m
> [Host Controller] [31m ("profile" => "full-ha"),[0m
> [Host Controller] [31m ("subsystem" => "jgroups"),[0m
> [Host Controller] [31m ("channel" => "server")[0m
> [Host Controller] [31m]) - failure description: "WFLYCTL0175: Resource [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\")[0m
> [Host Controller] [31m] does not exist; a resource at address [[0m
> [Host Controller] [31m (\"profile\" => \"full-ha\"),[0m
> [Host Controller] [31m (\"subsystem\" => \"jgroups\"),[0m
> [Host Controller] [31m (\"channel\" => \"server\")[0m
> [Host Controller] [31m] cannot be created until all ancestor resources have been added"[0m
> [Host Controller] [31m[0m[31m15:33:41,183 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) WFLYHC0034: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.[0m
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months