[JBoss JIRA] (WFLY-2261) standalone.sh --debug without port number not working
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2261?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2261:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1072227|https://bugzilla.redhat.com/show_bug.cgi?id=1072227] from MODIFIED to ON_QA
> standalone.sh --debug without port number not working
> ------------------------------------------------------
>
> Key: WFLY-2261
> URL: https://issues.jboss.org/browse/WFLY-2261
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Reporter: Cheng Fang
> Assignee: Jeff Mesnil
> Fix For: 8.1.0.CR1
>
>
> ./standalone.sh --debug port-num works, but it failed when omitting port number.
> sh -x standalone.sh --debug (expecting the default port 8787 to be used)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ' ""'
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone ''
> Listening for transport dt_socket at address: 8787
> 12:19:36,715 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:19:36,886 ERROR [stderr] (main) JBAS015801: Invalid option ''
> 12:19:36,893 INFO [stdout] (main)
> 12:19:36,893 INFO [stdout] (main) Usage: standalone.sh [args...]
> {noformat}
> sh -x standalone.sh --debug 8787 (the working command)
> {noformat}
> + eval '"/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java"' '-D"[Standalone]"' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n '"-Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log"' '"-Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties"' -jar '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar"' -mp '"/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules"' org.jboss.as.standalone '-Djboss.home.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT"' '-Djboss.server.base.dir="/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone"' ''
> ++ /Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk/Contents/Home/bin/java '-D[Standalone]' -server -XX:+UseCompressedOops -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/log/server.log -Dlogging.configuration=file:/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone/configuration/logging.properties -jar /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/jboss-modules.jar -mp /Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/modules org.jboss.as.standalone -Djboss.home.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT -Djboss.server.base.dir=/Users/cfang/dev/wildfly/build/target/wildfly-8.0.0.Beta2-SNAPSHOT/standalone
> Listening for transport dt_socket at address: 8787
> 12:20:39,251 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final
> 12:20:39,626 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.0.Beta2
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1159:
------------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1082775|https://bugzilla.redhat.com/show_bug.cgi?id=1082775] from MODIFIED to ON_QA
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-1547) deploy directories not cleaned up
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1547?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1547:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1078665|https://bugzilla.redhat.com/show_bug.cgi?id=1078665] from MODIFIED to ON_QA
> deploy directories not cleaned up
> ---------------------------------
>
> Key: WFLY-1547
> URL: https://issues.jboss.org/browse/WFLY-1547
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Alpha1
> Reporter: Shaun Appleton
> Assignee: jaikiran pai
> Fix For: 8.0.0.Beta1
>
> Attachments: deployment_with_hack_no_hook.txt
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-3220) ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3220?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3220:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1084872|https://bugzilla.redhat.com/show_bug.cgi?id=1084872] from MODIFIED to ON_QA
> ARJUNA016009 ArrayIndexOutOfBoundsException during periodic recovery on EJBTransactionRecoveryService
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3220
> URL: https://issues.jboss.org/browse/WFLY-3220
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Masafumi Miura
> Assignee: Masafumi Miura
> Fix For: 8.1.0.CR1
>
> Attachments: WFLY-3220-byteman-script.btm
>
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1035216 is also reproducible in wildfly.
> {code}
> WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016009: Caught:: java.lang.ArrayIndexOutOfBoundsException: 0
> at org.jboss.as.ejb3.remote.EJBTransactionRecoveryService.getXAResources(EJBTransactionRecoveryService.java:114)
> at com.arjuna.ats.internal.jbossatx.jta.XAResourceRecoveryHelperWrapper.getXAResources(XAResourceRecoveryHelperWrapper.java:51) [narayana-jts-integration-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.resourceInitiatedRecoveryForRecoveryHelpers(XARecoveryModule.java:516) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:182) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:743) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:371) [narayana-jts-jacorb-5.0.0.Final.jar:5.0.0.Final (revision: 9aa71)]
> {code}
> I think the line 111 "new XAResource\[receiverContexts.size()\]" should be placed inside synchronized block.
> {code:java|title=ejb3/src/main/java/org/jboss/as/ejb3/remote/EJBTransactionRecoveryService.java}
> 109 @Override
> 110 public XAResource[] getXAResources() {
> 111 final XAResource[] xaResources = new XAResource[receiverContexts.size()];
> 112 synchronized (receiverContexts) {
> 113 for (int i = 0; i < receiverContexts.size(); i++) {
> 114 xaResources[i] = EJBClientManagedTransactionContext.getEJBXAResourceForRecovery(receiverContexts.get(i), arjunaTxCoreEnvironmentBean.getValue().getNodeIdentifier());
> 115 }
> 116 }
> 117 return xaResources;
> 118 }
> ...
> 124 @Override
> 125 public void receiverRegistered(final EJBReceiverContext receiverContext) {
> 126 this.receiverContexts.add(receiverContext);
> 127 }
> {code}
> I think this "java.lang.ArrayIndexOutOfBoundsException: 0" will happen in the following scenario:
> # receiverContexts.size() = 0 at the line 111
> xaResources is created with new XAResource\[0\]
> # receiverRegistered method is called from other thread between the line 111 and 112
> Now receiverContexts.size() = 1
> # As receiverContexts.size() = 1, for-loop is executed
> Then "xaResources\[0\] = ..." will get ArrayIndexOutOfBoundsException at the line 114 because xaResources is empty array.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JBJCA-1159) ConnectionListener leaked if TSR throws IllegalStateException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1159?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1159:
------------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from MODIFIED to ON_QA
> ConnectionListener leaked if TSR throws IllegalStateException
> -------------------------------------------------------------
>
> Key: JBJCA-1159
> URL: https://issues.jboss.org/browse/JBJCA-1159
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.24.Final, 1.1.4.Final
> Environment: AS7 EAP6.1
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.25.Final, 1.1.5.Final, 1.2.0.Beta1
>
>
> When a connection is retrieved from the MCP, ironjacamar will register it to ongoing JTA transaction. However, if the ongoing TX is not 'active' anymore the connection is lost.
> The code of AbstractPool demonstrates the problem. The call to getLock will throw an exception if the current TX is not active anymore and the cl is not returned to the pool.
> This issue can be reproduced on AS7 by using any EJB that requires a tx and does something with a DB connection. Put a breakpoint in the code below after retrieving the connectionlistener, and then wait for the transaction to timeout. Once that's done, continue the thread. The connection is not release (can be seen in JMX)
> We have noticed this problem regularly during our performance tests.
> {code}
> ConnectionListener cl = mcp.getConnection(subject, cri);
> if (trace)
> log.tracef("Got connection from pool tracked by transaction=%s tx=%s", cl, trackByTransaction);
> TransactionSynchronizationRegistry tsr = getTransactionSynchronizationRegistry();
> Lock lock = getLock();
> try
> {
> lock.lockInterruptibly();
> }
> catch (InterruptedException ie)
> {
> Thread.interrupted();
> throw new ResourceException(bundle.unableObtainLock(), ie);
> }
> {code}
> It seems this issue was introduced by changes done for https://issues.jboss.org/browse/JBJCA-572
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JBJCA-1110) Pool statistics are not cleared
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1110?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1110:
------------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from MODIFIED to ON_QA
> Pool statistics are not cleared
> -------------------------------
>
> Key: JBJCA-1110
> URL: https://issues.jboss.org/browse/JBJCA-1110
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.19.Final
> Reporter: Koen Janssens
> Assignee: Jesper Pedersen
> Fix For: 1.1.2.Final
>
>
> Invoking the 'clear statistics' JMX method on a connection pool has no effect.
> Quite annoying since it forces me to restart to get a useful value for the 'average' values such as 'averageblockingtime'
> Better implement the method or don't provide a clear method at all.
> Today, org.jboss.jca.core.connectionmanager.pool.mcp.ManagedConnectionPoolStatisticsImpl#clear is a no-op...
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (JBJCA-1161) NPE in SemaphoreArrayListManagedConnectionPool
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1161?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1161:
------------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1088469|https://bugzilla.redhat.com/show_bug.cgi?id=1088469] from MODIFIED to ON_QA
> NPE in SemaphoreArrayListManagedConnectionPool
> ----------------------------------------------
>
> Key: JBJCA-1161
> URL: https://issues.jboss.org/browse/JBJCA-1161
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.25.Final
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.26.Final
>
>
> {noformat}
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:866)
> at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:312)
> at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:404)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months
[JBoss JIRA] (WFLY-2920) StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-2920?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-2920:
-----------------------------------------------
Vaclav Tunka <vtunka(a)redhat.com> changed the Status of [bug 1072747|https://bugzilla.redhat.com/show_bug.cgi?id=1072747] from MODIFIED to ON_QA
> StackOverflowError when org.jboss.as.jacorb.rmi.InterfaceAnalysis is analyzing javax.ejb.EJBObject
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-2920
> URL: https://issues.jboss.org/browse/WFLY-2920
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: IIOP
> Affects Versions: 8.0.0.Final
> Reporter: Osamu Nagano
> Assignee: Stuart Douglas
> Fix For: 8.1.0.CR1
>
> Attachments: td.dump
>
>
> Depending on when a thread context switch happens, an IIOP enabled EJB fails to be deployed by throwing {{java.lang.StackOverflowError}}. Here is the stack trace from the attached thread dump.
> {code}
> "MSC service thread 1-7" prio=10 tid=0x00007f52e8001800 nid=0x4d12 at breakpoint[0x00007f534093f000]
> java.lang.Thread.State: RUNNABLE
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
> at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> at org.jboss.as.jacorb.rmi.OperationAnalysis.<init>(OperationAnalysis.java:91)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.analyzeOperations(InterfaceAnalysis.java:116)
> at org.jboss.as.jacorb.rmi.ContainerAnalysis.doAnalyze(ContainerAnalysis.java:186)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.doAnalyze(InterfaceAnalysis.java:62)
> at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> ...
> at org.jboss.as.jacorb.rmi.WorkCacheManager.doTheWork(WorkCacheManager.java:177)
> at org.jboss.as.jacorb.rmi.WorkCacheManager.getAnalysis(WorkCacheManager.java:105)
> at org.jboss.as.jacorb.rmi.InterfaceAnalysis.getInterfaceAnalysis(InterfaceAnalysis.java:53)
> at org.jboss.as.jacorb.rmi.Util.getTypeIDLName(Util.java:104)
> at org.jboss.as.jacorb.rmi.ParameterAnalysis.<init>(ParameterAnalysis.java:50)
> Locked ownable synchronizers:
> - <0x00000000f9698790> (a java.util.concurrent.ThreadPoolExecutor$Worker)
> {code}
> The last part including {{Util.getTypeIDLName}} has been repeated as many as possible and the bottom of the stack has been lost. The same stack has been appeared in a different MSC service thread which is also executing an IIOP enabled EJB deployment.
> The customer identified an improper synchronization in {{org.jboss.as.jacorb.rmi.WorkCacheManager#getAnalysis()}}. It is reproducible by manually controlling a thread context switch using a debugger.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
12 years, 2 months