[JBoss JIRA] Created: (JBAS-8791) log4j-appender seems not working in jboss-logging (AS6 final)
by Gregoire Botquin (JIRA)
log4j-appender seems not working in jboss-logging (AS6 final)
-------------------------------------------------------------
Key: JBAS-8791
URL: https://issues.jboss.org/browse/JBAS-8791
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: 6.0.0.Final
Reporter: Gregoire Botquin
Assignee: David Lloyd
We are using some custom logger based on log4j appenders. I made a jboss-logging.xml configuration but it seems that my log4j-appender doesn't log anything. I'm working in AS6 final version.
I made an example with a standard log4j appender (neither working). The category "com.sample" should be managed by the log4jappender. Every second the bean should write something, but nothing happens, the log file is not even created. I tried with other log4j loggers/ custom loggers and no success.
When activating CONSOLE handler the logs are correctly written in console, but when only using the log4j-appender nothing happens after server started.
The configuration file seems correct (?), but can't unfortunately check it against a documentation yet.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<logging xmlns="urn:jboss:logging:6.0" xmlns:b="urn:jboss:bean-deployer:2.0">
<!-- ================================= -->
<!-- Preserve messages in a local file -->
<!-- ================================= -->
<!-- A time/date based rolling handler -->
<periodic-rotating-file-handler
file-name="${jboss.server.log.dir}/server.log"
name="FILE"
autoflush="true"
append="true"
suffix=".yyyy-MM-dd"> <!-- To roll over at the top of each hour, use ".yyyy-MM-dd-HH" instead -->
<error-manager>
<only-once/>
</error-manager>
<formatter>
<!-- To revert back to simple stack traces without JAR versions, change "%E" to "%e" below. -->
<!-- Uncomment this to get the class name in the log as well as the category
<pattern-formatter pattern="%d %-5p [%c] %C{1} (%t) %s%E%n"/>
-->
<!-- Uncomment this to log without the class name in the log -->
<pattern-formatter pattern="%d %-5p [%c] (%t) %s%E%n"/>
</formatter>
</periodic-rotating-file-handler>
<!-- ============================== -->
<!-- Append messages to the console -->
<!-- ============================== -->
<console-handler name="CONSOLE" autoflush="true" target="System.out">
<error-manager>
<only-once/>
</error-manager>
<level name="INFO"/>
<formatter>
<pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] %s%E%n"/>
</formatter>
</console-handler>
<log4j-appender name="Log4jAppender" class="org.apache.log4j.DailyRollingFileAppender">
<error-manager>
<only-once/>
</error-manager>
<level name="DEBUG"/>
<properties>
<!-- <property name="directory">${jboss.server.log.dir}/</property> -->
<property name="file">${jboss.server.log.dir}/log4j.log</property>
<property name="append">true</property>
<property name="datePattern">'.'yyyy-MM-dd</property>
</properties>
<formatter>
<pattern-formatter pattern="%d %-5p [%c] %m%n"/>
</formatter>
</log4j-appender>
<logger category="com.sample">
<level name="DEBUG"/>
<handlers>
<handler-ref name="Log4jAppender"/>
</handlers>
</logger>
<!-- ======================= -->
<!-- Setup the Root category -->
<!-- ======================= -->
<root-logger>
<!-- Set the root logger priority via a system property, with a default value. -->
<level name="${jboss.server.log.threshold:INFO}"/>
<handlers>
<handler-ref name="Log4jAppender"/>
<!--
<handler-ref name="CONSOLE"/>
<handler-ref name="FILE"/>
-->
</handlers>
</root-logger>
</logging>
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
package com.sample;
import javax.ejb.Schedule;
import javax.ejb.Stateless;
import org.apache.log4j.Logger;
//@Singleton
@Stateless
public class TestBean {
public static final Logger LOG = Logger.getLogger(TestBean.class);
public TestBean(){
System.out.println("TestBean is instantiated and should write someting in the log file");
LOG.info("This is information log");
}
@Schedule(second="*/1", minute="*",hour="*", persistent=false)
public void writeSomething(){
System.out.println("This should write something in the log file at scheduled times");
LOG.info("This is scheduled information log");
}
}
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBAS-7468) Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext
by Ganesh Ingle (JIRA)
Memory leak in org.jboss.security.plugins.authorization.JBossAuthorizationContext
---------------------------------------------------------------------------------
Key: JBAS-7468
URL: https://jira.jboss.org/jira/browse/JBAS-7468
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.1.0.GA, JBossAS-5.0.1.GA, JBossAS-5.0.0.GA
Environment: JBoss Version: jboss-5.1.0.GA, OS: Linux (2.6.18-164.el5), Architecture: amd64 64bit, JVM: Java HotSpot(TM) 64-Bit Server VM (14.0-b16, mixed mode)
Reporter: Ganesh Ingle
Assignee: Anil Saldhana
Our use case (only security related portion is mentioned here):
Axis 1.4 webservice, standard J2EE declarative security through WEB-INF/web.xml, a http client sends soap request and BASIC auth information, the JBoss server performs authentication and authorization as per WEB-INF/web.xml configuration.
We did a performance/stability test on above web service. After 8.5 million requests the server gone out of memory. We did heap dump analysis using VisualVM tool and found that the class org.jboss.security.plugins.authorization.JBossAuthorizationContext is consuming most of the memory. This class has a memer array named "controlFlags", this array was showing 25.7 million ControlFlag entries.
When we investigated the code we found that there is one instance of JBossAuthorizationManager per security domain and this manager has one instance of JBossAuthorizationContext. For every authorization the JBossAuthorizationContext initializes authorization modules and pushes their control flags (instances of class ControlFlag) in member arrays. When the authorization is complete, a commit/abort is invoked on all modules and finally the "modules" array is cleared. However, the "controlFlags" array is not cleared. We checked the entire class, this array never gets cleared.
We changed the code to clear both "modules" and "controlFlags" array in a finally block in method JBossAuthorizationContext.authorize(final Resource resource, final Subject subject, final RoleGroup callerRoles). We ran a 50million test after this fix, the test was successful which proves the fix worked.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBAS-9362) Long running thread leaks SimpleRole objects
by Tim Terlegard (JIRA)
Long running thread leaks SimpleRole objects
--------------------------------------------
Key: JBAS-9362
URL: https://issues.jboss.org/browse/JBAS-9362
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: 6.0.0.Final
Environment: Tested on Mac OS X 10.6.7 with Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02-334, mixed mode) 1.6.0_24
Reporter: Tim Terlegard
Assignee: Anil Saldhana
Attachments: simpleroletest.tar.gz
When invoking a long-running EJB method which makes a bunch of calls to some method in another EJB, then JBoss leaks SimpleRole objects. The SimpleRole objects are not removed by a manually triggered garbage collection.
The SimpleRole object leakage seems to go away if I remove the security domain in jboss.xml. When running my jboss application during the night JBoss had 4GB of SimpleRole objects.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JGRP-931) Logical addresses: canonicalize UUIDs with IDs (shorts)
by Bela Ban (JIRA)
Logical addresses: canonicalize UUIDs with IDs (shorts)
-------------------------------------------------------
Key: JGRP-931
URL: https://jira.jboss.org/jira/browse/JGRP-931
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
Instead of using UUIDs as addresses, the cluster members should agree on shorts, e.g. 1 for A, 2 for B and so on, and use these instead of UUIDs.
This happens after a certain warmup time. E.g. the coord could assign these IDs, so they're unique.
IdAddress and UUID have to be able to do equals() or compareTo() with each other !
Advantage:
- we send a short (2 bytes) instead of a UUID (16 bytes)
- we use an IdAddress (class with a short) instead of a UUID. This is 6 bytes less per instance
- IdAddress might be faster with equals() and hashCode() than UUID
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBBUILD-670) Migrate existing Nexus Audit information to standard XML format
by Paul Gier (JIRA)
Migrate existing Nexus Audit information to standard XML format
---------------------------------------------------------------
Key: JBBUILD-670
URL: https://issues.jboss.org/browse/JBBUILD-670
Project: JBoss Build System
Issue Type: Task
Reporter: Paul Gier
Assignee: John Casey
Fix For: Build Support 2011
We currently have audit information (username, timestamp) stored in .json files in the repository. Nexus uses an XML format to store this information, and recent versions of Nexus allow easy way to view this information in the Nexus UI. The existing audit information should be migrated to the standard Nexus XML format.
These XML files are located in the directory "sonatype-work/nexus/proxy/attributes". For each file in each Maven repository hosted by Nexus, there is a file with the same name in this attributes directory. For example, "sonatype-work/nexus/proxy/attributes/jboss-releases/org/jboss/javaee/jboss-servlet-api/2.5.0.GA/jboss-servlet-api-2.5.0.GA.jar" is actually an XML file containing the attributes for the named jar file.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JBBUILD-523) Issues with custom packaging in maven
by Paul Gier (JIRA)
Issues with custom packaging in maven
-------------------------------------
Key: JBBUILD-523
URL: https://jira.jboss.org/jira/browse/JBBUILD-523
Project: JBoss Build System
Issue Type: Task
Components: Maven
Reporter: Paul Gier
Fix For: Maven Build - Maint 2009
Steve ran into some issues when using custom packaging for the jdocbook plugin.
- Transitive dependency resolution does not work
- Two dependencies with the same packaging but different artifact handlers cannot both be resolved, because no info about the handler is encoded into the repo
- The plugin containing the custom packaging needs to programmatically register the artifact handler in addition to specifiying it in the components.xml
this has to be done by:
(1) retrieve the handler using @parameter expression="${component.org.apache.maven.artifact.handler.ArtifactHandler#jdocbook-style}"
(2) manually register it using project.getArtifact().setArtifactHandler( artifactHandler );
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JGRP-1302) RELAY: issues with shared transport
by Bela Ban (JIRA)
RELAY: issues with shared transport
-----------------------------------
Key: JGRP-1302
URL: https://issues.jboss.org/browse/JGRP-1302
Project: JGroups
Issue Type: Task
Affects Versions: 2.12
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.12.1
JBoss 6 creates a separate channel for each of its webapps that are marked as <distributable/> when mode=distribution. The reason is outlined in https://issues.jboss.org/browse/ISPN-658. This is a problem if we have for example a stack called "relay" (and in infinispan-configs.xml the "web" configuration refers to "relay"), and the transport is shared (singleton_name is set):
- webapp web.war is deployed
- A channel for web.war is created by Infinispan
- The channel creates the shared transport and RELAY establishes the TCP bridge cluster as first member
- Webapp SessionDemo.war is deployed
- A new channel is created. The shared transport is not initialized again, as it already was for web.war
- However, RELAY joins the TCP bridge cluster and thus is in the same cluster as web.war !
==> However, both subclusters are named the same ! This leads to issues
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (JGRP-1053) UNICAST: set retransmission timeout based on actual retransmission times
by Bela Ban (JIRA)
UNICAST: set retransmission timeout based on actual retransmission times
------------------------------------------------------------------------
Key: JGRP-1053
URL: https://jira.jboss.org/jira/browse/JGRP-1053
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 2.9
UNICAST needs to compute a rolling average of retransmission times, per sender (AckSenderWindow).
The retransmission timeout per sender can then be set based on the actual average retransmission times. The advantage is that we throttle retransmission when we have a lot of message loss, and speed it up again when there are no message drops.
The function to set the timeout should always compute the new timeot value based on (1) the old value times a decay factor and (2) a new value.
The average should go up relatively quickly if the actual retransmission values go up, but come down slowly when the actual values go down.
A potential function is shown below:
static final double SLOW_DECAY_FACTOR=0.9, FAST_DECAY_FACTOR=0.7;
static final double FAST_UP= 1 / FAST_DECAY_FACTOR, SLOW_UP= 1 / SLOW_DECAY_FACTOR;
static final double SAFETY_BUFFER=0.3;
static double avg=200;
public static void main(String[] args) {
final long[] times={200,200,400,400,500,500,500,500,500,100,100,100,100,100,100,100,100,100,100,100,100,100};
// final long[] times={200,200,200,200,200,200,200,200,200,200,200};
for(Long val: times) {
double result=avg(val);
System.out.println(val + ": " + result);
}
}
private static double avg(long val) {
double decay, up;
if(val > avg) {
decay=FAST_DECAY_FACTOR;
up=FAST_UP;
}
else {
decay=SLOW_DECAY_FACTOR;
up=SLOW_UP;
}
double old_val=avg * decay;
double result=(old_val + val * up) / 2;
avg=result;
return result * (1 + SAFETY_BUFFER);
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months