[JBoss JIRA] (AS7-5311) Deployment of multiple .rar's with ironjacamar.xml
by Jesper Pedersen (JIRA)
Jesper Pedersen created AS7-5311:
------------------------------------
Summary: Deployment of multiple .rar's with ironjacamar.xml
Key: AS7-5311
URL: https://issues.jboss.org/browse/AS7-5311
Project: Application Server 7
Issue Type: Bug
Components: JCA
Affects Versions: 7.1.2.Final (EAP)
Reporter: Jesper Pedersen
Assignee: Stefano Maestri
Priority: Critical
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
Deploying an .ear with multiple .rar's, which all have an ironjacamar.xml file results in
{noformat}
11:17:24,899 ERROR [org.jboss.msc.service] (MSC service thread 1-14) MSC000002: Invocation of listener "org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1@16c5f7e" failed: java.lang.IllegalArgumentException: JBAS014809: Ein Knoten ist bereits registriert unter '(deployment => *)(subdeployment => *)(subsystem => resource-adapters)(ironjacamar => ironjacamar)'
at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:108) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:68) [jboss-as-controller-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.connector.subsystems.resourceadapters.IronJacamarRegistrator.invoke(IronJacamarRegistrator.java:33) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.connector.deployers.ra.processors.ParsedRaDeploymentProcessor$1.registerIronjacamar(ParsedRaDeploymentProcessor.java:158) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.as.connector.deployers.ra.processors.AbstractResourceAdapterDeploymentServiceListener.transition(AbstractResourceAdapterDeploymentServiceListener.java:131) [jboss-as-connector-7.1.2.Final-redhat-1.jar:7.1.2.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1416) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl.access$2700(ServiceControllerImpl.java:49) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:1954) [jboss-msc-1.0.2.GA-redhat-1.jar:1.0.2.GA-redhat-1]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_31]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_31]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_31]
{noformat}
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5912) CLONE - MSC controller hangs when loading an ear with multiple persistence units on a single CPU core machine
by Brad Maxwell (JIRA)
Brad Maxwell created AS7-5912:
---------------------------------
Summary: CLONE - MSC controller hangs when loading an ear with multiple persistence units on a single CPU core machine
Key: AS7-5912
URL: https://issues.jboss.org/browse/AS7-5912
Project: Application Server 7
Issue Type: Bug
Components: JPA / Hibernate
Affects Versions: 7.1.1.Final
Environment: Centos 6, single core lib-virt VM
Reporter: Brad Maxwell
Assignee: Scott Marlow
Fix For: 7.1.3.Final (EAP), 7.2.0.Alpha1
Attachments: hungas7.txt
When deploying an EAR with two persistence units on single core machines, the server hangs.
When increasing the number of cores to two, the same server just works.
I traced the bug to the method in org.jboss.as.naming.WritableServiceBasedNamingStore.unbind
The container attempts to register "hibernate/SessionFactory" twice.
The first time it works, the second time it hangs on the wait statement.
I suspect a race condition in the ServiceControllerImpl.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-5888) Errors accessing CMR from ejbStore of the CMP EntityBean (EJB 2.1 spec)
by Kamesh Marellapudi (JIRA)
Kamesh Marellapudi created AS7-5888:
---------------------------------------
Summary: Errors accessing CMR from ejbStore of the CMP EntityBean (EJB 2.1 spec)
Key: AS7-5888
URL: https://issues.jboss.org/browse/AS7-5888
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Environment: Windows
Reporter: Kamesh Marellapudi
Background :: We are trying to upgrade our app from JBoss 4.0.1Sp3 to Jboss 7.1.1-Final. We have a lot of entity beans based on EJB 2.1 spec. We are noticing the following when we run our application on Jboss 7.1.1-Final. We did NOT have these issues on Jboss 4.0.1.
Issue :: : ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
What I found?
1. In our application we access CMRs of an entity bean from the ejbStore of the same entity bean.
2. ejbStore is invoked from the beforeCompletion of EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.
3. During the invocation of CMR on the entity bean the call gets delegated to JDBCCMRFieldBridge.getrelationSet(). In this method we have
the following
try {
// get the current transaction
CmpEntityBeanComponent component = getJDBCStoreManager().getComponent();
TransactionManager tm = component.getTransactionManager();
Transaction tx = tm.getTransaction();
// if whe have a valid transaction...
if (tx != null && (tx.getStatus() == Status.STATUS_ACTIVE || tx.getStatus() == Status.STATUS_PREPARING)) {
// crete the relation set and register for a tx callback
relationSet = new RelationSet(JDBCCMRFieldBridge.this, ctx, setHandle, false);
TxSynchronization sync = new TxSynchronization(FieldState.this);
tx.registerSynchronization(sync);
} else {
// if there is no transaction create a pre-failed list
relationSet = new RelationSet(JDBCCMRFieldBridge.this, ctx, new List[1], false);
}
return relationSet;
} catch (SystemException e) {
throw MESSAGES.errorCreatingRelationSet(e);
} catch (RollbackException e) {
throw MESSAGES.errorCreatingRelationSet(e);
}
So we are trying to register TxSynchronization from beforeCompletion of EntityBeanSynchronization.
4. Now in the TwoPhaseCoordinator.addSynchronization method we have the following piece of code
// disallow addition of Synchronizations that would appear
// earlier in sequence than any that has already been called
// during the pre-commmit phase. This generic support is required for
// JTA Synchronization ordering behaviour
if(sr instanceof Comparable && _currentRecord != null) {
Comparable c = (Comparable)sr;
if(c.compareTo(_currentRecord) != 1) {
return AddOutcome.AR_REJECTED;
}
}
and the SynchronizationImple.compareTo has the following
public int compareTo(Object object)
{
SynchronizationImple other = (SynchronizationImple)object;
if(this._isInterposed && (!other._isInterposed))
{
return 1;
}
else if((!this._isInterposed) && other._isInterposed)
{
return -1;
}
else if(this._theUid.equals(other._theUid))
{
return 0;
}
else
{
return this._theUid.lessThan(other._theUid) ? -1 : 1;
}
}
So basically what I understood is the TxSynchronization registration from ejbStore is a bit too late because we are already in the beforeCompletion of one of the synchronizations listed in the transaction unless its registered through TransactionSynchronizationRegistry.registerInterposedSynchronization.
Here is the full stacktrace
Caused by: javax.transaction.RollbackException: ARJUNA016053: Could not commit transaction.
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1177) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:117) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:75)
at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.afterDelivery(MessageEndpointInvocationHandler.java:72)
... 16 more
Caused by: javax.ejb.EJBException: javax.ejb.TransactionRolledbackLocalException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
at org.jboss.as.cmp.component.CmpEntityBeanComponentInstance.store(CmpEntityBeanComponentInstance.java:108)
at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanSynchronizationInterceptor$EntityBeanSynchronization.beforeCompletion(EntityBeanSynchronizationInterceptor.java:185)
at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:273) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:93) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:164) [jbossjts-4.16.2.Final.jar:]
at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1165) [jbossjts-4.16.2.Final.jar:]
... 19 more
Caused by: javax.ejb.TransactionRolledbackLocalException: ARJUNA016082: Synchronizations are not allowed! Transaction status isActionStatus.RUNNING
at org.jboss.as.ejb3.component.interceptors.EjbExceptionTransformingInterceptorFactories$2.processInvocation(EjbExceptionTransformingInterceptorFactories.java:93)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:32)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)
at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:173)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.entity.interceptors.EntityBeanPrimaryKeyInterceptor.processInvocation(EntityBeanPrimaryKeyInterceptor.java:52)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:72)
at com.taliantsoftware.policy.payrollreport.ejb.PayrollReportLocal$$$view1774.getPremiumPeriodCMR(Unknown Source)
at com.taliantsoftware.policy.payrollreport.ejb.PayrollReportBean.getContextRootId(PayrollReportBean.java:491)
at insureworx.ejbservices.history.ejb.JDBCHistoryHandler.createActivityDetail(JDBCHistoryHandler.java:628)
at insureworx.ejbservices.history.ejb.JDBCHistoryHandler.createActivity(JDBCHistoryHandler.java:430)
at insureworx.ejbservices.history.ejb.JDBCHistoryHandler.expireOldHistoryAndCreateNewHistory(JDBCHistoryHandler.java:390)
at insureworx.ejbservices.history.ejb.HistoryCapableJDBCEntityBean.expireOldHistoryAndCreateNewHistory(HistoryCapableJDBCEntityBean.java:67)
at insureworx.ejbservices.history.ejb.HistoryCapableJDBCEntityBean.registerForHistory(HistoryCapableJDBCEntityBean.java:253)
at insureworx.ejbservices.history.ejb.HistoryCapableJDBCEntityBean.ejbStore(HistoryCapableJDBCEntityBean.java:159)
at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source) [:1.7.0_09]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_09]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_09]
at org.jboss.as.ejb3.component.InvokeMethodOnTargetInterceptor.processInvocation(InvokeMethodOnTargetInterceptor.java:57)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ejb3.component.entity.EntityBeanComponentInstance.invokeEjbStore(EntityBeanComponentInstance.java:163)
at org.jboss.as.cmp.component.CmpEntityBeanComponentInstance.store(CmpEntityBeanComponentInstance.java:97)
... 25 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
11 years, 7 months
[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
11 years, 7 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
11 years, 7 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
11 years, 7 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
11 years, 7 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
11 years, 7 months