[JBoss JIRA] (JGRP-1538) FILE_PING.readAll too verbose
by Jesse Glick (JIRA)
Jesse Glick created JGRP-1538:
---------------------------------
Summary: FILE_PING.readAll too verbose
Key: JGRP-1538
URL: https://issues.jboss.org/browse/JGRP-1538
Project: JGroups
Issue Type: Bug
Reporter: Jesse Glick
Assignee: Bela Ban
Priority: Minor
{{log.info("reading all : " + clustername);}} may be called every minute or more (depending on configuration) and prints this not terribly interesting message even if there is only one participant in the cluster and nothing whatsoever is happening. Would be better to log at debug level I think.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5911) Statefull session beans are not (always) properly destroyed/disposed
by Martin Centner (JIRA)
Martin Centner created AS7-5911:
-----------------------------------
Summary: Statefull session beans are not (always) properly destroyed/disposed
Key: AS7-5911
URL: https://issues.jboss.org/browse/AS7-5911
Project: Application Server 7
Issue Type: Bug
Components: CDI / Weld, EE
Affects Versions: 7.1.0.Final
Reporter: Martin Centner
Assignee: Stuart Douglas
Statefull session beans are not always properly disposed when undeploying the application or stopping the application server.
To reproduce this I've created the following (Arquillian) test.
It contains a simple Java bean:
@Typed
public class TestBean {
private String message;
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
A corresponding producer:
public class TestBeanProducer {
private final Logger log = LoggerFactory.getLogger(getClass());
@Produces
public TestBean produceTestBean() {
log.info("produceTestBean()");
TestBean testBean = new TestBean();
testBean.setMessage("Hello World!");
return testBean;
}
public void disposeTestBean(@Disposes TestBean testBean) {
log.info("disposeTestBean()");
testBean.setMessage(null);
}
}
And finally the statefull session bean:
@Stateful
public class TestStatefullSessionBean {
private final Logger log = LoggerFactory.getLogger(getClass());
@Inject
transient TestBean testBean;
@PostConstruct
public void init() {
log.info("init()");
}
public void test() {
log.info(testBean.getMessage());
}
@PreDestroy
public void cleanUp() {
log.info("cleanUp()");
}
}
When I run this as Arquillian test in the container I get the following expected behavior:
21:13:13,668 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) JBAS015876: Starting deployment of "test.war"
21:13:14,083 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016002: Processing weld deployment test.war
21:13:14,084 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-2) JNDI bindings for session bean named TestStatefullSessionBean in deployment unit deployment "test.war" are as follows:
java:global/test/TestStatefullSessionBean!at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean
java:app/test/TestStatefullSessionBean!at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean
java:module/TestStatefullSessionBean!at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean
java:global/test/TestStatefullSessionBean
java:app/test/TestStatefullSessionBean
java:module/TestStatefullSessionBean
21:13:14,106 INFO [org.jboss.weld.deployer] (MSC service thread 1-3) JBAS016005: Starting Services for CDI deployment: test.war
21:13:14,118 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016008: Starting weld service for deployment test.war
21:13:14,216 INFO [org.jboss.web] (MSC service thread 1-4) JBAS018210: Registering web context: /test
21:13:14,232 INFO [org.jboss.as.server] (management-handler-thread - 11) JBAS018559: Deployed "test.war"
21:13:14,872 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (http--0.0.0.0-8080-1) produceTestBean()
21:13:14,873 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (http--0.0.0.0-8080-1) init()
21:13:14,881 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (http--0.0.0.0-8080-1) Hello World!
21:13:14,884 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (http--0.0.0.0-8080-1) cleanUp()
21:13:14,884 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (http--0.0.0.0-8080-1) disposeTestBean()
21:13:14,918 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) JBAS016009: Stopping weld service for deployment test.war
21:13:14,939 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment test.war in 26ms
21:13:14,951 INFO [org.jboss.as.repository] (management-handler-thread - 12) JBAS014901: Content removed from location /Users/mcentner/java/jboss-as-7.1.1.Final/standalone/data/content/5b/20bd9c42eb5e656c3f2b396125de45636a0b8a/content
21:13:14,952 INFO [org.jboss.as.server] (management-handler-thread - 12) JBAS018558: Undeployed "test.war"
However, when I deploy the "test.war" ...
21:31:24,792 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starting deployment of "test.war"
21:31:24,830 INFO [org.jboss.weld.deployer] (MSC service thread 1-8) JBAS016002: Processing weld deployment test.war
21:31:24,831 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-8) JNDI bindings for session bean named TestStatefullSessionBean in deployment unit deployment "test.war" are as follows:
java:global/test/TestStatefullSessionBean!at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean
java:app/test/TestStatefullSessionBean!at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean
java:module/TestStatefullSessionBean!at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean
java:global/test/TestStatefullSessionBean
java:app/test/TestStatefullSessionBean
java:module/TestStatefullSessionBean
21:31:24,858 INFO [org.jboss.weld.deployer] (MSC service thread 1-1) JBAS016005: Starting Services for CDI deployment: test.war
21:31:24,869 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) JBAS016008: Starting weld service for deployment test.war
21:31:24,929 INFO [org.jboss.web] (MSC service thread 1-8) JBAS018210: Registering web context: /test
21:31:24,941 INFO [org.jboss.as.server] (HttpManagementService-threads - 3) JBAS018559: Deployed "test.war"
... and click around in the JBoss AS7 Console (section "Naming") ...
21:43:01,763 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,764 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,766 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,767 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,769 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,770 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,771 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,772 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,778 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,778 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,781 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,781 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,782 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,782 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,784 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,784 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,784 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,785 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,786 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 4) produceTestBean()
21:43:01,787 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 4) init()
21:43:01,792 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,793 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,795 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,796 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,803 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,804 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,805 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,806 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,808 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,809 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
21:43:01,812 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestBeanProducer] (HttpManagementService-threads - 5) produceTestBean()
21:43:01,813 INFO [at.gv.stmk.zza2.test.jboss.jcr.TestStatefullSessionBean] (HttpManagementService-threads - 5) init()
... a number of instances of the TestBean are produced. When "test.war" is now undeployed (through the console) ...
21:45:48,745 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) JBAS016009: Stopping weld service for deployment test.war
21:45:48,755 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment test.war in 15ms
21:45:48,763 INFO [org.jboss.as.server] (HttpManagementService-threads - 6) JBAS018558: Undeployed "test.war"
... none of the generated instances is being destroyed / disposed.
In our real use case this prevents us from a clean shut down of a Java Content Repository.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5858) JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
by Bob Bennett (JIRA)
Bob Bennett created AS7-5858:
--------------------------------
Summary: JBOSS 7.1.1.Final hangs on z/OS with new JDK maintenance
Key: AS7-5858
URL: https://issues.jboss.org/browse/AS7-5858
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.1.Final
Environment: operating system - z/OS version 1.13
JDK version info:
java version "1.7.0"
Java(TM) SE Runtime Environment (build pmz6470sr2-20120901_01(SR2))
IBM J9 VM (build 2.6, JRE 1.7.0 z/OS s390x-64 20120809_118929 (JIT enabled, AOT enabled)
J9VM - R26_Java726_SR2_20120809_0948_B118929
JIT - r11.b01_20120808_24925
GC - R26_Java726_SR2_20120809_0948_B118929
J9CL - 20120809_118929)
JCL - 20120831_02 based on Oracle 7u3-b05
Reporter: Bob Bennett
Assignee: Jason Greene
When I install the jboss-as-7.1.1.Final on a z/OS system with the newest JDK, and start the standalone server, it gets stuck and never completes initialization. It also does not respond to kill, and requires kill -9 to terminate. I have javacore from the hang. I opened an issue with IBM support, and here is their response:
Hi Bob,
Have you contacted JBoss support for this issue?
>From my review of the javacore, every application-related thread is
waiting on some kind of internal state monitoring code. The most
prominent cause of waiting appears to be a CountdownLatch used in:
org/jboss/as/controller/ParallelBootOperationStepHandler
$ParallelBootTransactionControl.operationPrepared
A quick search found this possibly related JBoss bug which was
introduced because of incompatibilities with Java 7 (although it would appear to have been fixed before your current build, but I'm not certain
how.) https://issues.jboss.org/browse/AS7-2940?_sscc=t
The CountdownLatch is one of the Concurrency classes, and is very
simplistic in that it allows an application to direct threads to wait
until some certain number of actions have occured. The application code
(JBoss in this case) would need to explain how many countdowns are
required and which piece of code decrements the counter as needed.
There's not much to say from a JVM perspective other than the threads
are all waiting for an application-level event (a call to the
"countDown()" method 'N' times where 'N' is how many JBoss initialized
the CountDownLatch to originally.)
If the JBoss team believes there is a specific thread not processing for one reason or another, we could look at that from a JVM perspective to see why. Unfortunately we'd need the JBoss team to explain which thread
they think should be executing and why. A system dump of the problem
(taken using signal 3, or from the operator console) would potentially allow for the internal state variables associated here to be read out...
but that won't really be of any use if we don't know what JBoss expects
them to be.
Regards,
Java Defect Support
Please let me know if you need more info, either from myself or IBM JDK support.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5910) Welcome-file should rerfer to servlet mapping
by Brian Leathem (JIRA)
Brian Leathem created AS7-5910:
----------------------------------
Summary: Welcome-file should rerfer to servlet mapping
Key: AS7-5910
URL: https://issues.jboss.org/browse/AS7-5910
Project: Application Server 7
Issue Type: Bug
Components: Web
Affects Versions: 7.1.1.Final
Reporter: Brian Leathem
Assignee: Remy Maucherat
Welcome files that correspond to a servlet-mapping are ignored. As an example, add a welcome file "index.jsf" and map "*.jsf" to the faces servlet. The welcome file will not be served when navigating to the folder.
This is not in accordance with the Servlet 3.0 specification (Section 10.10):
{quote}
... the Web server MUST again append each welcome file in the order specified in the deployment descriptor to the partial request and check if a servlet is mapped to that request URI.
{quote}
As an example of this in practice, refer to one of the many stackoverflow questions on the subject:
http://stackoverflow.com/questions/4616493/how-to-set-jsf2-welcome-file-w...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-3681) JBoss crashes when run with AspectJ java agent
by Jack Lund (JIRA)
Jack Lund created AS7-3681:
------------------------------
Summary: JBoss crashes when run with AspectJ java agent
Key: AS7-3681
URL: https://issues.jboss.org/browse/AS7-3681
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.0.CR1b, 7.0.2.Final
Environment: OS X 10.7.2, Ubuntu 11.10
Reporter: Jack Lund
Assignee: Jason Greene
Priority: Blocker
When trying to start JBoss with the AspectJ java agent (-javaagent:/path/aspectjweaver.jar) to enable load-time weaving, JBoss crashes with the following stack trace in the logs:
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/jack/jboss-as-7.1.0.CR1b
JAVA: java
JAVA_OPTS: -server -javaagent:/home/jack/aspectjweaver.jar -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
=========================================================================
WARNING: Failed to load the specified logmodule org.jboss.logmanager:main
Exception in thread "main" java.lang.ExceptionInInitializerError
at org.jboss.as.server.Main.main(Main.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.jboss.modules.Module.run(Module.java:248)
at org.jboss.modules.Main.main(Main.java:313)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
at org.jboss.logmanager.Logger.getLogger(Logger.java:60)
at org.jboss.logmanager.log4j.BridgeRepositorySelector.<clinit>(BridgeRepositorySelector.java:42)
... 7 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (JASSIST-176) I get a NPE in TypeData
by John Bainbridge (JIRA)
John Bainbridge created JASSIST-176:
---------------------------------------
Summary: I get a NPE in TypeData
Key: JASSIST-176
URL: https://issues.jboss.org/browse/JASSIST-176
Project: Javassist
Issue Type: Bug
Affects Versions: 3.17.0-GA
Environment: Java 7
Reporter: John Bainbridge
Assignee: Shigeru Chiba
This kills my JVM. I'm looking at trying to make simple test case. It appears to be releated to JASSIST-175
caused by: java.lang.NullPointerException
at javassist.bytecode.stackmap.TypeData.commonSuperClassEx(TypeData.java:400)
at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes2(TypeData.java:342)
at javassist.bytecode.stackmap.TypeData$TypeVar.fixTypes(TypeData.java:325)
at javassist.bytecode.stackmap.TypeData$TypeVar.dfs(TypeData.java:270)
at javassist.bytecode.stackmap.MapMaker.fixTypes(MapMaker.java:301)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:151)
at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:100)
at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:423)
at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:405)
at javassist.expr.ExprEditor.doit(ExprEditor.java:113)
at javassist.CtClassType.instrument(CtClassType.java:1398)
at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:75)
at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
... 27 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months